{"thread":{"id":"11424","subject":"[PATCH] Teach revision walker about reflog ranges","startedAt":"2007-12-29T23:02:11Z","lastAt":"2007-12-30T10:32:03Z","messageCount":3,"participants":["Johannes Schindelin","Junio C Hamano"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"64196","messageId":"Pine.LNX.4.64.0712300000170.14355@wbgn129.biozentrum.uni-wuerzburg.de","threadId":"11424","inReplyTo":null,"subject":"[PATCH] Teach revision walker about reflog ranges","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-12-29T23:02:11Z","receivedAt":"2007-12-29T23:02:11Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"\nNow you can ask for a revision range\n\n\tmaster@{2.weeks.ago..1.day.ago}\n\nor even something like\n\n\tHEAD@{20..yesterday}\n\nIt does this by allocating an strbuf to construct the second ref string\n(in the above examples \"master@{1.day.ago}\" and \"HEAD@{yesterday}\",\nrespectively), which is never free()d.\n\nSigned-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>\n---\n\n\tAnother nail in the coffin of libification, but for the common \n\tone-shot command, it is the easiest way to support reflog ranges.\n\n revision.c |   14 ++++++++++++++\n 1 files changed, 14 insertions(+), 0 deletions(-)\n\ndiff --git a/revision.c b/revision.c\nindex 6e85aaa..3e7a834 100644\n--- a/revision.c\n+++ b/revision.c\n@@ -794,10 +794,24 @@ int handle_revision_arg(const char *arg, struct rev_info *revs,\n \t\tconst char *this = arg;\n \t\tint symmetric = *next == '.';\n \t\tunsigned int flags_exclude = flags ^ UNINTERESTING;\n+\t\tconst char *at;\n \n \t\t*dotdot = 0;\n \t\tnext += symmetric;\n \n+\t\tat = strstr(arg, \"@{\");\n+\t\tif (at && !strchr(at + 2, '}')) {\n+\t\t\tstruct strbuf buf;\n+\t\t\tstrcpy(dotdot, \"}\");\n+\t\t\tstrbuf_init(&buf, 0);\n+\t\t\tstrbuf_insert(&buf, 0, arg, at + 2 - arg);\n+\t\t\tif (!strcmp(next, \"}\"))\n+\t\t\t\tstrbuf_addch(&buf, '0');\n+\t\t\tstrbuf_addstr(&buf, next);\n+\t\t\t/* we will not free() this buffer */\n+\t\t\tnext = buf.buf;\n+\t\t}\n+\n \t\tif (!*next)\n \t\t\tnext = \"HEAD\";\n \t\tif (dotdot == arg)\n-- \n1.5.4.rc2.5.g44b6d-dirty\n"},{"id":"64198","messageId":"7vve6h9gvz.fsf@gitster.siamese.dyndns.org","threadId":"11424","inReplyTo":"Pine.LNX.4.64.0712300000170.14355@wbgn129.biozentrum.uni-wuerzburg.de","subject":"Re: [PATCH] Teach revision walker about reflog ranges","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-12-30T00:16:00Z","receivedAt":"2007-12-30T00:16:00Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n\n> Now you can ask for a revision range\n>\n> \tmaster@{2.weeks.ago..1.day.ago}\n>\n> or even something like\n>\n> \tHEAD@{20..yesterday}\n\nYou can _ask_ all you want, but it is not clear what it does\nfrom this description.  I guess you are rewriting master@{A..B}\nto master@{A}..master@{B}, but that is not clear from the commit\nlog nor documentation (did I even see a documentation patch?).\n\nAlso, I am not convinced that the rewrite gives the semantics\nthe users naturally expect from @{A..B}.  I would even suspect\nthat people would expect \"git log master@{0..2}\" to behave more\nlike \"git show master@{0} master@{1} master@{2}\".\n"},{"id":"64204","messageId":"Pine.LNX.4.64.0712301126560.14355@wbgn129.biozentrum.uni-wuerzburg.de","threadId":"11424","inReplyTo":"7vve6h9gvz.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] Teach revision walker about reflog ranges","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-12-30T10:32:03Z","receivedAt":"2007-12-30T10:32:03Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sat, 29 Dec 2007, Junio C Hamano wrote:\n\n> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n> \n> > Now you can ask for a revision range\n> >\n> > \tmaster@{2.weeks.ago..1.day.ago}\n> >\n> > or even something like\n> >\n> > \tHEAD@{20..yesterday}\n> \n> You can _ask_ all you want, but it is not clear what it does from this \n> description.  I guess you are rewriting master@{A..B} to \n> master@{A}..master@{B}, but that is not clear from the commit log nor \n> documentation (did I even see a documentation patch?).\n\nOh, sorry, I meant to mark this as RFC-after-1.5.4.  It's just that I had \na need for it, and hacked it.\n\n> Also, I am not convinced that the rewrite gives the semantics the users \n> naturally expect from @{A..B}.  I would even suspect that people would \n> expect \"git log master@{0..2}\" to behave more like \"git show master@{0} \n> master@{1} master@{2}\".\n\nIs that so?  I would have expected \"git log -g master@{2..0}\" like that.  \nIt would be relatively easy to accomodate your wish (almost: it would not \nhandle 0..2, but only 2..0) by calling\n\n\tinit_reflog_walk(&revs->reflog_info);\n\nin the case that \"..\" was found inside \"@{[...]}\".\n\nBut my use case was to make it easy to see what changed in a multi-branch \nremote without much typing: \"git log origin/master@{1..}\", which would not \nbe helped by that change.\n\nCiao,\nDscho\n"}]}