{"thread":{"id":"1866","subject":"Joining cg-*-id","startedAt":"2005-09-19T21:40:49Z","lastAt":"2005-09-21T21:19:42Z","messageCount":22,"participants":["Pavel Roskin","Petr Baudis","Linus Torvalds","Junio C Hamano","Matthias Urlichs","Paul Mackerras"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"8906","messageId":"1127166049.26772.26.camel@dv","threadId":"1866","inReplyTo":null,"subject":"Joining cg-*-id","fromName":"Pavel Roskin","fromEmail":"proski@gnu.org","sentAt":"2005-09-19T21:40:49Z","receivedAt":"2005-09-19T21:40:49Z","isPatch":false,"sender":{"key":"proski@gnu.org","avatar":null},"body":"Hello!\n\nI believe Cogito should keep the command list short.  When the *-id\nutilities got the cg-prefix, the list became longer by 3 commands.\n\nWhat if we join cg-commit-id, cg-parent-id and cg-tree-id into one cg-id\n(or cg-admin-id) utility?  It would work like cg-commit-id in absence of\nswitches, -p would make it work like cg-parent-id, and -t would make it\ncg-tree-id.\n\nAlternatively, this functionality should go to git.  It's low-level\nenough to be there.\n\n-- \nRegards,\nPavel Roskin\n"},{"id":"8909","messageId":"20050919215608.GA13845@pasky.or.cz","threadId":"1866","inReplyTo":"1127166049.26772.26.camel@dv","subject":"Re: Joining cg-*-id","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-09-19T21:56:08Z","receivedAt":"2005-09-19T21:56:08Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Mon, Sep 19, 2005 at 11:40:49PM CEST, I got a letter\nwhere Pavel Roskin <proski@gnu.org> told me that...\n> Hello!\n\nHello,\n\n> I believe Cogito should keep the command list short.  When the *-id\n> utilities got the cg-prefix, the list became longer by 3 commands.\n\nwell, those commands are semi-public, actually. E.g. cg-help does not\nlist them.\n\n> What if we join cg-commit-id, cg-parent-id and cg-tree-id into one cg-id\n> (or cg-admin-id) utility?  It would work like cg-commit-id in absence of\n> switches, -p would make it work like cg-parent-id, and -t would make it\n> cg-tree-id.\n\nPerhaps cg-object-id? I'm not principially opposed to that, but I don't\nsee much value in it either. Perhaps if this would come along with\nthe usage of git-rev-parse (see below)...\n\n> Alternatively, this functionality should go to git.  It's low-level\n> enough to be there.\n\nThere is git-rev-parse, but it is not as powerful (cannot take dates and\nsha1 completion does not work when listing parents) - OTOH it can\ncomplete sha1 ids even inside packs, which is really useful. Still, IMHO\nits usage is awful, so it'd take place for cg-Xnormid, but we would\nstill keep the *-id frontends (which would also handle the dates).\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nIf you want the holes in your knowledge showing up try teaching\nsomeone.  -- Alan Cox\n"},{"id":"8910","messageId":"Pine.LNX.4.58.0509191505470.2553@g5.osdl.org","threadId":"1866","inReplyTo":"20050919215608.GA13845@pasky.or.cz","subject":"Re: Joining cg-*-id","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-09-19T22:16:03Z","receivedAt":"2005-09-19T22:16:03Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 19 Sep 2005, Petr Baudis wrote:\n> \n> There is git-rev-parse, but it is not as powerful (cannot take dates and\n> sha1 completion does not work when listing parents)\n\nHmm.\n\nThat lack of sha1 completion is a bug. \n\nHow does the date thing work? It sounds like something horribly ambiguous, \nbut hey, maybe some useful semantics could be found.\n\nThe short sha1 problem is fixed thus,\n\n\t\tLinus\n\n----\nFix extended short SHA1 name completion\n\nget_sha1() would not do sha1 completion of short SHA1's when they were \npart of a more complex expression. So doing\n\n\tgit-rev-parse 727132834e6be48a93c1bd6458a29d474ce7d5d5^\n\nwould work, and return 87c6aeb4efdd4355918d127a91bd0adc5a02f8ff. But using \nthe shorthand version \n\n\tgit-rev-list 72713^\n\nwouldn't work.\n\nSigned-off-by: Linus Torvalds <torvalds@osdl.org>\n---\ndiff --git a/sha1_name.c b/sha1_name.c\n--- a/sha1_name.c\n+++ b/sha1_name.c\n@@ -84,19 +84,19 @@ static int find_short_packed_object(int \n \treturn 0;\n }\n \n-static int get_short_sha1(const char *name, unsigned char *sha1)\n+static int get_short_sha1(const char *name, int len, unsigned char *sha1)\n {\n \tint i;\n \tchar canonical[40];\n \tunsigned char res[20];\n \n+\tif (len < 4)\n+\t\treturn -1;\n \tmemset(res, 0, 20);\n \tmemset(canonical, 'x', 40);\n-\tfor (i = 0;;i++) {\n+\tfor (i = 0; i < len ;i++) {\n \t\tunsigned char c = name[i];\n \t\tunsigned char val;\n-\t\tif (!c || i > 40)\n-\t\t\tbreak;\n \t\tif (c >= '0' && c <= '9')\n \t\t\tval = c - '0';\n \t\telse if (c >= 'a' && c <= 'f')\n@@ -112,8 +112,6 @@ static int get_short_sha1(const char *na\n \t\t\tval <<= 4;\n \t\tres[i >> 1] |= val;\n \t}\n-\tif (i < 4)\n-\t\treturn -1;\n \tif (find_short_object_filename(i, canonical, sha1))\n \t\treturn 0;\n \tif (find_short_packed_object(i, res, sha1))\n@@ -254,7 +252,7 @@ static int get_sha1_1(const char *name, \n \tret = get_sha1_basic(name, len, sha1);\n \tif (!ret)\n \t\treturn 0;\n-\treturn get_short_sha1(name, sha1);\n+\treturn get_short_sha1(name, len, sha1);\n }\n \n /*\n"},{"id":"8911","messageId":"1127169021.26772.58.camel@dv","threadId":"1866","inReplyTo":"20050919215608.GA13845@pasky.or.cz","subject":"Re: Joining cg-*-id","fromName":"Pavel Roskin","fromEmail":"proski@gnu.org","sentAt":"2005-09-19T22:30:21Z","receivedAt":"2005-09-19T22:30:21Z","isPatch":false,"sender":{"key":"proski@gnu.org","avatar":null},"body":"Hello, Petr!\n\nThanks for quick replies.  I'm replying to both your messages.\n\nOn Mon, 2005-09-19 at 23:56 +0200, Petr Baudis wrote:\n> Dear diary, on Mon, Sep 19, 2005 at 11:40:49PM CEST, I got a letter\n> where Pavel Roskin <proski@gnu.org> told me that...\n> > Hello!\n> \n> Hello,\n> \n> > I believe Cogito should keep the command list short.  When the *-id\n> > utilities got the cg-prefix, the list became longer by 3 commands.\n> \n> well, those commands are semi-public, actually. E.g. cg-help does not\n> list them.\n\nBut cg-<TAB><TAB> does.\n\n> > What if we join cg-commit-id, cg-parent-id and cg-tree-id into one cg-id\n> > (or cg-admin-id) utility?  It would work like cg-commit-id in absence of\n> > switches, -p would make it work like cg-parent-id, and -t would make it\n> > cg-tree-id.\n> \n> Perhaps cg-object-id? I'm not principially opposed to that, but I don't\n> see much value in it either. Perhaps if this would come along with\n> the usage of git-rev-parse (see below)...\n\nThe value is having one command, one manpage and one place to fix little\nbugs and add more functionality.  Potentially, cg-Xnormid could be\nincorporated into that script, so bash wouldn't have to open one more\nfile.\n\n> > Alternatively, this functionality should go to git.  It's low-level\n> > enough to be there.\n> \n> There is git-rev-parse, but it is not as powerful (cannot take dates and\n> sha1 completion does not work when listing parents) - OTOH it can\n> complete sha1 ids even inside packs, which is really useful. Still, IMHO\n> its usage is awful, so it'd take place for cg-Xnormid, but we would\n> still keep the *-id frontends (which would also handle the dates).\n\nI see.  I guess time for git is just as abstract as phases of the moon -\nnobody would goes crazy when they repeat.\n\nPlease don't apply my patch yet - I forgot to document the optional\nargument.  I'll try to make cg-object-id now.\n\n-- \nRegards,\nPavel Roskin\n"},{"id":"8914","messageId":"20050919225422.GG18320@pasky.or.cz","threadId":"1866","inReplyTo":"Pine.LNX.4.58.0509191505470.2553@g5.osdl.org","subject":"Re: Joining cg-*-id","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-09-19T22:54:23Z","receivedAt":"2005-09-19T22:54:23Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Tue, Sep 20, 2005 at 12:16:03AM CEST, I got a letter\nwhere Linus Torvalds <torvalds@osdl.org> told me that...\n> How does the date thing work? It sounds like something horribly ambiguous, \n> but hey, maybe some useful semantics could be found.\n\nCurrently, in Cogito it is basically:\n\n\tgit-rev-list --min-age=\"$(date --date=$id +%s)\" --max-count=1 HEAD\n\nThe point is that you can then say\n\n\tcg-log -r yesterday\n\nto see all the changes which happenned during the last day, and such\n(so it is really useful to have the syntactic power of date(1) available).\n\nBut that semantics sucks, and I wouldn't mind changing it at all. I\nthink taking the previous commit works for everything but the start of\ncg-log range, and it is how CVS behaves. And with cg-log, you'll just\nhave one commit more, not so big a deal I think.\n\nJonas was who introduced this, IIRC, so cc'ing him too.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nVI has two modes: the one in which it beeps and the one in which\nit doesn't.\n"},{"id":"8915","messageId":"20050919225838.GH18320@pasky.or.cz","threadId":"1866","inReplyTo":"1127169021.26772.58.camel@dv","subject":"Re: Joining cg-*-id","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-09-19T22:58:38Z","receivedAt":"2005-09-19T22:58:38Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Tue, Sep 20, 2005 at 12:30:21AM CEST, I got a letter\nwhere Pavel Roskin <proski@gnu.org> told me that...\n> On Mon, 2005-09-19 at 23:56 +0200, Petr Baudis wrote:\n> > Dear diary, on Mon, Sep 19, 2005 at 11:40:49PM CEST, I got a letter\n> > where Pavel Roskin <proski@gnu.org> told me that...\n> > > I believe Cogito should keep the command list short.  When the *-id\n> > > utilities got the cg-prefix, the list became longer by 3 commands.\n> > \n> > well, those commands are semi-public, actually. E.g. cg-help does not\n> > list them.\n> \n> But cg-<TAB><TAB> does.\n\nGood point.\n\n> > > What if we join cg-commit-id, cg-parent-id and cg-tree-id into one cg-id\n> > > (or cg-admin-id) utility?  It would work like cg-commit-id in absence of\n> > > switches, -p would make it work like cg-parent-id, and -t would make it\n> > > cg-tree-id.\n> > \n> > Perhaps cg-object-id? I'm not principially opposed to that, but I don't\n> > see much value in it either. Perhaps if this would come along with\n> > the usage of git-rev-parse (see below)...\n> \n> The value is having one command, one manpage and one place to fix little\n> bugs and add more functionality.  Potentially, cg-Xnormid could be\n> incorporated into that script, so bash wouldn't have to open one more\n> file.\n\nWell, cg-Xnormid is basically pointless if it's not going to be a common\nbackend for multiple other commands. So I'd say either supersede it with\ngit-rev-parse or just merge it with cg-object-id.\n\n> Please don't apply my patch yet - I forgot to document the optional\n> argument.  I'll try to make cg-object-id now.\n\nWhich patch?\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nVI has two modes: the one in which it beeps and the one in which\nit doesn't.\n"},{"id":"8926","messageId":"1127175590.31115.10.camel@dv","threadId":"1866","inReplyTo":"20050919225838.GH18320@pasky.or.cz","subject":"Re: Joining cg-*-id","fromName":"Pavel Roskin","fromEmail":"proski@gnu.org","sentAt":"2005-09-20T00:19:50Z","receivedAt":"2005-09-20T00:19:50Z","isPatch":false,"sender":{"key":"proski@gnu.org","avatar":null},"body":"On Tue, 2005-09-20 at 00:58 +0200, Petr Baudis wrote:\n> Dear diary, on Tue, Sep 20, 2005 at 12:30:21AM CEST, I got a letter\n> where Pavel Roskin <proski@gnu.org> told me that...\n> > The value is having one command, one manpage and one place to fix little\n> > bugs and add more functionality.  Potentially, cg-Xnormid could be\n> > incorporated into that script, so bash wouldn't have to open one more\n> > file.\n> \n> Well, cg-Xnormid is basically pointless if it's not going to be a common\n> backend for multiple other commands. So I'd say either supersede it with\n> git-rev-parse or just merge it with cg-object-id.\n\nAgreed.\n\n> > Please don't apply my patch yet - I forgot to document the optional\n> > argument.  I'll try to make cg-object-id now.\n> \n> Which patch?\n\nThe one that adds USAGE.  Never mind - I see it's fixed already.\n\nAs for merging, I see that the existing *-id scripts are a mess.  For\ninstance, cg-parent returns parents separated by spaces, but cg-diff\nused \"head -1\" on its output to get the first parent, i.e it assumes\nnewline separated output.\n\nAnother thing that is broken is \"cg-commit-id origin^\" - apparently the\n\"^\" parsing is only designed for cg-parent-id.\n\nI think I'll start a local branch for fixing this, and then I'll send\nseparate patches.\n\n-- \nRegards,\nPavel Roskin\n"},{"id":"8928","messageId":"20050920002630.GA13537@pasky.or.cz","threadId":"1866","inReplyTo":"1127175590.31115.10.camel@dv","subject":"Re: Joining cg-*-id","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-09-20T00:26:31Z","receivedAt":"2005-09-20T00:26:31Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Tue, Sep 20, 2005 at 02:19:50AM CEST, I got a letter\nwhere Pavel Roskin <proski@gnu.org> told me that...\n> As for merging, I see that the existing *-id scripts are a mess.  For\n> instance, cg-parent returns parents separated by spaces, but cg-diff\n> used \"head -1\" on its output to get the first parent, i.e it assumes\n> newline separated output.\n\nActually, cg-parent-id's documentation seems to be wrong. We always\nreturn only the first parent. I've just updated the documentation for\nnow, even though in the future we might want to change this to reflect\nthe original documentation instead.\n\n> Another thing that is broken is \"cg-commit-id origin^\" - apparently the\n> \"^\" parsing is only designed for cg-parent-id.\n\nThat's a bug, IIRC it was originally meant to be general.\n\n> I think I'll start a local branch for fixing this, and then I'll send\n> separate patches.\n\nGood idea.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nVI has two modes: the one in which it beeps and the one in which\nit doesn't.\n"},{"id":"8935","messageId":"Pine.LNX.4.58.0509191746130.2553@g5.osdl.org","threadId":"1866","inReplyTo":"20050919225422.GG18320@pasky.or.cz","subject":"Re: Joining cg-*-id","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-09-20T00:50:21Z","receivedAt":"2005-09-20T00:50:21Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 20 Sep 2005, Petr Baudis wrote:\n> \n> Currently, in Cogito it is basically:\n> \n> \tgit-rev-list --min-age=\"$(date --date=$id +%s)\" --max-count=1 HEAD\n\nYes, for git-rev-list it makes sense, because that already more or less\n\"serializes\" things by date.\n\n> But that semantics sucks, and I wouldn't mind changing it at all. I\n> think taking the previous commit works for everything but the start of\n> cg-log range, and it is how CVS behaves.\n\nThe thing is, it may have sensible behaviour for CVS, but only because CVS \ndoesn't have any notion of concurrent development (even a branch isn't \nconcurrent - it's totally separate, and when you merge it, it becomes just \none big diff at the time of the merge).\n\nSo I'd love to have\n\n\tgit diff yesterday..\n\nbut the fact is, there's no sensible semantics for it. _which_ yesterday? \nThere might be five different points that are \"close to 24 hours ago\", \nalong five different paths backwards in the history.\n\nI suspect that the date-based thing really doesn't make sense as a\nrevision, only as a git log cut-off (ie the \"--min-age=\" flag is as close\nto sensibility as you can get).\n\n\t\tLinus\n"},{"id":"8972","messageId":"7vy85s9tgk.fsf@assigned-by-dhcp.cox.net","threadId":"1866","inReplyTo":"Pine.LNX.4.58.0509191505470.2553@g5.osdl.org","subject":"Re: Joining cg-*-id","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-09-20T05:52:27Z","receivedAt":"2005-09-20T05:52:27Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds <torvalds@osdl.org> writes:\n\n> That lack of sha1 completion is a bug. \n>\n> How does the date thing work? It sounds like something horribly ambiguous, \n> but hey, maybe some useful semantics could be found.\n\nI am not even sure what I would want to see, let alone what I\ncould show, when I say \"show logs of what happened last week\",\nafter I just pulled from a remote or two.\n\nI would imagine a gitk graph with nodes colored red for commits\nwith last week's timestamps, would be what I would want, but\nprobably that is useful only because I can see in the same gitk\nwindow how those red nodes connect with each other and with\ncommits outside the specified time window.  Without that context\ninformation I would probably be lost.\n\n> The short sha1 problem is fixed thus,\n\nThanks.  Applied.\n"},{"id":"8982","messageId":"pan.2005.09.20.10.11.38.565694@smurf.noris.de","threadId":"1866","inReplyTo":"7vy85s9tgk.fsf@assigned-by-dhcp.cox.net","subject":"Re: Joining cg-*-id","fromName":"Matthias Urlichs","fromEmail":"smurf@smurf.noris.de","sentAt":"2005-09-20T10:11:40Z","receivedAt":"2005-09-20T10:11:40Z","isPatch":false,"sender":{"key":"matthias@urlichs.de","avatar":"https://gravatar.com/avatar/2708905af227313eba6f2b2ae0f7d0259b5ac5d71baef58fe5a13c699ce0bbf0?d=mp&s=160"},"body":"Hi, Junio C Hamano wrote:\n\n> I would imagine a gitk graph with nodes colored red for commits\n> with last week's timestamps,\n\nOne feature I'd like to see in this context is a gitk tree view that lists\nnodes in date order, instead of the \"walk down one branch as far as\npossible before doing the next one\" process it currently uses.\n\n-- \nMatthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  smurf@smurf.noris.de\nDisclaimer: The quote was selected randomly. Really. | http://smurf.noris.de\n - -\nHow often I found where I should be going only by setting out for somewhere\nelse.\n\t\t-- R. Buckminster Fuller\n"},{"id":"8987","messageId":"17200.325.128562.160145@cargo.ozlabs.ibm.com","threadId":"1866","inReplyTo":"pan.2005.09.20.10.11.38.565694@smurf.noris.de","subject":"Re: Joining cg-*-id","fromName":"Paul Mackerras","fromEmail":"paulus@samba.org","sentAt":"2005-09-20T12:32:05Z","receivedAt":"2005-09-20T12:32:05Z","isPatch":false,"sender":{"key":"paulus@samba.org","avatar":"https://avatars.githubusercontent.com/u/1606439?v=4"},"body":"Matthias Urlichs writes:\n\n> One feature I'd like to see in this context is a gitk tree view that lists\n> nodes in date order, instead of the \"walk down one branch as far as\n> possible before doing the next one\" process it currently uses.\n\nIt's there already: the -d flag to gitk does that.\n\nThat shows them in date order subject to the constraint that children\nare shown before parents.  Yes, it is possible to have a commit that\nis older than its parent(s), if it or its parent(s) were created on a\nmachine whose date is set wrong.\n\nPaul.\n"},{"id":"8990","messageId":"20050920135735.GC1884@pasky.or.cz","threadId":"1866","inReplyTo":"Pine.LNX.4.58.0509191746130.2553@g5.osdl.org","subject":"Re: Joining cg-*-id","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-09-20T13:57:36Z","receivedAt":"2005-09-20T13:57:36Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Tue, Sep 20, 2005 at 02:50:21AM CEST, I got a letter\nwhere Linus Torvalds <torvalds@osdl.org> told me that...\n> On Tue, 20 Sep 2005, Petr Baudis wrote:\n> > But that semantics sucks, and I wouldn't mind changing it at all. I\n> > think taking the previous commit works for everything but the start of\n> > cg-log range, and it is how CVS behaves.\n> \n> The thing is, it may have sensible behaviour for CVS, but only because CVS \n> doesn't have any notion of concurrent development (even a branch isn't \n> concurrent - it's totally separate, and when you merge it, it becomes just \n> one big diff at the time of the merge).\n> \n> So I'd love to have\n> \n> \tgit diff yesterday..\n> \n> but the fact is, there's no sensible semantics for it. _which_ yesterday? \n> There might be five different points that are \"close to 24 hours ago\", \n> along five different paths backwards in the history.\n\nA well-defined meaning for this from Cogito standpoint would be \"the\nlast commit on our HEAD before the date and all commits committed and\nmerged to the HEAD\". In Cogito, you don't merge two branches _together_,\nyou merge one branch _into_ another (represented by the parents order),\nso this would be sensible.\n\nBut we would have to sort the log in merge order for this to be possible\n(and probably teach git-rev-list about it anyway).  I would absolutely\n*love* to have cg-log in merge order instead of date order - longer I\nsee it the more I believe that it's evil and you should really want\nmerge order instead. The trouble is that cg-log would be no longer\nincremental and would have to load the whole history first, a no-go for\nany measurably long history.\n\nBy the way, did I understand it right that the only difference between\nthe results of merge ordering and topo ordering is the order commits\nwith regard to the order of parents?\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nVI has two modes: the one in which it beeps and the one in which\nit doesn't.\n"},{"id":"8991","messageId":"Pine.LNX.4.58.0509200734440.2553@g5.osdl.org","threadId":"1866","inReplyTo":"20050920135735.GC1884@pasky.or.cz","subject":"Re: Joining cg-*-id","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-09-20T14:53:11Z","receivedAt":"2005-09-20T14:53:11Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 20 Sep 2005, Petr Baudis wrote:\n> > \n> > So I'd love to have\n> > \n> > \tgit diff yesterday..\n> > \n> > but the fact is, there's no sensible semantics for it. _which_ yesterday? \n> > There might be five different points that are \"close to 24 hours ago\", \n> > along five different paths backwards in the history.\n> \n> A well-defined meaning for this from Cogito standpoint would be \"the\n> last commit on our HEAD before the date and all commits committed and\n> merged to the HEAD\". In Cogito, you don't merge two branches _together_,\n> you merge one branch _into_ another (represented by the parents order),\n> so this would be sensible.\n\nNo, it's _not_ sensible or well-defined.\n\nThe order of the parents does not matter. It fundamentally _cannot_ \nmatter. I realize that both git and cogito put the \"primary parent\" first, \nbut that doesn't help one iota - because git is distributed, if the other \nside merged and we just did a fast-forward, the \"primary parent\" will be \nthe _other_ side.\n\nIn other words, anybody who thinks that the order of parents is meaningful \nis in for some nasty shocks. It really _fundamentally_ isn't true. I \nrealize that's hard to accept, but it's a truism in a distributed system. \nYou really cannot have parent ordering and distribution at the same time.\n\n> But we would have to sort the log in merge order for this to be possible\n> (and probably teach git-rev-list about it anyway).\n\nIt's not sensible regardless of how you order things. There _is_ no \nordering. \n\nSo if you give a date, and there is a merge after that date, you will\nalways have at least two ways to reach the next older commit (now, if\nyou're lucky, it will be a common one and unambiguous, but more commonly\nyou'll simply have _two_ commits that are \"most recent commit older than\nthe date\".\n\nAnd if you select one of them at random (or by deciding which parent is \nthe \"primary\" one), then \n\n\tgit diff yesterday..\n\nwill show not the changes since yesterday, but _all_ the changes that came \nin through the merge.\n\n> By the way, did I understand it right that the only difference between\n> the results of merge ordering and topo ordering is the order commits\n> with regard to the order of parents?\n\nThe only guarantees topo-ordering gives is that a parent will be shown \nbefore its children. So it may still mix up commits that happened \nbetween two parallell workflows, unlike merge-order that will always show \none parallell chain of development as a contiguous set of commits.\n\nOnly merge-order gives any meaning to the order of the parents, but as \nmentioned, that is irrelevant - a merge on the other side will \"flip\" the \nwhole world-view.\n\nAnd they happen.\n\n\t\tLinus\n"},{"id":"295012","messageId":"20050920150719.GB1836@pasky.or.cz","threadId":"1866","inReplyTo":"Pine.LNX.4.58.0509200734440.2553@g5.osdl.org","subject":"Re: Joining cg-*-id","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-09-20T15:07:19Z","receivedAt":"2005-09-20T15:07:19Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Tue, Sep 20, 2005 at 04:53:11PM CEST, I got a letter\nwhere Linus Torvalds <torvalds@osdl.org> told me that...\n> On Tue, 20 Sep 2005, Petr Baudis wrote:\n> > > \n> > > So I'd love to have\n> > > \n> > > \tgit diff yesterday..\n> > > \n> > > but the fact is, there's no sensible semantics for it. _which_ yesterday? \n> > > There might be five different points that are \"close to 24 hours ago\", \n> > > along five different paths backwards in the history.\n> > \n> > A well-defined meaning for this from Cogito standpoint would be \"the\n> > last commit on our HEAD before the date and all commits committed and\n> > merged to the HEAD\". In Cogito, you don't merge two branches _together_,\n> > you merge one branch _into_ another (represented by the parents order),\n> > so this would be sensible.\n> \n> No, it's _not_ sensible or well-defined.\n> \n> The order of the parents does not matter. It fundamentally _cannot_ \n> matter. I realize that both git and cogito put the \"primary parent\" first, \n> but that doesn't help one iota - because git is distributed, if the other \n> side merged and we just did a fast-forward, the \"primary parent\" will be \n> the _other_ side.\n> \n> In other words, anybody who thinks that the order of parents is meaningful \n> is in for some nasty shocks. It really _fundamentally_ isn't true. I \n> realize that's hard to accept, but it's a truism in a distributed system. \n> You really cannot have parent ordering and distribution at the same time.\n\nOk ok. I can now remember already learning about this once, but I forgot\nagain. I should write it down into some README for myself or so, I\nguess. ;-) Sorry about the noise.\n\nI'll just drop the date revision specifier support from Cogito. I don't\nknow if any measurable number of people actually use it in the real\nworld anyway.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nVI has two modes: the one in which it beeps and the one in which\n"},{"id":"8994","messageId":"pan.2005.09.20.15.13.21.656923@smurf.noris.de","threadId":"1866","inReplyTo":"Pine.LNX.4.58.0509200734440.2553@g5.osdl.org","subject":"Re: Joining cg-*-id","fromName":"Matthias Urlichs","fromEmail":"smurf@smurf.noris.de","sentAt":"2005-09-20T15:13:24Z","receivedAt":"2005-09-20T15:13:24Z","isPatch":false,"sender":{"key":"matthias@urlichs.de","avatar":"https://gravatar.com/avatar/2708905af227313eba6f2b2ae0f7d0259b5ac5d71baef58fe5a13c699ce0bbf0?d=mp&s=160"},"body":"Hi, Linus Torvalds wrote:\n\n> And if you select one of them at random (or by deciding which parent is\n> the \"primary\" one), then\n> \n> \tgit diff yesterday..\n> \n> will show not the changes since yesterday, but _all_ the changes that came\n> in through the merge.\n\nIMHO the way out is to realize that you did the same thing yesterday,\nso presumably, if we teach git to remember what yesterday's head was,\nthere's no problem.\n\nSo let's do a \"git diff-since yesterday\" which simply forks a\n\"git diff since/yesterday..HEAD\", and then copies .git/HEAD to\n.git/refs/since/yesterday.\n\nJust don't call it \"yesterday\" in the documentation ;-)  and print a nice\nerror message instead of an ugly one if the user hasn't run the program\nbefore. (But still do the copy.)\n\n-- \nMatthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  smurf@smurf.noris.de\nDisclaimer: The quote was selected randomly. Really. | http://smurf.noris.de\n - -\nWhat if everything is an illusion and nothing exists?  In that case, I\ndefinitely overpaid for my carpet.\n\t\t-- Woody Allen, \"Without Feathers\"\n"},{"id":"9001","messageId":"Pine.LNX.4.58.0509200906120.2553@g5.osdl.org","threadId":"1866","inReplyTo":"20050920150719.GB1836@pasky.or.cz","subject":"Re: Joining cg-*-id","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-09-20T16:54:57Z","receivedAt":"2005-09-20T16:54:57Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 20 Sep 2005, Petr Baudis wrote:\n> \n> I'll just drop the date revision specifier support from Cogito. I don't\n> know if any measurable number of people actually use it in the real\n> world anyway.\n\nI think the date specifier makes sense for cg-log, though. \n\nIe it doesn't make sense as a generic cg-*-id thing, but it _does_ make \nsense as a totally log-specific case.\n\nMaybe it could use \"-d\" instead of \"-r\", since it's really a totally \nseparate control. For example, there's nothing wrong with\n\n\tcg-log -d yesterday v2.6.12..\n\nwhich would limit the revisions _both_ to a date _and_ to a version.\n\nSo it's just \"diff against time\" that makes no sense. But both \"git log\" \nand \"git whatchanged\" are sensible in time: there's no problem with saying \n\"what commits happened in the last 24 hours\", but there _is_ a problem \nwith saying \"show me the difference from 24 hours ago\".\n\nSee? The \"list of commits\" is sensible, it's just the \"one revision\" thing \nthat isn't.\n\nHere's a stupid example of how to do this in git. \n\nWith this silly patch, this like\n\n\tgit whatchanged --since=\"1 month ago\"\n\tgit log --since=\"5 days ago\"\n\tgitk --since=yesterday\n\nall work. I don't know how _useful_ it is, but it's kind of cool.\n\n(Side note: the \"gitk\" thing works really badly. gitk doesn't quote its \narguments to \"git-rev-list\", so something like\n\n\tgitk --since=\"1 month ago\"\n\ndoes NOT work, while \"--since=yesterday\" does, because it has no spaces. \nGaah. \"Obi-Paul Mackerras, you're our only hope\")\n\n\t\tLinus\n\n---\ndiff --git a/rev-parse.c b/rev-parse.c\n--- a/rev-parse.c\n+++ b/rev-parse.c\n@@ -6,6 +6,7 @@\n #include \"cache.h\"\n #include \"commit.h\"\n #include \"refs.h\"\n+#include \"quote.h\"\n \n #define DO_REVS\t\t1\n #define DO_NOREV\t2\n@@ -125,6 +126,27 @@ static int show_reference(const char *re\n \treturn 0;\n }\n \n+static void show_datestring(const char *datestr)\n+{\n+\tFILE *date;\n+\tstatic char buffer[100] = \"--max-age=\";\n+\tstatic char cmd[1000];\n+\tint len;\n+\n+\t/* date handling requires both flags and revs */\n+\tif ((filter & (DO_FLAGS | DO_REVS)) != (DO_FLAGS | DO_REVS))\n+\t\treturn;\n+\tsnprintf(cmd, sizeof(cmd), \"date --date=%s +%%s\", sq_quote(datestr));\n+\tdate = popen(cmd, \"r\");\n+\tif (!date || !fgets(buffer + 10, sizeof(buffer) - 10, date))\n+\t\tdie(\"git-rev-list: bad date string\");\n+\tpclose(date);\n+\tlen = strlen(buffer);\n+\tif (buffer[len-1] == '\\n')\n+\t\tbuffer[--len] = 0;\n+\tshow(buffer);\n+}\n+\n int main(int argc, char **argv)\n {\n \tint i, as_is = 0, verify = 0;\n@@ -207,6 +229,10 @@ int main(int argc, char **argv)\n \t\t\t\tprintf(\"%s/.git\\n\", cwd);\n \t\t\t\tcontinue;\n \t\t\t}\n+\t\t\tif (!strncmp(arg, \"--since=\", 8)) {\n+\t\t\t\tshow_datestring(arg+8);\n+\t\t\t\tcontinue;\n+\t\t\t}\n \t\t\tif (verify)\n \t\t\t\tdie(\"Needed a single revision\");\n \t\t\tshow_flag(arg);\n"},{"id":"9010","messageId":"Pine.LNX.4.58.0509201224360.2553@g5.osdl.org","threadId":"1866","inReplyTo":"Pine.LNX.4.58.0509200906120.2553@g5.osdl.org","subject":"Re: Joining cg-*-id","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-09-20T19:34:10Z","receivedAt":"2005-09-20T19:34:10Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 20 Sep 2005, Linus Torvalds wrote:\n> \n> (Side note: the \"gitk\" thing works really badly. gitk doesn't quote its \n> arguments to \"git-rev-list\", so something like\n> \n> \tgitk --since=\"1 month ago\"\n> \n> does NOT work, while \"--since=yesterday\" does, because it has no spaces. \n> Gaah. \"Obi-Paul Mackerras, you're our only hope\")\n\nFixed thusly, I think.\n\nThere is 'eval' magic with pure lists. I'm getting convinced that tcl is \nevil after all - that's just _confusing_. A real language shouldn't have \nsemantic differences from this change, but it clearly does.\n\nHowever, getting gitk working also shows a problem with --topo-order\n(which gitk uses) and the time limits. See\n\n\t[torvalds@g5 git]$ git-rev-list $(git-rev-parse --since=\"8 days ago\" HEAD) | wc\n\t     80      80    3280\n\t[torvalds@g5 git]$ git-rev-list --topo-order $(git-rev-parse --since=\"8 days ago\" HEAD) | wc\n\t     10      10     410\n\nwhich is because when we sort things topologically, they won't be in date \norder any more (surprise surprise), so the whole date-cut-off logic \ndoesn't actually work.\n\nSo I'm sad to say that\n\n\tgitk --since=\"5 days ago\"\n\nstill doesn't do what you'd actually _want_ it to do with gitk. But at \nleast gitk can now parse the arguments right.\n\n\t\tLinus\n\n---\ndiff --git a/gitk b/gitk\n--- a/gitk\n+++ b/gitk\n@@ -33,8 +33,8 @@ proc getcommits {rargs} {\n     set nextupdate [expr $startmsecs + 100]\n     set ncmupdate 1\n     if [catch {\n-\tset parse_args [concat --default HEAD $rargs]\n-\tset parsed_args [split [eval exec git-rev-parse $parse_args] \"\\n\"]\n+\tset parse_cmd [concat git-rev-parse --default HEAD $rargs]\n+\tset parsed_args [split [eval exec $parse_cmd] \"\\n\"]\n     }] {\n \t# if git-rev-parse failed for some reason...\n \tif {$rargs == {}} {\n"},{"id":"9025","messageId":"20050921085037.GC24902@pasky.or.cz","threadId":"1866","inReplyTo":"Pine.LNX.4.58.0509200906120.2553@g5.osdl.org","subject":"Re: Joining cg-*-id","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-09-21T08:50:37Z","receivedAt":"2005-09-21T08:50:37Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Tue, Sep 20, 2005 at 06:54:57PM CEST, I got a letter\nwhere Linus Torvalds <torvalds@osdl.org> told me that...\n> On Tue, 20 Sep 2005, Petr Baudis wrote:\n> > \n> > I'll just drop the date revision specifier support from Cogito. I don't\n> > know if any measurable number of people actually use it in the real\n> > world anyway.\n> \n> I think the date specifier makes sense for cg-log, though. \n> \n> Ie it doesn't make sense as a generic cg-*-id thing, but it _does_ make \n> sense as a totally log-specific case.\n> \n> Maybe it could use \"-d\" instead of \"-r\", since it's really a totally \n> separate control. For example, there's nothing wrong with\n> \n> \tcg-log -d yesterday v2.6.12..\n\nYes, I agree on that. I added the -d option now and will remove the -r\ndate functionality soon.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nVI has two modes: the one in which it beeps and the one in which\nit doesn't.\n"},{"id":"9033","messageId":"17201.14169.150101.991868@cargo.ozlabs.ibm.com","threadId":"1866","inReplyTo":"Pine.LNX.4.58.0509201224360.2553@g5.osdl.org","subject":"Re: Joining cg-*-id","fromName":"Paul Mackerras","fromEmail":"paulus@samba.org","sentAt":"2005-09-21T10:35:05Z","receivedAt":"2005-09-21T10:35:05Z","isPatch":false,"sender":{"key":"paulus@samba.org","avatar":"https://avatars.githubusercontent.com/u/1606439?v=4"},"body":"Linus Torvalds writes:\n\n> On Tue, 20 Sep 2005, Linus Torvalds wrote:\n> > \n> > (Side note: the \"gitk\" thing works really badly. gitk doesn't quote its \n> > arguments to \"git-rev-list\", so something like\n> > \n> > \tgitk --since=\"1 month ago\"\n> > \n> > does NOT work, while \"--since=yesterday\" does, because it has no spaces. \n> > Gaah. \"Obi-Paul Mackerras, you're our only hope\")\n\n<scratches head> It works for me - with your rev-list.c and\nrev-parse.c patches, an unmodified gitk (as in current git.git) works\njust fine; both gitk --since=yesterday and gitk --since=\"1 day ago\"\ngive the same set of commits (two merges and an NTFS change, plus\n\"Linux v2.6.14-rc2\" and a SCSI zfcp patch shown with open circles).\n\n> There is 'eval' magic with pure lists. I'm getting convinced that tcl is \n> evil after all - that's just _confusing_. A real language shouldn't have \n> semantic differences from this change, but it clearly does.\n\nI can't see any semantic difference...\n\nCan you still replicate the problem with an unmodified gitk?\n\nPaul.\n"},{"id":"9041","messageId":"Pine.LNX.4.58.0509210750060.2553@g5.osdl.org","threadId":"1866","inReplyTo":"17201.14169.150101.991868@cargo.ozlabs.ibm.com","subject":"Re: Joining cg-*-id","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-09-21T14:51:33Z","receivedAt":"2005-09-21T14:51:33Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 21 Sep 2005, Paul Mackerras wrote:\n> \n> Can you still replicate the problem with an unmodified gitk?\n\nOooh. I can't. Very strange. I definitely could yesterday:  \n\"--since=yesterday\" worked, but \"--since='1 week ago'\" didn't.\n\nMagic. Maybe I mistyped something.\n\n\t\tLinus\n"},{"id":"9072","messageId":"17201.52846.627734.327798@cargo.ozlabs.ibm.com","threadId":"1866","inReplyTo":"Pine.LNX.4.58.0509210750060.2553@g5.osdl.org","subject":"Re: Joining cg-*-id","fromName":"Paul Mackerras","fromEmail":"paulus@samba.org","sentAt":"2005-09-21T21:19:42Z","receivedAt":"2005-09-21T21:19:42Z","isPatch":false,"sender":{"key":"paulus@samba.org","avatar":"https://avatars.githubusercontent.com/u/1606439?v=4"},"body":"Linus Torvalds writes:\n\n> Oooh. I can't. Very strange. I definitely could yesterday:  \n> \"--since=yesterday\" worked, but \"--since='1 week ago'\" didn't.\n\nAhhh... \"--since='1 week ago'\" doesn't work because of the extra set\nof single quotes: we end up doing:\n\n\tgit-rev-parse --default HEAD \"--since='1 week ago'\"\n\nwhich gives this error:\n\n\tdate: invalid date `'1 week ago''\n\tfatal: git-rev-list: bad date string\n\nGitk's error message is admittedly less than informative, but that's\nthe worst it's guilty of (this time :).\n\nPaul.\n"}]}