Re: Bug report: %h for abbreviated hashes broken after 1.7.1

Marcus Comstedt wrote:

Todd A. Jacobs <tjacobs <at> si2services.com> writes:

quoted

Fair enough. Thank you for taking the time to explain further. I guess
I still don't understand how both the patch and the tag are both on
the master branch:

    $ git branch --contains v1.7.2.2
    * master

    $ git branch --contains 35039ce
    * master

The commit tagged with v1.7.2.2 is on the master branch because
it was merged there.  The tag was not cut from the master branch
but from the maint branch.  You are fooled by git branch here because
you display only your local branches, and you don't have a local
maint branch.  Add -r to the command, and you will see the commits
are in multiple branches at origin.

I'm afraid the git command line tools are rather unhelpful in these
cases (it's hard to find the answer if you don't already know it),
but gitk allows you to see it quite nicely.  Run "gitk origin/master",
and search for 35039ce.  You'll see the commit being made on a topic
branch, which is merged into master (the leftmost track) on 2010-08-18.
You can also clearly see v1.7.2.2 being cut from maint (the track
immediately to the right of master) on 2010-08-20, shortly after which
maint is merged into master (c11969), which is why master "contains"
8c67c3, which is what you're really looking for when you say
"--contains v1.7.2.2".

In cases like this I find tag --contains handy:

    $ git tag --contains 35039ce

Returns nothing, as no tag has 35039ce.

-- 
Todd        OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
A word to the wise ain't necessary -- it's the stupid ones who need
the advice.
    -- Bill Cosby