From: Jay Soffian Date: Mon, 16 May 2011 07:18:21 GMT Subject: Re: [PATCH v3] Add log.abbrevCommit config variable Message-ID: In-Reply-To: <20110516070047.GA26270@elie> On Mon, May 16, 2011 at 3:00 AM, Jonathan Nieder 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.