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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Jonathan Nieder <jrnieder@xxxxxxxxx> writes:

> Jay Soffian wrote:
>> On Sun, May 15, 2011 at 6:42 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
>
>>> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]