git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH] Fix overwritten remote ref on with fast-import.

From
Florian Achleitner <florian.achleitner.2.6.31@gmail.com>
Date
Jul 16, 2012, 22:33 UTC
Message-ID
<11883284.WI8IR4K6qp@flobuntu>
In-Reply-To
<20120716003024.GA4246@burratino>
On Sunday 15 July 2012 19:30:25 Jonathan Nieder wrote:
Show 20 quoted lines
> 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?

I got that problem when I wanted to make remote-svn fetch to refs/remotes/ instead of the formerly hardcoded (in fast-export.c) refs/heads/master. I didn't yet have the refspec capability (now I have it), and that seems to be a significant part of the problem. The scenario is as follows: The fast import stream contains 'commit refs/remotes/svnfile/master' and fast- import adds all the commits on top of it and updates the ref correctly. But the string affected by the patch, 'private', contains the remote name of the branch because it is duped from ref->name, namely refs/heads/master. As a consequence, subsequent processing leads to:

fatal: bad object 0000000000000000000000000000000000000000 error: svn::file:///anypath did not send all necessary objects

..because it expects something to have arrived on refs/heads/master.

If ref/heads/master already exists, it works, but the resulting refs are wrong. refs/remotes/svnfile/master points to the same commit as ref/heads/master does, which is the one created locally. There is no ref to the remote commits.

It follows that, on re-fetching the same remote it fails and fast-import refuses to update the ref: warning: Not updating refs/remotes/svnfile/master (new tip 5479b212afab5ef541c142bf75357405b7888e4d does not contain 4e49b15fcc9797bb90e36ec90c14de3d5437a94d)

That's because the refs/remotes/svnfile/master points to the wrong local-only commit.

After exploring the whole fetch process by inserting dozens of printfs, I concluded that it's wrong to retrieve the sha1 to update by passing the branch name on the remote side (in private) to read_ref, which gives the sha1 of a local branch, but that the correct ref is stored in ->peer_ref. I wasn't really sure what peer-ref is meant to be. That's what lead to the patch, but..

> 
> Does that remote helper advertise the 'refspec' capability?  If so,
> what refspec does it use?  If not, why not?
When it does advertise refspec like:
Debug: Remote helper: <- refspec refs/heads/master:refs/remotes/svnfile/master
it all works. Unfortunatly I didn't understand that a day ago.

But I'm still not completely sure about what the line I wanted to patch is for. Doc about git-remote-helpers says: "If no refspec capability is advertised, there is an implied refspec *:*." Hmm..so if the helper doesn't advertise 'refspec' the remote refs/heads/master is always fetched to the local refs/heads/master? If yes, it makes sense now! A little comment in the sources would help a lot.

Show 7 quoted lines
> 
> It might seem silly to ask for these things when you're providing a
> fix along with the report!  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.
I think we can throw that patch away.
> 
> Curious,
> Jonathan
Previous: Junio C HamanoNext: Jonathan Nieder
Message 12 of 20 in “GSOC remote-svn”
  1. 0/4 GSOC remote-svnFlorian Achleitner, Jul 11, 2012
  2. 1/4 vcs-svn: add fast_export_note to create notesFlorian Achleitner, Jul 11, 2012
  3. 2/4 Allow reading svn dumps from files via file:// urls.Florian Achleitner, Jul 11, 2012
  4. 3/4 Create a note for every imported commit containing svn metadata.Florian Achleitner, Jul 11, 2012
  5. 4/4 When debug==1, start fast-import with "--stats" instead of "--quiet".Florian Achleitner, Jul 11, 2012
  6. Dmitry IvankovJul 11, 2012
  7. Junio C HamanoJul 11, 2012
  8. Stephen BashJul 11, 2012
  9. Fix overwritten remote ref on with fast-import.Florian Achleitner, Jul 15, 2012
  10. Jonathan NiederJul 16, 2012
  11. Junio C HamanoJul 16, 2012
  12. Florian AchleitnerJul 16, 2012
  13. Jonathan NiederJul 17, 2012
  14. Florian AchleitnerJul 17, 2012
  15. Jonathan NiederJul 17, 2012
  16. Florian AchleitnerJul 17, 2012
  17. Jonathan NiederJul 17, 2012
  18. Florian AchleitnerJul 17, 2012
  19. Add explanatory comment for transport-helpers refs mapping.Florian Achleitner, Jul 17, 2012
  20. Jonathan NiederJul 17, 2012

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.