Hi Norbert,
On Fri, Mar 8, 2019 at 2:51 AM Norbert Nemec
<norbert.ne...@microsoft.com> 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 git-p4.py 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,
Elijah
