mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Norbert Nemec <>
To: "" <>
Subject: RE: fast-import on existing branches
Date: Fri, 8 Mar 2019 17:33:40 +0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

Thanks, Elijah, I had indeed missed that block about the ^0 handling.

I still don't get why this awkward workaround is required. Why isn't that lookup done by default? Performance can't be the reason, since the same lookup is done lateron anyway, just as correctness check. The way I read the documentation, providing no "from" should continue committing to a branch in any case. I would never have seen the continuation of an incremental import a "special case". There is a number of tools around that sync a git repo from some other source and would regularly need to continue an existing branch.


-----Original Message-----
From: Elijah Newren <> 
Sent: Friday, March 8, 2019 4:41 PM
To: Norbert Nemec <>
Subject: Re: fast-import on existing branches

Hi Norbert,

On Fri, Mar 8, 2019 at 2:51 AM Norbert Nemec <> wrote:
> Hi there,
> I've struggled for quite some time to sort out documented, intended and actual behavior of git fast-import. Unless I'm completely mistaken, it seems to be a straightforward bug, but if that is the case, I am really surprised why nobody else has stumbled over it before:
> I managed to use fast-import for a chain of commits onto a new branch into an empty repository.
> I managed to use fast-import to create a new branch starting from an existing parent using the 'from' command as documented.
> What I failed to do is to add commits on top of an existing branch in a new fast-import stream. As it seems, the variant of using 'commit' without 'from' only works on branches that were created within the same fast-import stream!
> The different approaches I tried (each with new fast-import stream on 
> existing repo with existing branch)
> * 'commit' without 'from'
> -> Error: "Not updating <branch> (new tip <hash> does not contain 
> -> <hash>)
> And indeed looking into the repo afterwards, a new commit exists without any parent.
> * 'commit' with 'from' both naming the same branch
> -> Error: "Can't create a branch from itself"
> The only workarounds that I could find are to either explicitly looking up the top commit on the target branch and hand that to fast-import or create a temporary branch with a different name.

I would have just used "from <sha1>" where <sha1> is something I look up from the current branch I want to update.  But, re-looking at the docs, it appears git-fast-import.txt covers this already with a possibly easier syntax:

The special case of restarting an incremental import from the current branch value should be written as:
        from refs/heads/branch^0
The `^0` suffix is necessary as fast-import does not permit a branch to start from itself, and the branch is created in memory before the `from` command is even read from the input.  Adding `^0` will force fast-import to resolve the commit through Git's revision parsing library, rather than its internal branch table, thereby loading in the existing value of the branch.

Perhaps try that?

> Looking through the code of fast-import.c, I can indeed lookup_branch and new_branch only deal with internal data structures and the only point were read_ref is called to actually read existing branches from the repo is in update_branch to check whether the parent was set correctly. What is missing is a call to read_ref in either lookup_branch or new_branch (probably both have to be reworked in some way to handle this cleanly). From all I can see a fix should be fairly straightforward to implement, but I am really not sure whether I have the full picture on this.
> (I found all of this struggling with which appears to 
> contains a complex and not fully correct mechanism to determine the 
> 'initalParent' that appears to implement just such a workaround.)
> I would be grateful for any input on this issue! Greetings, Norbert

Hope that helps,

  reply	other threads:[~2019-03-08 17:33 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-08 10:50 fast-import on existing branches Norbert Nemec
2019-03-08 15:40 ` Elijah Newren
2019-03-08 17:33   ` Norbert Nemec [this message]
2019-03-11 19:46     ` Elijah Newren
2019-03-12  9:18       ` Norbert Nemec

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).