On Tue, Apr 16, 2013 at 4:59 AM, Thomas Rast <tr...@inf.ethz.ch> wrote:
> Felipe Contreras <felipe.contre...@gmail.com> writes:
>> Clearly, that's the correct behavior. Why would anybody send a change
>> that does something other than the correct behavior?
> Along the same lines, why would anyone write broken code? Nobody does,
Yes, I should change the subject to:
transport-helper: update remote helper namespace, because that's
exactly the thing we DON'T want to do, the purpose of this patch is to
mess up everything
Suree. I'm willing and knowingly introducing a change that goes
diametrically opposite to what we want.
> If anyone reads that commit message in more than a few weeks, then it's
> because some of the code is *broken*.
That is irrelevant. Junio said the correct behavior was not described,
when if fact it clearly is. Whether or not the patch has a bug in it
is irrelevant to the fact that the correct behavior is described or
> So the reader is investigating a
> situation where there must be a flaw somewhere, and trying to pin down
> the source. Having access to the thinking behind each commit means s/he
> can more easily verify whether that thinking was correct and still
Sure, and where is the thinking not clear? The remote helper ref is
not updated, so we do update it. How is that not clear?
> And your commit messages do nothing towards that end.
Oh, it does. You just don't understand how remote-helper works.
> A cursory look^W^Wreview of the messages in fc/remote-hg:
[skipping irrelevant comments]
I'm sorry, did you actually hit an issue that required to look at the
commit message to understand where the issue came from? No? Then I
won't bother with hypotheticals.
If you want to waste your time, by all means, rewrite all my commit
messages with essays that nobody will ever read. I'm not going to do
that for some hypothetical case that will never happen. I'm not going
to waste my time.
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