Re: git log --no-walk --tags produces strange result for certain user
On 01/16/2014 11:31 AM, Michael Haggerty wrote: > 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. 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 mhag...@alum.mit.edu http://softwareswirl.blogspot.com/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git log --no-walk --tags produces strange result for certain user
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 mhag...@alum.mit.edu http://softwareswirl.blogspot.com/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git log --no-walk --tags produces strange result for certain user
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 signature.asc Description: Digital signature
Re: git log --no-walk --tags produces strange result for certain user
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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git log --no-walk --tags produces strange result for certain user
Sorry for the duplication, but does anyone have an idea about this issue? I'm worried because I've already received reports from 3 users, and I'm not sure if just skipping these "pseudo-tags" is a correct decision. Thanks for any help! -- Kirill. On Dec 3, 2013, at 14:08 , Kirill Likhodedov wrote: > Hey, > > I use the following commands to receive the list of tags together with hashes > the point to: > >git log --tags --no-walk --format=%H%d%x01 --decorate=full > > Generally it works fine, however a user reported that for his repository this > command returns the list containing several hashes without tag references. > Something like this: > >05c9a3a6247698ff740ca3a79828456347afdcef (HEAD, tag: refs/tags/2.33, > refs/remotes/origin/master, refs/remotes/origin/HEAD, refs/heads/master) >a7fda708d76d7f83d5a160b6b137b98b7677f771 (tag: refs/tags/2.44) >f119c2e7c69bb5ed1da5bae29c8754550ab96bde >07385a6ebe5a2e01e6ba9c8d0cb7b15c9a13f65d (tag: refs/tags/1.69) > > Here third hash doesn't have a reference. There are 3 such hashes in his > repository. > > How can this happen? Is it a bug or some special scenario? > > * I've already asked the user to execute `git tag --points-at` on these > "suspiciously tagged" hashes: nothing was returned. > * `git show --decorate=full` executed on these hashes return commit details, > and no references on them. > * From the log user sees that these hashes indicate some "normal" commits, > nothing special at first glance. > > Git version that he uses is 1.8.4.0. > > Thanks! > > -- Kirill. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
