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

[Shawn O. Pearce]

Ian Clatworthy <ian.clatworthy at canonical.com> wrote:
> Sverre Rabbelier wrote:
> >>> feature file-commands-apply-to-committed-state
> > 
> > I must not have been paying attention; what do file commands apply to currently?
> 
> They apply to the *incremental* state after previous FileCommands. Why's
> that a problem? Consider the following examples ...
...
> Basically, the current processing rules are a nightmare

The fast-import processing rules are the biggest mistake I have
ever made in a software program.

They happened because I don't remember why.  Its either that was
what cvs2svn wanted, or it was simply what seemed to be the most
efficient way to write fast-import for our hacked up cvs2svn at the
time.  And we never realized it was a problem until we implemented
"R" and "C" in the language, as prior to that "R" was unnecessary
since renames in git are after-the-fact.

> Life would be *so* much
> simplier for me, and every other fast-export developer, if the semantics
> were 'vs last commit' as opposed to 'incremental'.

Yes, this is true.  As soon as we have a "feature oh-please-make-it-sane"
supported, everyone will produce with it, because not doing so is nuts.

> The code in bzr
> fast-import would half in complexity as well.

I don't know, do you want to support streams made by tools that don't
know this "feature fix-shawns-fking-mistake"?  If so, you'd need to
keep all of that complexity in case the feature wasn't enabled. :-)

What do we call this feature?  file-commands-apply-to-committed-state
is rather long, and might be descriptive, but I've had to think
about it for a minute to realize what you are trying to say here,
and I wrote git-fast-import.  What would the average stream export
writer think when he's trying to create a tool to convert from
random source X to his chosen VCS?

Its too late here, I don't have any good suggestions on thie name
for this feature.  I've given you two more equally bad ones above.

-- 
Shawn.