{"thread":{"id":"619","subject":"Summary of core GIT while you are away.","startedAt":"2005-05-14T10:51:14Z","lastAt":"2005-05-27T05:21:30Z","messageCount":28,"participants":["Junio C Hamano","Linus Torvalds","Petr Baudis","Daniel Barkalow","Kay Sievers","H. Peter Anvin"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"3298","messageId":"7vzmuy13od.fsf@assigned-by-dhcp.cox.net","threadId":"619","inReplyTo":null,"subject":"Summary of core GIT while you are away.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-05-14T10:51:14Z","receivedAt":"2005-05-14T10:51:14Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Hoping that you had a good time during your vacation, and at the\nsame time also hoping to help you catch up with GIT traffic,\nhere is my version of the summary of things that happened in the\nGIT community around core GIT [*1*].\n\n - Just when I was forced to discontinue git-jc tree because my\n ISP webspace was running out, Petr Baudis started git-pb tree\n hosted at kernel.org next to his cogito repository, promising\n to pick up and keep good bits from the mailing list traffic.\n\n He's been doing quite a good job at it and if you pull from\n his tree, you will not miss anything worth keeping. I can\n personally vouch for the crap-free-ness of his tree up to\n commit 95649d6cf9ec68f05d1dc57ec1b989b8d263a7ae (not that I\n suspect Petr will put crap in the tree after that, but that\n is the head as of this writing). They consist of half\n bugfixes and half enhancements; all of them help Porcelain\n layers and end users. Old git-jc tree has all been sucked\n into git-pb before being shut down, so we did not lose\n anything from there either.\n\n - A notable change you need to adjust your scripts and .profile\n to is that GIT environment variable names have changed. All\n of them now have GIT_ as prefix. Old names continue to work\n for now, though.\n\n - Nicolas Pitre's deltification patch is still cooking and in\n its latest incarnation it looked quite promising to me (the\n impact to the core is kept reasonably small and cleanly\n isolated). Once fsck is made aware of it in the next round,\n I expect it to be ready to merge.\n\n - Brad Roberts has been working on libification to remove the\n assumption of having a single active_cache array. I have\n minor qualms about it (I think it should also be tied with\n the index.lock handling for updates), but other than that, it\n looked admirably cleanly done. I expect it to be in a\n mergeable state in the next round if/when he catches up with\n the tip of git-pb tree.\n\n - David Greaves has done all the heavy lifting for core GIT\n documentation. It now is hosted at kernel.org with a nice\n web interface.\n\n - I have sent out about a dozen patches Petr has not caught up,\n mostly because we work in different timezones. Other than\n that I have not seen anything immediately mergeable to the\n core GIT in the mailing list traffic.\n\n - Also you see names of many people in the git-pb log who\n contributed bugfixes and enhancements. I am not belittling\n their contributions, but just not going to repeat what you\n can get from the log yourself.\n\nThat's about it. Now please start pulling from \n\n\trsync://rsync.kernel.org/pub/scm/cogito/git-pb.git/\n\n[Footnote]\n\n*1* Porcelain layer seems to have had many more interesting\ndiscussions, but I am not qualified to comment on them (I was\nnot following most of them).\n\n"},{"id":"3415","messageId":"Pine.LNX.4.58.0505160837080.28162@ppc970.osdl.org","threadId":"619","inReplyTo":"7vzmuy13od.fsf@assigned-by-dhcp.cox.net","subject":"Re: Summary of core GIT while you are away.","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-05-16T16:10:10Z","receivedAt":"2005-05-16T16:10:10Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\n\nOn Sat, 14 May 2005, Junio C Hamano wrote:\n>\n> Hoping that you had a good time during your vacation, and at the\n> same time also hoping to help you catch up with GIT traffic,\n> here is my version of the summary of things that happened in the\n> GIT community around core GIT [*1*].\n\nThanks. I'm back and reading email, but have by no means caught up yet.\n\nAnyway, everythign I've read so far makes sense, and it might make sense\nto continue git development using just git-pb. The only thing I personally\nthink sucks is the author/committer matching of git-rev-list/tree, since\nit would seem like somebody might well like to match on an arbitrary part\nof a commit, and special-casing author/committer seems somewhat broken. \nBut that's a fairly minor nit.\n\nI personally suspect that both git-rev-list and git-rev-tree should have\nan alternate output format that could be more easily grepped by subsequent\ncommands. For example, right now git-rev-list just outputs a list of\ncommit ID's, and it might make sense to have a flag to just append the\ncommit message to the output, and zero-terminate it (and if the commit\nmessage has a NUL byte in it, just truncate it at that point).\n\nThen you could just do\n\n\tgit-rev-list -v --header HEAD | grep -z 'author[^\\n]*Linus'\n\nto tell it to do the \"verbose\" thing (only showing the header of the \ncommit, not the whole message), and grep for \"Linus\" in the author line.\n\nOr, if you want to see all commits that are signed off by so-and-so, do:\n\n\tgit-rev-list -v HEAD | grep -zi 'signed-off-by:[^\\n]*so-and-so'\n\nand it would still be pretty efficient, and a _lot_ more generic and \nflexible than the \"--author\" and \"--committer\" flags.\n\nI also suspect that a lot of uses if git-rev-{tree|list} actually want to \nsee the commit stuff anyway, ie things like gitweb etc currently likely \nend up doing a separate \"git-cat-file commit \" to get the whole \ncommit information, which the \"-v\" flag would just give directly.\n\nThe only question is whether you want to have it be human-readable by\ndefault (indent the message lines with a , and nonheaders with\n+4* or something), and then have a \"-z\" flag to do the\nmachine-readable version described above.\n\nHmm?\n\n\t\tLinus\n"},{"id":"3418","messageId":"7vekc6onzc.fsf_-_@assigned-by-dhcp.cox.net","threadId":"619","inReplyTo":"Pine.LNX.4.58.0505160837080.28162@ppc970.osdl.org","subject":"rev-list/tree committer/author information.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-05-16T21:33:11Z","receivedAt":"2005-05-16T21:33:11Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":">>>>> \"LT\" == Linus Torvalds writes:\n\nLT> Anyway, everything I've read so far makes sense, and it\nLT> might make sense to continue git development using just\nLT> git-pb. The only thing I personally think sucks is the\nLT> author/committer matching of git-rev-list/tree, since it\nLT> would seem like somebody might well like to match on an\nLT> arbitrary part of a commit, and special-casing\nLT> author/committer seems somewhat broken.\n\nWell, that author/committer thing is not in git-pb yet, if I am\nnot mistaken [*1].\n\nThe only reason why I did it that way was because the strategy\ntaken by \"struct object\" derivatives seemed to pick up bare\nabsolute minimum to support actual callers that have immediate\nneed for information stored in structural fields, as opposed to\ndesigning for helping yet to be written callers by adding fields\nto hold information of \"having this might also help somebody in\nthe future\" type. And the author and committer names are in the\nstructured fields while signed-off-by and others are not. Also\nwhen author / committer name strings are intern'ed like the way\nI did, the memory consumption even for a long sequence of\ncommits are kept reasonably low. However,...\n\nLT> I personally suspect that both git-rev-list and git-rev-tree\nLT> should have an alternate output format that could be more\nLT> easily grepped by subsequent commands. For example, right\nLT> now git-rev-list just outputs a list of commit ID's, and it\nLT> might make sense to have a flag to just append the commit\nLT> message to the output, and zero-terminate it (and if the\nLT> commit message has a NUL byte in it, just truncate it at\nLT> that point).\n\nI think what you said here makes more sense [*2*]. The above\nimplies to keep the unpacked raw data as a whole to be\naccessible to the callers for at least commit objects and if we\ngo that route I think it would make more sense to do that\nuniformly for everything (probably except for pure \"blob\"\nobjects for size concerns but we might as well do them while we\nare at it). On the other hand, the current lifetime rules being\nwhat it is, that strategy may introduce memory consumption\nproblems when working on a huge project.\n\n[Footnote]\n\n*1* Petr has been applying quite good judgements. I would have\npolluted git-jc with that patch already if I were still running\nit. So far, I have been generally happy with his acceptance\ncriteria for external patches. Anything he places on hold or\njust outright returns to me, I later find rooms for improvements\nmyself, and the later rounds that eventually get accepted always\nturn out to be far cleaner, thanks to his comments.\n\n*2* At least in principle. I am not quite sure what the output\nshould look like for rev-tree.\n\n"},{"id":"3421","messageId":"20050516221957.GD8609@pasky.ji.cz","threadId":"619","inReplyTo":"7vekc6onzc.fsf_-_@assigned-by-dhcp.cox.net","subject":"Re: rev-list/tree committer/author information.","fromName":"Petr Baudis","fromEmail":"pasky@ucw.cz","sentAt":"2005-05-16T22:19:57Z","receivedAt":"2005-05-16T22:19:57Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Mon, May 16, 2005 at 11:33:11PM CEST, I got a letter\nwhere Junio C Hamano told me that...\n> >>>>> \"LT\" == Linus Torvalds writes:\n> \n> LT> Anyway, everything I've read so far makes sense, and it\n> LT> might make sense to continue git development using just\n> LT> git-pb. The only thing I personally think sucks is the\n> LT> author/committer matching of git-rev-list/tree, since it\n> LT> would seem like somebody might well like to match on an\n> LT> arbitrary part of a commit, and special-casing\n> LT> author/committer seems somewhat broken.\n> \n> Well, that author/committer thing is not in git-pb yet, if I am\n> not mistaken [*1].\n> \n> The only reason why I did it that way was because the strategy\n> taken by \"struct object\" derivatives seemed to pick up bare\n> absolute minimum to support actual callers that have immediate\n> need for information stored in structural fields, as opposed to\n> designing for helping yet to be written callers by adding fields\n> to hold information of \"having this might also help somebody in\n> the future\" type. And the author and committer names are in the\n> structured fields while signed-off-by and others are not. Also\n> when author / committer name strings are intern'ed like the way\n> I did, the memory consumption even for a long sequence of\n> commits are kept reasonably low. However,...\n\nI like Linus' suggestion. At the very least, what about making the\nmatching generic for the header? Something like --match-header or\nwhatever.\n\n> *1* Petr has been applying quite good judgements. I would have\n> polluted git-jc with that patch already if I were still running\n> it. So far, I have been generally happy with his acceptance\n> criteria for external patches. Anything he places on hold or\n> just outright returns to me, I later find rooms for improvements\n> myself, and the later rounds that eventually get accepted always\n> turn out to be far cleaner, thanks to his comments.\n\nThanks for the praise :-), but I'm actually quite unhappy with putting\npatches \"on hold\" and it's not intentional. It's just that I don't feel\nright about the patch enough to apply it immediately, and I either don't\nhave time to voice my concerns if they are non-trivial, or I just want\nsome time to think about it.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nC++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor\n"},{"id":"3422","messageId":"20050516222241.GE8609@pasky.ji.cz","threadId":"619","inReplyTo":"Pine.LNX.4.58.0505160837080.28162@ppc970.osdl.org","subject":"Re: Summary of core GIT while you are away.","fromName":"Petr Baudis","fromEmail":"pasky@ucw.cz","sentAt":"2005-05-16T22:22:41Z","receivedAt":"2005-05-16T22:22:41Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Mon, May 16, 2005 at 06:10:10PM CEST, I got a letter\nwhere Linus Torvalds told me that...\n> The only question is whether you want to have it be human-readable by\n> default (indent the message lines with a , and nonheaders with\n> +4* or something), and then have a \"-z\" flag to do the\n> machine-readable version described above.\n\nI'd prefer that, in order to be consistent with the diff tools and such.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nC++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor\n"},{"id":"3424","messageId":"Pine.LNX.4.21.0505161747290.30848-100000@iabervon.org","threadId":"619","inReplyTo":"7vekc6onzc.fsf_-_@assigned-by-dhcp.cox.net","subject":"Re: rev-list/tree committer/author information.","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2005-05-16T22:35:17Z","receivedAt":"2005-05-16T22:35:17Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Mon, 16 May 2005, Junio C Hamano wrote:\n\n> The only reason why I did it that way was because the strategy\n> taken by \"struct object\" derivatives seemed to pick up bare\n> absolute minimum to support actual callers that have immediate\n> need for information stored in structural fields, as opposed to\n> designing for helping yet to be written callers by adding fields\n> to hold information of \"having this might also help somebody in\n> the future\" type. And the author and committer names are in the\n> structured fields while signed-off-by and others are not. Also\n> when author / committer name strings are intern'ed like the way\n> I did, the memory consumption even for a long sequence of\n> commits are kept reasonably low. However,...\n\nI think if we had a good reason to make author and committer structured,\nthere must be some reason we'll want them parsed out eventually, although\nwe may not have reached the point at which it makes sense to do it.\n\n> The above implies to keep the unpacked raw data as a whole to be\n> accessible to the callers for at least commit objects and if we\n> go that route I think it would make more sense to do that\n> uniformly for everything (probably except for pure \"blob\"\n> objects for size concerns but we might as well do them while we\n> are at it). On the other hand, the current lifetime rules being\n> what it is, that strategy may introduce memory consumption\n> problems when working on a huge project.\n\nPerhaps have a struct object field for the unpacked data, have it filled\nby a unpack_object(struct object *) function, have the parse functions use\nit if it's filled, and have a function to free it (and NULL the field).\n\nSo, if you want the actual contents, you'd call\nunpack_object(&commit->obj) before parse_commit(commit), and\nclose_object(&commit_obj) when you're done, and the parse wouldn't\nduplicate the work. The lifetime rules only really care that the return\nvalue from lookup_*() stays the same for the duration of the program, not\nthat the fields in it don't get cleared (aside from the flags and the\nhash).\n\nThis could be useful even for blobs; I'm working on a program to do\ndiff/merge on commits and everything under them (taking advantage of all\navailable information if the fast path leads to a conflict); it would be\nnice not to have to go through the filesystem with the blob data.\n\n\t-Daniel\n*This .sig left intentionally blank*\n\n"},{"id":"3429","messageId":"7vekc6n4ld.fsf@assigned-by-dhcp.cox.net","threadId":"619","inReplyTo":"Pine.LNX.4.21.0505161747290.30848-100000@iabervon.org","subject":"Re: rev-list/tree committer/author information.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-05-16T23:17:18Z","receivedAt":"2005-05-16T23:17:18Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":">>>>> \"DB\" == Daniel Barkalow writes:\n\nDB> Perhaps have a struct object field for the unpacked data,...\nDB> ..., and the parse wouldn't duplicate the work.\n\nAbsolutely. That is what I wanted to see ever since I started\nlooking at \"struct object\" derivatives.\n\n"},{"id":"3958","messageId":"20050526004411.GA12360@vrfy.org","threadId":"619","inReplyTo":"Pine.LNX.4.58.0505160837080.28162@ppc970.osdl.org","subject":"Re: Summary of core GIT while you are away.","fromName":"Kay Sievers","fromEmail":"kay.sievers@vrfy.org","sentAt":"2005-05-26T00:44:11Z","receivedAt":"2005-05-26T00:44:11Z","isPatch":false,"sender":{"key":"kay.sievers@vrfy.org","avatar":null},"body":"On Mon, May 16, 2005 at 09:10:10AM -0700, Linus Torvalds wrote:\n> \n> The only thing I personally\n> think sucks is the author/committer matching of git-rev-list/tree, since\n> it would seem like somebody might well like to match on an arbitrary part\n> of a commit, and special-casing author/committer seems somewhat broken. \n\n> I personally suspect that both git-rev-list and git-rev-tree should have\n> an alternate output format that could be more easily grepped by subsequent\n> commands. For example, right now git-rev-list just outputs a list of\n> commit ID's, and it might make sense to have a flag to just append the\n> commit message to the output, and zero-terminate it (and if the commit\n> message has a NUL byte in it, just truncate it at that point).\n> \n> Then you could just do\n> \n> \tgit-rev-list -v --header HEAD | grep -z 'author[^\\n]*Linus'\n> \n> to tell it to do the \"verbose\" thing (only showing the header of the \n> commit, not the whole message), and grep for \"Linus\" in the author line.\n\nWhat happened to that idea? That's not already working in some other way I\nmissed, right? The pickaxe stuff is nice and was easy to call from the cgi,\nbut searching in commit messages would be nice too.\nIf it's not going to happen in the git-binaries, I may do it just in the\ncgi itself.\n\nKay\n"},{"id":"3960","messageId":"7vzmuig561.fsf@assigned-by-dhcp.cox.net","threadId":"619","inReplyTo":"20050526004411.GA12360@vrfy.org","subject":"Re: Summary of core GIT while you are away.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-05-26T01:13:58Z","receivedAt":"2005-05-26T01:13:58Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":">>>>> \"KS\" == Kay Sievers writes:\n\nKS> What happened to that idea? That's not already working in some other way I\nKS> missed, right? The pickaxe stuff is nice and was easy to call from the cgi,\nKS> but searching in commit messages would be nice too.\nKS> If it's not going to happen in the git-binaries, I may do it just in the\nKS> cgi itself.\n\nI haven't done anything about this yet. I was kind of waiting\nfor the blob retention API for \"struct object\" derivatives to\ncome to the conclusion.\n\n\n"},{"id":"3961","messageId":"Pine.LNX.4.58.0505251826460.2307@ppc970.osdl.org","threadId":"619","inReplyTo":"20050526004411.GA12360@vrfy.org","subject":"Re: Summary of core GIT while you are away.","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-05-26T01:45:14Z","receivedAt":"2005-05-26T01:45:14Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 26 May 2005, Kay Sievers wrote:\n>\n> On Mon, May 16, 2005 at 09:10:10AM -0700, Linus Torvalds wrote:\n> > \n> > Then you could just do\n> > \n> > \tgit-rev-list -v --header HEAD | grep -z 'author[^\\n]*Linus'\n> > \n> > to tell it to do the \"verbose\" thing (only showing the header of the \n> > commit, not the whole message), and grep for \"Linus\" in the author line.\n> \n> What happened to that idea? That's not already working in some other way I\n> missed, right? The pickaxe stuff is nice and was easy to call from the cgi,\n> but searching in commit messages would be nice too.\n> If it's not going to happen in the git-binaries, I may do it just in the\n> cgi itself.\n\nOk, you twisted my arm. Checked in.\n\n\tgit-rev-list --header HEAD | grep -z 'author[\\n]*Linus'\n\nand you will get output that is a series of commits by me (strictly \nspeaking, that's not true, since the \"author\" thing might be in the \nnon-header part).\n\nThe format is:\n\n\t '\\n' '\\0'\n\nand if the full commit message is binary and contains NUL bytes in itself\n(only crazy people do that, but let's keep in mind that crazy people\nexist), we naturally truncate it at the first NUL. This makes it easy to \nparse, and is what makes \"grep -z\" work, for example.\n\nIt also has a rudimentary \"stop at commit x\" function, but I'm not doing\nany reachability analysis, so it's purely based on the commit date, and is\nthus _not_ equivalent to \"git-rev-tree START ^END\". I reserve the right to\ntry to change that behaviour, though, if I decide I (or sombody else ;) \ncan do a nice incremental reacability thing.\n\nSo you can do\n\n\tgit-rev-list --header HEAD v2.6.12-rc5\n\nand it will print out all the commits in date order until it hits \nv2.6.12-rc5 (which it won't print out).\n\nThe output format is really optimized for something like \"git log\" or\n\"gitweb\". I suspect it's pretty much perfect for doing the \"last 10\" \nthings, without having to do \"git-cat-file\" for each commit.\n\nOh, and I considered adding a \"--header-lines=c\" which limits the header\nprintout to 'c' lines (probably starting at where the free-form thing \nstarts, so that \"--header-lines=0\" would print out just the fixed-format \nheader of the commit messages.\n\n(This is slightly different from what I initially envisioned, which had\n\"-v\" and \"--header\", and I'm not sure it's better but it ended up being\nwhat I did. If you think my first idea was better, send me a (by now\ntrivial) patch).\n\n\t\tLinus\n"},{"id":"3962","messageId":"Pine.LNX.4.58.0505251845270.2307@ppc970.osdl.org","threadId":"619","inReplyTo":"7vzmuig561.fsf@assigned-by-dhcp.cox.net","subject":"Re: Summary of core GIT while you are away.","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-05-26T01:53:32Z","receivedAt":"2005-05-26T01:53:32Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 25 May 2005, Junio C Hamano wrote:\n> \n> I haven't done anything about this yet. I was kind of waiting\n> for the blob retention API for \"struct object\" derivatives to\n> come to the conclusion.\n\nI decided on it, and it's a hacky (but reasonable) decision.\n\n\"parse_commit()\" always retains the buffer for the commit. It's very\ncommit-specific, since (a) that's the main data structure that you'd\nactually want to retain and (b) of all the core objects (ignoring tags) \ncommits tend to be the smallest and fewest, so this fixed policy has the\nleast impact memory-usage-wise.\n\nIf you want to free it, you can do\n\n\tfree(commit->buffer);\n\tcommit->buffer = NULL;\n\nand you should be all good (but the only user I thought migh want to is \n\"fsck\", and that one doesn't need to, since it never calls \n\"parse_commit()\" at all - it calls \"parse_commit_buffer()\" which does \n_not_ do this, since the caller already knows the buffer and can choose to \ndo it if it wants to.\n\nOh, thinking about that actually brings up a bug: mixing parse_commit()\nand parse_commit_buffer() is unsafe, since the state of the buffer is\nunclear. Normally that's ok, _except_ when we use just \"parse_object()\" \n(like we do in \"lookup_commit_reference()\"), when we really don't know. \nHmm.\n\n\t\tLinus\n"},{"id":"3996","messageId":"20050526202712.GA6024@vrfy.org","threadId":"619","inReplyTo":"Pine.LNX.4.58.0505251826460.2307@ppc970.osdl.org","subject":"Re: Summary of core GIT while you are away.","fromName":"Kay Sievers","fromEmail":"kay.sievers@vrfy.org","sentAt":"2005-05-26T20:27:12Z","receivedAt":"2005-05-26T20:27:12Z","isPatch":false,"sender":{"key":"kay.sievers@vrfy.org","avatar":null},"body":"On Wed, May 25, 2005 at 06:45:14PM -0700, Linus Torvalds wrote:\n> \n> \n> On Thu, 26 May 2005, Kay Sievers wrote:\n> >\n> > On Mon, May 16, 2005 at 09:10:10AM -0700, Linus Torvalds wrote:\n> > > \n> > > Then you could just do\n> > > \n> > > \tgit-rev-list -v --header HEAD | grep -z 'author[^\\n]*Linus'\n> > > \n> > > to tell it to do the \"verbose\" thing (only showing the header of the \n> > > commit, not the whole message), and grep for \"Linus\" in the author line.\n> > \n> > What happened to that idea? That's not already working in some other way I\n> > missed, right? The pickaxe stuff is nice and was easy to call from the cgi,\n> > but searching in commit messages would be nice too.\n> > If it's not going to happen in the git-binaries, I may do it just in the\n> > cgi itself.\n> \n> Ok, you twisted my arm. Checked in.\n> \n> \tgit-rev-list --header HEAD | grep -z 'author[\\n]*Linus'\n\nNice, thanks. Here is a very first try. It searches the commit messages\nand uses pickaxe to search in the file content:\n http://ehlo.org/~kay/gitweb.cgi?p=git/git.git;a=search;s=symlink\n\nBefore someone asks: kernel.org needs to wait until cogito has catched up and\nreleased a new version and it is installed on the machines.\n\nKay\n"},{"id":"4000","messageId":"7vd5rdbtif.fsf@assigned-by-dhcp.cox.net","threadId":"619","inReplyTo":"20050526202712.GA6024@vrfy.org","subject":"Re: Summary of core GIT while you are away.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-05-26T20:51:36Z","receivedAt":"2005-05-26T20:51:36Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":">>>>> \"KS\" == Kay Sievers writes:\n\nKS> Before someone asks: kernel.org needs to wait until cogito has catched up and\nKS> released a new version and it is installed on the machines.\n\nJust from curiosity, does anybody runs (need to run) Cogito on\nkernel.org machine(s)? Or is it that gitweb depends on Cogito,\nnot running directly on top of Plumbing?\n\n"},{"id":"4007","messageId":"42964979.2030806@zytor.com","threadId":"619","inReplyTo":"20050526202712.GA6024@vrfy.org","subject":"Re: Summary of core GIT while you are away.","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2005-05-26T22:11:05Z","receivedAt":"2005-05-26T22:11:05Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"Kay Sievers wrote:\n> \n> Nice, thanks. Here is a very first try. It searches the commit messages\n> and uses pickaxe to search in the file content:\n> http://ehlo.org/~kay/gitweb.cgi?p=git/git.git;a=search;s=symlink\n> \n> Before someone asks: kernel.org needs to wait until cogito has catched up and\n> released a new version and it is installed on the machines.\n> \n\nPetr, it seems we need a new Cogito release soon. 0.10 really has \nfallen behind a lot. Also, separating out Cogito from git-core would be \nnice.\n\n\t-hpa\n"},{"id":"4008","messageId":"7vy8a18w1e.fsf@assigned-by-dhcp.cox.net","threadId":"619","inReplyTo":"20050526202712.GA6024@vrfy.org","subject":"Re: Summary of core GIT while you are away.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-05-26T22:25:17Z","receivedAt":"2005-05-26T22:25:17Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":">>>>> \"KS\" == Kay Sievers writes:\n\nKS> Nice, thanks. Here is a very first try. It searches the commit messages\nKS> and uses pickaxe to search in the file content:\nKS> http://ehlo.org/~kay/gitweb.cgi?p=git/git.git;a=search;s=symlink\n\nNice, thanks for using pickaxe ;-). One request, knowing well\nthat what you have on ehlo is your first cut.\n\nThe pickaxe really shines when you can paste a couple of lines\nof code in the version you are having trouble with (or just you\nare curious about) in order to see where they came from. For\nexample, I did an equivalent of the following command back to\nfigure out which patch and author to give credit to when I stole\nthe tagged output format for git-ls-files from Cogito branch:\n\ngit-rev-list pasky |\ngit-diff-tree -v -p --stdin \\\n-S'static const char *tag_cached = \"\";\nstatic const char *tag_unmerged = \"\";\nstatic const char *tag_removed = \"\";'\n\nSince this is primarily about program code, forbidding '*' is\nrather nasty, and not being able to do multiple lines makes it\nquite less useful than it could be.\n\n\n"},{"id":"4010","messageId":"20050526232953.GA6215@vrfy.org","threadId":"619","inReplyTo":"7vd5rdbtif.fsf@assigned-by-dhcp.cox.net","subject":"Re: Summary of core GIT while you are away.","fromName":"Kay Sievers","fromEmail":"kay.sievers@vrfy.org","sentAt":"2005-05-26T23:29:53Z","receivedAt":"2005-05-26T23:29:53Z","isPatch":false,"sender":{"key":"kay.sievers@vrfy.org","avatar":null},"body":"On Thu, May 26, 2005 at 01:51:36PM -0700, Junio C Hamano wrote:\n> >>>>> \"KS\" == Kay Sievers writes:\n> \n> KS> Before someone asks: kernel.org needs to wait until cogito has catched up and\n> KS> released a new version and it is installed on the machines.\n> \n> Just from curiosity, does anybody runs (need to run) Cogito on\n> kernel.org machine(s)? Or is it that gitweb depends on Cogito,\n> not running directly on top of Plumbing?\n\nThe cgi doesn't need it. Cogito has the spec file and the Mekefile\nwith support for it - that was the reason the RPM made it on the machines\nthere.\nSplitting the git-core stuff completely out of Cogito and install\nCogito with a dependency on the git package is the only sane option I\nthink.\n\nKay\n"},{"id":"4013","messageId":"20050526235944.GB6215@vrfy.org","threadId":"619","inReplyTo":"7vy8a18w1e.fsf@assigned-by-dhcp.cox.net","subject":"Re: Summary of core GIT while you are away.","fromName":"Kay Sievers","fromEmail":"kay.sievers@vrfy.org","sentAt":"2005-05-26T23:59:44Z","receivedAt":"2005-05-26T23:59:44Z","isPatch":false,"sender":{"key":"kay.sievers@vrfy.org","avatar":null},"body":"On Thu, May 26, 2005 at 03:25:17PM -0700, Junio C Hamano wrote:\n> >>>>> \"KS\" == Kay Sievers writes:\n> \n> KS> Nice, thanks. Here is a very first try. It searches the commit messages\n> KS> and uses pickaxe to search in the file content:\n> KS> http://ehlo.org/~kay/gitweb.cgi?p=git/git.git;a=search;s=symlink\n> \n> Nice, thanks for using pickaxe ;-). One request, knowing well\n> that what you have on ehlo is your first cut.\n\nYeah, I like it a lot. Nice work.\n\nAny idea, what's the reason, it doesn't find anything here in the\nkernel tree:\n git-rev-list HEAD | git-diff-tree -S'TIMEOUT' --stdin\n\nwhile:\n git-rev-list --header HEAD | grep -z TIMEOUT\n\nprints the commit:\n 6897089c5f7989603ccb9c696050470ba1dbd262\n\nwith the following change:\n git-diff-tree -p 6897089c5f7989603ccb9c696050470ba1dbd262 6f31e42221c7deae4527136ce0dd73990d8bc1d1\n diff --git a/drivers/base/firmware_class.c\n b/drivers/base/firmware_class.c\n --- a/drivers/base/firmware_class.c\n +++ b/drivers/base/firmware_class.c\n @@ -102,9 +102,6 @@ firmware_class_hotplug(struct class_devi\n if (add_hotplug_env_var(envp, num_envp, &i, buffer, buffer_size, &len,\n \"FIRMWARE=%s\", fw_priv->fw_id))\n return -ENOMEM;\n - if (add_hotplug_env_var(envp, num_envp, &i, buffer, buffer_size,\n &len,\n - \"TIMEOUT=%i\", loading_timeout))\n - return -ENOMEM;\n \n envp[i] = NULL;\n\n> The pickaxe really shines when you can paste a couple of lines\n> of code in the version you are having trouble with (or just you\n> are curious about) in order to see where they came from. For\n> example, I did an equivalent of the following command back to\n> figure out which patch and author to give credit to when I stole\n> the tagged output format for git-ls-files from Cogito branch:\n> \n> git-rev-list pasky |\n> git-diff-tree -v -p --stdin \\\n> -S'static const char *tag_cached = \"\";\n> static const char *tag_unmerged = \"\";\n> static const char *tag_removed = \"\";'\n\nNice feature, maybe we can add it later (see next).\n\n> Since this is primarily about program code, forbidding '*' is\n> rather nasty, and not being able to do multiple lines makes it\n> quite less useful than it could be.\n\nI see what you mean, but allow to pass any charater through a cgi to a\ninvoked shell as a command-line option is a nightmare without being very\ncarful. That's why only a few character allowed now. I'm not sure how\nto do that without creating possibly a big hole in the webserver. :)\n\nKay\n"},{"id":"4014","messageId":"7vll618rnw.fsf@assigned-by-dhcp.cox.net","threadId":"619","inReplyTo":"20050526232953.GA6215@vrfy.org","subject":"Re: Summary of core GIT while you are away.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-05-26T23:59:47Z","receivedAt":"2005-05-26T23:59:47Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":">>>>> \"KS\" == Kay Sievers writes:\n\nKS> The cgi doesn't need it. Cogito has the spec file and the\nKS> Mekefile with support for it - that was the reason the RPM\nKS> made it on the machines there.\n\nAh, just installation convenience. I see.\n\n\n"},{"id":"4015","messageId":"7vfyw98qvp.fsf@assigned-by-dhcp.cox.net","threadId":"619","inReplyTo":"20050526235944.GB6215@vrfy.org","subject":"Re: Summary of core GIT while you are away.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-05-27T00:16:42Z","receivedAt":"2005-05-27T00:16:42Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":">>>>> \"KS\" == Kay Sievers writes:\n\nKS> On Thu, May 26, 2005 at 03:25:17PM -0700, Junio C Hamano wrote:\n>> >>>>> \"KS\" == Kay Sievers writes:\n>> \nKS> Nice, thanks. Here is a very first try. It searches the commit messages\nKS> and uses pickaxe to search in the file content:\nKS> http://ehlo.org/~kay/gitweb.cgi?p=git/git.git;a=search;s=symlink\n>> \n>> Nice, thanks for using pickaxe ;-). One request, knowing well\n>> that what you have on ehlo is your first cut.\n\nKS> Yeah, I like it a lot. Nice work.\n\nKS> Any idea, what's the reason, it doesn't find anything here in the\nKS> kernel tree:\nKS> git-rev-list HEAD | git-diff-tree -S'TIMEOUT' --stdin\n\nDies this work for you? Notice \"-r\".\n\ngit-rev-list HEAD | git-diff-tree -r -S'TIMEOUT' --stdin\n\n"},{"id":"4016","messageId":"20050527002225.GB9858@vrfy.org","threadId":"619","inReplyTo":"7vfyw98qvp.fsf@assigned-by-dhcp.cox.net","subject":"Re: Summary of core GIT while you are away.","fromName":"Kay Sievers","fromEmail":"kay.sievers@vrfy.org","sentAt":"2005-05-27T00:22:25Z","receivedAt":"2005-05-27T00:22:25Z","isPatch":false,"sender":{"key":"kay.sievers@vrfy.org","avatar":null},"body":"On Thu, May 26, 2005 at 05:16:42PM -0700, Junio C Hamano wrote:\n> >>>>> \"KS\" == Kay Sievers writes:\n> \n> KS> On Thu, May 26, 2005 at 03:25:17PM -0700, Junio C Hamano wrote:\n> >> >>>>> \"KS\" == Kay Sievers writes:\n> >> \n> KS> Nice, thanks. Here is a very first try. It searches the commit messages\n> KS> and uses pickaxe to search in the file content:\n> KS> http://ehlo.org/~kay/gitweb.cgi?p=git/git.git;a=search;s=symlink\n> >> \n> >> Nice, thanks for using pickaxe ;-). One request, knowing well\n> >> that what you have on ehlo is your first cut.\n> \n> KS> Yeah, I like it a lot. Nice work.\n> \n> KS> Any idea, what's the reason, it doesn't find anything here in the\n> KS> kernel tree:\n> KS> git-rev-list HEAD | git-diff-tree -S'TIMEOUT' --stdin\n> \n> Dies this work for you? Notice \"-r\".\n> \n> git-rev-list HEAD | git-diff-tree -r -S'TIMEOUT' --stdin\n\nYes, works perfect! Sorry, I need to get used to repositories with subdirectories. :)\n\nThanks,\nKay\n"},{"id":"4018","messageId":"7vsm097b6x.fsf@assigned-by-dhcp.cox.net","threadId":"619","inReplyTo":"20050526235944.GB6215@vrfy.org","subject":"Re: Summary of core GIT while you are away.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-05-27T00:40:54Z","receivedAt":"2005-05-27T00:40:54Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":">>>>> \"KS\" == Kay Sievers writes:\n\nKS> I see what you mean, but allow to pass any charater through a cgi to a\nKS> invoked shell as a command-line option is a nightmare without being very\nKS> carful.\n\nYou are absolutely right that you must be careful. But being\ncareful is not that hard.\n\nI do not know what you are using to parse the data coming from\nthe browser (presumably application/x-www-form-urlencoded or\nsomesuch), but once you got the raw data out of it in a variable\nin your host language (sorry I do not know what language you are\nwriting in, either), quoting that value safely for shell command\nline is very simple and easy. You can emulate what sq_expand()\nin diff.c does.\n\nEssentially you take advantage of single quote quoting which\nlets you pass anything other than single quotes as literals, and\ndeal with single quotes by stepping out temporarily of the\nsingle quote environment every time you see a single quote,\nquote that single quote with a backslash, and immediately after\nthat you go back into single quote environment again and continue.\n\n original sq_expand result\n name ==> name ==> 'name'\n a b ==> a b ==> 'a b'\n a'b ==> a'\\''b ==> 'a'\\''b'\n\nSo in shell, using sed, you would do something like this:\n\n------------\n#!/bin/sh\n\norig=\"foo '\"'\\bar\tb\naz'\n\nscript=\"s/'/'\\\\\\\\\\\\''/g\" ;# change (') to ('\\'')\n\nsq_inside=`echo \"$orig\" | sed \"$script\"`\n\necho \"'$sq_inside'\" ;# and enclose the whole thing in sq pair\n------------\n\n"},{"id":"4023","messageId":"42967CFE.7030007@zytor.com","threadId":"619","inReplyTo":"7vll618rnw.fsf@assigned-by-dhcp.cox.net","subject":"Re: Summary of core GIT while you are away.","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2005-05-27T01:50:54Z","receivedAt":"2005-05-27T01:50:54Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"Junio C Hamano wrote:\n> \n> KS> The cgi doesn't need it. Cogito has the spec file and the\n> KS> Mekefile with support for it - that was the reason the RPM\n> KS> made it on the machines there.\n> \n> Ah, just installation convenience. I see.\n> \n\nNot \"just\" an installation convenience. Right now cogito and git-core \n*conflict*. That's why cogito really needs to be broken out from \ngit-core, so git-core can be updated independently.\n\n\t-hpa\n"},{"id":"4026","messageId":"7vk6ll2vde.fsf@assigned-by-dhcp.cox.net","threadId":"619","inReplyTo":"42967CFE.7030007@zytor.com","subject":"Re: Summary of core GIT while you are away.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-05-27T03:36:13Z","receivedAt":"2005-05-27T03:36:13Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":">>>>> \"HPA\" == H Peter Anvin writes:\n\nHPA> Junio C Hamano wrote:\nKS> The cgi doesn't need it. Cogito has the spec file and the\nKS> Mekefile with support for it - that was the reason the RPM\nKS> made it on the machines there.\n>> Ah, just installation convenience. I see.\n\nHPA> Not \"just\" an installation convenience. Right now cogito and git-core\nHPA> *conflict*. That's why cogito really needs to be broken out from\nHPA> git-core, so git-core can be updated independently.\n\nWhat I learned from this thread are these:\n\n (1) CGI does not need Cogito but just needs core GIT.\n (2) Nobody said he uses Cogito on kernel.org machines.\n (3) But Cogito is installed nevertheless.\n (4) Installation of Cogito is done via RPM \"with Makefiles and\n spec files\" and both Cogito and core GIT comes bundled in.\n (5) I gather that there is no core GIT only RPM (nobody said\n this explicitly in this thread, though, so I may be\n mistaken about this point).\n\nAnd that was where my comment about \"just an installation\nconvenience\" came from.\n\nIf somebody said Cogito _is_ used on kernel.org machines, then I\nwould not have said \"just\" nor \"convenience\". That would mean\nthere is a real need to have Cogito and having just core GIT\nwould not be enough.\n\n"},{"id":"4029","messageId":"42969B98.7070701@zytor.com","threadId":"619","inReplyTo":"7vk6ll2vde.fsf@assigned-by-dhcp.cox.net","subject":"Re: Summary of core GIT while you are away.","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2005-05-27T04:01:28Z","receivedAt":"2005-05-27T04:01:28Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"Junio C Hamano wrote:\n> \n> HPA> Not \"just\" an installation convenience. Right now cogito and git-core\n> HPA> *conflict*. That's why cogito really needs to be broken out from\n> HPA> git-core, so git-core can be updated independently.\n> \n> What I learned from this thread are these:\n> \n> (1) CGI does not need Cogito but just needs core GIT.\n> (2) Nobody said he uses Cogito on kernel.org machines.\n> (3) But Cogito is installed nevertheless.\n> (4) Installation of Cogito is done via RPM \"with Makefiles and\n> spec files\" and both Cogito and core GIT comes bundled in.\n> (5) I gather that there is no core GIT only RPM (nobody said\n> this explicitly in this thread, though, so I may be\n> mistaken about this point).\n> \n> And that was where my comment about \"just an installation\n> convenience\" came from.\n> \n> If somebody said Cogito _is_ used on kernel.org machines, then I\n> would not have said \"just\" nor \"convenience\". That would mean\n> there is a real need to have Cogito and having just core GIT\n> would not be enough.\n\nI, for one, use Cogito on the kernel.org machines.\n\n\t-hpa\n"},{"id":"4030","messageId":"7v4qcp2tp1.fsf@assigned-by-dhcp.cox.net","threadId":"619","inReplyTo":"42969B98.7070701@zytor.com","subject":"Re: Summary of core GIT while you are away.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-05-27T04:12:26Z","receivedAt":"2005-05-27T04:12:26Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":">>>>> \"HPA\" == H Peter Anvin writes:\n\nHPA> I, for one, use Cogito on the kernel.org machines.\n\nI see. I see cogito.git catching up to the Linus core, so this\nwould not be much of a problem anymore.\n\n\n"},{"id":"4031","messageId":"42969E6E.5080606@zytor.com","threadId":"619","inReplyTo":"7v4qcp2tp1.fsf@assigned-by-dhcp.cox.net","subject":"Re: Summary of core GIT while you are away.","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2005-05-27T04:13:34Z","receivedAt":"2005-05-27T04:13:34Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"Junio C Hamano wrote:\n>>>>>>\"HPA\" == H Peter Anvin writes:\n> \n> \n> HPA> I, for one, use Cogito on the kernel.org machines.\n> \n> I see. I see cogito.git catching up to the Linus core, so this\n> would not be much of a problem anymore.\n> \n\nIt would still be a lot nicer to have them decoupled.\n\n\t-hpa\n"},{"id":"4032","messageId":"7vy8a11e8q.fsf@assigned-by-dhcp.cox.net","threadId":"619","inReplyTo":"42969E6E.5080606@zytor.com","subject":"Re: Summary of core GIT while you are away.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-05-27T04:31:33Z","receivedAt":"2005-05-27T04:31:33Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":">>>>> \"HPA\" == H Peter Anvin writes:\n\nHPA> Junio C Hamano wrote:\n>>>>>>> \"HPA\" == H Peter Anvin writes:\nHPA> I, for one, use Cogito on the kernel.org machines.\n>> I see. I see cogito.git catching up to the Linus core, so this\n>> would not be much of a problem anymore.\n\nHPA> It would still be a lot nicer to have them decoupled.\n\nNo question about it. Let's give Petr some time.\n\n\n"},{"id":"4034","messageId":"Pine.LNX.4.58.0505262216190.17402@ppc970.osdl.org","threadId":"619","inReplyTo":"42969E6E.5080606@zytor.com","subject":"Re: Summary of core GIT while you are away.","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-05-27T05:21:30Z","receivedAt":"2005-05-27T05:21:30Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 26 May 2005, H. Peter Anvin wrote:\n> \n> It would still be a lot nicer to have them decoupled.\n\nYes, but git has been changing so much that I think it has made sense to \nhave it together with cogito, so that you don't have version skew.\n\nHave we gotten to the point where git is calming down? Judging by the raw\ndiff etc changes, I'd say no, but on the other hand, those are largely\nover, and maybe we don't have any serious real incompatibilities pending\nany mroe...\n\nThe object data structures have been pretty stable (thank the Gods!), but \ncommand line switches and some data output formats certainly have not.\n\nThe one big change I see coming is that I really want to make\n\"git-rev-list HEAD TAIL\" work right (ie do a real reachabilty thing rather\nthan the date-based thing), at which point you'd _usually_ not need to use\nthe full logic of git-rev-tree that can do multiple parents etc. But that\nchange should be compatible, I hope (ie old scripts will continue to use\ngit-rev-tree and play games with the output, because they'd not know any\nbetter).\n\n\t\t\tLinus\n"}]}