Bug report: %h for abbreviated hashes broken after 1.7.1

Bug report: %h for abbreviated hashes broken after 1.7.1

[Todd A. Jacobs]

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?

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

[Jonathan Nieder]

Todd A. Jacobs wrote:

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

$ 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

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

[Todd A. Jacobs]

On Wed, Aug 25, 2010 at 12:14 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> $ git log --oneline v1.7.2.2..35039ced9296786bc0971bf5385c0d6f6ea5ea1e
> 35039ce archive: abbreviate substituted commit ids again

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.

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

[Björn Steinbrink]

[Added Jonathan back to Cc...]

On 2010.08.25 01:07:28 -0400, Todd A. Jacobs wrote:
> On Wed, Aug 25, 2010 at 12:14 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> > $ git log --oneline v1.7.2.2..35039ced9296786bc0971bf5385c0d6f6ea5ea1e
> > 35039ce archive: abbreviate substituted commit ids again

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

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

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

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

[Jonathan Nieder]

Hi again,

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

>> $ git log --oneline v1.7.2.2..35039ced9296786bc0971bf5385c0d6f6ea5ea1e
>> 35039ce archive: abbreviate substituted commit ids again
>
> I'm not at all sure I understand your point.

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

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

[Todd A. Jacobs]

> 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:

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

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

[Marcus Comstedt]

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

> 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

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

[Todd Zullinger]

[-- Attachment #1: Type: text/plain, Size: 1819 bytes --]

Marcus Comstedt wrote:
> Todd A. Jacobs <tjacobs <at> si2services.com> writes:
>
>> 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


[-- Attachment #2: Type: application/pgp-signature, Size: 542 bytes --]