Comment 6 for bug 931994

On 02/14/2012 05:26 PM, jugglefish wrote:
> Thx for repoening. It's always better to have a clutterd refs (which I
> could simply cleanup) until there is an "optimal" solution. I enjoy this
> really easy bzr-revid<=>git-SHA mapping "API".
The refs are used for bzr revisions which are completely roundtripped
into git. "git fetch bzr::..." at the moment discards some bzr metadata
that can't be represented in git.

This is the reason "git fetch" no longer creates .git/refs/bzr entries.
When proper roundtripping support is added, it'll start creating them again.
>
> However the content of any .git/ref file can really be only one single
> SHA1 I'd assume. :-<
Right, but it can point at a git tree object - which should be
sufficient; that tree object can just have bzr revids as entries.
> git notes simply keeps the last SHA1 in the refs/notes/NAMESPACE
> (NAMESPACE defaults to commit) and whenever they update it they track
> the former SHA1 via the parent object, so you can traverse the "history"
> via git log.
>
> git notes --ref=bzrrevid -m 'REVIDFROMBAZAAR' would be a way to do it in
> "plain git"
Wouldn't that annotate a specific git revision, rather than add
something that can be searched by bzr revision id?

Cheers,

Jelmer