Re: [PATCH] Add 'git fast-export', the sister of 'git fast-import'

[Johannes Schindelin <Johannes.Schindelin@gmx.de>]

Hi,

On Mon, 26 Nov 2007, Shawn O. Pearce wrote:

> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > This program dumps (parts of) a git repository in the format that
> > fast-import understands.
> ...
> > +-------------------------------------------------------------------
> > +$ git fast-export --all | (cd /empty/repository && git fast-import)
> > +-------------------------------------------------------------------
> > +
> > +This will export the whole repository and import it into the existing
> > +empty repository.  Except for reencoding commits that are not in
> > +UTF-8, it would be a one-to-one mirror.
> 
> WTF?
> 
> Why are you reencoding the commits on output in fast-export? Why aren't 
> you dumping them raw to the stream?  fast-import takes them raw.  Oh, it 
> doesn't have a way to set the encoding header. DOH.

Not only that... FTFD:

~ Commit messages are free-form and are not interpreted by Git.  
~ Currently they must be encoded in UTF-8, as fast-import does not permit 
~ other encodings to be specified.

So the documentation stated very much that I _had_ to do it that way.

> I think this should be prefixed by fast-import patch to teach it 
> something like "encoding N" as a subcommand of commit, so that you can 
> feed data in a non UTF-8 encoding and get it to include the proper 
> encoding header in the commit object it creates.  That way a pipeline 
> like the above really does create a duplicate repository, with the same 
> commit SHA-1s, even if the commits weren't in UTF-8.

IMHO it's not worth that hassle.  People who want to use fast-import 
usually want something fast which works, and not bother with specifying 
encodings.

Further, if you go down that road, some people will want to be able to say 
"that commit is KOI-8, this one is UTF-8, and the third is encoded in 
pre-Christian Tibetan runes."

But maybe I am wrong.

Ciao,
Dscho