On Wed, Sep 02, 2015 at 01:11:35PM -0700, Junio C Hamano wrote: > John Keeping <john@xxxxxxxxxxxxx> writes: > > OTOH, I don't think there's any disagreement about what "relative-local" > > and "raw-local" would output were they supported, just whether they are > > useful. There doesn't seem to be any harm in supporting them; > > "relative-local" will be identical to "relative" and "raw-local" will > > require preparatory code movement for the raw output. > > Sure. > > Bikeshedding further, while Peff's message "-local is meaningless" > is a correct statement of the fact, I do not think it explains well > why we chose to error out instead of giving the most natural result > (i.e. exactly the same as 'relative'). > > Perhaps stating "relative-local is not supported" without saying why > would be better. "Because it is meaningless, we refuse to support > the option." is a very strong statement that tells aspiring future > Git hackers not to attempt to add a support for it, which is > probably a wrong message to send. In which case, should we just support it now? Normally I'd suggest banning controversial options on the basis that it's easier in the future to allow something that was previously banned than change the meaning of an options, but in this case I can't see any other meaning for these options than that described above. -- 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