Jeff King <peff@xxxxxxxx> writes:
> I'd probably call it something verbose and boring like
> --use-default-with-uninteresting or --default-on-negative.
> I dunno.
These two names are improvement, but there needs a hint that the
change we are interested in is to use default even when revs are
given as long as ALL of them are negative ones. Which in turn means
there is NO positive ones given.
So perhaps "--use-default-without-any-positive".
Having said that, I have to wonder how serious a breakage we are
going to cause to established users and scripts if we made this
change without any explicit option. After all, it would be rather
obvious that people will get a history with some commits (or none at
all) when they were expecting no output that the "default behaviour"
has changed. I also wonder how would scripts take advantage of the
current "defeat --default as soon as we see any rev, even a negative
one"---in short, I am not sure if the theoretical regression this
new "option" is trying to avoid is worth avoiding in the first
place.
Is there a way to say "usually this command has built-in --default=HEAD
behaviour, but I am declining that" already, i.e.
$ git log --no-default $REVS
that will result in an empty set if we accept the change proposed
here but make it unconditional? If so "This and future versions of
Git will honor the --default even when there are other revisions
given on the command line, as long as they are ALL negative ones.
This is a backward incompatibile change, but you can update your
scripts with '--no-default' if you do not like the new behaviour" in
the release notes may be a viable alternative way forward.
If there is no such way in the released versions of Git, then that
would not work, and a strict opt-in like the approach taken by the
proposed patch would become necessary.
