{"thread":{"id":"24854","subject":"Bug report: %h for abbreviated hashes broken after 1.7.1","startedAt":"2010-08-25T02:54:35Z","lastAt":"2010-08-25T17:27:19Z","messageCount":8,"participants":["Todd A. Jacobs","Jonathan Nieder","Björn Steinbrink","Marcus Comstedt","Todd Zullinger"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"148926","messageId":"AANLkTinR6_DFD_MbFRbtyJKPhZG1Os0ro=4TcC2h_xZo@mail.gmail.com","threadId":"24854","inReplyTo":null,"subject":"Bug report: %h for abbreviated hashes broken after 1.7.1","fromName":"Todd A. Jacobs","fromEmail":"tjacobs@si2services.com","sentAt":"2010-08-25T02:54:35Z","receivedAt":"2010-08-25T02:54:35Z","isPatch":false,"sender":{"key":"tjacobs@si2services.com","avatar":null},"body":"I have the following string in a file:\n\n $Format:Git ID: (%h) %ci$\n\nwhich is being expanded by git-archive. In git 1.7.1, this properly expands to:\n\n Git ID: (58b31cf) 2010-08-24 14:00:00 -0400\n\nbut in 1.7.1.1 and 1.7.2.2 I am getting:\n\n Git ID: (58b31cf99592ca39b1d6b0f08f71674a7ed0ffbd) 2010-08-24 14:00:00 -0400\n\nChecking 'man git-log' still says:\n\n %h: abbreviated commit hash\n\nso this seems to be some sort of regression in how pretty formats are\nbeing expanded. It looks like commit\n35039ced9296786bc0971bf5385c0d6f6ea5ea1e was supposed to fix this, but\nit apparently still isn't working in the latest tarballs available on\nkernel.org.\n\nCan someone please look into this?\n"},{"id":"148936","messageId":"20100825041440.GH11619@burratino","threadId":"24854","inReplyTo":"AANLkTinR6_DFD_MbFRbtyJKPhZG1Os0ro=4TcC2h_xZo@mail.gmail.com","subject":"Re: Bug report: %h for abbreviated hashes broken after 1.7.1","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2010-08-25T04:14:40Z","receivedAt":"2010-08-25T04:14:40Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Todd A. Jacobs wrote:\n\n> Checking 'man git-log' still says:\n> \n> %h: abbreviated commit hash\n> \n> so this seems to be some sort of regression in how pretty formats are\n> being expanded. It looks like commit\n> 35039ced9296786bc0971bf5385c0d6f6ea5ea1e was supposed to fix this, but\n> it apparently still isn't working in the latest tarballs available on\n> kernel.org.\n\n$ git log --oneline v1.7.2.2..35039ced9296786bc0971bf5385c0d6f6ea5ea1e\n35039ce archive: abbreviate substituted commit ids again\n$\n\nYou might also be interested in the section \"Repositories, branches,\nand documentation\", from the note from the maintainer sent to this\nlist from time to time. [1]\n\nHope that helps,\nJonathan\n\n[1] http://git.kernel.org/?p=git/git.git;a=blob_plain;f=MaintNotes;hb=todo\n"},{"id":"148942","messageId":"AANLkTi=+tGLfs-t6+fjRu68Mt76dJw4sbNCoO9q9+uyp@mail.gmail.com","threadId":"24854","inReplyTo":"20100825041440.GH11619@burratino","subject":"Re: Bug report: %h for abbreviated hashes broken after 1.7.1","fromName":"Todd A. Jacobs","fromEmail":"tjacobs@si2services.com","sentAt":"2010-08-25T05:07:28Z","receivedAt":"2010-08-25T05:07:28Z","isPatch":false,"sender":{"key":"tjacobs@si2services.com","avatar":null},"body":"On Wed, Aug 25, 2010 at 12:14 AM, Jonathan Nieder wrote:\n> $ git log --oneline v1.7.2.2..35039ced9296786bc0971bf5385c0d6f6ea5ea1e\n> 35039ce archive: abbreviate substituted commit ids again\n\nI'm not at all sure I understand your point. I'd already pointed out\nthat the referenced commit claimed to have fixed the problem, but\ndoesn't appear to be working in recent versions. With 1.7.2.2, I'm\nstill getting the unabbreviated commit IDs with %h.\n\nTag v1.7.2.2 is almost a month after 35039ce, so I'm not sure where\nyou're going with that, either. It should definitely be part of the\n1.7.2.2 tarball, but the problem persists.\n\nIf I've somehow misunderstood your points, please restate them. The\nproblem is definitely ongoing, regardless of what 35039ce says.\n"},{"id":"148948","messageId":"20100825061643.GB2938@atjola.homenet","threadId":"24854","inReplyTo":"AANLkTi=+tGLfs-t6+fjRu68Mt76dJw4sbNCoO9q9+uyp@mail.gmail.com","subject":"Re: Bug report: %h for abbreviated hashes broken after 1.7.1","fromName":"Björn Steinbrink","fromEmail":"b.steinbrink@gmx.de","sentAt":"2010-08-25T06:16:44Z","receivedAt":"2010-08-25T06:16:44Z","isPatch":false,"sender":{"key":"b.steinbrink@gmx.de","avatar":"https://avatars.githubusercontent.com/u/230962?v=4"},"body":"[Added Jonathan back to Cc...]\n\nOn 2010.08.25 01:07:28 -0400, Todd A. Jacobs wrote:\n> On Wed, Aug 25, 2010 at 12:14 AM, Jonathan Nieder wrote:\n> > $ git log --oneline v1.7.2.2..35039ced9296786bc0971bf5385c0d6f6ea5ea1e\n> > 35039ce archive: abbreviate substituted commit ids again\n\nThat shows that the commit is not in the tag's ancestry.\n\n> Tag v1.7.2.2 is almost a month after 35039ce, so I'm not sure where\n> you're going with that, either. It should definitely be part of the\n> 1.7.2.2 tarball, but the problem persists.\n\nMaybe it should be, but it isn't. With non-linear histories, commit\ndates don't tell you whether one commit is an ancestor of another\ncommit.\n\nBjörn\n"},{"id":"148950","messageId":"20100825062403.GA15858@burratino","threadId":"24854","inReplyTo":"AANLkTi=+tGLfs-t6+fjRu68Mt76dJw4sbNCoO9q9+uyp@mail.gmail.com","subject":"Re: Bug report: %h for abbreviated hashes broken after 1.7.1","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2010-08-25T06:24:03Z","receivedAt":"2010-08-25T06:24:03Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi again,\n\nTodd A. Jacobs wrote:\n> On Wed, Aug 25, 2010 at 12:14 AM, Jonathan Nieder wrote:\n\n>> $ git log --oneline v1.7.2.2..35039ced9296786bc0971bf5385c0d6f6ea5ea1e\n>> 35039ce archive: abbreviate substituted commit ids again\n>\n> I'm not at all sure I understand your point.\n\nSorry, let me try again.\n\nAs you know, in a distributed development model, history is not\nlinear. It is possible to have multiple lines of development by\npeople who are not aware of each other:\n\n o --- o --- o --- o\n /\n o --- o --- o --- o\n\nthat are only later merged.\n\n o --- o --- o ----- o\n / \\\n o --- o --- o --- o --- o\n\nSometimes even a single person will use history like this, for\nrelease management purposes. A change that has not yet been\nreleased will be kept on one branch while releases are cut from\nanother branch.\n\nThe command\n\n $ git log --oneline v2.9..topic\n\nlists commits that are in the history of the \"topic\" branch but\nare not part of the v2.9 release.\n\nSo my response was to indicate that there is no contradiction\nhere: that fix has been prepared but it is not part of the v1.7.2.2\nrelease.\n\nRegards,\nJonathan\n"},{"id":"148953","messageId":"AANLkTimebn+p9dcUWQiUPT8WwC-tuPpTM8M+ptq4Q9uc@mail.gmail.com","threadId":"24854","inReplyTo":"20100825062403.GA15858@burratino","subject":"Re: Bug report: %h for abbreviated hashes broken after 1.7.1","fromName":"Todd A. Jacobs","fromEmail":"tjacobs@si2services.com","sentAt":"2010-08-25T07:20:28Z","receivedAt":"2010-08-25T07:20:28Z","isPatch":false,"sender":{"key":"tjacobs@si2services.com","avatar":null},"body":"> As you know, in a distributed development model, history is not\n> linear.  It is possible to have multiple lines of development by\n> people who are not aware of each other:\n\nFair enough. Thank you for taking the time to explain further. I guess\nI still don't understand how both the patch and the tag are both on\nthe master branch:\n\n $ git branch --contains v1.7.2.2\n * master\n\n $ git branch --contains 35039ce\n * master\n\nwhile still not being exported at v1.7.2.2. Diffing:\n\n git diff 35039ce v1.7.2.2 -- archive.c\n\nstill shows the patch unapplied, but I can't understand why since both\ncommits are on the same branch. What I'm not seeing is where it's\nunapplied, reverted, or otherwise stripped out of the progression\nalong master. What am I missing here?\n\nMeanwhile, whether it isn't merged in, or because the patch doesn't\nwork/was reverted/won the lottery/took a vacation, the bottom line is\nthat the last two releases of git Do The Wrong Thing (tm) with\nexport-subst strings when called by git-archive.\n\nI'd really like to know (for my own git-knowledge growth) how to\nfigure out where the patch went, if not up the master tree, but in the\nend all I want is the right functionality back. :)\n"},{"id":"148958","messageId":"loom.20100825T095907-907@post.gmane.org","threadId":"24854","inReplyTo":"AANLkTimebn+p9dcUWQiUPT8WwC-tuPpTM8M+ptq4Q9uc@mail.gmail.com","subject":"Re: Bug report: %h for abbreviated hashes broken after 1.7.1","fromName":"Marcus Comstedt","fromEmail":"marcus@mc.pp.se","sentAt":"2010-08-25T08:08:18Z","receivedAt":"2010-08-25T08:08:18Z","isPatch":false,"sender":{"key":"marcus@mc.pp.se","avatar":"https://avatars.githubusercontent.com/u/411296?v=4"},"body":"Todd A. Jacobs si2services.com> writes:\n\n> Fair enough. Thank you for taking the time to explain further. I guess\n> I still don't understand how both the patch and the tag are both on\n> the master branch:\n> \n> $ git branch --contains v1.7.2.2\n> * master\n> \n> $ git branch --contains 35039ce\n> * master\n\nThe commit tagged with v1.7.2.2 is on the master branch because\nit was merged there. The tag was not cut from the master branch\nbut from the maint branch. You are fooled by git branch here because\nyou display only your local branches, and you don't have a local\nmaint branch. Add -r to the command, and you will see the commits\nare in multiple branches at origin.\n\nI'm afraid the git command line tools are rather unhelpful in these\ncases (it's hard to find the answer if you don't already know it),\nbut gitk allows you to see it quite nicely. Run \"gitk origin/master\",\nand search for 35039ce. You'll see the commit being made on a topic\nbranch, which is merged into master (the leftmost track) on 2010-08-18.\nYou can also clearly see v1.7.2.2 being cut from maint (the track\nimmediately to the right of master) on 2010-08-20, shortly after which\nmaint is merged into master (c11969), which is why master \"contains\"\n8c67c3, which is what you're really looking for when you say\n\"--contains v1.7.2.2\".\n\n // Marcus\n"},{"id":"148973","messageId":"20100825172718.GC4925@inocybe.localdomain","threadId":"24854","inReplyTo":"loom.20100825T095907-907@post.gmane.org","subject":"Re: Bug report: %h for abbreviated hashes broken after 1.7.1","fromName":"Todd Zullinger","fromEmail":"tmz@pobox.com","sentAt":"2010-08-25T17:27:19Z","receivedAt":"2010-08-25T17:27:19Z","isPatch":false,"sender":{"key":"tmz@pobox.com","avatar":"https://avatars.githubusercontent.com/u/806319?v=4"},"body":"Marcus Comstedt wrote:\n> Todd A. Jacobs si2services.com> writes:\n>\n>> Fair enough. Thank you for taking the time to explain further. I guess\n>> I still don't understand how both the patch and the tag are both on\n>> the master branch:\n>>\n>> $ git branch --contains v1.7.2.2\n>> * master\n>>\n>> $ git branch --contains 35039ce\n>> * master\n>\n> The commit tagged with v1.7.2.2 is on the master branch because\n> it was merged there. The tag was not cut from the master branch\n> but from the maint branch. You are fooled by git branch here because\n> you display only your local branches, and you don't have a local\n> maint branch. Add -r to the command, and you will see the commits\n> are in multiple branches at origin.\n>\n> I'm afraid the git command line tools are rather unhelpful in these\n> cases (it's hard to find the answer if you don't already know it),\n> but gitk allows you to see it quite nicely. Run \"gitk origin/master\",\n> and search for 35039ce. You'll see the commit being made on a topic\n> branch, which is merged into master (the leftmost track) on 2010-08-18.\n> You can also clearly see v1.7.2.2 being cut from maint (the track\n> immediately to the right of master) on 2010-08-20, shortly after which\n> maint is merged into master (c11969), which is why master \"contains\"\n> 8c67c3, which is what you're really looking for when you say\n> \"--contains v1.7.2.2\".\n\nIn cases like this I find tag --contains handy:\n\n $ git tag --contains 35039ce\n\nReturns nothing, as no tag has 35039ce.\n\n-- \nTodd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\nA word to the wise ain't necessary -- it's the stupid ones who need\nthe advice.\n -- Bill Cosby\n\n"}]}