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

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 29, 2018, 21:03 UTC
Message-ID: <xmqqin3s94vf.fsf@gitster-ct.c.googlers.com>
In-Reply-To: <20180829200553.19379-1-agruenba@redhat.com>

Andreas Gruenbacher <agruenba@redhat.com> writes:

Show 14 quoted lines

> 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.