Eyvind Bernhardsen <eyvind-git@xxxxxxxxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
