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.
Greetings,
Norbert
-----Original Message-----
From: Elijah Newren <new...@gmail.com>
Sent: Friday, March 8, 2019 4:41 PM
To: Norbert Nemec <norbert.ne...@microsoft.com>
Cc: git@vger.kernel.org
Subject: Re: fast-import on existing branches
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
