Bug report: %h for abbreviated hashes broken after 1.7.1

I have the following string in a file:

    $Format:Git ID: (%h) %ci$

which is being expanded by git-archive. In git 1.7.1, this properly expands to:

    Git ID: (58b31cf) 2010-08-24 14:00:00 -0400

but in 1.7.1.1 and 1.7.2.2 I am getting:

    Git ID: (58b31cf99592ca39b1d6b0f08f71674a7ed0ffbd) 2010-08-24 14:00:00 -0400

Checking 'man git-log' still says:

    %h: abbreviated commit hash

so this seems to be some sort of regression in how pretty formats are being expanded. It looks like commit 35039ced9296786bc0971bf5385c0d6f6ea5ea1e was supposed to fix this, but it apparently still isn't working in the latest tarballs available on kernel.org.

Can someone please look into this?

Todd A. Jacobs wrote:

$ git log --oneline v1.7.2.2..35039ced9296786bc0971bf5385c0d6f6ea5ea1e 35039ce archive: abbreviate substituted commit ids again $

You might also be interested in the section "Repositories, branches, and documentation", from the note from the maintainer sent to this list from time to time. [1]

Hope that helps, Jonathan

[1] http://git.kernel.org/?p=git/git.git;a=blob_plain;f=MaintNotes;hb=todo

On Wed, Aug 25, 2010 at 12:14 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:

I'm not at all sure I understand your point. I'd already pointed out that the referenced commit claimed to have fixed the problem, but doesn't appear to be working in recent versions. With 1.7.2.2, I'm still getting the unabbreviated commit IDs with %h.

Tag v1.7.2.2 is almost a month after 35039ce, so I'm not sure where you're going with that, either. It should definitely be part of the 1.7.2.2 tarball, but the problem persists.

If I've somehow misunderstood your points, please restate them. The problem is definitely ongoing, regardless of what 35039ce says.

[Added Jonathan back to Cc...]

On 2010.08.25 01:07:28 -0400, Todd A. Jacobs wrote:

That shows that the commit is not in the tag's ancestry.

Maybe it should be, but it isn't. With non-linear histories, commit dates don't tell you whether one commit is an ancestor of another commit.

Björn

Hi again,

Todd A. Jacobs wrote:

Sorry, let me try again.

As you know, in a distributed development model, history is not linear. It is possible to have multiple lines of development by people who are not aware of each other:

   o --- o --- o --- o
  /
 o --- o --- o --- o

that are only later merged.

   o --- o --- o ----- o
  /                     \
 o --- o --- o --- o --- o

Sometimes even a single person will use history like this, for release management purposes. A change that has not yet been released will be kept on one branch while releases are cut from another branch.

The command

 $ git log --oneline v2.9..topic

lists commits that are in the history of the "topic" branch but are not part of the v2.9 release.

So my response was to indicate that there is no contradiction here: that fix has been prepared but it is not part of the v1.7.2.2 release.

Regards, Jonathan

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

while still not being exported at v1.7.2.2. Diffing:

    git diff 35039ce v1.7.2.2 -- archive.c

still shows the patch unapplied, but I can't understand why since both commits are on the same branch. What I'm not seeing is where it's unapplied, reverted, or otherwise stripped out of the progression along master. What am I missing here?

Meanwhile, whether it isn't merged in, or because the patch doesn't work/was reverted/won the lottery/took a vacation, the bottom line is that the last two releases of git Do The Wrong Thing (tm) with export-subst strings when called by git-archive.

I'd really like to know (for my own git-knowledge growth) how to figure out where the patch went, if not up the master tree, but in the end all I want is the right functionality back. :)

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

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

Marcus Comstedt wrote:

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

    $ git tag --contains 35039ce

Returns nothing, as no tag has 35039ce.