| === jaimef is now known as fsbot | ||
| === fsbot is now known as jaimef | ||
| frathgeber | jelmer: i found this answer from 3 years ago saying there is an option `bzr diff --format=git-am`: https://answers.launchpad.net/bzr/+question/106814 | 10:19 |
|---|---|---|
| frathgeber | has that since been removed? | 10:19 |
| frathgeber | i'm using bzr 2.6.0~bzr6573.6287~ppa4050~precise1 and bzr-git 0.6.9+bzr1613~ppa131.1471~precise1 | 10:20 |
| frathgeber | another more recent answer from you (https://answers.launchpad.net/bzr/+question/204262) seems to suggest it has | 10:20 |
| jelmer | frathgeber: Hi | 12:10 |
| jelmer | frathgeber: you need the bzr-git plugin | 12:10 |
| === mmrazik is now known as mmrazik|afk | ||
| frathgeber | jelmer: i have bzr-git 0.6.9, but it complains about not knowing --format=git-am (--format=git works) | 12:35 |
| jelmer | frathgeber: ah, I think you want 'bzr send --format=git-am' | 13:17 |
| === wedgwood_away is now known as wedgwood | ||
| frathgeber | jelmer: send doesn't seem to like that format either: bzr: ERROR: Bad value "git-am" for option "format" | 13:56 |
| frathgeber | jelmer: my real question is acutally this, wondering if you might have an idea? http://stackoverflow.com/q/15660467/396967 | 13:57 |
| frathgeber | i was just thinking we might be able to circumvent the problem with exporting a patch series | 13:57 |
| frathgeber | jelmer: according to `git help send` the valid format options are 2 and 4 | 13:59 |
| === wedgwood is now known as wedgwood_away | ||
| === wedgwood_away is now known as wedgwood | ||
| === wedgwood is now known as wedgwood_away | ||
| === wedgwood_away is now known as wedgwood | ||
| jelmer | frathgeber: bzr send --format=git perhaps? | 14:18 |
| jelmer | frathgeber: if that doesn't work either, then you are probably running a version of bzr or bzr-git that is too old | 14:18 |
| jelmer | frathgeber: for general imports from bzr to git, you can also use "bzr dpush" to create the git branch | 14:19 |
| frathgeber | jelmer: jep, bzr send --format=git seems to be supported but crashes: i suspect in the version of bzr-git the send command is not compatible to bzr 2.6.0dev3 | 14:24 |
| frathgeber | jelmer: re dpush: this will first convert the bzr branch to a bzr-git repository via dulwich i assume? and then push to a git remote? | 14:26 |
| frathgeber | presumably this will require using dpush to initially populate the git repository? what about dpushing multiple bzr branches? will they maintain the correct ancestry relationships also over on the git side? | 14:30 |
| jelmer | frathgeber: dpush is easiest when you are pushing to a local git repository | 14:39 |
| jelmer | frathgeber: dpushing multiple bzr branches will have related ancestry | 14:39 |
| jelmer | frathgeber: you'll have to create a local git repository and an (empty) branch in it before you can dpush to it | 14:40 |
| frathgeber | jelmer: ok, thanks. so the result is equivalent to using bzr fast-export | git fast-import? | 14:42 |
| jelmer | frathgeber: no, it's a different history from what fast-export/fast-import would create | 14:42 |
| frathgeber | in what way? | 14:42 |
| jelmer | frathgeber: there are likely subtle differences in the way the git commits are created | 14:43 |
| frathgeber | ah, ok. so the revision DAG will be the same but the SHA1s? | 14:44 |
| jelmer | frathgeber: yeah, the SHA1s will be different | 14:45 |
| frathgeber | can i dpush to a bare git repo? | 14:45 |
| jelmer | the ancestry graph should have the same shape; bzr dpush preserves the shape that it had in bzr, I'm not entirely sure about fastexport/fastimport | 14:45 |
| jelmer | frathgeber: yes, though there needs to be an empty branch in that repo | 14:46 |
| frathgeber | how do i create an empty branch? | 14:46 |
| frathgeber | jelmer: wouldn't the branch normally only be created when i push to the bare repo for the first time? | 14:49 |
| jelmer | frathgeber: "bzr init /path/to/git/repo" should do it, assuming the git repo already exists | 14:52 |
| jelmer | frathgeber: "bzr dpush" was designed mostly to contribute to existing git projects from bzr | 14:53 |
| jelmer | ideally it would indeed create new branches too, but I never got around to implementing that | 14:53 |
| frathgeber | ok | 14:53 |
| frathgeber | so if our base is the bzr repo, we export to git and then make changes on the git side, we should be able to sync them back to bzr, but only if we have *the same* bzr-git repo that was created for the conversion. is that approximately correct? | 14:55 |
| frathgeber | jelmer: created by dpush i mean. and this repo will have different bzr commit ids than the "original" bzr branches, so the original bzr repo and the bzr-git repo will appear (to bzr) to not share any history, right? | 14:57 |
| jelmer | frathgeber: basically, yes | 14:58 |
| jelmer | frathgeber: "bzr dpush" will update your local bzr repository to only have data that can be represented in git | 14:58 |
| jelmer | frathgeber: and will basically have the same contents as the result of "bzr branch /path/to/your/git/repo /clone/in/bzr" | 14:59 |
| frathgeber | jelmer: yep, that makes sense and was what i assumed it would do | 15:00 |
| jelmer | frathgeber: you can use --no-rebase to preserve the original bzr repository. in that case, "bzr pull /path/to/new/git/repo" will give a "diverged branches" error | 15:00 |
| frathgeber | ok | 15:02 |
| frathgeber | jelmer: unfortunately that means that it probably won't help in our use case: the main problem i'm describing in http://stackoverflow.com/q/15660467/396967 is that we 1) export bzr -> git 2) filter the git repo (strip some files from history) | 15:02 |
| jelmer | frathgeber: dpush takes care of step 1, filtering the git repository can be done independent of that | 15:03 |
| jelmer | frathgeber: do you care about working in git and bzr? | 15:03 |
| jelmer | I thought you just wanted to do a one-off migration to git? | 15:03 |
| frathgeber | jelmer: yes, so far there's no problem. but now we want to be able to migrate further branches over to the filtered git repo while preserving their ancestry | 15:03 |
| frathgeber | jelmer: yes, it's a one-off migration | 15:04 |
| jelmer | frathgeber: that should work fine, as long as you do the filtering in a way that's consistent | 15:04 |
| jelmer | (i.e. so the same filter command on the same commit generates the same result commit with the same sha1) | 15:04 |
| frathgeber | jelmer: i *think* that's the case. however i'm still not sure how that would work in practice: would whoever wants to import another branch have to repeat steps 1) and 2) on their branch and then push? | 15:07 |
| jelmer | frathgeber: yes | 15:14 |
| jelmer | frathgeber: another option is to just do the import and then just have a commit on trunk that removes the problematic directory | 15:15 |
| jelmer | you could always rewrite the repository history in the future to strip out those large files | 15:16 |
| frathgeber | jelmer: yes, but that would require every contributor to get a fresh clone of the rewritten history, pay attention to not accidentally push from an "old" clone etc. that's why we rather do it in the conversion process | 15:17 |
| frathgeber | jelmer: the bzr -> git migration will require that anyway, so we'd rather do it now and be done with it | 15:18 |
| frathgeber | jelmer: however we don't necessarily want to import *everyone's* branches because some of them might well be dead/dormant. so we'd rather have a safe and easy to use migration path for our collaborators/contributors and their branches | 15:19 |
| jelmer | frathgeber: I would argue that that's mostly a git question; if you have multiple related branches, can you run a filter command that will keep consistent identity for the commits they have in common | 15:19 |
| frathgeber | jelmer: yes, git filter-branch can do that. i'm starting to think that maybe we can't get round importing everyone's branches all at once and run the filtering afterwards | 15:21 |
| frathgeber | that seems to me to be the only safe option | 15:22 |
| frathgeber | jelmer: would the git smart server help? bzr serve --git? | 15:26 |
| jelmer | frathgeber: I don't see how it would. whatever you do, the filtering is the issue - not the importing from bzr | 15:27 |
| jelmer | frathgeber: bzr can create consistent git commits for a particular bzr repo | 15:27 |
| jelmer | s/particular bzr repo/bzr repo with the same history/ | 15:28 |
| jelmer | if two people run bzr dpush on seperate branches of your project and they each have revision X in bzr then they will both end up with revision X' (with the same SHA1) in git | 15:28 |
| frathgeber | ok, i think the same is true with fast-export | 15:29 |
| frathgeber | jelmer: yes, i agree the filtering is the issue. i was hoping i could maybe integrate the filtering in the export pipeline i.e. bzr fast-export | filter | git fast-import | 15:30 |
| frathgeber | and ideally combine that with writing marks files on both end to save having to redo the work for every branch (but only ex/import missing commits) | 15:31 |
| frathgeber | i was looking at git_fast_filter which appears to be designed for that purpose: https://github.com/maxandersen/jbosstools-gitmigration/tree/master/git_fast_filter | 15:32 |
| frathgeber | but it can only deal with git fast-export streams, it chokes on bzr fast-export streams | 15:32 |
| jelmer | frathgeber: even with --plain? | 15:33 |
| frathgeber | seems so, yes | 15:33 |
| jelmer | frathgeber: how does it fail? | 15:34 |
| frathgeber | it dies on this line: https://github.com/maxandersen/jbosstools-gitmigration/blob/master/git_fast_filter/git_fast_filter.py#L720 | 15:34 |
| jelmer | I doubt you can reuse marks files in this case btw, because the marks file was generated for a slightly different stream than the resulting stream after the filter | 15:35 |
| frathgeber | jelmer: yes, i was thinking about that: there might be revisions disappearing because they only touch stripped files | 15:36 |
| frathgeber | jelmer: it chokes on this line in the fast-export stream: "M 644 inline .hgignore" (which doesn't match the regex pattern) | 15:38 |
| frathgeber | jelmer: but as you say, it's potentially unsafe anyway even if i could get it to work. i'm more and more leaning towards importing all branches before filtering | 15:40 |
| clyon | Hi. I have a problem with bzr on the gcc repo in launchpad. | 16:32 |
| clyon | bzr revno lp:~christophe-lyon/gcc/4.8-disable-peeling2 | 16:32 |
| clyon | bzr: ERROR: Server sent an unexpected error: ('error', 'GhostRevisionsHaveNoRevno', 'Could not determine revno for {svn-v4:138bc75d-0d04-0410-961f-82ee72b054a4:trunk:196812} because its ancestry shows a ghost at {svn-v4:138bc75d-0d04-0410-961f-82ee72b054a4:trunk:196812}') | 16:32 |
| clyon | bzr --version | 16:32 |
| clyon | Bazaar (bzr) 2.5.1 | 16:32 |
| clyon | Python interpreter: /usr/bin/python 2.7.3 | 16:32 |
| clyon | The host is running Ubuntu 12.04 (x86_64) | 16:33 |
| clyon | How can I fix this? | 16:34 |
| fullermd | Is it just a remote issue? | 16:35 |
| clyon | Sorry, what do you mean by remote? | 16:36 |
| fullermd | I mean, does it happen only when you try to revno the branch on lp, or does it happen when you have the branch locally too? | 16:36 |
| clyon | Only remotely. | 16:37 |
| fullermd | Ghosts have always been a fruitful source of bugs. So I wouldn't be surprised if there were one hiding in the twisty details of whatever RPC calls revno makes on remotes. | 16:37 |
| clyon | From another host running bzr 2.1.4/python 2.6.5, it works | 16:37 |
| fullermd | Probably that version is old enough that it's really "dumb" about how it goes about doing a remote revno. | 16:38 |
| clyon | Too bad. What can I do? (I don't know how that mirroring of GCC works, from svn to bzr) | 16:38 |
| fullermd | Probably not much; it sucks having a history with ghosts, so if that's avoidable it would be good. But it's often not. | 16:39 |
| fullermd | It IS a bug in bzr that revno fails in that way (I mean, it would be a bug blowing up all over the place, but it's _definitely_ a bug that it blows up in remote but works locally) | 16:40 |
| fullermd | So it's worth filing a bug on. Or fixing yourself, but that'll take time and knowledge of what are probably some of the uglier bits of bzrlib. | 16:40 |
| fullermd | Since it's fairly well localized, it's probably a relatively tractable bug at least. | 16:41 |
| clyon | How can I workaround it? It's used in our validation script, which monitors the bzr database... | 16:41 |
| fullermd | Mmm. Well, you can try decorating things to not use the smart methods. Calling directly to the HTTP URL would work, or I think a nosmart+bzr+ssh (or is it bzr+ssh+nosmart?). Have to bypass the lp: directory service, but that's easy enough. | 16:42 |
| fullermd | If it fits, better would be to have a local branch mirror and revno against it. | 16:42 |
| clyon | OK. I have to read the doc about nosmart :-) | 16:43 |
| fullermd | Looks like it's nosmart+b+s: | 16:43 |
| fullermd | % bzr info bzr+ssh+nosmart://localhost/nonexistent | 16:43 |
| fullermd | bzr: ERROR: Unsupported protocol for url "bzr+ssh+nosmart://localhost/nonexistent" | 16:43 |
| fullermd | % bzr info nosmart+bzr+ssh://localhost/nonexistent | 16:43 |
| fullermd | bzr: ERROR: Not a branch: "nosmart+bzr+ssh://localhost/nonexistent/". | 16:43 |
| LarstiQ | that revno error happens with bzr.dev too | 16:44 |
| clyon | bzr revno nosmart+bzr+ssh://launchpad.net/~christophe-lyon/gcc/4.8-disable-peeling2 | 16:46 |
| clyon | ssh: connect to host launchpad.net port 22: Connection refused | 16:46 |
| fullermd | Nah, the branch URL is a little different. | 16:47 |
| fullermd | If you've got a local mirror of the branch, you can just grab the URL from it. | 16:48 |
| fullermd | Or I think... | 16:48 |
| fullermd | Yeah, you can do a "bzr info lp:whatever" and get the full URL from that. | 16:48 |
| clyon | Indeed. | 16:48 |
| clyon | bzr revno nosmart+bzr+ssh://bazaar.launchpad.net/~christophe-lyon/gcc/4.8-disable-peeling2 | 16:48 |
| clyon | 122393 | 16:48 |
| clyon | Thanks! | 16:49 |
| fullermd | Actually, now that I think about it, I think you can 'nosmart+lp' even. That's simpler. | 16:50 |
| clyon | Confirmed! | 16:51 |
| fullermd | Worth filing a bug en passant anyway, just for doc purposes. | 16:51 |
| clyon | OK, I will do it. | 16:51 |
| clyon | Just reported as #1161018 | 16:54 |
| fullermd | bug 1161018 | 16:55 |
| ubot5 | bug 1161018 in Bazaar "bzr revno fails on ghost ancestry" [Undecided,New] https://launchpad.net/bugs/1161018 | 16:55 |
| === r0bby_ is now known as robbyoconnor | ||
| * fullermd waves at vila. | 20:50 | |
| === nopf_ is now known as nopf | ||
| === wedgwood is now known as wedgwood_away | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!