Re: "commit"s without "from" in fast-import

["Shawn O. Pearce" <spearce@spearce.org>]

Eyvind Bernhardsen <eyvind-git@orakel.ntnu.no> wrote:
> On 18. mars. 2008, at 04.43, Shawn O. Pearce wrote:
> [...]
> >Maybe we should make this more formalized in the documentation as
> >allowable, so if it does break for an importer the importer author
> >has to fix git-fast-import, bzr-fast-import, *-fast-import instead.
> 
> In the interests of language strictness, I think it should be  
> explicitly either allowed or forbidden, and if it is forbidden I think  
> fast-import should barf on it.

Agreed.
 
> From a git perspective it seems ok to allow it, since a commit is  
> only really a tree and a set of parent commits.  "from" adds a parent  
> and initialises the tree, "merge" adds a parent without touching the  
> tree.  But maybe I'm thinking too git-centrically.
> 
> I can try to make a documentation patch that allows it and see if  
> having it "on paper" makes it more or less reasonable.

I'm leaning towards leaving it in the language as allowed, and thus
documenting that this is not only possible, but actively used by
importers as it can be an easy way to setup a subsequent change
with no initial files.

But I have to wonder what the bzr-fast-import folks would say.
I've CC'd in James and Ian, as they have been working on the bzr
side for a little.

James, Ian -- to give you the short backstory we are talking about
creating a new branch _without_ a "from", but instead using a single
"merge" to specify the sole ancestor revision of a new commit to
be placed on the new branch.  This allows the frontend to supply
all files for the tree as none were inherited from the sole ancestor.

The other (more obvious?) approach to accomplish the same result
is to use "from" followed by a "filedeleteall" to clear the files,
then supply the new files.  Both approaches have the exact same
result in git-fast-import.

-- 
Shawn.