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

[Jay Soffian <jaysoffian@gmail.com>]

On Mon, May 16, 2011 at 3:00 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> 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.

Well, then why wasn't the change simply reverted?

> For example, maybe (after fixing the scripts we already know about,
> such as tig) we could add the log.abbrevcommit variable right away but
> advertise it as experimental:
>
>        *Warning* This option is experimental and will break your
>        scripts.  It is only provided to give script authors a
>        chance to test this functionality and fix their scripts
>        before the feature is advertised in earnest.
>
> One transition plan could look like this:
>
>  1. In the release notes to v1.7.6, mention that there is a change
>    on the horizon that would break people's scripts and encourage
>    script authors to switch to "rev-list | diff-tree -s --stdin"
>    if their scripts depend on the details of "git log" format
>    (in particular, if their scripts do not work correctly after
>    s/log/log --abbrev-commit/).  Introduce the log.abbrevcommit
>    variable to help people test, guarded by a compile-time
>    option and disabled by default.
>
>  2. In v1.7.7, introduce the log.abbrevcommit variable, advertised
>    as "This will break your system --- don't use it unless you
>    are trying to find such breakage and fix it".
>
>  3. In v1.8.0, introduce the variable in earnest and recommend
>    that people use it.
>
> I think step 1 is going too far --- it should be possible to give
> users rope like this without worrying that they are going to be
> irresponsible about it.
>
> 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.

To my mind, we call "--pretty=raw" de-facto plumbing and keep the
change as is. Though perhaps, there is a cleaner implementation if we
say that --pretty=raw is indeed plumbing.

> Thanks for some food for thought.

And here I thought this was a simple one. :-(

j.