{"thread":{"id":"7019","subject":"Memory overrun in http-push.c","startedAt":"2007-02-28T15:15:17Z","lastAt":"2007-03-04T09:18:52Z","messageCount":39,"participants":["Eygene Ryabinkin","Andy Parkins","Johannes Schindelin","Florian Weimer","Alex Riesen","Junio C Hamano","Uwe Kleine-König","Shawn O. Pearce","Jakub Narebski","Matthieu Moy","Linus Torvalds","Daniel Barkalow"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"35819","messageId":"20070228151516.GC57456@codelabs.ru","threadId":"7019","inReplyTo":null,"subject":"Memory overrun in http-push.c","fromName":"Eygene Ryabinkin","fromEmail":"rea-git@codelabs.ru","sentAt":"2007-02-28T15:15:17Z","receivedAt":"2007-02-28T15:15:17Z","isPatch":false,"sender":{"key":"rea-git@codelabs.ru","avatar":null},"body":"Good day!\n\nSpotted the memory overrun in the http-push.c. Exists at least in\n1.5.0.x, not sure about latest development branch. The patch is\nattached.\n-- \nEygene\n\n\n--- http-push.c.orig\tWed Feb 28 15:15:01 2007\n+++ http-push.c\tWed Feb 28 15:15:21 2007\n@@ -1295,7 +1295,7 @@\n \tsprintf(url, \"%s%s\", remote->url, path);\n \n \t/* Make sure leading directories exist for the remote ref */\n-\tep = strchr(url + strlen(remote->url) + 11, '/');\n+\tep = strchr(url + strlen(remote->url) + 1, '/');\n \twhile (ep) {\n \t\t*ep = 0;\n \t\tslot = get_active_slot();\n"},{"id":"35824","messageId":"200702281541.41164.andyparkins@gmail.com","threadId":"7019","inReplyTo":"20070228151516.GC57456@codelabs.ru","subject":"Re: Memory overrun in http-push.c","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-02-28T15:41:38Z","receivedAt":"2007-02-28T15:41:38Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Wednesday 2007 February 28 15:15, Eygene Ryabinkin wrote:\n> --- http-push.c.orig    Wed Feb 28 15:15:01 2007\n> +++ http-push.c Wed Feb 28 15:15:21 2007\n> @@ -1295,7 +1295,7 @@\n\nA patch for git that wasn't made with git.\n\nDon't take this the wrong way Eygene, but why?\n\n\n\nAndy\n-- \nDr Andy Parkins, M Eng (hons), MIET\nandyparkins@gmail.com\n"},{"id":"35825","messageId":"Pine.LNX.4.63.0702281642420.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"7019","inReplyTo":"200702281541.41164.andyparkins@gmail.com","subject":"Re: Memory overrun in http-push.c","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-02-28T15:42:52Z","receivedAt":"2007-02-28T15:42:52Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 28 Feb 2007, Andy Parkins wrote:\n\n> On Wednesday 2007 February 28 15:15, Eygene Ryabinkin wrote:\n> > --- http-push.c.orig    Wed Feb 28 15:15:01 2007\n> > +++ http-push.c Wed Feb 28 15:15:21 2007\n> > @@ -1295,7 +1295,7 @@\n> \n> A patch for git that wasn't made with git.\n> \n> Don't take this the wrong way Eygene, but why?\n\nOld habits die hard?\n\nCiao,\nDscho\n"},{"id":"35847","messageId":"87tzx6i6hw.fsf@mid.deneb.enyo.de","threadId":"7019","inReplyTo":"20070228151516.GC57456@codelabs.ru","subject":"Re: Memory overrun in http-push.c","fromName":"Florian Weimer","fromEmail":"fw@deneb.enyo.de","sentAt":"2007-02-28T16:36:43Z","receivedAt":"2007-02-28T16:36:43Z","isPatch":false,"sender":{"key":"fw@deneb.enyo.de","avatar":null},"body":"* Eygene Ryabinkin:\n\n> Spotted the memory overrun in the http-push.c. Exists at least in\n> 1.5.0.x, not sure about latest development branch. The patch is\n> attached.\n\nIs this issue security-relevant? After all, the misplaced pointer is\ndereferenced and written to.\n"},{"id":"35916","messageId":"20070301051323.GG57456@codelabs.ru","threadId":"7019","inReplyTo":"200702281541.41164.andyparkins@gmail.com","subject":"Re: Memory overrun in http-push.c","fromName":"Eygene Ryabinkin","fromEmail":"rea-git@codelabs.ru","sentAt":"2007-03-01T05:13:24Z","receivedAt":"2007-03-01T05:13:24Z","isPatch":false,"sender":{"key":"rea-git@codelabs.ru","avatar":null},"body":"Andy, good day!\n\nWed, Feb 28, 2007 at 03:41:38PM +0000, Andy Parkins wrote:\n> On Wednesday 2007 February 28 15:15, Eygene Ryabinkin wrote:\n> > --- http-push.c.orig    Wed Feb 28 15:15:01 2007\n> > +++ http-push.c Wed Feb 28 15:15:21 2007\n> > @@ -1295,7 +1295,7 @@\n> \n> A patch for git that wasn't made with git.\n> \n> Don't take this the wrong way Eygene, but why?\n\nBecause I am trying to set up Git repository to be used over HTTPS,\nbut it is failing now: seems like CURL library provokes the SIGSEGV.\nThe actual patch was made for the FreeBSD ports, so I've used plain\nold 'diff -u'.\n\nAs Johannes pointed out, old habits are still alive. And when some\ntool serves me the right way, I am happy with it. To make the patch\nwith Git I should create repository, hack there, merge it to the\nFreeBSD port, install and so on. A bit boring, do not take me wrong ;))\n-- \nEygene\n"},{"id":"35918","messageId":"20070301051928.GH57456@codelabs.ru","threadId":"7019","inReplyTo":"87tzx6i6hw.fsf@mid.deneb.enyo.de","subject":"Re: Memory overrun in http-push.c","fromName":"Eygene Ryabinkin","fromEmail":"rea-git@codelabs.ru","sentAt":"2007-03-01T05:19:28Z","receivedAt":"2007-03-01T05:19:28Z","isPatch":false,"sender":{"key":"rea-git@codelabs.ru","avatar":null},"body":"Florian, good day!\n\n> > Spotted the memory overrun in the http-push.c. Exists at least in\n> > 1.5.0.x, not sure about latest development branch. The patch is\n> > attached.\n> \n> Is this issue security-relevant? After all, the misplaced pointer is\n> dereferenced and written to.\n\nIt can be relevant: basically, it is the heap overflow, because\n'url' is allocated by xmalloc. Did not tried to exploit it, but\nold sudo exploit proved that even one byte off memory dereference\ncan be exploited. But this particular exploit will work only for\nthe URLs where the 'path' is shorter than 10 bytes. And I doubt\nthat many people are running http-push in the set-uid mode, so\nthe exploit target will be the person running git-push over HTTP,\nnot the root user. But it does not mean that this is not an issue.\n\nSorry for the long letter.\n-- \nEygene\n"},{"id":"35928","messageId":"81b0412b0703010015l5c91c68pd4748ae379db98bb@mail.gmail.com","threadId":"7019","inReplyTo":"20070301051323.GG57456@codelabs.ru","subject":"Re: Memory overrun in http-push.c","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-03-01T08:15:32Z","receivedAt":"2007-03-01T08:15:32Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 3/1/07, Eygene Ryabinkin wrote:\n> As Johannes pointed out, old habits are still alive. And when some\n> tool serves me the right way, I am happy with it. To make the patch\n> with Git I should create repository, hack there, merge it to the\n\nhacking on Git you already have a git repo, don't you?\nIt should have been as simple as:\n\n$ vi http-push.c\n...\n$ git diff\n\n:)\n\nBTW, git diff works outside of a git repositories (well, very recent\ngit should).\n"},{"id":"35937","messageId":"20070301091058.GA63606@codelabs.ru","threadId":"7019","inReplyTo":"81b0412b0703010015l5c91c68pd4748ae379db98bb@mail.gmail.com","subject":"Re: Memory overrun in http-push.c","fromName":"Eygene Ryabinkin","fromEmail":"rea-git@codelabs.ru","sentAt":"2007-03-01T09:11:00Z","receivedAt":"2007-03-01T09:11:00Z","isPatch":false,"sender":{"key":"rea-git@codelabs.ru","avatar":null},"body":"> >As Johannes pointed out, old habits are still alive. And when some\n> >tool serves me the right way, I am happy with it. To make the patch\n> >with Git I should create repository, hack there, merge it to the\n> \n> hacking on Git you already have a git repo, don't you?\n\nNo, I was doing FreeBSD port of Git 1.5.0, so it was just the tarball.\nOld habits, you know ;))\n\n> It should have been as simple as:\n> \n> $ vi http-push.c\n> ...\n> $ git diff\n> \n> :)\n> \n> BTW, git diff works outside of a git repositories (well, very recent\n> git should).\n\nOnce I will get Git working for me I will get used to it and will\ndo many things in Git.\n\nOK, I've forgot to ask in my previous letter: will the issue with\n'+11' instead of '+1' be fixed (or its already fixed)? Or 11 is 10 + 1,\nwhere 10 it strlen(\"git\") trice plus one just to be sure? ;)))\n-- \nEygene\n"},{"id":"35941","messageId":"81b0412b0703010121s59884556ha36e5ff72010f96c@mail.gmail.com","threadId":"7019","inReplyTo":"20070301091058.GA63606@codelabs.ru","subject":"Re: Memory overrun in http-push.c","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-03-01T09:21:47Z","receivedAt":"2007-03-01T09:21:47Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 3/1/07, Eygene Ryabinkin wrote:\n> OK, I've forgot to ask in my previous letter: will the issue with\n> '+11' instead of '+1' be fixed (or its already fixed)? Or 11 is 10 + 1,\n> where 10 it strlen(\"git\") trice plus one just to be sure? ;)))\n\nYour patch is already commited.\n\nhttp://www.kernel.org/git/?p=git/git.git;a=commit;h=2c46759db757eb742590e8547cb0c63e8bdb1da1\n"},{"id":"35945","messageId":"7vslcpux62.fsf@assigned-by-dhcp.cox.net","threadId":"7019","inReplyTo":"81b0412b0703010015l5c91c68pd4748ae379db98bb@mail.gmail.com","subject":"Re: Memory overrun in http-push.c","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-03-01T09:32:05Z","receivedAt":"2007-03-01T09:32:05Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Alex Riesen\" writes:\n\n> On 3/1/07, Eygene Ryabinkin wrote:\n>> As Johannes pointed out, old habits are still alive. And when some\n>> tool serves me the right way, I am happy with it. To make the patch\n>> with Git I should create repository, hack there, merge it to the\n>\n> hacking on Git you already have a git repo, don't you?\n\nYou do not have to insist on using git to hack on git itself. I\nwas more annoyed by the fact that the patch was an attachment,\nthan it was generated by diff without leading a/ and b/ paths.\n\nBeing able to accept a patch that was made against freshly\nextracted tarball distribution is a good thing. I can take\ndiffs generated by GNU diff against released tarballs just\nfine.\n\nIf you make it a requirement to send even an trivially obvious\npatch from controlled source, it would make the barrier to\ncontribute much higher. Once you make it hard enough to submit\npatches, you will end up seeing only whining without patches on\nthis list. I do not think we want to go in that direction.\n"},{"id":"35953","messageId":"81b0412b0703010204m7ccba9f0nedc14a180cf1b2cf@mail.gmail.com","threadId":"7019","inReplyTo":"7vslcpux62.fsf@assigned-by-dhcp.cox.net","subject":"Re: Memory overrun in http-push.c","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-03-01T10:04:52Z","receivedAt":"2007-03-01T10:04:52Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 3/1/07, Junio C Hamano wrote:\n> >> As Johannes pointed out, old habits are still alive. And when some\n> >> tool serves me the right way, I am happy with it. To make the patch\n> >> with Git I should create repository, hack there, merge it to the\n> >\n> > hacking on Git you already have a git repo, don't you?\n>\n> You do not have to insist on using git to hack on git itself.\n\nthat wasn't it. It just haven't occurred to me at all, that someone\ncould hack on git without using it. I feel very uncomfortable\nchanging anything not under version control (specifically - not\nin git repository ;) Just haven't though of tarballs.\n"},{"id":"35958","messageId":"200703011040.35971.andyparkins@gmail.com","threadId":"7019","inReplyTo":"7vslcpux62.fsf@assigned-by-dhcp.cox.net","subject":"Re: Memory overrun in http-push.c","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-03-01T10:40:33Z","receivedAt":"2007-03-01T10:40:33Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Thursday 2007 March 01 09:32, Junio C Hamano wrote:\n\n> If you make it a requirement to send even an trivially obvious\n\nI certainly wasn't suggesting that it should be a requirement. I just thought \nthere was a certain irony. Perhaps even a lesson to be learned - find out \nwhy someone has chosen (even with git in front of them and deep enough inside \nto find bugs in it), not to use git.\n\nI think there is a usability lesson to be pulled from this situation. Why \ndidn't Eygene just say:\n\n $ tar zxvf git-tarball.tgz\n $ cd git\n $ git init\n $ vim http-push.c\n $ git diff\n\nNote, that was not an attack on Eygene - I genuinely am interested to know \nwhere we should put the documentation that tells a new user what they need to \nknow quickly.\n\nSomehow, git has failed this person. I was simply wondering in what way.\n\nHowever, Eygene's response made it sound like a situational thing - it was \ninconvenient to actually install git. Fair enough.\n\n\nAndy\n-- \nDr Andy Parkins, M Eng (hons), MIET\nandyparkins@gmail.com\n"},{"id":"35964","messageId":"20070301112611.GC63606@codelabs.ru","threadId":"7019","inReplyTo":"81b0412b0703010121s59884556ha36e5ff72010f96c@mail.gmail.com","subject":"Re: Memory overrun in http-push.c","fromName":"Eygene Ryabinkin","fromEmail":"rea-git@codelabs.ru","sentAt":"2007-03-01T11:26:11Z","receivedAt":"2007-03-01T11:26:11Z","isPatch":false,"sender":{"key":"rea-git@codelabs.ru","avatar":null},"body":"Thu, Mar 01, 2007 at 10:21:47AM +0100, Alex Riesen wrote:\n> On 3/1/07, Eygene Ryabinkin wrote:\n> >OK, I've forgot to ask in my previous letter: will the issue with\n> >'+11' instead of '+1' be fixed (or its already fixed)? Or 11 is 10 + 1,\n> >where 10 it strlen(\"git\") trice plus one just to be sure? ;)))\n> \n> Your patch is already commited.\n\nThank you!\n-- \nEygene\n"},{"id":"35972","messageId":"20070301120042.GD63606@codelabs.ru","threadId":"7019","inReplyTo":"200703011040.35971.andyparkins@gmail.com","subject":"Re: Memory overrun in http-push.c","fromName":"Eygene Ryabinkin","fromEmail":"rea-git@codelabs.ru","sentAt":"2007-03-01T12:00:42Z","receivedAt":"2007-03-01T12:00:42Z","isPatch":false,"sender":{"key":"rea-git@codelabs.ru","avatar":null},"body":"Good day!\n\n> was more annoyed by the fact that the patch was an attachment,\n> than it was generated by diff without leading a/ and b/ paths.\n\nSo, git is unable to use this type of patches directly and I will\nneed to do\n$ patch < patchfile\n$ rm file.orig\n$ git commit\n\nJust wondering what is bad with the diffs without leading a/ and b/.\n\n> I certainly wasn't suggesting that it should be a requirement. I just thought\n> there was a certain irony. Perhaps even a lesson to be learned - find out \n> why someone has chosen (even with git in front of them and deep enough inside \n> to find bugs in it), not to use git.\n\nI've just realized that I need git because I need disconnected\ncommits. That's why I left my beloved SVN and started to hack GIT ;))\n\nBy the way, I am missing one thing: the Id keyword in the file. The\nproblem is that when some user is telling me: there is a bug in the\nfunction a() that is inside the file b.c, then I can ask him to\ngive me the $Id$ tag of the file and I will have the full information\nabout the file version. Can I have it with git if user has just the\nsources without any signs of the file versions? I've glanced over\nthe git manual, but was unable to find anything usable.\n\n> I think there is a usability lesson to be pulled from this situation. Why \n> didn't Eygene just say:\n> \n> $ tar zxvf git-tarball.tgz\n> $ cd git\n> $ git init\n> $ vim http-push.c\n> $ git diff\n> \n> Note, that was not an attack on Eygene - I genuinely am interested to know \n> where we should put the documentation that tells a new user what they need to \n> know quickly.\n> \n> Somehow, git has failed this person. I was simply wondering in what way.\n> \n> However, Eygene's response made it sound like a situational thing - it was \n> inconvenient to actually install git. Fair enough.\n\nNot incovinient to install git, but it was just convinient to me to\nuse FreeBSD port. The other way round ;))\n-- \nEygene\n"},{"id":"35974","messageId":"7vr6s9qi8b.fsf@assigned-by-dhcp.cox.net","threadId":"7019","inReplyTo":"20070301120042.GD63606@codelabs.ru","subject":"Re: Memory overrun in http-push.c","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-03-01T12:08:20Z","receivedAt":"2007-03-01T12:08:20Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Eygene Ryabinkin writes:\n\n> Good day!\n>\n>> was more annoyed by the fact that the patch was an attachment,\n>> than it was generated by diff without leading a/ and b/ paths.\n>\n> So, git is unable to use this type of patches directly and I will\n> need to do\n> $ patch < patchfile\n> $ rm file.orig\n> $ git commit\n\nIn case it was unclear, I was saying that \"attachment was more\nannoying\" than \"diff output that does not follow the established\nconvention to be applied with patch -p1\". Both I can handle,\nbut dealing with the former is more work for me.\n"},{"id":"35975","messageId":"20070301132030.GK57456@codelabs.ru","threadId":"7019","inReplyTo":"7vr6s9qi8b.fsf@assigned-by-dhcp.cox.net","subject":"Re: Memory overrun in http-push.c","fromName":"Eygene Ryabinkin","fromEmail":"rea-git@codelabs.ru","sentAt":"2007-03-01T13:20:31Z","receivedAt":"2007-03-01T13:20:31Z","isPatch":false,"sender":{"key":"rea-git@codelabs.ru","avatar":null},"body":"> In case it was unclear, I was saying that \"attachment was more\n> annoying\" than \"diff output that does not follow the established\n> convention to be applied with patch -p1\". Both I can handle,\n> but dealing with the former is more work for me.\n\nAh, sorry, got it.\n-- \nEygene\n"},{"id":"35986","messageId":"Pine.LNX.4.63.0703011802130.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"7019","inReplyTo":"20070301120042.GD63606@codelabs.ru","subject":"Re: Memory overrun in http-push.c","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-03-01T17:11:26Z","receivedAt":"2007-03-01T17:11:26Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 1 Mar 2007, Eygene Ryabinkin wrote:\n\n> By the way, I am missing one thing: the Id keyword in the file. The \n> problem is that when some user is telling me: there is a bug in the \n> function a() that is inside the file b.c, then I can ask him to give me \n> the $Id$ tag of the file and I will have the full information about the \n> file version.\n\nThe problem is: Git does not track files, but rather trees. So, there is \nno sane way to add an Id.\n\nBut all is not lost! If your colleague sends you the offending file, you \ncan calculate the object name from it by\n\n\t$ git-hash-object -t blob \n\nIf the file is too big, your colleague can run it herself and send you the \nobject name (it is a 40 character hex string, but the first 8 or so should \nreally be sufficient).\n\nThen you can run\n\n\t$ git log -p HEAD \n\nin your repository, and search for \"index \". You will find \nthe commit which changed the file _from_ the state your colleague is \nseeing.\n\nThe idea is that the diff shows not only the names, but also a line \"index \n..\", where the abbrev's are the abbreviated object names \nof the old and new versions of that file.\n\nBTW we had a similar discussion a while ago, which made me even write a \npatch for git-name-rev to name objects, too, but it was rejected as the \nworkflow I outlined above is already sufficient for your use case.\n\nHth,\nDscho\n"},{"id":"35988","messageId":"20070301175200.GA21433@informatik.uni-freiburg.de","threadId":"7019","inReplyTo":"20070301120042.GD63606@codelabs.ru","subject":"Re: Memory overrun in http-push.c","fromName":"Uwe Kleine-König","fromEmail":"ukleinek@informatik.uni-freiburg.de","sentAt":"2007-03-01T17:52:00Z","receivedAt":"2007-03-01T17:52:00Z","isPatch":false,"sender":{"key":"u.kleine-koenig@pengutronix.de","avatar":"https://gravatar.com/avatar/354b5e3ceb2806a2f1e1e382ac29ddbdad18288654da62b61eb13583a857eee7?d=mp&s=160"},"body":"Hello Eygene,\n\n> By the way, I am missing one thing: the Id keyword in the file. The\n> problem is that when some user is telling me: there is a bug in the\n> function a() that is inside the file b.c, then I can ask him to\n> give me the $Id$ tag of the file and I will have the full information\n> about the file version. Can I have it with git if user has just the\n> sources without any signs of the file versions? I've glanced over\n> the git manual, but was unable to find anything usable.\nGit and the linux kernel (can) have the commit hash in their version.\n\nFor git you can see it with\n\n\t$ git version\n\tgit version 1.5.0.2.260.g2eb065\n\nfor the linux kernel you have to enable CONFIG_LOCALVERSION_AUTO, then\nyou get:\n\n\t$ uname -r\n\t2.6.20-g509cb37e\n\nKnowing the commit you can determine the corresponding \"version\" of b.c.\n\nThere are some other possiblities to communicate that hash. E.g.\na tar archive created with\n\t\n\t$ git-archive --format=tar ...\n\nallows you do to\n\n\t$ git-get-tar-commit-id < $tarfile\n\t2eb06531e3d53c2604f20c32e5cb791d5044ff02\n\nBest regards\nUwe\n\n-- \nUwe Kleine-König\n\nexit vi, lesson IV:\nZ Z\n\nNB: may write current file\n"},{"id":"35993","messageId":"200703011831.29321.andyparkins@gmail.com","threadId":"7019","inReplyTo":"Pine.LNX.4.63.0703011802130.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: Memory overrun in http-push.c","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-03-01T18:31:27Z","receivedAt":"2007-03-01T18:31:27Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Thursday 2007, March 01, Johannes Schindelin wrote:\n\n> The problem is: Git does not track files, but rather trees. So, there\n> is no sane way to add an Id.\n\n> If the file is too big, your colleague can run it herself and send\n> you the object name (it is a 40 character hex string, but the first 8\n> or so should really be sufficient).\n\nSo when you say \"there is no sane way to add an Id\", you meant \"here is \na perfect string that would act as an Id\"? ;-)\n\n\n\nAndy\n-- \nDr Andy Parkins, M Eng (hons), MIET\nandyparkins@gmail.com\n"},{"id":"35996","messageId":"Pine.LNX.4.63.0703011941020.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"7019","inReplyTo":"200703011831.29321.andyparkins@gmail.com","subject":"Re: Memory overrun in http-push.c","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-03-01T18:41:35Z","receivedAt":"2007-03-01T18:41:35Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 1 Mar 2007, Andy Parkins wrote:\n\n> On Thursday 2007, March 01, Johannes Schindelin wrote:\n> \n> > The problem is: Git does not track files, but rather trees. So, there\n> > is no sane way to add an Id.\n> \n> > If the file is too big, your colleague can run it herself and send\n> > you the object name (it is a 40 character hex string, but the first 8\n> > or so should really be sufficient).\n> \n> So when you say \"there is no sane way to add an Id\", you meant \"here is \n> a perfect string that would act as an Id\"? ;-)\n\nGot it.\n\nSo, in a very real sense, we have file ids. Even tree ids. And commit ids.\n\nCiao,\nDscho\n"},{"id":"35998","messageId":"200703011931.32170.andyparkins@gmail.com","threadId":"7019","inReplyTo":"Pine.LNX.4.63.0703011941020.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: Memory overrun in http-push.c","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-03-01T19:31:30Z","receivedAt":"2007-03-01T19:31:30Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Thursday 2007, March 01, Johannes Schindelin wrote:\n\n> Got it.\n>\n> So, in a very real sense, we have file ids. Even tree ids. And commit\n> ids.\n\nAbsolutely. Moreso than CVS/SVN. Putting $Id$ $Rev$ in a git managed \nfile would have far more meaning that it does in a CVS managed file.\n\nActually, $Id$ covers the file hash; $Rev$ covers the commit hash. I \nwonder if the tree id would be useful to finish the set?\n\nThe reason it's so hard to do is because putting the file id in the file \nwould change the file, and hence its Id. Ouch. However, I reckon the \nupcoming gitattributes stuff is going to have no trouble keeping the \nfile contents stable from git's point of view and yet let you \nmangle/unmangle the contents with this keyword stuff.\n\nActually once gitattributes exists we almost have to have a $Id$, the \nhash of the working directory file isn't stable because it might have \nhad it's line endings mangled. On the other hand we could argue that \ngit-hash-object should have unmangling options anyway.\n\n\n\nAndy\n-- \nDr Andy Parkins, M Eng (hons), MIET\nandyparkins@gmail.com\n"},{"id":"36005","messageId":"Pine.LNX.4.63.0703012140370.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"7019","inReplyTo":"200703011931.32170.andyparkins@gmail.com","subject":"Re: Memory overrun in http-push.c","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-03-01T20:43:17Z","receivedAt":"2007-03-01T20:43:17Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 1 Mar 2007, Andy Parkins wrote:\n\n> Putting $Id$ $Rev$ in a git managed file would have far more meaning \n> that it does in a CVS managed file.\n\nNo. My point was that you do not even have to have an id. The hash of the \nobject is the id.\n\nThis is obviously much better than the mess of CVS/SVN's file ids. There \nis an option, even, to switch off key expansion, so you can have erroneous \nids. That just cannot happen with hashes.\n\nOf course, it does not give you any hint about when this file was current. \nBut there is no way to tell in distributed development _anyway_. You have \nto look it up, when, and who, changed the file to the current state.\n\nCiao,\nDscho\n"},{"id":"36010","messageId":"81b0412b0703011343je4de3b6ra5c1d577da041dcf@mail.gmail.com","threadId":"7019","inReplyTo":"Pine.LNX.4.63.0703011802130.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: Memory overrun in http-push.c","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-03-01T21:43:00Z","receivedAt":"2007-03-01T21:43:00Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 3/1/07, Johannes Schindelin wrote:\n>\n> > By the way, I am missing one thing: the Id keyword in the file. The\n> > problem is that when some user is telling me: there is a bug in the\n> > function a() that is inside the file b.c, then I can ask him to give me\n> > the $Id$ tag of the file and I will have the full information about the\n> > file version.\n>\n> The problem is: Git does not track files, but rather trees. So, there is\n> no sane way to add an Id.\n>\n> But all is not lost! If your colleague sends you the offending file, you\n> can calculate the object name from it by\n>\n> $ git-hash-object -t blob \n>\n\nWont work. The ids in question are really strings embedded into object.\nSomething like:\n\n $Id 1.2 user filename.c$\n\nThey can be found, extracted from the binary and sent to developer\nwith a bug report. It's more of a build signature.\nIOW, the colleague in question has to have the source, which,\nI suspect, he wont.\n\nOf course, it's very simple to embed the HEAD into build and\ntell the tester to send the SHA-1 in case of bug report.\n"},{"id":"36014","messageId":"20070301215455.GC9254@spearce.org","threadId":"7019","inReplyTo":"81b0412b0703011343je4de3b6ra5c1d577da041dcf@mail.gmail.com","subject":"Re: Memory overrun in http-push.c","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-03-01T21:54:55Z","receivedAt":"2007-03-01T21:54:55Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Alex Riesen wrote:\n> Wont work. The ids in question are really strings embedded into object.\n> Something like:\n> \n> $Id 1.2 user filename.c$\n> \n> They can be found, extracted from the binary and sent to developer\n> with a bug report. It's more of a build signature.\n> IOW, the colleague in question has to have the source, which,\n> I suspect, he wont.\n> \n> Of course, it's very simple to embed the HEAD into build and\n> tell the tester to send the SHA-1 in case of bug report.\n\nYes. Either the commit SHA-1 or the output of git-describe does\nthe trick. Even better when your program prints this value on\ndemand, like say `git version`. ;-)\n\nBefore programmers got smart and wrote switches to dump the\nversion (aka -v/-V/--version) users were expected to use\n`strings frob | grep '$Id' | mail baddev@example.com` to\nsend in bug reports. What a world we live in! ;-)\n\n-- \nShawn.\n"},{"id":"36078","messageId":"200703021005.13620.andyparkins@gmail.com","threadId":"7019","inReplyTo":"Pine.LNX.4.63.0703012140370.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: Memory overrun in http-push.c","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-03-02T10:05:12Z","receivedAt":"2007-03-02T10:05:12Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Thursday 2007 March 01 20:43, Johannes Schindelin wrote:\n\n> > Putting $Id$ $Rev$ in a git managed file would have far more meaning\n> > that it does in a CVS managed file.\n>\n> No. My point was that you do not even have to have an id. The hash of the\n> object is the id.\n\nI think you're thinking of these tags in too strict terms. You're right they \naren't /needed/ you can query the version control system for the information. \nHowever, if you sent them out in a tarball to someone who didn't have or want \nto have your version control system, then it is much easier for them to be \nable to tell you the $Id$ field from the file itself than to generate the \nhash or send you a copy of the file.\n\nThey're purely for information. As I've mentioned before, personally the only \nplace I use them is in inkscape SVG files (thank the lord SVG's are ASCII), \nwhere I add a text field that appears on the diagram itself and I write $Id$ \nas the text. Then whenever I print that diagram out (which makes it much \nharder to hash), I will know which version of the file I'm looking at. This \nis the /only/ thing I miss from subversion.\n\n> This is obviously much better than the mess of CVS/SVN's file ids. There\n> is an option, even, to switch off key expansion, so you can have erroneous\n> ids. That just cannot happen with hashes.\n\nAs I said, I don't think anyone ever imagines that these Id fields are \nabsolute guarantees of correctness - nor does any version control \nsystem /ever/ read them and use them. They are there only as a convenience \nfor the user. Obviously, I could just edit the $Id$ anyway if I wanted, so \nit obviously isn't absolute.\n\n> Of course, it does not give you any hint about when this file was current.\n> But there is no way to tell in distributed development _anyway_. You have\n> to look it up, when, and who, changed the file to the current state.\n\nWhat about this though:\n * Tag a release\n * Export the working tree into a fresh directory\n * Edit each source file to put the hash of the tagged revision into\n every file.\n * Edit the makefile to include the tag hash in the released version\n * tar it up\n * Release\nIt's such a mundane, useless waste of time to edit the hash in by hand - why \ncan't the version control system do it?\n\nIt's already nearly there in the form of git-describe. It's only purpose is \nto supply strings that describe the current revision. Well, so would $Id$, \nbut for files instead.\n\nI don't see that keywords are the evil they're made out to be; they're for \nconvenience, not for absolute truth. When some random printout of the source \nturns up, at least the $Id$ might give you a clue as to which version it is. \nIf it doesn't, well you're no worse off.\n\nHere's another similar idea: generating copyright lines. Let's say we want to \ncopyright every source file - that means writing \"(C) Junio, (C) Johannes, \netc\" at the top of every file. Wouldn't it be nicer if we could put \n$Copyright$ in the file, then have some git-blame-like machinery fill in the \ncopyrights automatically based on who's made contributions?\n\ne.g.\n\n git-blame refs.c | sort -f 2 | uniq -c -s 10 -w 10 | sort -nr\n\n\n\nAndy\n-- \nDr Andy Parkins, M Eng (hons), MIET\nandyparkins@gmail.com\n"},{"id":"36091","messageId":"es9cnt$egh$1@sea.gmane.org","threadId":"7019","inReplyTo":"20070301120042.GD63606@codelabs.ru","subject":"Re: Memory overrun in http-push.c","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-03-02T14:38:01Z","receivedAt":"2007-03-02T14:38:01Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Eygene Ryabinkin wrote:\n\n> By the way, I am missing one thing: the Id keyword in the file. The\n> problem is that when some user is telling me: there is a bug in the\n> function a() that is inside the file b.c, then I can ask him to\n> give me the $Id$ tag of the file and I will have the full information\n> about the file version. Can I have it with git if user has just the\n> sources without any signs of the file versions? I've glanced over\n> the git manual, but was unable to find anything usable.\n \nFirst, keyword expansion on checkout (CVS-like) is an abomination;\nthe proper way is to do it on _build_ time, like git and Linux kernel\ndo, so \"git version\" (or \"git --version\") and \"uname -a\" gives us\nthe version which can be used with git to go to it.\n\nSecond, there were some work on git mailing list to create git command\nwhich given a blob (or sha1 of a blob object) would list all commits\n(in date order) which have this exact version of a file (of a blob).\n\nThird, tar files generated by git-acrhive have version embedded as\na comment in them.\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"36092","messageId":"es9d7l$egh$2@sea.gmane.org","threadId":"7019","inReplyTo":"200703021005.13620.andyparkins@gmail.com","subject":"Re: Memory overrun in http-push.c","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-03-02T14:46:26Z","receivedAt":"2007-03-02T14:46:26Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Andy Parkins wrote:\n\n\n> What about this though:\n> * Tag a release\n> * Export the working tree into a fresh directory\n> * Edit each source file to put the hash of the tagged revision into\n> every file.\n> * Edit the makefile to include the tag hash in the released version\n> * tar it up\n> * Release\n> It's such a mundane, useless waste of time to edit the hash in by hand - why \n> can't the version control system do it?\n\nWhat about this (that is roughtly what git and Linux kernel use):\n * Tag a release\n * Issue \"make dist\" which would automatically replace @@STH_VERSION@@\n (or ++STH_VERSION++ for example in Perl files) with result of\n \"git describe\" (although I think that plain old \"make\" also does this)\n _and_ create proper STH_VERSION file\n * tar it up using \"git archive --format=tar\" which would add version\n as a tar comment\n * Release\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"36094","messageId":"Pine.LNX.4.63.0703021617040.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"7019","inReplyTo":"es9cnt$egh$1@sea.gmane.org","subject":"Re: Memory overrun in http-push.c","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-03-02T15:17:21Z","receivedAt":"2007-03-02T15:17:21Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 2 Mar 2007, Jakub Narebski wrote:\n\n> Second, there were some work on git mailing list to create git command \n> which given a blob (or sha1 of a blob object) would list all commits (in \n> date order) which have this exact version of a file (of a blob).\n\nIt was shot down, and rightly so.\n\nCiao,\nDscho\n"},{"id":"36096","messageId":"200703021522.44592.andyparkins@gmail.com","threadId":"7019","inReplyTo":"es9d7l$egh$2@sea.gmane.org","subject":"Re: Memory overrun in http-push.c","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-03-02T15:22:43Z","receivedAt":"2007-03-02T15:22:43Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Friday 2007 March 02 14:46, Jakub Narebski wrote:\n\n> What about this (that is roughtly what git and Linux kernel use):\n> * Tag a release\n> * Issue \"make dist\" which would automatically replace @@STH_VERSION@@\n> (or ++STH_VERSION++ for example in Perl files) with result of\n> \"git describe\" (although I think that plain old \"make\" also does this)\n> _and_ create proper STH_VERSION file\n> * tar it up using \"git archive --format=tar\" which would add version\n> as a tar comment\n> * Release\n\nYep; you've improved the workflow for my example. However, it's not quite the \nsame because in git the tokens in the \".perl\" files are substituted into \nfiles without the suffix. This means that those files aren't the real source \nfiles. You can't put that token in the source files themselves because that \nwould change their content and would then show up to git as changes.\n\nTherefore git itself has to be involved with the keyword substitution, because \nyou want it to be blind to that substitution when it's checking for changes.\n\nOf course that's all predicated on you actually wanting keywords. For people \nthat don't want them, I can see why the point is moot.\n\n\nAndy\n-- \nDr Andy Parkins, M Eng (hons), MIET\nandyparkins@gmail.com\n"},{"id":"36097","messageId":"200703021523.37010.andyparkins@gmail.com","threadId":"7019","inReplyTo":"es9cnt$egh$1@sea.gmane.org","subject":"Re: Memory overrun in http-push.c","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-03-02T15:23:35Z","receivedAt":"2007-03-02T15:23:35Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Friday 2007 March 02 14:38, Jakub Narebski wrote:\n\n> First, keyword expansion on checkout (CVS-like) is an abomination;\n> the proper way is to do it on _build_ time, like git and Linux kernel\n\nWhat about my SVG example? There is no build time, the file is the file.\n\n\nAndy\n-- \nDr Andy Parkins, M Eng (hons), MIET\nandyparkins@gmail.com\n"},{"id":"36098","messageId":"vpqd53racjg.fsf@olympe.imag.fr","threadId":"7019","inReplyTo":"200703021523.37010.andyparkins@gmail.com","subject":"Re: Memory overrun in http-push.c","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2007-03-02T15:30:11Z","receivedAt":"2007-03-02T15:30:11Z","isPatch":false,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"Andy Parkins writes:\n\n> On Friday 2007 March 02 14:38, Jakub Narebski wrote:\n>\n>> First, keyword expansion on checkout (CVS-like) is an abomination;\n>> the proper way is to do it on _build_ time, like git and Linux kernel\n>\n> What about my SVG example? There is no build time, the file is the file.\n\nSame with manually written HTML, or even just plain text files, or ...\n\nA typical other example is when you're working with people having some\nkind of alergy to revision control systems. Then, you have to send the\nsource, and they send you back the modified source. That's very hard\nto manage without some kind of timestamp within the file.\n\nHowever, I have to admit that workflows requiring keyword expansions\nstill appear dirty to me.\n\nA (dirty too) solution is to have a pre-commit hook that would update\nthe keywords for each modified file. Then, the keyword is in the\nsource itself.\n\n-- \nMatthieu\n"},{"id":"36101","messageId":"200703021549.05761.andyparkins@gmail.com","threadId":"7019","inReplyTo":"vpqd53racjg.fsf@olympe.imag.fr","subject":"Re: Memory overrun in http-push.c","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-03-02T15:48:48Z","receivedAt":"2007-03-02T15:48:48Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Friday 2007 March 02 15:30, Matthieu Moy wrote:\n\n> A (dirty too) solution is to have a pre-commit hook that would update\n> the keywords for each modified file. Then, the keyword is in the\n> source itself.\n\nThat would be bad for merges though. I think it's got to be filtered out in a \npre-commit or equivalent script.\n\n\nAndy\n\n-- \nDr Andy Parkins, M Eng (hons), MIET\nandyparkins@gmail.com\n"},{"id":"36116","messageId":"Pine.LNX.4.63.0703022014410.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"7019","inReplyTo":"200703021005.13620.andyparkins@gmail.com","subject":"Re: Memory overrun in http-push.c","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-03-02T19:16:25Z","receivedAt":"2007-03-02T19:16:25Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 2 Mar 2007, Andy Parkins wrote:\n\n> Here's another similar idea: generating copyright lines. Let's say we \n> want to copyright every source file - that means writing \"(C) Junio, (C) \n> Johannes, etc\" at the top of every file. Wouldn't it be nicer if we \n> could put $Copyright$ in the file, then have some git-blame-like \n> machinery fill in the copyrights automatically based on who's made \n> contributions?\n\nThat's a horrible idea. A typo fix is not copyrightable. You'd add these. \nAn obious fix is not copyrightable. You'd add these cases, too.\n\nBesides, IMHO adding copyright should be a _concious_ act.\n\nCiao,\nDscho\n"},{"id":"36122","messageId":"200703021942.58780.andyparkins@gmail.com","threadId":"7019","inReplyTo":"Pine.LNX.4.63.0703022014410.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: Memory overrun in http-push.c","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-03-02T19:42:57Z","receivedAt":"2007-03-02T19:42:57Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Friday 2007, March 02, Johannes Schindelin wrote:\n\n> On Fri, 2 Mar 2007, Andy Parkins wrote:\n> > Here's another similar idea: generating copyright lines. Let's say\n> > we want to copyright every source file - that means writing \"(C)\n> > Junio, (C) Johannes, etc\" at the top of every file. Wouldn't it be\n> > nicer if we could put $Copyright$ in the file, then have some\n> > git-blame-like machinery fill in the copyrights automatically based\n> > on who's made contributions?\n>\n> That's a horrible idea. A typo fix is not copyrightable. You'd add\n> these. An obious fix is not copyrightable. You'd add these cases,\n> too.\n\nWell, I wasn't actually suggesting that as a final solution, it might be \nthat it's done by more than just line count, and that some clever bit \nof machinery measures real contribution. That wasn't really the point.\n\n> Besides, IMHO adding copyright should be a _concious_ act.\n\nWell, IMHO, the concious act was the commital of a change.\n\nA lot of your objection to this seems to be \"IMHO\". Fine: you don't \nlike keywords, you wouldn't be /forced/ to use them. I can see a use \nfor them. I'm having a lot of trouble understanding why they are seen \nas inherently evil. Difficult to implement, I would accept, \nimpractical to make work in git would be fine; but not this hand wavery \nthat there is no conceivable use for them.\n\n\nAndy\n\n-- \nDr Andy Parkins, M Eng (hons), MIET\nandyparkins@gmail.com\n"},{"id":"36136","messageId":"7vr6s7dzrh.fsf@assigned-by-dhcp.cox.net","threadId":"7019","inReplyTo":"Pine.LNX.4.63.0703021617040.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"identifying blobs (was Re: Memory overrun in http-push.c)","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-03-02T22:52:34Z","receivedAt":"2007-03-02T22:52:34Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> On Fri, 2 Mar 2007, Jakub Narebski wrote:\n>\n>> Second, there were some work on git mailing list to create git command \n>> which given a blob (or sha1 of a blob object) would list all commits (in \n>> date order) which have this exact version of a file (of a blob).\n>\n> It was shot down, and rightly so.\n\nI think this \"rightly\" needs a clarification (otherwise Jakub\nwouldn't have said the above).\n\nIt wasn't that identifying the commit that contained the version\nof the file was not needed. It is just there already is a way\nto do so, and \"to create git command\" turns out to be\nunnecessary. Something like:\n\n\t$ hash=`git hash-object --stdin <$file_in_question`\n\t$ git log -z --raw -r --abbrev=40 |\n grep -z '^:[0-7][0-7]* [0-7][0-7]* [0-9a-f][0-9a-f]* '\"$hash\"'\n"},{"id":"36137","messageId":"Pine.LNX.4.64.0703021505380.3953@woody.linux-foundation.org","threadId":"7019","inReplyTo":"7vr6s7dzrh.fsf@assigned-by-dhcp.cox.net","subject":"Re: identifying blobs (was Re: Memory overrun in http-push.c)","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-03-02T23:10:30Z","receivedAt":"2007-03-02T23:10:30Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 2 Mar 2007, Junio C Hamano wrote:\n> \n> It wasn't that identifying the commit that contained the version\n> of the file was not needed. It is just there already is a way\n> to do so, and \"to create git command\" turns out to be\n> unnecessary. Something like:\n> \n> \t$ hash=`git hash-object --stdin <$file_in_question`\n> \t$ git log -z --raw -r --abbrev=40 |\n> grep -z '^:[0-7][0-7]* [0-7][0-7]* [0-9a-f][0-9a-f]* '\"$hash\"'\n\nThat's not very nice, because if the blob is already in the *top* commit, \nand isn't changed in a long long time, you'll not see it until it changes \n(which is potentially at the root commit when it was introduced).\n\nSo it's better to do something like\n\n - get the hash\n\n\thash=`git hash-object --stdin <$file_in_question`\n\n - see if it is in the current top of the tree\n\n\tgit ls-tree -r HEAD | cut -d3- | grep ^$hash\n\n - after that, start doing the backwards searching for things where it \n went away if it was there before (roughly your \"git log -z ...\")\n\nwhich should be fairly simple and straightforward.\n\nFor extra bonus points, the script could be trivially written so that it \nallows the user to specify a path limiter, so that you say \"can you tell \nme which version this blob existed in, but I only want to know about \ndrivers/scsi/ and include/scsi/\"\n\n\t\tLinus\n"},{"id":"36228","messageId":"Pine.LNX.4.64.0703040234510.6485@iabervon.org","threadId":"7019","inReplyTo":"200703021005.13620.andyparkins@gmail.com","subject":"Re: Memory overrun in http-push.c","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2007-03-04T08:17:31Z","receivedAt":"2007-03-04T08:17:31Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Fri, 2 Mar 2007, Andy Parkins wrote:\n\n> What about this though:\n> * Tag a release\n> * Export the working tree into a fresh directory\n> * Edit each source file to put the hash of the tagged revision into\n> every file.\n> * Edit the makefile to include the tag hash in the released version\n> * tar it up\n> * Release\n> It's such a mundane, useless waste of time to edit the hash in by hand - why \n> can't the version control system do it?\n\nActually, how about doing keyword expansion just like the new CRLF\nhandling? Have the text filter replace $Id...$ with $Id$ going into the \ndatabase, and $Id$ with $Id $ coming out of the database. The info \ncould even include the commit (although that might be confusing for files \nthat you haven't changed since you checked them out, and when you checked \nthem out, they weren't changed in that commit; the commit would be a sort \nof arbitrary choice among commits that have that file).\n\nIt seems to me like keywords fit the pattern we now have (with \nCRLF-conversion) of data which isn't tracked, but is present in working \ndirectory files. In the CRLF case, it's a constant character (CR), but \nthere's no reason we couldn't have the non-canonical form depend on more \ninformation. (And we'd beat CVS/SVN for accuracy: if keyword substitution \nisn't on, nothing appears in $Id$ tags, rather than being left with \nsomething inaccurate).\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"36229","messageId":"7virdh76kh.fsf@assigned-by-dhcp.cox.net","threadId":"7019","inReplyTo":"Pine.LNX.4.64.0703040234510.6485@iabervon.org","subject":"Re: Memory overrun in http-push.c","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-03-04T08:31:58Z","receivedAt":"2007-03-04T08:31:58Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Daniel Barkalow writes:\n\n> Actually, how about doing keyword expansion just like the new CRLF\n> handling?\n\nThat part is true, but practically speaking the only thing you\ncan honestly replace is $Id$ with blob object name, and nothing\nelse. Trying to put anything that is available via commit would\nat best telling a lie and at worst ending up denying the index\n(and denying the index is denying git as somebody said). You\ncould fake the values for $Author$ and $Date$ from HEAD commit,\nbut your index may or may not match HEAD commit when you check\nout path from it.\n"},{"id":"36230","messageId":"Pine.LNX.4.64.0703040335110.6485@iabervon.org","threadId":"7019","inReplyTo":"7virdh76kh.fsf@assigned-by-dhcp.cox.net","subject":"Re: Memory overrun in http-push.c","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2007-03-04T09:18:52Z","receivedAt":"2007-03-04T09:18:52Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Sun, 4 Mar 2007, Junio C Hamano wrote:\n\n> Daniel Barkalow writes:\n> \n> > Actually, how about doing keyword expansion just like the new CRLF\n> > handling?\n> \n> That part is true, but practically speaking the only thing you\n> can honestly replace is $Id$ with blob object name, and nothing\n> else. Trying to put anything that is available via commit would\n> at best telling a lie and at worst ending up denying the index\n> (and denying the index is denying git as somebody said). You\n> could fake the values for $Author$ and $Date$ from HEAD commit,\n> but your index may or may not match HEAD commit when you check\n> out path from it.\n\nI was somehow expecting the index to be on the \"working directory\" side of \nconversions, but that obviously doesn't work very well (since you'd get a \nton of unreachable blobs all the time that way). Even so, I think the \nuseful thing would the the \"git-describe\" for HEAD, if the index entry is \nactually from HEAD (otherwise, it's a state that nobody else has seen, \nright? No point in trying to specify further...). I don't think Author and \nDate from a commit really works, because they wouldn't actually reflect \nthe last change to anything near the tag, necessarily. The commit hash, on \nthe other hand, tends you what to run blame on.\n\nBut, in any case, $Id $ would put into the working directory \nfile (and suitable installed derivates thereof) something that would lead \npeople with the repository to the actual blob, with at least a possible \ncontext. $Id :$, for =HEAD, if HEAD: \nis , should be just right.\n\nIs it common to check out files from the index which don't match HEAD? The \nonly case I can think of is resetting to a state stored in the index with \nupdate-index. I think my personal workflow is always HEAD->index->working \ndirectory->index->new HEAD.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"}]}