[Nix-dev] Re: DVCS - what we care about?

[Peter Simons]

Hi Yury,

 > I don't say "git throws away history" but let me give you example of
 > lost information.
 >
 > <initial commit>
 > git co -b stdenv
 > git ci <-- commit A
 > git co master
 > git ci <-- commit B
 > git co stdenv; git merge master <-- commit C
 > git co master; git merge stdenv <-- (fast-forward) commit C
 >
 > Now "master" and "stdenv" point to the same vertex, and you can't
 > easily search for commits made in "stdenv" (i.e. A) versus commits
 > made in "master" (i.e. B).

 $ git init
 $ echo -e '#!/bin/sh\n\ngit-notes add -m "Committed to $(cat $GIT_DIR/HEAD)"' >.git/hooks/post-commit
 $ chmod +x .git/hooks/post-commit
 $ for n in {foo,bar,foobar}.txt; do echo yo >$n; done
 $ git add foo.txt
 $ git commit -m 'initial'
 $ git checkout -b stdenv
 $ git add bar.txt
 $ git commit -m 'commit a'
 $ git checkout master
 $ git add foobar.txt
 $ git commit -m 'commit b'
 $ git checkout stdenv
 $ git merge master
 $ git checkout master
 $ git merge stdenv
 $ git log
 commit 48719791c15bffb38375536b10353167e52bc227
 Merge: e210e3a a2035e6
 Author: Peter Simons <simons at cryp.to>
 Date:   Fri Aug 13 15:15:37 2010 +0200

     Merge branch 'master' into stdenv

 commit a2035e60590f729760831b371c8443b1f9889b82
 Author: Peter Simons <simons at cryp.to>
 Date:   Fri Aug 13 15:14:23 2010 +0200

     commit b

 Notes:
     Committed to ref: refs/heads/master

 commit e210e3a64b6a51e3078bd38578bbba6070f4be3f
 Author: Peter Simons <simons at cryp.to>
 Date:   Fri Aug 13 15:14:08 2010 +0200

     commit a

 Notes:
     Committed to ref: refs/heads/stdenv

 commit 370df5eca753a02788bfc99707322b6f0655f1a2
 Author: Peter Simons <simons at cryp.to>
 Date:   Fri Aug 13 15:13:51 2010 +0200

     initial

 Notes:
     Committed to ref: refs/heads/master


 >>> Never ever rebase a published branch.
 >>
 >> Frankly, if I had an interest in snappy one-liners, I'd be watching
 >> an Arnold Schwarzenegger movie instead of discussing software
 >> engineering.
 >
 > man git-rebase
 > /RECOVERING FROM UPSTREAM REBASE
 > (second match)

The manual pages discusses how to handle branches that prefer rebase
over merge. The mere fact that this section exists should be a strong
indication that people *do* rebase published branches. The reason why
people do that is because it is a good idea, it just so happens that
tracking these kind of branches is slightly more complicated than
tracking those branches that are merged. The use case I was referring to
is discussed in the section "The easy case". The man pages says,
basically, "rebase your branch relative to the origin". In practice,
this means running

  git config branch.your_branch_name_here.rebase true

once, and after that a simple "git pull" will do the trick. Arguably,
the consequences of this approach are more complex to understand than
merges are, but, personally, I believe that the additional complexity
pays off because the resulting history is so much clearer and nicer to
read.

Anyway, this is a matter of taste, and there are pros and cons for both
approaches. The good thing about Git is that is gives you a choice.

Take care,
Peter