On Thu, Apr 25, 2013 at 3:36 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Felipe Contreras <felipe.contreras@xxxxxxxxx> 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. I don't see the value of pointing that out in the particular commit, since you are the only one that would do anything with that information, and it seems the message came across. If there's any issues with that, just drop the patch, and if there's issues with the rest of the series, just drop them. I'll resend when the stuff is merged to master. > * 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. That's exactly what I've been doing. You are extrapolating from this particular patch, which I already admitted I made a mistake, and it's not really important in any way. > * 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. The history *is* readable. If anybody has any problems with the commit messages, the place to mention such problems is IN THE PATCH REVIEW. Nobody has done that, because either nobody has any problems, or they are not interested. Either way, there's nothing I can do about it. *This* patch is an exception, and I'm not willing to waste time on this extremely trivial patch. Drop it. >> 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. You want to drop the whole series because of a cleanup patch with a less-than-perfect commit message? Even though there quite likely won't be any conflicts if you drop the single patch. Fine, drop the whole series. >> ... 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. Are you saying that because *ONE PATCH*, introduces a fix without mentioning it in the commit message, *THE WHOLE* project becomes unmaintainable? If not, then why are we discussing about something that is not happening? > 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. And I am. Because I made a mistake in this patch doesn't mean the same happened in all the patches. I am helping my fellow developers by replying to the comments they make when I send the patches for review. Unfortunately, the only developer other than you that has made any comment at all, Ramkumar Ramachandra, did so in a bellicose tone, but I replied to all his comments either way, which where invalid. The only comment where he is right and I acknowledged making a small mistake, is trivial, does not cause any issues, and can be easily dropped. > Do not take the "users matter" mantra to the extreme. You need other > developers to put users first. No, I don't. It would be nice, yes, but not necessary. Now, let's drop this pointless discussion and deal with the actual issue. What do you want to do? 1) Drop this patch 2) Drop the whole series 3) I reroll without the change that was not described Anything else, I'm not interested in doing. There's tasks with actual value to do. Cheers. -- 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