| lduros | so basically I did: bzr import firefox-12.0.tar.bz2 upstream | 00:04 |
|---|---|---|
| lduros | then bzr commit -m'ff12' | 00:05 |
| lduros | then bzr import firefox-13.0.tar.bz2 upstream | 00:05 |
| lduros | bzr commit -m'ff13' | 00:05 |
| lduros | then in my other (previously existing branch), I do: bzr merge upstream | 00:05 |
| lduros | does this make all sense? | 00:06 |
| lduros | looks like the two imports worked | 00:06 |
| lduros | but since my own branch is not related to upstream in any kind, since I created it beforehand, I get this when trying to merge: | 00:07 |
| lduros | bzr: ERROR: Branches have no common ancestor, and no merge base revision was specified. | 00:07 |
| lduros | so base revision I should probably put 1 | 00:08 |
| lduros | i guess | 00:08 |
| lduros | since a commit in my branch corresponds to Firefox 12 | 00:08 |
| AfC | lduros: so before you figure out how to fix this, | 00:09 |
| lduros | AfC: ? | 00:09 |
| AfC | lduros: I assume you recognize that if you had *started* with the imports and *then* created your own working branch(es) they would have had said common ancestor and all this would be Just Working™ | 00:10 |
| lduros | yes i know but I started that a while ago | 00:10 |
| AfC | sure | 00:10 |
| lduros | my own branch, I mean | 00:10 |
| AfC | just setting the scene here | 00:10 |
| AfC | lots of people don't realize that part | 00:10 |
| lduros | yes, in retrospect I should have done it | 00:10 |
| lduros | :-) | 00:10 |
| AfC | now we just need to fix the scenario you've found yourself in | 00:10 |
| AfC | lduros: rude question: how much history do you have on your working branch? | 00:11 |
| lduros | 112 revisions, not that bad I guess | 00:11 |
| AfC | lduros: a lot? only one or two | 00:11 |
| lduros | I could probably just apply a patch | 00:11 |
| AfC | No, that's a lot | 00:11 |
| lduros | and forget about it | 00:11 |
| AfC | so you're not going to want to throw that away. | 00:11 |
| AfC | (sure, you could throw it away, but why should you have to?) | 00:12 |
| lduros | well, I don't know, if it's easier I could | 00:12 |
| AfC | at this point, as far as I know, you have two options | 00:12 |
| lduros | ok | 00:12 |
| AfC | lduros: (it's *certainly* easier) | 00:12 |
| lduros | ok | 00:12 |
| fullermd | I don't see how... | 00:12 |
| lduros | so what if I do this: | 00:12 |
| AfC | lduros: but it's also Wrong and the one thing that Bazaar has going for it over the other DVCSen is that it acts correctly. | 00:12 |
| lduros | hmm, not sure how to interpret this | 00:13 |
| AfC | fullermd: (because just dumping his current tree onto the upstream import will create a single delta that he can commit and then we can all move on and go drink coffee. Easier. More to the point, easier than:) | 00:13 |
| AfC | lduros: at this point, as far as I know, you have two options: | 00:13 |
| AfC | 1) use bzr rebase | 00:14 |
| lduros | ok | 00:14 |
| AfC | 2) use some magic merge that gets around the common ancestor problem. | 00:14 |
| lduros | the magic merge seems tricky | 00:14 |
| fullermd | I think it's way easier than either of those two. | 00:14 |
| AfC | I have a feeling that (2) exists, but I don't know the syntax :( | 00:14 |
| fullermd | You started with FF 12 and then made a pile of changes on top, neh? | 00:14 |
| AfC | fullermd: if you've got (3) please, speak up | 00:14 |
| lduros | and also I added the upstream files with a non-empty branch already | 00:14 |
| lduros | meaning I had files in there | 00:14 |
| lduros | hah | 00:14 |
| lduros | yeh, so maybe i'll try to take the current version I have (which is IceCat 12) | 00:15 |
| AfC | fullermd: right, so how can he merge a branch with 112 revisions from scratch (and some monster revision as #1 I bet) starting onto a branch with 2 imports of two versions of upstream? | 00:15 |
| lduros | Take IceCat 12 and take Firefox 12, make a patch using diff | 00:15 |
| fullermd | Oh, that wasn't what I read from your descriptions. That does make it harder. | 00:15 |
| lduros | then create an upstream branch, import FF12 | 00:16 |
| fullermd | Well, in my mind his r1 was already upstream 12, so he could just make a 'new' branch from that to use as the upstream. Put 13 on that, then merge it in; done. | 00:16 |
| lduros | fullermd: it was more like r41 which was upstream 12 + custom stuff | 00:17 |
| lduros | so it's really a tangled mess | 00:17 |
| lduros | :-) | 00:17 |
| lduros | I'm willing to just keep it as an archive branch | 00:17 |
| fullermd | Is your custom stuff off on the side, or all intertwined in the existing files? | 00:17 |
| lduros | mostly on the side I guess | 00:18 |
| lduros | but some might be intertwined, not much | 00:18 |
| lduros | but I'm a bit lazy also | 00:18 |
| lduros | :-) | 00:18 |
| lduros | and maybe sometimes it's better to start clean | 00:18 |
| fullermd | If you can isolate the changes in the existing files into a few small bits, you may be able to create a pure upstream 12 branch, dump the 'old' files you have and merge that in place, put your changes back into them, then go on with later version merges. | 00:18 |
| lduros | ok | 00:18 |
| fullermd | That would save all the history in your other files, and have the original versions of your changes sitting in the history too. | 00:19 |
| fullermd | It would bloat up your repo with a giant delete and a giant add though. | 00:19 |
| fullermd | And of course the "same" files wouldn't be related to each other historically. | 00:19 |
| lduros | haha | 00:19 |
| lduros | right | 00:19 |
| lduros | alright, let me try | 00:20 |
| fullermd | The latter is suboptimal ugliness that can be considered historical archive. The former is some level of added size burden you'd carry forever; whether it's significant I don't know. | 00:20 |
| fullermd | I have vague memories that the groupcompress format will compress content across file identities, in which case it may not be a big bump. | 00:21 |
| lduros | yeh, I'm not sure, what I want to make sure is that all my custom changes are there | 00:21 |
| fullermd | But if it doesn't, it would be. | 00:21 |
| AfC | I'd judge the real question to be whether or not you will be continuing to track upstream. If so, then it's worth getting on to a workflow based on their releases, rather than your original tree. | 00:21 |
| lduros | yes sure i'll keep tracking upstream | 00:21 |
| AfC | otherwise, it's not entirely clear what the goal is | 00:21 |
| fullermd | Definitely. Doing a 12->13 merge up manually would suck. Having a 14 and 15 and 16 after that too would be nightmarish. | 00:21 |
| lduros | right | 00:21 |
| fullermd | (and anyway, it's FF, so you'd have to do one of those, what, every 36 hours or something, when they make a new major release?) | 00:21 |
| lduros | :-P | 00:22 |
| lduros | alright, I'll experiment a bit, look again at these advice | 00:22 |
| lduros | and try to get somewhere :-] | 00:22 |
| === AfC is now known as AfC|gym | ||
| fullermd | Yeah. I'd probably experiment a bit with two or three options, see which seems to work best. | 00:23 |
| lduros | yeh | 00:24 |
| lduros | thanks much | 00:25 |
| lduros | :-) | 00:25 |
| === r0bby_ is now known as robbyoconnor | ||
| === wgrant_ is now known as wgrant | ||
| mgz | morning | 08:09 |
| fullermd | No, I don't think I'll allow that. | 08:11 |
| mgz | it has been decreed. | 08:14 |
| fullermd | Well, recreed it. | 08:14 |
| rhitier | hi. I've commited many times before discovering my whoami was wrong. Can I edit the "committer" of previous commits ? | 09:33 |
| mgrandi | dont think so unless you use one of those rabasing things that basically create new commits | 09:34 |
| rhitier | "rabasing thing" ? | 09:34 |
| mgrandi | rebasing* | 09:36 |
| mgrandi | i dont know much about how bzr does it, basically edits the history im guessing | 09:36 |
| LeoNerd | It's a form of history rewriting | 09:37 |
| LeoNerd | It's rather rude on anyone else who's seen the branch, but if it's a private one currently with no chance anyone else has seen it it should be fine | 09:37 |
| rhitier | mgrandi, LeoNerd : thanks, I'll try that as it is a private before sending. | 09:40 |
| jelmer | bzr rebase isn't particularly useful in that regard | 09:41 |
| mgz | what is the easiest way of replaying history? export then import? | 09:44 |
| jelmer | I think so, or shelve + uncommitt | 09:47 |
| rhitier | when I merge a contributor's patch, do I imports all its commits history ? | 09:49 |
| jelmer | rhitier: if it's a bundle, yes | 09:50 |
| mgz | or if you're merging a branch, anything using merge before commit basically | 09:50 |
| rhitier | isnt bundle naturally created with bzr send ? | 09:51 |
| jelmer | rhitier: yes | 09:52 |
| rhitier | ok. I merged. Should I commit before being able to see history logs of applied patch ? | 09:53 |
| jelmer | rhitier: yep, or you can use e.g. qlog | 09:53 |
| rhitier | I created a branch. I merged the patch. And now the log shows a "Pending Merges". After a commit, contributor's commits appear as a branche of my latest commit. Is that it ? | 09:58 |
| rhitier | (with strange rew numbers, like 50.1.2 ) | 09:59 |
| mgz | rhitier: roughly | 10:02 |
| rhitier | thanks all. I go on branching/hacking ;-) | 10:03 |
| jam | jelmer: ping, I think I need a refresher on getting and building source debs | 13:22 |
| jelmer | jam: sure | 13:26 |
| jelmer | mumble? | 13:27 |
| jam | jelmer: sounds good | 13:27 |
| === zyga is now known as zyga-food | ||
| === zyga-food is now known as zyga | ||
| === zyga_ is now known as zyga | ||
| cedeon | Hi guys. Can anyone help me , i need to merge two branches which the data is absolutely identical yet for reasons that blow my mind bzr wont merge as it says it doesn't share a common ancestory. Is there any simple way of doing this without it generating a whole bunch of .moved files in the process? | 22:00 |
| jelmer | cedeon: the branches aren't related as far as bzr is concerned | 22:10 |
| jelmer | cedeon: the files would all have different unique file identifiers | 22:10 |
| jelmer | you can see this by running "bzr ls --show-ids" in the two branches | 22:11 |
| cedeon | so its not like git where they have the file contents hashed? | 22:11 |
| cedeon | is there anyway to force copy they file identifiers? | 22:12 |
| cedeon | from one branch to the other? | 22:12 |
| jelmer | cedeon: when you add a file, you can use "bzr add --file-ids-from <otherbranch>" to make it use the same file ids | 22:17 |
| cedeon | cool thanks , i'll give that a try | 22:18 |
| bob2 | I don't think git works the way you think it does either | 22:50 |
| bob2 | oh heh | 22:53 |
| bob2 | don't quite understand how it works, the branches have no ca | 22:54 |
| cedeon | well maybe im going about this the wrong way.. i cant 'add' because i have a lot of history on my branch... basically i have a situation where i have 31 revisions and some guy gave me a bzr repo with six revisions and different file ids. I KNOW that my revision 30 equals his revision 0 yet i cant figure out how to merge these together | 22:58 |
| cedeon | it just seems like this sort of thing should be simple | 22:59 |
| bob2 | nah | 22:59 |
| bob2 | you can bzr-rewrite his on top of yours though | 23:00 |
| cedeon | i can rollback to rev 30 so im at the stage where the file bits are identicle | 23:00 |
| bob2 | how did all the fileids get lost | 23:00 |
| cedeon | i dunno i guess he made a new repo from my files and didn't use my repo | 23:00 |
| cedeon | how do i rewrite his on top of mine? | 23:01 |
| cedeon | i tried merging his and then deleting all the .moved files.. committing but then i have his file ids so i cant merge my 31 back | 23:02 |
| jelmer | cedeon: still there? | 23:13 |
| jelmer | cedeon: I would: | 23:13 |
| cedeon | yeah im here | 23:13 |
| jelmer | 1) create a copy of the branch at the point where the histories are still shared | 23:13 |
| cedeon | check :) | 23:13 |
| jelmer | 2) sync his files over the new copy | 23:13 |
| jelmer | 3) "bzr add --file-ids-from YOURBRANCH" | 23:13 |
| cedeon | oh wait, they have no shared history if you mean bzr history | 23:13 |
| jelmer | 4) remove files that weren't present in his branch | 23:13 |
| jelmer | cedeon: in that case, start with an empty branch | 23:14 |
| jelmer | or actually, revision 30 you were referring to earlier | 23:14 |
| jelmer | (but revision 30 from your branch) | 23:14 |
| cedeon | yeah i've rolled back to rev 30 | 23:14 |
| cedeon | ok i think i get you | 23:15 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!