Comment 7 for bug 931994

Hello Jelmer,

On 14.02.2012 17:41, Jelmer Vernooij wrote:
[...]
>> 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.

Sounds very reasonable and I think this is what I meant.

>> 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?

Yes and No.

git log -S'LOOKUPVALUE' --format="%H" refs/notes/bzr

would be needed to query the SHA1 for a bzr-revid "LOOKUPVALUE" inside
"bzr" namespace. On *huge* history performance might be an issue.

git log -n1 --notes=bzr --format="%N" SHA1

would do the lookup in opposite way.

Greets and hth,
Peter
--
Peter Niederlag * Ehlentruper Weg 70 * 33604 Bielefeld *
Fon (mobil): 0172 / 516 48 55 *
http://www.niekom.de * TYPO3 und EDV Dienstleistungen *