On Jan 13, 2010, at 12:14 PM, Stephen J. Turnbull wrote:
> The main thing that worries me in any such process is that bzr can
> take a relatively long time to do a push.

Indeed, anything more than a few seconds would seem unusual if not unacceptable to the typical busy Git user.

The alternative would be to do it asynchronously and undo the push if it fails (a "git reset" is trivial).  The user
could then only be notified by e-mail.

Perhaps the first option can be tried to see what the delay is.


>> What happens when the changes that originated on the git side are
>> re-imported to the git repository?  Would we get double revisions?
> 
> I think not.  This is the point of the fastimport format.  Although
> it's possible that some metadata present in git objects is not
> supplied by bzr.  In that case you would.
> 
>> Also, would importing sidestep the new revisions on the git side
>> because the "marks" file points to an earlier previous revision?
> 
> I don't understand precisely what you mean by "importing", "sidestep",
> or "new revisions on the git side".


OK, if the fastimport mechanism aligns revisions in both directions then that's not going to be a problem:

from the fast-export man page:

" Any commits that have already been marked will not be exported again. If the backend uses a similar --import-marks
           file, this allows for incremental bidirectional exporting of the repository by keeping the marks the same across runs."

As a next step, could somebody with access to Bzr and the "marks" used for the `cz' mirror try out the export and the commit hook?