On Mon, Apr 15, 2013 at 6:14 PM, Junio C Hamano <gits...@pobox.com> wrote:
> Felipe Contreras <felipe.contre...@gmail.com> writes:
>> And about this:
> What about it? Is that the one you said you are going to reroll?
At first, but then I changed my mind.
> I do not recall the details of Peff's complaints, but re-reading the
> log message of the patch itself, seeing "correctly" twice is not
> satisfactory. As you very well know, a bug description that says
> "This does not correctly work!" and stops there is not as useful as
> a description that defines what "correct" behaviour is expected.
The subject is: transport-helper: update remote helper namespace
Clearly, that's the correct behavior. Why would anybody send a change
that does something other than the correct behavior?
When pushing, the remote namespace is updated correctly
(e.g. refs/origin/master), but not the remote helper's
So it should be clear now: the remote namespace refs/origin/master is
updated, but not the remote helper's namespace
refs/testgit/origin/master, which is what I already said. I don't know
what more do you expect. When you push 'refs/heads/master' to origin,
you expect 'refs/remotes/origin/master' to point to the same commit,
same with 'refs/testgit/origin/master', why would you expect to point
> If one of them said "update correctly to record what was pushed" or
> something like that, that should be sufficient.
Sure, it's still under the definition of "cooking" in my mind. Anyway,
I'm not feeling a great urge to resubmit this patch just because of
the commit message, which I think it's perfectly fine. There's more
interesting things work on.
Personally I feel it's preferable to fix the actual issue that is
already present rather than hold it because the commit message might
or might not be enough for hypothetical point in the future.
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