Hi Elijah, thanks for explaining the motivation behind the current solution!
I still believe the situation could be improved without breaking compatibility: * in the documentation the paragraph about "Omitting the from command" should change "existing branches" into something like "existing branches within the cache of the current fast-import stream". The current phrasing is simply wrong. * the documentation of the "from branch^0" variant currently looks like a solution for a rare situation that is easily overlooked. Maybe it could be integrated with the paragraph about "Omitting" since it is very closely related. * in update_branch the warning could hint at the possible solution (explicitly supply a from parent_branch^0 argument) * I'm still not sure why it would hurt to change fatal error in parse_from about creating a branch from itself to simply fall back to the ^0 behavior? A much better solution in my view would be to aim for real statelessness and make the caching of branch pointers completely transparent. For all I can see, fast-import nearly follows this paradigm but violates it in this subtle point. Once way to achieve this would be to offer an explicit way to state that a commit should have no parent and deprecate the variant without "from" argument, issuing a warning. The great practical advantage of that would be that interrupting and continuing the fast-import stream would be guaranteed to deliver the same result. Far more important is the conceptual simplicity: A developer could completely forget about caching when it comes to correctness and only think of it when it comes to performance optimization. Anyway: these are all improvements for future developers. Personally, I am satisfied with everything I have. Greetings, Norbert -----Original Message----- From: Elijah Newren <new...@gmail.com> Sent: Monday, March 11, 2019 8:46 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 9:38 AM Norbert Nemec <norbert.ne...@microsoft.com> wrote: > > 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 If this "awkward workaround", as you put it, were removed it would make it impossible to create a commit with no parent without using a different branch name. I really like being able to export, modify, and re-import history, using something of the form: git fast-export --all | <edit the stream somehow> | git fast-import --force which would no longer work if fast-import automatically assumed a parent for every from-less commit in the input based on the reference name. Personally, I'm more on the side of not understanding why "from" isn't required whenever you want your commit to have a parent; users can specify either a sha or a mark-id easily enough; I don't see what it saves to allow omitting it, and it inevitably leads to other confusion like yours. But I'm well over a decade too late to advocate for that. Hope that helps, Elijah
