Felipe Contreras <felipe.contre...@gmail.com> writes: > But I do not care that much really. The patch is good either way, if > you don't like it, you go ahead and fix it, because I won't. I have > 174 remote-helper related patches in my queue, and nobody benefits > from rambling about a one liner that is obviously correct, not you, > not me, not the users, not the developers.
Three random points. * For this particular patch [1/9], especially because this would land close to the corresponding remote-hg fixes (e.g. "has_key is deprecated"), I think it is sufficient to say "port fixes from corresponding remote-hg patches" (you said it in 0/9 and didn't say it in 1/9, though) without going into individual details. Anybody who wonders what these changes were about will have a clue to check contemporary patches to remote-hg that way. * You may want to hold onto those 174 patches and polish their explanation up to save the list audiences' time by avoiding this kind of useless "why no explanation" exchanges. * If you do not want to keep a readable history, it would mean that nobody but you will fix problems discovered in the future in remote-hg, and there is no point carrying it in my tree for other Git developers to look at it. The users are better off getting them from your tree and that will make it clear for them whom to ask help/fix for when they hit a snag. > Junio of course might disagree and drop this patch, but then he would > need to deal with the fallout of possible conflicts. A much more sensible thing in such a case for me to do actually is to drop the whole thing. I do not want to do that unless necessary. > ... I think the less-than-perfect commit messages in a > *contrib* script that is extremely recent is a small price to pay for > having nice and workable bzr and mercurial remote-helpers as soon as > possible I do not share this view at all. The users survived without it long enough; they can wait for a well maintained version. On the other hand, shipping something that will not be maintainable is not the way to help end users. It is being irresponsive to them. Helping other developers understand your code is a way to ensure that your code that would help users will be kept maintained. I do not agree with Ram at all when he says that developers are more important than users, and I agree with you that the project exists for users, and not for developers. But you need to help your fellow developers anyway by spending effort to keep your history readable, in order to help them help the users. Do not take the "users matter" mantra to the extreme. You need other developers to put users first. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
