Re: Access to CVS

[Aaron Schrab <aaron@schrab.com>]

At 07:37 -0800 13 Dec 2012, Bart Schaefer <schaefer@brasslantern.com> wrote:
>On Dec 13,  1:58pm, Oliver Kiddle wrote:
>}
>} +* Do not merge your private feature branches onto the master branch: a
>} +  linear history without merge commits is simpler to follow (and to
>} +  bisect). Both "git cherry-pick" and "git merge --ff-only" can be used
>} +  bring changes over to another branch without a merge commit.
>
>Is there any way to actually enforce this?

If the main git repository were fully under our control, yes, a hook 
could be setup there to reject pushes which introduce merge commits.  
Unfortunately, I'm not aware of any of the free git hosting sites which 
allow that type of policy to be configured for repositories that they 
host, although I haven't really looked into that.

>How does one "recover" from an accidental merge commit?

If that were to happen, we'd either need to live with it or rewrite 
published history.  I think just allowing it to stay in would be the 
better option, having an occasional merge in the history shouldn't 
introduce much confusion an is better than dealing with the mess of 
altering commits that were already made public.

If the accidental merge is discovered before it has been pushed, or any 
other changes have been made to the target branch the merge can be 
backed out simply by using:

  git reset --hard HEAD~

To reset the branch and working tree to the state before the merge, 
allowing another try at merging the changes without creating a merge 
commit.  This would also blow away any uncommitted changes, although 
those could be safely saved away using `git stash` before doing the 
reset and then recovered later with `git stash pop`.