[PATCH] Teach revision walker about reflog ranges

[PATCH] Teach revision walker about reflog ranges

[Johannes Schindelin]

Now you can ask for a revision range

	master@{2.weeks.ago..1.day.ago}

or even something like

	HEAD@{20..yesterday}

It does this by allocating an strbuf to construct the second ref string
(in the above examples "master@{1.day.ago}" and "HEAD@{yesterday}",
respectively), which is never free()d.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---

	Another nail in the coffin of libification, but for the common 
	one-shot command, it is the easiest way to support reflog ranges.

 revision.c |   14 ++++++++++++++
 1 files changed, 14 insertions(+), 0 deletions(-)

diff --git a/revision.c b/revision.c
index 6e85aaa..3e7a834 100644
--- a/revision.c
+++ b/revision.c
@@ -794,10 +794,24 @@ int handle_revision_arg(const char *arg, struct rev_info *revs,
 		const char *this = arg;
 		int symmetric = *next == '.';
 		unsigned int flags_exclude = flags ^ UNINTERESTING;
+		const char *at;
 
 		*dotdot = 0;
 		next += symmetric;
 
+		at = strstr(arg, "@{");
+		if (at && !strchr(at + 2, '}')) {
+			struct strbuf buf;
+			strcpy(dotdot, "}");
+			strbuf_init(&buf, 0);
+			strbuf_insert(&buf, 0, arg, at + 2 - arg);
+			if (!strcmp(next, "}"))
+				strbuf_addch(&buf, '0');
+			strbuf_addstr(&buf, next);
+			/* we will not free() this buffer */
+			next = buf.buf;
+		}
+
 		if (!*next)
 			next = "HEAD";
 		if (dotdot == arg)
-- 
1.5.4.rc2.5.g44b6d-dirty

Re: [PATCH] Teach revision walker about reflog ranges

[Junio C Hamano]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> Now you can ask for a revision range
>
> 	master@{2.weeks.ago..1.day.ago}
>
> or even something like
>
> 	HEAD@{20..yesterday}

You can _ask_ all you want, but it is not clear what it does
from this description.  I guess you are rewriting master@{A..B}
to master@{A}..master@{B}, but that is not clear from the commit
log nor documentation (did I even see a documentation patch?).

Also, I am not convinced that the rewrite gives the semantics
the users naturally expect from @{A..B}.  I would even suspect
that people would expect "git log master@{0..2}" to behave more
like "git show master@{0} master@{1} master@{2}".

Re: [PATCH] Teach revision walker about reflog ranges

[Johannes Schindelin]

Hi,

On Sat, 29 Dec 2007, Junio C Hamano wrote:

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> > Now you can ask for a revision range
> >
> > 	master@{2.weeks.ago..1.day.ago}
> >
> > or even something like
> >
> > 	HEAD@{20..yesterday}
> 
> You can _ask_ all you want, but it is not clear what it does from this 
> description.  I guess you are rewriting master@{A..B} to 
> master@{A}..master@{B}, but that is not clear from the commit log nor 
> documentation (did I even see a documentation patch?).

Oh, sorry, I meant to mark this as RFC-after-1.5.4.  It's just that I had 
a need for it, and hacked it.

> Also, I am not convinced that the rewrite gives the semantics the users 
> naturally expect from @{A..B}.  I would even suspect that people would 
> expect "git log master@{0..2}" to behave more like "git show master@{0} 
> master@{1} master@{2}".

Is that so?  I would have expected "git log -g master@{2..0}" like that.  
It would be relatively easy to accomodate your wish (almost: it would not 
handle 0..2, but only 2..0) by calling

	init_reflog_walk(&revs->reflog_info);

in the case that ".." was found inside "@{[...]}".

But my use case was to make it easy to see what changed in a multi-branch 
remote without much typing: "git log origin/master@{1..}", which would not 
be helped by that change.

Ciao,
Dscho