Better interoperability with Bitkeeper for fast-import/-export

Better interoperability with Bitkeeper for fast-import/-export

[Philip Prindeville]

Hi.

I tried to import into git a repo that I was working on (because it just seemed easier), but when I tried to export the repo back out after making my changes I found it choking on a few things.

It was explained to me (by the Bitkeeper folks) that git meta-data doesn’t accurately track file moves…  If a file disappears from one place and reappears in another with the same contents, that’s assumed to be a move.

Given that “git mv” is an explicit action, I’m not sure why that wouldn’t be explicitly tracked.

But I’ve not looked too closely under the covers about how git represents stuff, so maybe there’s more to it than I’m assuming.

During an export using “-M” and “-C”, Bitkeeper complained:

fast-import: line 'R ports/winnt/libntp/nt_clockstuff.c ports/winnt/ntpd/nt_clockstuff.c' not supported

so I tried removing those two options, and it got further, this time stalling on:

fast-import: Unknown command: tag ntp-stable

I like git, mostly because I’ve used it a lot more… and I like the GitHub service.  I use Bitkeeper because a few projects I work on are already set up to use it and it’s not my call whether it’s worth the effort to make the conversion or live with it.

So… this is an appeal for both to play better together.

What’s involved in getting git to track file/directory moves/renames so that it’s palatable to Bitkeeper?

Thanks,

-Philip

Re: Better interoperability with Bitkeeper for fast-import/-export

[Elijah Newren]

Hi Philip,

On Tue, Jul 3, 2018 at 1:40 PM, Philip Prindeville
<philipp_subx@redfish-solutions.com> wrote:
> Hi.
>
> I tried to import into git a repo that I was working on (because it just seemed easier), but when I tried to export the repo back out after making my changes I found it choking on a few things.
>
> It was explained to me (by the Bitkeeper folks) that git meta-data doesn’t accurately track file moves…  If a file disappears from one place and reappears in another with the same contents, that’s assumed to be a move.
>
> Given that “git mv” is an explicit action, I’m not sure why that wouldn’t be explicitly tracked.

Not a full explanation, but see
https://git-scm.com/book/en/v2/Git-Internals-Moving-Files

> But I’ve not looked too closely under the covers about how git represents stuff, so maybe there’s more to it than I’m assuming.
>
> During an export using “-M” and “-C”, Bitkeeper complained:

Why would you add -C?  Does bitkeeper also track copies?

> fast-import: line 'R ports/winnt/libntp/nt_clockstuff.c ports/winnt/ntpd/nt_clockstuff.c' not supported
>
> so I tried removing those two options, and it got further, this time stalling on:
>
> fast-import: Unknown command: tag ntp-stable

If the fast-import command you are using can't read tags, then perhaps
you should report that to the authors of the fast-import tool you are
using and/or only feed branches to your fast-export command.

> I like git, mostly because I’ve used it a lot more… and I like the GitHub service.  I use Bitkeeper because a few projects I work on are already set up to use it and it’s not my call whether it’s worth the effort to make the conversion or live with it.
>
> So… this is an appeal for both to play better together.
>
> What’s involved in getting git to track file/directory moves/renames so that it’s palatable to Bitkeeper?

Not tracking file/directory moves/renames wasn't an oversight but a
fundamental design decision; see e.g.
https://public-inbox.org/git/Pine.LNX.4.64.0510211826350.10477@g5.osdl.org/.

However, supposing that we did track renames, how would we tell
bitkeeper?  Well, we'd print out a line that looks like this in the
fast-export:

'R ports/winnt/libntp/nt_clockstuff.c ports/winnt/ntpd/nt_clockstuff.c'

which is precisely the line that bitkeeper's fast-import was choking
on.  So, it sounds like they don't support importing rename
information (or at least the version of fast-import you're using
doesn't).  I think this is where the bug is; you'll probably want to
report it to whoever maintains the fast-import command that is choking
on this line.

Once that's fixed, you can export from git with the -M flag, and from
that output, there'll be no way to tell whether the original
repository tracked renames or detected them after the fact.


Hope that helps,
Elijah

Re: Better interoperability with Bitkeeper for fast-import/-export

[Philip Prindeville]

> On Jul 3, 2018, at 3:27 PM, Elijah Newren <newren@gmail.com> wrote:
> 
> Hi Philip,
> 
> On Tue, Jul 3, 2018 at 1:40 PM, Philip Prindeville
> <philipp_subx@redfish-solutions.com> wrote:
>> Hi.
>> 
>> I tried to import into git a repo that I was working on (because it just seemed easier), but when I tried to export the repo back out after making my changes I found it choking on a few things.
>> 
>> It was explained to me (by the Bitkeeper folks) that git meta-data doesn’t accurately track file moves…  If a file disappears from one place and reappears in another with the same contents, that’s assumed to be a move.
>> 
>> Given that “git mv” is an explicit action, I’m not sure why that wouldn’t be explicitly tracked.
> 
> Not a full explanation, but see
> https://git-scm.com/book/en/v2/Git-Internals-Moving-Files


Why not add the logic to track moves/renames?  That link explains what it does, but not why it does it.


> 
>> But I’ve not looked too closely under the covers about how git represents stuff, so maybe there’s more to it than I’m assuming.
>> 
>> During an export using “-M” and “-C”, Bitkeeper complained:
> 
> Why would you add -C?  Does bitkeeper also track copies?


I figure that I’d furnish the maximum amount of meta data, and bitkeeper would use what it could and ignore the rest.


> 
>> fast-import: line 'R ports/winnt/libntp/nt_clockstuff.c ports/winnt/ntpd/nt_clockstuff.c' not supported
>> 
>> so I tried removing those two options, and it got further, this time stalling on:
>> 
>> fast-import: Unknown command: tag ntp-stable
> 
> If the fast-import command you are using can't read tags, then perhaps
> you should report that to the authors of the fast-import tool you are
> using and/or only feed branches to your fast-export command.


Well, I’ll just do branches for now…


> 
>> I like git, mostly because I’ve used it a lot more… and I like the GitHub service.  I use Bitkeeper because a few projects I work on are already set up to use it and it’s not my call whether it’s worth the effort to make the conversion or live with it.
>> 
>> So… this is an appeal for both to play better together.
>> 
>> What’s involved in getting git to track file/directory moves/renames so that it’s palatable to Bitkeeper?
> 
> Not tracking file/directory moves/renames wasn't an oversight but a
> fundamental design decision; see e.g.
> https://public-inbox.org/git/Pine.LNX.4.64.0510211826350.10477@g5.osdl.org/.


"I'm convinced that git handles renames better than any other SCM ever. 
Exactly because we figure it out when it matters.”

I disagree.  When the move happens, there’s a commit message that goes along with that.  There’s an insight into why the move is happening.

That’s something that software can’t do for you.


> 
> However, supposing that we did track renames, how would we tell
> bitkeeper?  Well, we'd print out a line that looks like this in the
> fast-export:
> 
> 'R ports/winnt/libntp/nt_clockstuff.c ports/winnt/ntpd/nt_clockstuff.c'
> 
> which is precisely the line that bitkeeper's fast-import was choking
> on.  So, it sounds like they don't support importing rename
> information (or at least the version of fast-import you're using
> doesn't).  I think this is where the bug is; you'll probably want to
> report it to whoever maintains the fast-import command that is choking
> on this line.


Already done:

https://users.bitkeeper.org/t/using-fast-import-from-git-into-bk/907

Not sure I understand the response:

"The rename info that git gives us is a guess, that’s why there is that 0-100% next to it, that’s showing you how much of the two versions of the file were identical. So that info is unreliable, it’s just a guess."

Okay, what’s stopping them from doing their best with the information provided, even if it is a guess?

By the way, what happens when you interactively rebase a bunch of commits, change their order, and in the middle of an “edit”, do a “git mv … …” followed by a “git commit --amend && git rebase --continue”?

-Philip



> 
> Once that's fixed, you can export from git with the -M flag, and from
> that output, there'll be no way to tell whether the original
> repository tracked renames or detected them after the fact.
> 
> 
> Hope that helps,
> Elijah