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