Jonathan Nieder <> 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.

That, too.

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at

Reply via email to