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
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