Re: [RFC] revision: Don't let ^<rev> cancel out the default <rev>

From: Jeff King <peff@peff.net>
Date: Aug 29, 2018, 23:30 UTC
Message-ID: <20180829233026.GA15005@sigill.intra.peff.net>
In-Reply-To: <xmqqin3s94vf.fsf@gitster-ct.c.googlers.com>

On Wed, Aug 29, 2018 at 02:03:34PM -0700, Junio C Hamano wrote:

Show 28 quoted lines

> Andreas Gruenbacher <agruenba@redhat.com> writes:
> 
> > Some commands like 'log' default to HEAD if no other revisions are
> > specified on the command line or otherwise.  Unfortunately, excludes
> > (^<rev>) cancel out that default, so when a command only excludes
> > revisions (e.g., 'git log ^origin/master'), the command will not produce
> > any result.
> >
> > If all the specified revisions are excludes, it seems more useful to
> > stick with the default revision instead.
> >
> > This makes writing wrappers that exclude certain revisions much easier:
> > for example, a simple alias l='git log ^origin/master' will show the
> > revisions between origin/master and HEAD by default, and 'l foo' will
> > show the revisions between origin/master and foo, as you would usually
> > expect.
> 
> That is a _huge_ departure from the behaviour established for the
> past 10 years, but it would certainly be more useful.
> 
> As long as we can prove that that a command line with only negative
> revs is absolutely useless, the backward incompatibility may be OK
> to swallow, especially for commands like "git log" that implicitly
> use "--default HEAD", as they are meant for human consumption, and
> not for scripts.
> 
> I am not offhand 100% sure that a rev list with only negative revs
> is totally useless, though.

Yeah, I'm uneasy that somebody is relying on the current behavior, especially for scripting where we often do something like:

  git rev-list $new --not --all

and an empty $new really should return an empty result (that's our usual connectivity check, but I'd imagine some pre-receive hooks may end up doing similar things). For rev-list I think you'd have to specify --default to trigger this behavior, so that helps. But it still makes me nervous.

I'm _less_ uneasy with it for git-log, though I think people do have a habit of scripting around it (because it knows some tricks that rev-list doesn't).

Given that the mentioned use case was writing wrappers, could we hide this behind:

  git config alias.l 'git log --default-on-negative ^origin/master'

That's obviously less convenient to type, but I think it would usually be part of scripted calls (otherwise you'd know already that you have no positive refs and would just add ".." or HEAD or whatever).

-Peff