{"thread":{"id":"48825","subject":"Better interoperability with Bitkeeper for fast-import/-export","startedAt":"2018-07-03T20:56:23Z","lastAt":"2018-07-03T21:56:12Z","messageCount":3,"participants":["Philip Prindeville","Elijah Newren"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"351653","messageId":"E37C3A33-489B-4FEB-9170-097514B41317@redfish-solutions.com","threadId":"48825","inReplyTo":null,"subject":"Better interoperability with Bitkeeper for fast-import/-export","fromName":"Philip Prindeville","fromEmail":"philipp_subx@redfish-solutions.com","sentAt":"2018-07-03T20:40:50Z","receivedAt":"2018-07-03T20:56:23Z","isPatch":false,"sender":{"key":"philipp_subx@redfish-solutions.com","avatar":null},"body":"Hi.\n\nI 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.\n\nIt 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.\n\nGiven that “git mv” is an explicit action, I’m not sure why that wouldn’t be explicitly tracked.\n\nBut 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.\n\nDuring an export using “-M” and “-C”, Bitkeeper complained:\n\nfast-import: line 'R ports/winnt/libntp/nt_clockstuff.c ports/winnt/ntpd/nt_clockstuff.c' not supported\n\nso I tried removing those two options, and it got further, this time stalling on:\n\nfast-import: Unknown command: tag ntp-stable\n\nI 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.\n\nSo… this is an appeal for both to play better together.\n\nWhat’s involved in getting git to track file/directory moves/renames so that it’s palatable to Bitkeeper?\n\nThanks,\n\n-Philip\n\n"},{"id":"351658","messageId":"CABPp-BFbDx4z2TiqiexyNJzA5UC5D7ZH6Uw-XLXeG3tDCHRKog@mail.gmail.com","threadId":"48825","inReplyTo":"E37C3A33-489B-4FEB-9170-097514B41317@redfish-solutions.com","subject":"Re: Better interoperability with Bitkeeper for fast-import/-export","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2018-07-03T21:27:48Z","receivedAt":"2018-07-03T21:27:53Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"Hi Philip,\n\nOn Tue, Jul 3, 2018 at 1:40 PM, Philip Prindeville\n<philipp_subx@redfish-solutions.com> wrote:\n> Hi.\n>\n> 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.\n>\n> 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.\n>\n> Given that “git mv” is an explicit action, I’m not sure why that wouldn’t be explicitly tracked.\n\nNot a full explanation, but see\nhttps://git-scm.com/book/en/v2/Git-Internals-Moving-Files\n\n> 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.\n>\n> During an export using “-M” and “-C”, Bitkeeper complained:\n\nWhy would you add -C?  Does bitkeeper also track copies?\n\n> fast-import: line 'R ports/winnt/libntp/nt_clockstuff.c ports/winnt/ntpd/nt_clockstuff.c' not supported\n>\n> so I tried removing those two options, and it got further, this time stalling on:\n>\n> fast-import: Unknown command: tag ntp-stable\n\nIf the fast-import command you are using can't read tags, then perhaps\nyou should report that to the authors of the fast-import tool you are\nusing and/or only feed branches to your fast-export command.\n\n> 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.\n>\n> So… this is an appeal for both to play better together.\n>\n> What’s involved in getting git to track file/directory moves/renames so that it’s palatable to Bitkeeper?\n\nNot tracking file/directory moves/renames wasn't an oversight but a\nfundamental design decision; see e.g.\nhttps://public-inbox.org/git/Pine.LNX.4.64.0510211826350.10477@g5.osdl.org/.\n\nHowever, supposing that we did track renames, how would we tell\nbitkeeper?  Well, we'd print out a line that looks like this in the\nfast-export:\n\n'R ports/winnt/libntp/nt_clockstuff.c ports/winnt/ntpd/nt_clockstuff.c'\n\nwhich is precisely the line that bitkeeper's fast-import was choking\non.  So, it sounds like they don't support importing rename\ninformation (or at least the version of fast-import you're using\ndoesn't).  I think this is where the bug is; you'll probably want to\nreport it to whoever maintains the fast-import command that is choking\non this line.\n\nOnce that's fixed, you can export from git with the -M flag, and from\nthat output, there'll be no way to tell whether the original\nrepository tracked renames or detected them after the fact.\n\n\nHope that helps,\nElijah\n"},{"id":"351664","messageId":"D7D581C6-6349-4319-895C-55930431A933@redfish-solutions.com","threadId":"48825","inReplyTo":"CABPp-BFbDx4z2TiqiexyNJzA5UC5D7ZH6Uw-XLXeG3tDCHRKog@mail.gmail.com","subject":"Re: Better interoperability with Bitkeeper for fast-import/-export","fromName":"Philip Prindeville","fromEmail":"philipp_subx@redfish-solutions.com","sentAt":"2018-07-03T21:56:06Z","receivedAt":"2018-07-03T21:56:12Z","isPatch":false,"sender":{"key":"philipp_subx@redfish-solutions.com","avatar":null},"body":"\n\n> On Jul 3, 2018, at 3:27 PM, Elijah Newren <newren@gmail.com> wrote:\n> \n> Hi Philip,\n> \n> On Tue, Jul 3, 2018 at 1:40 PM, Philip Prindeville\n> <philipp_subx@redfish-solutions.com> wrote:\n>> Hi.\n>> \n>> 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.\n>> \n>> 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.\n>> \n>> Given that “git mv” is an explicit action, I’m not sure why that wouldn’t be explicitly tracked.\n> \n> Not a full explanation, but see\n> https://git-scm.com/book/en/v2/Git-Internals-Moving-Files\n\n\nWhy not add the logic to track moves/renames?  That link explains what it does, but not why it does it.\n\n\n> \n>> 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.\n>> \n>> During an export using “-M” and “-C”, Bitkeeper complained:\n> \n> Why would you add -C?  Does bitkeeper also track copies?\n\n\nI figure that I’d furnish the maximum amount of meta data, and bitkeeper would use what it could and ignore the rest.\n\n\n> \n>> fast-import: line 'R ports/winnt/libntp/nt_clockstuff.c ports/winnt/ntpd/nt_clockstuff.c' not supported\n>> \n>> so I tried removing those two options, and it got further, this time stalling on:\n>> \n>> fast-import: Unknown command: tag ntp-stable\n> \n> If the fast-import command you are using can't read tags, then perhaps\n> you should report that to the authors of the fast-import tool you are\n> using and/or only feed branches to your fast-export command.\n\n\nWell, I’ll just do branches for now…\n\n\n> \n>> 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.\n>> \n>> So… this is an appeal for both to play better together.\n>> \n>> What’s involved in getting git to track file/directory moves/renames so that it’s palatable to Bitkeeper?\n> \n> Not tracking file/directory moves/renames wasn't an oversight but a\n> fundamental design decision; see e.g.\n> https://public-inbox.org/git/Pine.LNX.4.64.0510211826350.10477@g5.osdl.org/.\n\n\n\"I'm convinced that git handles renames better than any other SCM ever. \nExactly because we figure it out when it matters.”\n\nI 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.\n\nThat’s something that software can’t do for you.\n\n\n> \n> However, supposing that we did track renames, how would we tell\n> bitkeeper?  Well, we'd print out a line that looks like this in the\n> fast-export:\n> \n> 'R ports/winnt/libntp/nt_clockstuff.c ports/winnt/ntpd/nt_clockstuff.c'\n> \n> which is precisely the line that bitkeeper's fast-import was choking\n> on.  So, it sounds like they don't support importing rename\n> information (or at least the version of fast-import you're using\n> doesn't).  I think this is where the bug is; you'll probably want to\n> report it to whoever maintains the fast-import command that is choking\n> on this line.\n\n\nAlready done:\n\nhttps://users.bitkeeper.org/t/using-fast-import-from-git-into-bk/907\n\nNot sure I understand the response:\n\n\"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.\"\n\nOkay, what’s stopping them from doing their best with the information provided, even if it is a guess?\n\nBy 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”?\n\n-Philip\n\n\n\n> \n> Once that's fixed, you can export from git with the -M flag, and from\n> that output, there'll be no way to tell whether the original\n> repository tracked renames or detected them after the fact.\n> \n> \n> Hope that helps,\n> Elijah\n\n"}]}