Re: Bug report: %h for abbreviated hashes broken after 1.7.1
- From
Marcus Comstedt <marcus@mc.pp.se>
- Date
- Aug 25, 2010, 08:08 UTC
- Message-ID
- <loom.20100825T095907-907@post.gmane.org>
- In-Reply-To
- <AANLkTimebn+p9dcUWQiUPT8WwC-tuPpTM8M+ptq4Q9uc@mail.gmail.com>
Todd A. Jacobs <tjacobs <at> si2services.com> writes:
Show 9 quoted lines
> 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".
// Marcus