Thread (1 message) 1 message, 1 author, 2016-06-15

Re: [PATCH v3] Add log.abbrevCommit config variable

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:51:15

Jonathan Nieder [off-list ref] writes:
Jay Soffian wrote:
quoted
On Sun, May 15, 2011 at 6:42 PM, Junio C Hamano [off-list ref] wrote:
quoted
quoted
I am not entirely happy about this change. The "ditto" refers to an ugly
workaround we had to add with 4f62c2b (log.decorate: only ignore it under
"log --pretty=raw", 2010-04-08) only because it was too late to revert the
change in 72d9b22 (Merge branch 'sd/log-decorate', 2010-05-08) that was
about to become part of 1.7.2-rc0 release. If we knew better, we probably
wouldn't have added the log.decorate variable that requires this hack that
requires us to say that 'log --pretty=raw' is special.

If we stop before adding a new configuration, we do not have to repeat the
same mistake we made earlier.

I dunno.
I disagree that log.decorate is a mistake and that the workaround is
ugly.
I suppose part of what Junio is saying is that by the time the commits
referenced above were written, git had already broken some scripts
(including gitk) and those changes were part of a desparate attempt to
contain the damage.  So they are not a great example to look to for
the sort of smooth transition it is possible to set up proactively.
Thanks for rephasing.
One transition plan could look like this:
...
Now, returning to "log --pretty=raw".  Is it plumbing or not?  It
would be nice to advertise whichever way it is decided (I guess it is
de facto plumbing) in the "git log" reference documentation and to
follow that decision in cases like this one.

Thanks for some food for thought.
Although I find the cop-out "if you set this variable, some third-party
tools may break---please do not complain to us, but send bug reports to
these third-party folks" somewhat attractive, I am reluctant to take that
position. I suspect some projects do work that way, and if it works for
them, it may turn out that we wouldn't get much flak doing so ourselves,
but still...

But having slept on this, I would agree that it is a pragmatic solution to
declare "pretty=raw _is_ special" and keep it that way.  Let's queue v3
from Jay and see what happens.

Thanks.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help