[prev in list] [next in list] [prev in thread] [next in thread] 

List:       git
Subject:    Re: [PATCH] Teach revision walker about reflog ranges
From:       Johannes Schindelin <Johannes.Schindelin () gmx ! de>
Date:       2007-12-30 10:32:03
Message-ID: Pine.LNX.4.64.0712301126560.14355 () wbgn129 ! biozentrum ! uni-wuerzburg ! de
[Download RAW message or body]

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

-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
[prev in list] [next in list] [prev in thread] [next in thread]