Jonathan Nieder <jrnie...@gmail.com> writes:
> Hi Florian,
> Florian Achleitner wrote:
>> After importing new commits on top of refs/remotes/* the
>> ref was overwritten with the local refs/heads/master, because the name
>> of the remote reference to fetch, i.e. refs/heads/master, was used to
>> retrieve old_sha1 for it's local counterpart. Therefore, old_sha1 pointed
>> to the local head which was not contained in the remote branch and couldn't
>> be updated (printing a warning ..).
> I assume you are talking about the status quo here. It's easy to
> forget that others have not already applied your patch, but using the
> present tense would make reading easier. Think of the patch
> description as a special kind of bug report.
> Unfortunately, as a bug report, the above is lacking some detail. Do
> I understand correctly that some remote helper is failing when git
> invokes its 'import' command? What are the symptoms? If it prints a
> warning, what is the exact warning?
> Does that remote helper advertise the 'refspec' capability? If so,
> what refspec does it use? If not, why not?
> It might seem silly to ask for these things when you're providing a
> fix along with the report!
I share the puzzlement you expressed above, and it is unclear if
this is a fix or covering a user error with butchering a code that
is working as intended, making two wrongs happen to collide into
producing a right.
At least it needs a better description of the problem it tries to
fix, preferrably in the form of a new test for the transport helper.
> However, if someone else runs into the
> same symptoms, they need to be able to find your patch quickly; if
> your patch has a bad side-effect then we need to know why not to
> revert it; and if someone new starts working on the same area of code,
> they need to know what bugs to avoid reintroducing.
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