please check BK&MTN to GIT conversion dry-run repository

please check BK&MTN to GIT conversion dry-run repository

[Jan Luebbe]

Hi!

I've produced a git repository with the combined history from bitkeeper
and monotone. Please check if this looks sane. I will redo this tomorrow
when MTN is readonly.

Jan

Re: please check BK&MTN to GIT conversion dry-run repository

[Jan Luebbe]

And here it is: http://git.sicherheitsschwankung.de/?p=jan/oetest.git

Re: please check BK&MTN to GIT conversion dry-run repository

[Koen Kooi]

On 14-10-2008 15:17, Jan Luebbe wrote:
> And here it is: http://git.sicherheitsschwankung.de/?p=jan/oetest.git

Looks ok to me: 
http://git.sicherheitsschwankung.de/?p=jan/oetest.git;a=history;f=conf/local.conf.sample;h=36407b015deecd76b60a9abf7246ac82fb266c4c;hb=HEAD

regards,

Koen

Re: please check BK&MTN to GIT conversion dry-run repository

[Richard Purdie]

On Tue, 2008-10-14 at 15:17 +0200, Jan Luebbe wrote:
> And here it is: http://git.sicherheitsschwankung.de/?p=jan/oetest.git

The BKCVS conversion still has the problems I wanted to get resolved
before we did this for example:

http://git.sicherheitsschwankung.de/?p=jan/oetest.git;a=commit;h=66944efa040bdf36062522c7c33413fc1e039d83

Where two commits have been rolled into one.

The original plan was to add the BKCVS later as a git tree graft rather
than hardcoding it into the history now in a broken form. Is it too late
to do this now?

Cheers,

Richard

Re: please check BK&MTN to GIT conversion dry-run repository

[Jan Lübbe]

On Wed, 2008-10-15 at 10:27 +0100, Richard Purdie wrote:
> The original plan was to add the BKCVS later as a git tree graft rather
> than hardcoding it into the history now in a broken form. Is it too late
> to do this now?

It is not possible to change history in git without changing the commit
hashes. (so a "graft" is impossible without rebasing)

> The BKCVS conversion still has the problems I wanted to get resolved
> before we did this for example:
> 
> http://git.sicherheitsschwankung.de/?p=jan/oetest.git;a=commit;h=66944efa040bdf36062522c7c33413fc1e039d83
> 
> Where two commits have been rolled into one.

I tried to figure out how to solve this, but ran out of time. Adding the
(somewhat mangled) bk history now doesn't have any disadvantages and
still allows to find ot where the files come from. If someone figures
out how to do a better conversion, we can still rebase, it that is
desired.

-- 
Jan Lübbe <jluebbe@lasnet.de>            http://sicherheitsschwankung.de
 gpg-key      1024D/D8480F2E 2002-03-20
 fingerprint  1B25 F91F 9E7B 5D4F 1282  02D6 8A83 8BE4 D848 0F2E

Re: please check BK&MTN to GIT conversion dry-run repository

[Richard Purdie]

On Wed, 2008-10-15 at 15:42 +0200, Jan Lübbe wrote:
> On Wed, 2008-10-15 at 10:27 +0100, Richard Purdie wrote:
> > The original plan was to add the BKCVS later as a git tree graft rather
> > than hardcoding it into the history now in a broken form. Is it too late
> > to do this now?
> 
> It is not possible to change history in git without changing the commit
> hashes. (so a "graft" is impossible without rebasing)

It is possible, you just do something like:

echo "$commit-id $graft-id" >> .git/info/grafts

which then adds some history to the start of the tree. Look up git tree
grafts and you'll find further information about this feature.

> > The BKCVS conversion still has the problems I wanted to get resolved
> > before we did this for example:
> > 
> > http://git.sicherheitsschwankung.de/?p=jan/oetest.git;a=commit;h=66944efa040bdf36062522c7c33413fc1e039d83
> > 
> > Where two commits have been rolled into one.
> 
> I tried to figure out how to solve this, but ran out of time. Adding the
> (somewhat mangled) bk history now doesn't have any disadvantages 

It does since we can't now add a correct version at a later date using a
tree graft.

> and
> still allows to find ot where the files come from. If someone figures
> out how to do a better conversion, we can still rebase, it that is
> desired.

No, we don't want to ever rebase. I'd much prefer we had a graft for
that point in time so we can just replace the history as and when we
come up with a better version.

Cheers,

Richard

Re: please check BK&MTN to GIT conversion dry-run repository

[Jan Lübbe]

On Wed, 2008-10-15 at 16:20 +0100, Richard Purdie wrote:
> On Wed, 2008-10-15 at 15:42 +0200, Jan Lübbe wrote:
> > On Wed, 2008-10-15 at 10:27 +0100, Richard Purdie wrote:
> > > The original plan was to add the BKCVS later as a git tree graft rather
> > > than hardcoding it into the history now in a broken form. Is it too late
> > > to do this now?
> > 
> > It is not possible to change history in git without changing the commit
> > hashes. (so a "graft" is impossible without rebasing)
> 
> It is possible, you just do something like:
> 
> echo "$commit-id $graft-id" >> .git/info/grafts
> 
> which then adds some history to the start of the tree. Look up git tree
> grafts and you'll find further information about this feature.

Oh, this is new to me :/ When i talked about importing BK history with
Holger he didn't seem to have any doubts.

> > > The BKCVS conversion still has the problems I wanted to get resolved
> > > before we did this for example:
> > > 
> > > http://git.sicherheitsschwankung.de/?p=jan/oetest.git;a=commit;h=66944efa040bdf36062522c7c33413fc1e039d83
> > > 
> > > Where two commits have been rolled into one.
> > 
> > I tried to figure out how to solve this, but ran out of time. Adding the
> > (somewhat mangled) bk history now doesn't have any disadvantages 
> 
> It does since we can't now add a correct version at a later date using a
> tree graft.

From what i just read about grafts, it will replace the parent
information for the specified commit. So we could still replace the
current BK import with the correct one.

Grafts are local only though.

> > and
> > still allows to find ot where the files come from. If someone figures
> > out how to do a better conversion, we can still rebase, it that is
> > desired.
> 
> No, we don't want to ever rebase. I'd much prefer we had a graft for
> that point in time so we can just replace the history as and when we
> come up with a better version.

We could import BK again (correctly) into a separate branch and then
document how to graft it to instead of the current stuff.

-- 
Jan Lübbe <jluebbe@lasnet.de>            http://sicherheitsschwankung.de
 gpg-key      1024D/D8480F2E 2002-03-20
 fingerprint  1B25 F91F 9E7B 5D4F 1282  02D6 8A83 8BE4 D848 0F2E

Re: please check BK&MTN to GIT conversion dry-run repository

[Richard Purdie]

On Thu, 2008-10-16 at 10:31 +0200, Jan Lübbe wrote:
> Oh, this is new to me :/ When i talked about importing BK history with
> Holger he didn't seem to have any doubts.

I thought I'd made the idea of using a graft for this clear but
obviously not :(.

> >From what i just read about grafts, it will replace the parent
> information for the specified commit. So we could still replace the
> current BK import with the correct one.
> 
> Grafts are local only though.

They won't get passed through a git clone? I guess that isn't a problem
as long as we do this on the master repository and document it.

> > > and
> > > still allows to find ot where the files come from. If someone figures
> > > out how to do a better conversion, we can still rebase, it that is
> > > desired.
> > 
> > No, we don't want to ever rebase. I'd much prefer we had a graft for
> > that point in time so we can just replace the history as and when we
> > come up with a better version.
> 
> We could import BK again (correctly) into a separate branch and then
> document how to graft it to instead of the current stuff.

It is now too late to rebuild the tree without the BKCVS information?
I'd prefer not to have the wrong information hanging around if at all
possible.

Cheers,

Richard

Re: please check BK&MTN to GIT conversion dry-run repository

[Koen Kooi]

On 16-10-2008 11:39, Richard Purdie wrote:
> On Thu, 2008-10-16 at 10:31 +0200, Jan Lübbe wrote:
>> Oh, this is new to me :/ When i talked about importing BK history with
>> Holger he didn't seem to have any doubts.
>
> I thought I'd made the idea of using a graft for this clear but
> obviously not :(.
>
>> > From what i just read about grafts, it will replace the parent
>> information for the specified commit. So we could still replace the
>> current BK import with the correct one.
>>
>> Grafts are local only though.
>
> They won't get passed through a git clone? I guess that isn't a problem
> as long as we do this on the master repository and document it.
>
>>>> and
>>>> still allows to find ot where the files come from. If someone figures
>>>> out how to do a better conversion, we can still rebase, it that is
>>>> desired.
>>> No, we don't want to ever rebase. I'd much prefer we had a graft for
>>> that point in time so we can just replace the history as and when we
>>> come up with a better version.
>> We could import BK again (correctly) into a separate branch and then
>> document how to graft it to instead of the current stuff.
>
> It is now too late to rebuild the tree without the BKCVS information?
> I'd prefer not to have the wrong information hanging around if at all
> possible.

Let's just leave it as it is. It currently gives up a much better 
history than we had in mtn and peope will stop claiming I'm responsible 
for all their bugs when their bisect turns up the bk import.
The downside is that I can't claim that I wrote OE in one day anymore ;)

regards,

Koen

Re: please check BK&MTN to GIT conversion dry-run repository

[Michael 'Mickey' Lauer]

To be honest, I don't care a lot about the pre-mtn commits being part of the 
history.
I'd be fine with them living in a seperate repository for the rare cases you 
really want to dig into the history.

-- 
:M: