Git describe question

Git describe question

[Mark Burton]

Hi,

Having just pulled the latest updates, git describe says:

v1.5.6.3-315-g10ce020

Why does it think there are 315 commits on top of the v1.5.6.3 tag? I
would have expected a much smaller number than that.

Thanks,

Mark

Re: Git describe question

[Junio C Hamano]

Mark Burton <markb@ordern.com> writes:

> Having just pulled the latest updates, git describe says:
>
> v1.5.6.3-315-g10ce020
>
> Why does it think there are 315 commits on top of the v1.5.6.3 tag?

Short answer.  Because there are.  Count'em ;-)

	$ git rev-list v1.5.6.3..master | wc -l

A longer answer.  v1.5.6.X releases are from 'maint'.  The branch has
forked from the mainline loooong time ago (at v1.5.6, to be exact), and
has only fixes.  'master' is a separate branch for development that would
eventually lead to the next major release (planned to be v1.6.0).

Re: Git describe question

[Mark Burton]

Thanks for the speedy response.

> A longer answer.  v1.5.6.X releases are from 'maint'.  The branch has
> forked from the mainline loooong time ago (at v1.5.6, to be exact), and
> has only fixes.  'master' is a separate branch for development that would
> eventually lead to the next major release (planned to be v1.6.0).

Ok, I understand what it's doing now - but that makes me wonder if it
would be useful/possible to be able to specify that git describe only
considers the commits on top of the tag for the current (or some
specified branch). i.e. at the moment, gitk shows 8 commits on top of
v1.5.6.3 in the master branch.

As the master branch is the checked out branch and the v1.5.6.3 tag
tags a commit in that branch (via the merge) is it not possible to only
consider the commits between the tag and the HEAD on that branch?

Sorry, I don't understand the git internals (yet) so I don't know if
this is a stupid question and I am certainly not in a position to try
and implement it myself (yet).

Cheers,

Mark

Re: Git describe question

[Jean-Luc Herren]

Mark Burton wrote:
> Ok, I understand what it's doing now - but that makes me wonder if it
> would be useful/possible to be able to specify that git describe only
> considers the commits on top of the tag for the current (or some
> specified branch). i.e. at the moment, gitk shows 8 commits on top of
> v1.5.6.3 in the master branch.

Are you saying "git describe" should output v1.5.6.3-8-g10ce020?
That would be misleading and even wrong.  This would be like
saying that there are only 8 commits of difference between
v1.5.6.3 and 10ce20, which is not true.  The differences between
those two commits are over 300 single commits and that's also what
"git (log|diff) v1.5.6.3..10ce20" will tell you.  All 300+ commits
that have been made to the branch master since the branch maint
forked off are part of 10ce20, but not part of v1.5.6.3.  It seems
fine to me that "git describe" reflects this difference.

> As the master branch is the checked out branch and the v1.5.6.3 tag
> tags a commit in that branch (via the merge) [...]

I don't think people usually say "tag X is on branch Y", excepted
maybe if Y has never been merged anywhere.  Specifically, nobody
would say v1.5.6.3 is *on* branch master.  But it's part of its
history.  v1.5.6.3 is *on* maint, at best.

jlh

Re: Git describe question

[Junio C Hamano]

Jean-Luc Herren <jlh@gmx.ch> writes:

> Mark Burton wrote:
> ...
> I don't think people usually say "tag X is on branch Y", excepted
> maybe if Y has never been merged anywhere.  Specifically, nobody
> would say v1.5.6.3 is *on* branch master.  But it's part of its
> history.  v1.5.6.3 is *on* maint, at best.

Actually I am somewhat sympathetic to Mark here.  Probably what he wants
is to describe 10ce020 as v1.5.6-390-10ce020.

While that probably is doable by using the first-parent-only traversal, I
do not think it is such a good idea.  It is not how branches in git are
designed to work.  As Merlyn always says in #git at freenode, a branch is
an illusion, and it is especially true in the presense of fast-forward
merge (aka the upstream maintainer asking a subsystem lieutenant to do a
merge for him).

Re: Git describe question

[Mark Burton]

On Mon, 14 Jul 2008 16:17:52 -0700
Junio C Hamano <gitster@pobox.com> wrote:

> Jean-Luc Herren <jlh@gmx.ch> writes:
> 
> > Mark Burton wrote:
> > ...
> > I don't think people usually say "tag X is on branch Y", excepted
> > maybe if Y has never been merged anywhere.  Specifically, nobody
> > would say v1.5.6.3 is *on* branch master.  But it's part of its
> > history.  v1.5.6.3 is *on* maint, at best.
> 
> Actually I am somewhat sympathetic to Mark here.  Probably what he wants
> is to describe 10ce020 as v1.5.6-390-10ce020.
> 
> While that probably is doable by using the first-parent-only traversal, I
> do not think it is such a good idea.  It is not how branches in git are
> designed to work.  As Merlyn always says in #git at freenode, a branch is
> an illusion, and it is especially true in the presense of fast-forward
> merge (aka the upstream maintainer asking a subsystem lieutenant to do a
> merge for him).

Hi Guys,

Many thanks for the replies which make sense.

I guess the thing that prompted my original email was the fact that
when you look at output from gitk, the "distance" between 1.5.6.3 and
HEAD is only a few commits and that led me to expect that the output of
describe would show a smaller number than it does. I now understand why
it is how it is.

However, the git describe manual page does mention branches:

>With something like git.git current tree, I get:
>
>           [torvalds@g5 git]$ git-describe parent
>           v1.0.4-14-g2414721
>i.e. the current head of my "parent" branch is based on v1.0.4,
>but since it has a handful commits on top of that, describe has added
>the number of additional commits ("14") and an abbreviated object name
>for the commit itself ("2414721") at the end.

If you're a git newbie (like me) those words suggest that the commits
are "on" branch parent and you could measure the direct distance
between them by following the branch. Perhaps, the manual page should
contain a sentence similar to this:

Branches have no influence on the git describe long format output 
which is derived only from the number of commits in the chain from the
described tag to the committish.

Cheers,

Mark