On Mon, Apr 28, 2014 at 12:03 PM, Sitaram Chamarty <sitaramc@xxxxxxxxx> wrote: >> Johan Herland <johan@xxxxxxxxxxx> writes: >>> Obviously, the feature would necessarily have to be optional, simply >>> because Git would have to keep understanding the old commit object >>> format for a LONG time (probably indefinitely), and there's nothing >>> you can do to prevent others from creating old-style commit objects. > > Johan: I seem to have missed your previous email (fat-fingered something > on my mail client I expect). > > Your **reasons** for making it optional are all wrong. People like me > (and David) who are opposed to this run the risk that if the **format** > were to officially change in some way or for some reason (like, say, if > SHA1 is no longer in favour, or whatever), then this "feature" is > foisted on us willy-nilly. > > That's not good. > > So, while I appreciate your point that it should be optional, please > let's accept that in the end it should be optional because **not > everyone likes it**! You may have missed more than just one previous email... I tried (but obviously failed) to make it clear from the start that I personally don't support this feature (although, as long as it's optional I'm mostly indifferent to it). Trying to steer the discussion towards a constructive end, I then argued that even IF we were to agree that this was a good change (and this thread CLEARLY demonstrates that we DO NOT agree), it would STILL be better to first implement this change within the confines of the existing object model, without making any changes to Git itself. Having done an initial implementation "outside" of the git core (which should be fairly straightforward with hooks + git-interpret-trailers), Jeremy would have gotten the feature he wanted (or at least a close approximation), and we could then observe if this feature became popular/useful enough to consider integrating it into core Git. So, the only constructive way forward (whether we like the feature or not) is for Jeremy (or someone else) to first implement it "outside" the Git core. THIS is my point, and I really, REALLY tried to explain it while AVOIDING the inevitable flamewar about what "belongs" in a commit object or not. It's not that I don't have an opinion on that subject; it's that everybody has their own opinion, and it's largely a philosophical discussion that boils down to peoples workflows, preferences, backgrounds, and whatnot. As such, it's perfect material for the flamewar we're currently observing... ...Johan -- Johan Herland, <johan@xxxxxxxxxxx> www.herland.net -- 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