[Nix-dev] Re: new possible movement to git (?)

[Michael Raskin]

<4E5566E6.9050101 at shealevy.com> <4E576C9C.4010903 at shealevy.com>
<E1Qwubl-0003wO-00.7c6f434c-mail-ru at smtp15.mail.ru>)
Mime-Version: 1.0
Content-type: text/plain; charset="UTF-8"

>On Fri, Aug 26, 2011 at 13:36, Michael Raskin <7c6f434c at mail.ru> wrote:
>> With SVN I can easily look up which commits were initially done in
>> stdenv branch and which were done in trunk. Ditto with Mercurial. But
>> with git you seem to need some extra knowledge to do that after the
>> proposed move.
>I agree, but only If you use rebase.  git rebase is nice for local
>branches, but is a nightmare when you are working a large number of
>persons.

Any change in the history is a nightmare when you have more than 
one repository that had the original history. That's fine

>In git cherry-picks are not tracking the patch history.  Thus you
>cannot rely on cherry-pick with git as you do with subversion.
>
>The other mean is to use merges, which keep the history as it is.
>Thus you can see that this was a previous branch which has been merged
>into the master (trunk)

As far as I remember, you need to keep old branch head at the position
where it was merged for this to work. Unlike hg and monotone, commit
doesn't remember its branch per se and you cannot store the branch where
commit belongs automatically. This means that after conversion
we will lose data, because we have multiple merges of branch stdenv to
trunk. Also, if you have branches that later split in branches and are 
merged directly into master, you cannot automatically find out which
of the branches was created only during split. 

>Changing VCS also implies to change the workflow which is based on it.
> Having used git / hg / svn, I really love to be able to seek the
>history very fast, which is really slow in hg and svn.

Frankly, I tried multiple DVCSes (I used hg, bzr and mtn for a lot of time
and sent some patches to git-managed projects) and git makes most stress
on managing huge projects and least stress on having a nice straightforward
conceptual system that covers all operations (or on keeping all data it has
now in future).