Matthieu.Moy at grenoble-inp.fr
Sat Jul 23 04:22:10 PDT 2011
Andrew Trick <atrick at apple.com> writes:
> I would like to think that git generation numbers are sufficient for
> this so we don't need to resort to timestamps or tags.
This works only if you have a "trunk branch", in the sense that you know
exactly which sequence of commit is your "trunk". Git's designed is
really not trunk-oriented, Linus has worked very hard against this
concept while creating Git.
The closest you can get is
git log --first-parent
the first parent being the one on which the guy who did the merge were
before starting merging.
But, suppose we have this:
A---B <-- upstream version
C <-- me
Then, if I merge from upstream, I get
C---D <-- me
and D's first parent will be D. Then, if upstream merges from me, it
fast-forwards and you get
C---D <-- me, upstream
And B, which used to be a "mainline commit" is not one anymore. People
who used to say "commit with generation number 1 in upstream" were
refering to B, and the same sentence now refers to C.
Each problem has a solution, so if upstream had merged from me with
--no-ff, it would have got
A---B---E <-- upstream
\ \ /
C---D <-- me
With E having the same content as D, but different parents and commit
It's not the workflow promoted by Git, but it works, if you make sure
upstream always merges with --no-ff (that usually means making upstream
an automated bot, and not human being using "git push").
> Mercurial has local revision numbers for this purpose, which I thought
> were quite handy. Comments on that point are welcome.
The point with local revision numbers is that they are local. You can
never say "bug has been fixed in revision 1234" without saying which
repository you're talking about. Revision 1234 in my LLVM repository
wouldn't necessarily be the same as the one used by a buildbot or some
They're handy to work locally, but not as an identifier to use accross a
I tend to find them more confusing than helpfull, but that's a matter of
taste, and may be due to lack of experince with Mercurial ;-).
More information about the llvm-dev