bzr-git, the git map, fetching revisions, and being very slow

Jelmer Vernooij jelmer at
Tue Nov 24 12:09:14 GMT 2009

On Tue, 2009-11-24 at 21:43 +1000, Ian Clatworthy wrote: 
> Jelmer Vernooij wrote:
> > In this situation dpush needs the Git sha1's of the objects he's trying
> > to push into the remote git repository. bzr-git creates this map during
> > import time but it only stores it in the target bzr branch during the
> > import, the map is not copied around when branches based on that
> > original import are created (since there is no hook in bzr for this).
> One possibility is to put the map in .bzrmeta/git-map. The data would
> then be carted around, though it could potentially cause end-user
> confusion is they were required to resolve merges.
The shamap isn't deterministic and might be calculated for existing bzr
revisions not created with bzr-git so it can't be in .bzrmeta (which is
versioned IIUC). 

> Another option is to add "Luggage" as a feature to the core, so stuff
> like this can be propagated. See
> It would make me really
> happy to see that spec implemented driven by a need like this.
This seems like the ideal long-term solution for this.

For now, I would like to see a hook that e.g. gets called for each
revision that is fetched between two repositories
(InterRepository.hooks['copy_revisions'] ?). This should be sufficient
for bzr-git to copy the required bits of the sha map.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: This is a digitally signed message part
Url : 

More information about the bazaar mailing list