On Mon, Feb 23, 2009 at 8:39 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Felipe Contreras <felipe.contreras@xxxxxxxxx> writes: > >> It's not breakage that needs to be fixed, it's UI improvement,... >> ... Don't you >> think that --format=email is more natural than --pretty=email? > > That heavily depends on when you ask. > > If it _were_ during the period when we were actively building this > bikeshed, then I would have said "yeah, that color looks prettier". > > But a proposal to repaint the bikeshed in a different color long after it > was built needs to be supported by an argument that is much stronger than > "I do not like the current one, I am improving it by painting in a better > color." IOW, you came too late to just bikeshed. > > People already are used to finding the shed in the scenery by looking for > that original color, however ugly the color might be. The answer to your > question has to become quite different when you take that into account; > otherwise you are being irresponsible to your users. The color of a bikeshed is essentially irrelevant, red vs blue makes almost no difference. Are you suggesting that --pretty and --format are essentially the same and therefore arguing about one vs the other is a waste of time? Words have associated meaning, choosing one over the other makes a big difference, sometimes huge. Image what would have happened if programming languages would have chosen 'check' instead of 'if'... > This falls into the "it would have been very nice if it were like that > from day one. I'd happily agree with you,... only if we didn't do it the > way we originally did" category. You cannot call such a change an > improvement without thinking why the above statement is heavily qualified > with "if it were" and "only if we didn't". I'm saying we should be in point B (--format), you are saying we are already in point A (--pretty), it would have been nicer to choose B since day one, but we didn't. I'm still saying we should be in point B, even if the path from A to B is unclear, and maybe tedious, it's still an improvement, and as such it must be done eventually. AFAIK git's user interface is one of the big areas for improvement, and a common complaint from anti-gitters... this is an example of one of the issues. Perhaps there should be a way to handle this "it would have been very nice if it were like that from day one" cases, maybe queue the patches on a separate branch until some big release? 1.7.x? Or maybe in the meantime generate a warning: X is deprecated, please use Y instead. The issue that comes into my mind is the old 'git-foo' format. The switch wasn't handled correctly according to many people... most users noticed until it was very late. That's why deprecation warnings make sense. > I am actually Ok with having a synonym --format that works *identically* > with how --pretty works, and then update how both of them work to make > them better perhaps in a follow-up patch. You accept style names that you > recognize as before, and instead of erroring out, if the unrecognized > string has % in it, pretend as if "tformat:" was in front of it. It still > has the "two keywords for the same thing" misfortune, but that is > something you cannot avoid. You yourself would need to say "newer git > would accept --format=short, but with the version shipped by your > distribution you may have to say --pretty instead" when teaching new > people who come after you. Hopefully not many people would complain as > long as you do not break the existing --pretty, I would rather say --pretty is history, if you have 1.7.x, use --format. > Also I like Linus's --oneline === --pretty=oneline, but I haven't audited > the list of double-dash options our commands take that are unrelated to > pretty-printing styles. If there are ones that look or sound similar to > the recognized style names (or if some commands may want to use the word > for controlling their own operation that is not related to pretty-printing > in their future enhancement), it would cause grief to us down the road. > The only one I can think of offhand is --full, so this probably is Ok. Yeah, I would like --oneline too. -- Felipe Contreras -- 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
