use single ref for bzr->git mappings

[jugglefish]

Using git-bzr from inside git via the remote-helper for the bzr:: prefix all bzr revisions will be tracked in .git/refs/bzr. which clutters the refs/ in git.

It would be nice if the mapping between bazaar revisions and git SHA1 could be managed in other ways.

[Jelmer Vernooij (jelmer)]

In what sense is this clutte, is it really a problem to store these things in refs/ ? E.g. git notes use refs/ too and they could have the same number of refs.

[Jelmer Vernooij (jelmer)]

For the moment, git-remote-bzr doesn't actually roundtrip revisions so there is no point in setting these refs. I've fixed it to no longer set them.

They will appear again later when we fix roundtripping support. I would still be interested to hear why putting this data in refs/ is a problem.

[jugglefish (pniederlag)]

afaik notes adds *one* file per namespace in .git/refs/notes/.

gitk picks up any refs/ that are part of the history and shows them along the commit. This gets pretty much crowded given the extremly long ref names that are stored in refs/bzr.

Also the output of 'git show-ref' is pretty much stuffed, while showing only one entry for each notes namespace

In gerenal I'd say refs/ is not really well suited for something that is by definition one2one per commit.

Havin one ref-file with the mapping inside would be more nice in these terms.

[Jelmer Vernooij (jelmer)]

On 02/14/2012 03:29 PM, jugglefish wrote:
> afaik notes adds *one* file per namespace in .git/refs/notes/.
>
> gitk picks up any refs/ that are part of the history and shows them
> along the commit. This gets pretty much crowded given the extremly long
> ref names that are stored in refs/bzr.
>
> Also the output of 'git show-ref' is pretty much stuffed, while showing
> only one entry for each notes namespace
>
> In gerenal I'd say refs/ is not really well suited for something that is
> by definition one2one per commit.
>
> Havin one ref-file with the mapping inside would be more nice in these
> terms.
Ah, hmm. I guess we could indeed do one ref file too. I'll reopen this bug.

Cheers,

Jelmer

[jugglefish (pniederlag)]

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".

However the content of any .git/ref file can really be only one single SHA1 I'd assume. :-<

Maybe you could mimik something like git notes, or even just merely use the git notes "implementation" to track the bzr revisions-id?

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"

Thx for your support and listening!

[Jelmer Vernooij (jelmer)]

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

[jugglefish (pniederlag)]

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 *