[LLVMdev] git

[Andrew Trick]

On Jul 22, 2011, at 12:29 AM, Matthieu Moy wrote:

> Andrew Trick <atrick at apple.com> writes:
> 
>> SVN revision numbers are central to my workflow. I use them to tag
>> results generated against various builds. I like those results sorted
>> by time and the chronology should be obvious,
> 
> This means in the presence of branches, you want the ordering to be
> 
> [branch A] build 1
> [branch B] build 2
> [branch A] build 3
> [branch C] build 4
> 
> ?
> 
> It seems to me that your solution works only if you have a very simple
> branch topology, where you can essentially consider branches in
> isolation. As soon as you consider non-trunk branches and merge commits
> to be important, the history is a DAG, and the problem is not that
> version numbers are not linear, but that the history itself is not.
> 
> Of course, if you've used SVN extensively, you've been trained to think
> that history has to be somewhat linear, and perhaps even that the trunk
> branch is the only one needing QA attention. Migration from SVN to Git
> is hard because you have to change the mental model, not just command
> names and how revisions are named.


You've mistaken me for someone who doesn't understand why DVCS is important. Please stop using this list to evangelize git.

My point is that we have QA and release engineering processes that work on each branch independently and work best with chronological build #s *per branch*.

I would like to think that git generation numbers are sufficient for this so we don't need to resort to timestamps or tags. Mercurial has local revision numbers for this purpose, which I thought were quite handy. Comments on that point are welcome.

-Andy