Wincent Colaiuta <win@xxxxxxxxxxx> writes: > The problem in this case was that my patch didn't receive any > meaningful feedback (ie. suggestions for improvement), only a lot of > bikeshed stuff about whether the environment variable should have an > underscore prefix or not, whether or not I should use "export FOO=..." > or not etc. So I didn't know what was necessary in order to get it > accepted. I do not think that is the case. I think _GIT_FOO vs GIT_FOO is an important detail, not at all a bikeshed color, to make things consistent. "export VAR=VAL" also is a valid concern (you said in a separate message you only know about bash, and I later asked people if they use shells that get affected with it but we happily run otherwise. I personally do not think the latter is a problem, but since somebody already raised it as a potential issue, it gave us a good chance to hear from people on minority platforms, if only to build confidence in us to use that POSIX form. Maybe it is just me, but I think my suggestion to replace not just "git commit" part but also "git add" part is also an important design issue. In any case, after a discussion, sending out a readily applyable patch would help to make sure we reached a reasonable consensus; it makes it easier for other people to try out your proposed draft of the consensus without waiting for me or anybody else and give positive feedback. The difference between the variant I posted and your revised one I see are: * As discussed, we have precedence like GITHEAD_* and GIT_REFLOG_ACTION that are used purely for inter-tool communication without the leading underscore, so I followed them for consistency. * The part of the message that is overridable is made wider; that way, we can later choose to have "git rebase --continue" do the final "git add -u" step, just like we made "git rebase --skip" to run "git reset --hard", without changing revert/cherry-pick,as I explained in the comment to my patch. * I made the help-message creation into a separate function. This is just a minor detail, but I think it is good for readability. * I am setting and exporting the help environment near the beginning of rebase--interactive just once; again I think this is more readable. But other than that, the basic idea is the same and is all yours. If these details (I do not think the overridability is a minor detail, though) look like bikeshedding to you, that is somewhat sad. You seem to be very capable of producing usable code, but these details (consistency and flexibility) matter for longer term stability, and I would really want to see capable people pay attention to such details, especially I sometimes fail to do so myself. - 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
