Any plans/needs to extend the fast-import format?

[Ian Clatworthy]

Shawn O. Pearce wrote:

> I think there is, rename information for starters might be hard to
> encode, though fast-import does have a rename command, but given
> that the language says the rename is applied immediately, this can
> make cases like "rename A->B, rename B->A" really nasty to encode.

Right. The current git-fast-import semantics of progressive command
application makes it 10x harder (at least!) to write something like bzr
fast-export reliably. Bazaar's API gives us "here's the set of changes
from revision X to revision Y". But ordering those changes into
fast-import commands so that renames don't break things is *really* ugly.

>> * An optional properties section in a commit. Each property would
>>   have a name and value, both utf-8 encoded.
> 
> This I find could be dangerous, what are additional properties,
> and what should they look like when loaded in another VCS?  Git has
> tried to resist adding hidden fields to the commit headers, because
> then they aren't as easy to access for a human.

By definition, revision properties are tool-specific. We could capture
that semantically by prefixing the names with the tool, a bit like xml
namespaces. The current alternative is to do the sort of thing that
Monotone's fast-export tool does: append metadata as name:value lines
onto the end of the commit message. That's pretty gross IMO.

FWIW, Bazaar uses revision properties for tracking related-bug metadata.
among other things. bzr-svn, bzr-git, etc. uses revision properties as
well to aid interacting with other VCS tools.

> Sverre recently added patches to git fast-import to declare options
> at the top of the stream, but these are implementation specific
> options unique to git-fast-import:
> 
>   http://article.gmane.org/gmane.comp.version-control.git/125853

So what do you expect other importers to do with these? Perhaps you
should include a tool field in the option command so this becomes more
widely useful and importers know which ones are for them vs other
importers? There's no way all importers will have the same option names,
let alone semantics.

> Instead we might get better mileage by declaring
> features that the stream uses, and then parses which do not know
> that feature abort:
> 
>   feature multiple-authors
>   feature ghost-revisions
>   feature ...

That sounds a useful way forward. Let's start with ...

feature file-commands-apply-to-committed-state

:-)

Ian C.