[fastimport/MERGE] Train fixes

[James Westby]

On Mon, 2008-03-10 at 19:35 -0400, Shawn O. Pearce wrote:
> > 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 don't disagree at all.


I didn't think that you did. I applaud your wish to make the format
as VCS-agnostic as possible. That will allow us to build many great
tools and share the work.

When talking about bzr fast-import with Ian at the sprint last week
we both commented how un-git-specific the stream was already, for 
instance reporting renames directly, which is not necessary for git,
but I guess is a space saver if you have the information already.

> 
> See above, I suggest we include the ghost in the stream, but
> make sure its denoted as a ghost and not a reference we expect to
> be valid.
> 
> Lets back up a second.  What the heck is a ghost?  And is it just a
> 20 byte string (aka a SHA-1)?  In other words, is it really something
> that the fast-import stream format would be able to otherwise accept
> as starting point for a branch in a "from" command?
>  

Well, we're not even dealing with SHA-1 names here, as bzr doesn't have
them readily available, so bzr-fast-export just uses mark references
everywhere.

I don't really understand all the implications of a ghost, but I know
it is a reference to an object (commit) that you know exists (usually
because it is one of your parents), but that you don't actually have
stored.

This means that bzr-fast-export currently falls over as it tries to 
export the ghost as a commit, as it thinks it needs to as it is a parent
of something that it is exporting, but it can't access the object to
export it.

I think the best solution may be to introduce a ghost command in the 
stream that is similar to a commit command, and specifically allows
you to assign a mark. Then the commit command can simply reference that,
and the importer handle the ghost command however they like. Do you
have another suggested solution?

> > 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.
> 
> Well, git can store it, and we could extract it back out in
> fast-export but to really make the repository appear "sound"
> we need to record that the ghost does not exist in the grafts.
> Its messy for git, but that isn't your problem.
> 

I'm still interested in the solution though.

Thanks,

James