Permalink
Browse files

Turning off syntax highlight until I can figure out a color blind fri…

…endly theme for pygment
  • Loading branch information...
1 parent e87b1cc commit a6643345f78bad42089d87365dbd09dbff6a6b5a Chris White committed Mar 25, 2013
View
38 :q!
@@ -0,0 +1,38 @@
+On git push --force
+===================
+Chris White<cwprogram@live.com>
+v1.0, Tue Feb 19 PST 2013
+
+== Introduction
+
+`git push --force` can be a pretty scary command to execute for some, as it should be. The worst case scenario is that history is rewritten on a remote repository, and people lose valuable work. It is also bypassing the integrity that git provides. To quote the `git push` man page:
+
+[source,text]
+----
+ -f, --force
+ Usually, the command refuses to update a remote ref that is not an ancestor of the local ref used to overwrite it.
+ This flag disables the check. This can cause the remote repository to lose commits; use it with care.
+----
+
+So what does it mean to "use it with care"? This article is meant to quickly list a few use cases where I consider `git push --force` to be reasonable to utilize.
+
+== Personal Code
+
+First would be repositories where the author has sole access to both local and remote repositories (self-hosted). The author may decide that a few commits produce a messy log and wish to clean them up with `git rebase` after having pushed them to a remote repository. They could also do something more simplistic with `git commit --amend` after again, having pushed to a remote repository. This can be either a complete mistake (typo in the commit message), or intentional after looking over a few commits later. In essence, it becomes more of a convenience for them.
+
+== Personal Code Forks
+
+Somewhat like personal code, but potentially available to other users to have access to the code. These are generally forks of other repositories in order to generate pull requests of some sort. Personally I have an exclusive fork of RVM that I use to make contributions to the project. In this case rebasing and amendments may be requested by upstream developers after they have had a chance to review contributions. This is popular process on code sharing sites such as GitHub to cleanup commits before they are integrated to a larger audience. Like personal code repositories, this is another case where history rewrites carry less risk, though it should be noted that users can at some point interact with the repository. In this case the developer should consider whether or not they want to affect that user's history. An example of this is having 10 users forking the personal code fork (stale upstream for example). In such cases I would recommend against using `git push --force`.
+
+== Emergencies *With Communication*
+
+Examples of what can be considered an emergency would be issues such as passwords and credit cards getting pushed. If it's something such as credit cards, the developer may have to bite the bullet and overwrite history, communicating to other users of the repository regarding the issue. This is much easier to deal with for internal repositories, but public facing repositories are a bigger pain. In cases of public repositories, you will have to deal with potential user fallout, as well as the fact that someone may have a copy of the repository backed up before the push happened. There is not a universal answer to this, and should be weighed on a case-per-case basis as with other emergencies. Just remember to communicate these changes so that users understand that the lack of integrity between local and remote repositories is intended and not unauthorized access.
+
+== Conclusion
+
+To conclude, here are some basic rules regarding using `git push --force`:
+
+* In general, don't push unless your local repository is in a state that should be pushed out to the repository to avoid these situations
+* If there are other users of the repository, don't do it, using `git revert` if really necessary (emergencies should be weighed accordingly)
+* For repositories with sole authors, there is less risk and `git push --force` is reasonable to utilize
+* When in doubt, communicate
@@ -14,7 +14,7 @@ WARNING: This article utilizes `git push --force` which I've link:/git/git-force
So right now there's a fix I made for a bug in RVM that I'm about to put in a pull request for. So now I'll fake a mistake and commit it:
-[source,console]
+[source,text]
----
$ vim scripts/cli
$ git add scripts/cli
@@ -36,7 +36,7 @@ Now it's not only committed, but also pushed to the remote repository (which is
The first order of business is reverting the mistake:
-[source,console]
+[source,text]
----
$ git revert 618f4398bfeea938a1b9878b9fcf419b94d85e6c
[ruby-reinstall 67b8cf6] Revert "This is a mistake"
@@ -71,7 +71,7 @@ Date: Tue Feb 19 19:54:54 2013 -0800
This would be annoying for the person on the other side of the pull request to review. That's where `git rebase` comes in handy. In this case `git rebase` will be started by what's called interactive mode. Interactive mode uses `$EDITOR` to handle history adjustments:
-[source,console]
+[source,text]
$ git rebase -i HEAD~3 # work with all commits starting from 3 commits up to HEAD
[source,text]
@@ -136,7 +136,7 @@ Fixed rvm reinstall/remove ruby not working properly. Addresses issue #1550.
This results in the final commit message:
-[source,console]
+[source,text]
----
$ git rebase -i HEAD~3
[detached HEAD b3d43f3] Fixed rvm reinstall/remove ruby not working properly. Addresses issue #1550.
@@ -165,7 +165,7 @@ That's it. Now all that's left is a single commit with a fixed commit message al
[NOTE]
As the remote server will question the edits for integrity purposes, `--force` *must* be used
-[source,console]
+[source,text]
----
$ git push origin ruby-reinstall --force
Counting objects: 7, done.
@@ -15,7 +15,7 @@ of the logic behind it.
A basic example of a method being called in a class is something like this:
-[source,python]
+[source,text]
----
#!/bin/python
@@ -49,7 +49,7 @@ is being passed in behind the scenes, as shown from `method_call` located in
`Objects/classobject.c` in the Python source tree. The code listing for
`method_call` is as follows:
-[source,c]
+[source,text]
----
static PyObject *
method_call(PyObject *func, PyObject *arg, PyObject *kw)
@@ -87,7 +87,7 @@ There's quite a bit of C code here, but only a few parts need to be focused
on. First the code attempts to get `self` by looking at what called the
method. If nothing comes back, Python throws an error:
-[source,c]
+[source,text]
----
PyObject *self = PyMethod_GET_SELF(func);
PyObject *result;
@@ -102,7 +102,7 @@ method. If nothing comes back, Python throws an error:
Next it resizes the argument array, adding one to the length in order to
accommodate `self` being passed in:
-[source,c]
+[source,text]
----
Py_ssize_t argcount = PyTuple_Size(arg);
PyObject *newarg = PyTuple_New(argcount + 1);
@@ -111,7 +111,7 @@ accommodate `self` being passed in:
Then it shifts in self as the first argument, adding the other arguments at
the end:
-[source,c]
+[source,text]
----
PyTuple_SET_ITEM(newarg, 0, self);
for (i = 0; i < argcount; i++) {
@@ -125,7 +125,7 @@ the end:
Finally the method is now called with self and the other arguments passed into
the method:
-[source,c]
+[source,text]
result = PyObject_Call((PyObject *)func, arg, kw);
NOTE: The references to *REF in the code is for Python's garbage collection system, which uses http://arctrix.com/nas/python/gc/[reference counting]
@@ -142,7 +142,7 @@ reasons given for why Python in particular decided to go with this system.
Take for example the following code:
-[source,python]
+[source,text]
----
class Person:
@@ -157,7 +157,7 @@ myself.setname("Chris", "White")
Now take away the `self`:
-[source,python]
+[source,text]
----
class Person:
@@ -175,7 +175,7 @@ referenced somewhere in the class later.
For an example of this:
-[source,python]
+[source,text]
----
#!/bin/python
@@ -94,7 +94,7 @@ Working at EngineYard I use a number of tools to help with various tasks. Of imp
Skype has a binary tampering system which prevents flagging some security protections off so it works properly. While this is rather unfortunate Skype is an essential business tool. With that in mind it takes a few steps to get it running:
-[source,console]
+[source,text]
----
# mkdir -p /etc/portage/package.unmask
# mkdir -p /etc/portage/package.license
@@ -111,7 +111,7 @@ After this and some headset setup Skype worked without a hitch and showed no iss
Same here with needing to disable protections. This was achieved through doing:
-[source,console]
+[source,text]
----
# emerge dropbox
# paxctl -c /opt/dropbox/dropbox
@@ -122,7 +122,7 @@ Same here with needing to disable protections. This was achieved through doing:
This needs to use the latest version to keep up with the Google download page:
-[source,console]
+[source,text]
----
# echo 'www-plugins/google-talkplugin' >> /etc/portage/package.keywords/googletalk
# echo '=www-plugins/google-talkplugin-3.13.2.0 Google-TOS' >> /etc/portage/package.license/googletalk
@@ -136,7 +136,7 @@ This was put off till the end in order to avoid dealing with too much trouble du
First is to logout of the system entirely for all users. In this case there was only one user. Also X11 based login managers such as gdm, kdm, and xdm will all need to be shutdown. Next, have a root screen up to handle the administrative tasks, and be sure it isn't in the `/home` directory somewhere. Now to create an encrypted location for `/home` to map to:
-[source,console]
+[source,text]
----
# mv /home /home.orig
# mkdir /home /home.enc
@@ -157,27 +157,29 @@ Please choose from one of the following options:
Here standard mode was selected by simply pressing enter. This provides a reasonable balance between security an performance for a desktop system. After selection of the security mode, a prompt will appear to set the key for encryption. Enter the password and remember, if you lose it your home data will no longer be accessible in plain form. It's recommended to back up the data to a tarball somewhere, and then use gpg encryption to secure it:
-[source,console]
+[source,text]
----
# tar cjpvf /backup/someplace/home-backup.tar.bz2 /home.orig
# gpg -c /backup/someplace/home-backup.tar.bz2
----
Later backups can be retrieved by running:
-[source,console]
+[source,text]
# gpg /backup/someplace/home-backup.tar.bz2.gpg
Which will prompt for the password used to protect the file, and decrypt if it was successfully entered. Now it's time to encrypt the home data by simply copying the old data to the new encrypted home:
-[source,console]
+[source,text]
----
# rsync -a --progress /home.orig/ /home/
----
+WARNING: You don't need to do this if you use a desktop login system like `xdm`
+
One final step for X11 users is to get around an issue with the Xauthority file not locking properly. The following snippet can be added to the user shell's rc file (`~/.bashrc` for example):
-[source,console]
+[source,text]
----
export XAUTHORITY=/tmp/.Xauthority-$USER
export ICEAUTHORITY=/tmp/.ICEauthority-$USER

0 comments on commit a664334

Please sign in to comment.