git branch help?

[Peter Hutterer]

On Tue, Aug 03, 2010 at 08:49:14AM +0200, Kevin Kofler wrote:
> Peter Hutterer wrote:
> > I think this may be the main issue here - there is no meaning of "newer"
> > in git.
> 
> There is a partial order given by ancestry, and 2 revisions you want to 
> compare WILL in general be ordered. 

there is an order provided one revision is an ancestor of the other
revision. this is not always the case.

> (In fact, whenever it makes sense to 
> numerically compare SVN revision IDs, the commits will also be ordered in a 
> DVCS. Comparing revision IDs from different branches or even different 
> repositories does not make sense in SVN either, but that's not what people 
> are interested in anyway.)
> 
> > Don't rely on it an you'll be fine. What matters is whether a change is in
> > a repository or not. Which one is newer hardly ever matters.
> 
> Nonsense. If, say, Fedora ships foo-12345678 and Ubuntu ships
> foo-abcdef00, you'll want to know whether 12345678 or abcdef00 is the
> newer snapshot from the master of foo

which one is newer: Fedora's packaged version of X server 1.8 + backports
and distro-specific fixes or Ubuntu's packaged version of 1.8 + backports
and distro-specific fixes?
The concept of "newer" doesn't apply here because the branches diverge at
the common ancestor (server 1.8).

> (And if they're both snapshots from master, they WILL be 
> ordered unless upstream rewrote their published history, which is just plain 
> evil.) 

if they're both snapshots from master without any distro-specific patches,
git-describe will tell you exactly which one is newer.

whot at barra:~/xorg/xserver> git describe
xorg-server-1.8.99.905-8-g09a0ad9

so I'm 8 commits past the 1.8.99.905 tag. But again, this is only a
measurement for newer as long as one commit is a descendant of the other.

> Or, another use case, if we have foo-3.14-0.17.12345678git.fc12 and 
> foo-3.14-0.18.abcdef00git.fc13, how do you verify that the upgrade path is 
> correct and does not in fact downgrade foo when upgrading to F13? The 
> sequence number before (17 vs. 18) might have been incremented due to one or 
> more plain rebuild(s), it doesn't necessarily reflect the sequence of 
> upstream snapshots being packaged.

in the packages I co-maintain, we use the snapshot date as identifier, not
the commit. so you get e.g. xorg-x11-drv-wacom-0.10.8-1.20100803.fc12
the exact git commit is also noted in the fedora repo. So the version number
of the package only goes backwards if you freshly snapshot F12 but not F13.
This is not the ideal solution, but it does the job, we only update every
few days or weeks anyway (and even then mostly only in rawhide, not released
versions).

if you really want to get fancy, you can put the git-describe numbering in
there which should never go backwards unless you rewrite history.
 
Cheers,
  Peter