Git describe question

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

Mark Burton <markb@ordern.com> writes:

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).

Thanks for the speedy response.

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

Mark Burton wrote:

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.

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

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

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).

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

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:

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