[fastimport/MERGE] Train fixes

[James Westby]

On Mon, 2008-03-10 at 18:50 -0400, Shawn O. Pearce wrote:
> Yea.  Technically git-fast-import's code would permit me to let
> the stream request a ghost parent, and actually produce data files
> with a successful exit code, but the repository would fail git-fsck.
> Tools like git-checkout (to fetch files) and git-log would seem to
> work just fine, until we tried to hit the ghost, and then all hell
> would break loose.
> 
> If you really do have such a parent commit that you know the SHA-1
> of but will never be able to obtain the proper content for again,
> but you need that parent in your ancestry in order to maintain other
> child SHA-1s then yea, you don't really have any choice other than
> to create the ghost reference.
> 
> In git a "graft" can be used to tell the runtime tools like git-log
> and git-fsck that the parent is gone and shall never be, but grafts
> do not automatically travel when you use git-clone to copy someone
> else's tree to your own system.  Publishing a history with a graft
> is a pretty horrible thing to do.
> 
> Fortunately nobody has thus far come to us and said "soooo, my
> history is bust but I need to record that parent marker anyway".
> Sounds like a bzr<->git roundtrip may actually need to support that?
> 
> I'm open to some sort of notation in the stream format that a
> ghost is being used and thus a missing object is to be expected.
> With such a notation git-fast-import can automatically dump the
> ghost entry into the graft file, and spit out a big fat warning
> after the import is done.
> 
> I'd rather not blanket allow missing references during an import.
> That just sounds like trouble for a buggy frontend.
> 

Hi Shawn,

Thanks for the extra information.

My first thoughts are that we should strive to have the stream
format contain information that allows you to describe the history
that you are converting from, and then allow the importers to handle
this as they see fit.

I realise representing the ghost is going to be troublesome for 
git-fast-import, and you will know better than us how that should
be done. However if we are unable to represent it at all in
the stream format then there is no chance of a round-trip of bzr->bzr.
Obviously this round trip is currently of little significance, but
if we were to implement something like git-filter-branch on top
of this then it would be more important.

Thanks,

James