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

[Sverre Rabbelier]

Heya,

On Mon, Aug 24, 2009 at 21:47, Ian
Clatworthy<ian.clatworthy at canonical.com> wrote:
> 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.

Why? The commit message is free form, and under control of the export
tool. In git there isn't much difference between storing the meta-data
in the commit message and some special field, it just moves up/down a
few lines in the commit object.

Compare current hg-git exported git object:
```
tree fe03f9b382ef2f9b6ea3fc1424e0d211929d66d9
parent a27787550229616ba0a0fdf9e5dd18b708e1e382
author Lennard de Rijk <ljvderijk at gmail.com> 1248955343 +0200
committer Lennard de Rijk <ljvderijk at gmail.com> 1248955343 +0200

Renamed main CSS and map JS file due to recent changes.

--HG--
rename : app/soc/content/css/soc-090708.css =>
app/soc/content/css/soc-090730.css
rename : app/soc/content/js/map-090420.js => app/soc/content/js/map-090730.js
```

versus what you propose:
```
tree fe03f9b382ef2f9b6ea3fc1424e0d211929d66d9
parent a27787550229616ba0a0fdf9e5dd18b708e1e382
rename app/soc/content/css/soc-090708.css => app/soc/content/css/soc-090730.css
rename app/soc/content/js/map-090420.js => app/soc/content/js/map-090730.js
author Lennard de Rijk <ljvderijk at gmail.com> 1248955343 +0200
committer Lennard de Rijk <ljvderijk at gmail.com> 1248955343 +0200

Renamed main CSS and map JS file due to recent changes.
```

Honestly, what is the difference? Except that with the former you have
to change the git object format, and the tools to deal with your
special fields, whereas with the latter everything Just Works (see
hg-git and git-svn as 'proof'). Another advantage of the
commit-message based approach is that the user can edit changes
easily; rewriting of bzr history using git filter-branch's
commit-message-filter is suddenly possible.

> 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.

Hg has a similar system (using 'extra' fields), and hg-git does
perfect round-trips between hg and git by storing this information in
the commit message. Please rethink your decision to want to do things
the bzr way in git; using commit messages to store the things you need
would require no changes to git or the fast-import format, and I think
it'd work just as well.

Now, wrt to the 'feature' extension, that would definitely be useful.
Especially if we teach fast-import to fail with a decent message,
instead of 'command option not recognised', saying 'this version of
fast-import does not support the option feature, please upgrade to a
more recent version' or something like that would be nice.

-- 
Cheers,

Sverre Rabbelier