Hi everybody,
I received one more complaint for this issue, and now it appears in a public repository https://github.com/spray/spray
To reproduce:
# git clone https://github.com/spray/spray
# cd spray
# git log --no-walk --tags --pretty="%H %d" --decorate=full | tail -3
3273edafcd9f9701d62e061c5257c0a09e2e1fb7 (tag: refs/tags/v0.8.0-RC1)
ff3a2946bc54da76ddb47e82c81419cc7ae3db6b (tag: refs/tags/v0.7.0)
8b4043428b90b7f45b7241b3c2c032cf785479ce
So here the last hash doesn't have a decoration.
Thanks for any help.
Kirill.
From: brian m. carlson <hidden> Date: 2016-06-15 22:59:28
On Mon, Dec 16, 2013 at 03:52:35PM +0400, Kirill Likhodedov wrote:
Hi everybody,
I received one more complaint for this issue, and now it appears in a public repository https://github.com/spray/spray
To reproduce:
# git clone https://github.com/spray/spray
# cd spray
# git log --no-walk --tags --pretty="%H %d" --decorate=full | tail -3
3273edafcd9f9701d62e061c5257c0a09e2e1fb7 (tag: refs/tags/v0.8.0-RC1)
ff3a2946bc54da76ddb47e82c81419cc7ae3db6b (tag: refs/tags/v0.7.0)
8b4043428b90b7f45b7241b3c2c032cf785479ce
So here the last hash doesn't have a decoration.
This looks like a bug:
vauxhall ok % git describe 8b4043428b90b7f45b7241b3c2c032cf785479ce
v0.5.0
I'm looking at it.
--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187
From: brian m. carlson <hidden> Date: 2016-06-15 22:59:28
git log did not correctly handle decorations when a tag object referenced
another tag object that was no longer a ref, such as when the second tag was
deleted. The commit would not be decorated correctly because parse_object had
not been called on the second tag and therefore its tagged field had not been
filled in, resulting in none of the tags being associated with the relevant
commit.
Call parse_object to fill in this field if it is absent so that the chain of
tags can be dereferenced and the commit can be properly decorated. Include
tests as well to prevent future regressions.
Signed-off-by: brian m. carlson <redacted>
---
log-tree.c | 13 ++++++++++---
t/t4205-log-pretty-formats.sh | 15 +++++++++++++++
2 files changed, 25 insertions(+), 3 deletions(-)
From: Michael Haggerty <hidden> Date: 2016-06-15 22:59:40
On 12/16/2013 12:52 PM, Kirill Likhodedov wrote:
I received one more complaint for this issue, and now it appears in a public repository https://github.com/spray/spray
To reproduce:
# git clone https://github.com/spray/spray
# cd spray
# git log --no-walk --tags --pretty="%H %d" --decorate=full | tail -3
3273edafcd9f9701d62e061c5257c0a09e2e1fb7 (tag: refs/tags/v0.8.0-RC1)
ff3a2946bc54da76ddb47e82c81419cc7ae3db6b (tag: refs/tags/v0.7.0)
8b4043428b90b7f45b7241b3c2c032cf785479ce
So here the last hash doesn't have a decoration.
The problem is that reference refs/tags/v0.5.0 points at a tag object
8f6ca98087 which itself points at another tag object 2eddbcbff4 which
finally points at commit 8b4043428b. Probably we should handle
recursive tag objects like this, but OTOH I can't think of a reason why
one would want to create them in the first place.
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
From: Michael Haggerty <hidden> Date: 2016-06-15 22:59:41
On 01/16/2014 11:31 AM, Michael Haggerty wrote:
On 12/16/2013 12:52 PM, Kirill Likhodedov wrote:
quoted
I received one more complaint for this issue, and now it appears in a public repository https://github.com/spray/spray
To reproduce:
# git clone https://github.com/spray/spray
# cd spray
# git log --no-walk --tags --pretty="%H %d" --decorate=full | tail -3
3273edafcd9f9701d62e061c5257c0a09e2e1fb7 (tag: refs/tags/v0.8.0-RC1)
ff3a2946bc54da76ddb47e82c81419cc7ae3db6b (tag: refs/tags/v0.7.0)
8b4043428b90b7f45b7241b3c2c032cf785479ce
So here the last hash doesn't have a decoration.
The problem is that reference refs/tags/v0.5.0 points at a tag object
8f6ca98087 which itself points at another tag object 2eddbcbff4 which
finally points at commit 8b4043428b. Probably we should handle
recursive tag objects like this, but OTOH I can't think of a reason why
one would want to create them in the first place.
Junio just pointed out to me that this bug has been fixed already, by
Brian Carlson, in 5e1361cc, which is already in master. Sorry for the
noise.
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/