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

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> > On Sun, 25 Nov 2007, Junio C Hamano wrote:
> >
> >> I am not sure if abort should be the default.
> >
> > I tried to be conservative.
> >
> >> If a straight dump-restore is made without rewriting, the result will 
> >> be identical to the original, right?
> >
> > Yep.
> > ...
> > I agree that for most serious operations sed is not good enough.
> 
> My comment was more about the perception from a new user (not a "new git
> user", but a "new fast-export and fast-import user").
> 
> When you see a command pair foo-export and foo-import, and it is
> advertised that you can pipe them together, a new user would first try a
> straight dump-restore, and would see the warning even though he did not
> do any editing on the stream.
> 
> 	Huh?  Why does a tag signature become invalid because of merely
> 	exporting and then importing?  What is this warning about?

> You would explain "yeah in your trial run you did not edit but the
> command pair is to allow you editing the contents in between, and if you
> do that, the object names might change.".
> 
> If the default were "straight copy", then the user will not get an
> invalid signature on his trial run, but will get an invalid signature
> when he rewrites the object stream.  You would get a message on the list
> like this:
> 
> 	Hello, I tried fast-export piped to fast-import so that I can
> 	rewrite my repository, but I am getting invalid signature on
> 	signed tags.  It does not seem to happen if I do not edit but
> 	just use the fast-export output without modification.  What am I
> 	doing wrong?
> 
> And that is the time the explanation first becomes useful.  IOW, you are
> warning at the wrong place.  "It may or may not corrupt the signature, I
> do not know.  Because it depends on what you are going to do with my
> output, I cannot know.  I am warning you anyway to cover my backside".
> 
> I am wondering if fast-import input syntax can be extended to allow
> checking inconsistencies.  A command to import a tag could take an
> additional object name and tell it to warn if the name of the tagged
> object (the one sent with "from:%d\n" part) is different from that
> object name.  At that point, you know the object was rewritten and the
> signature is invalid, and the choice of warning, stripping or aborting
> becomes a useful thing to have.