[00:04] <lduros> so basically I did: bzr import firefox-12.0.tar.bz2 upstream
[00:05] <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:06] <lduros> does this make all sense?
[00:06] <lduros> looks like the two imports worked
[00:07] <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:08] <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:09] <AfC> lduros: so before you figure out how to fix this,
[00:09] <lduros> AfC: ?
[00:10] <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:11] <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:12] <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:13] <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:14] <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:15] <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:16] <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:17] <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:18] <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:19] <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:20] <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:21] <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:22] <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:23] <fullermd> Yeah.  I'd probably experiment a bit with two or three options, see which seems to work best.
[00:24] <lduros> yeh
[00:25] <lduros> thanks much
[00:25] <lduros> :-)
[08:09] <mgz> morning
[08:11] <fullermd> No, I don't think I'll allow that.
[08:14] <mgz> it has been decreed.
[08:14] <fullermd> Well, recreed it.
[09:33] <rhitier> hi. I've commited many times before discovering my whoami was wrong. Can I edit the "committer" of previous commits ?
[09:34] <mgrandi> dont think so unless you use one of those rabasing things that basically create new commits
[09:34] <rhitier> "rabasing thing" ?
[09:36] <mgrandi> rebasing*
[09:36] <mgrandi> i dont know much about how bzr does it, basically edits the history im guessing
[09:37] <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:40] <rhitier> mgrandi, LeoNerd : thanks, I'll try that as it is a private before sending.
[09:41] <jelmer> bzr rebase isn't particularly useful in that regard
[09:44] <mgz> what is the easiest way of replaying history? export then import?
[09:47] <jelmer> I think so, or shelve + uncommitt
[09:49] <rhitier> when I merge a contributor's patch, do I imports all its commits history ?
[09:50] <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:51] <rhitier> isnt bundle naturally created with bzr send ?
[09:52] <jelmer> rhitier: yes
[09:53] <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:58] <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:59] <rhitier> (with strange rew numbers, like 50.1.2 )
[10:02] <mgz> rhitier: roughly
[10:03] <rhitier> thanks all. I go on branching/hacking ;-)
[13:22] <jam> jelmer: ping, I think I need a refresher on getting and building source debs
[13:26] <jelmer> jam: sure
[13:27] <jelmer> mumble?
[13:27] <jam> jelmer: sounds good
[22:00] <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:10] <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:11] <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:12] <cedeon> is there anyway to force copy they file identifiers?
[22:12] <cedeon> from one branch to the other?
[22:17] <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:18] <cedeon> cool thanks , i'll give that a try
[22:50] <bob2> I don't think git works the way you think it does either
[22:53] <bob2> oh heh
[22:54] <bob2> don't quite understand how it works, the branches have no ca
[22:58] <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:59] <cedeon> it just seems like this sort of thing should be simple
[22:59] <bob2> nah
[23:00] <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:01] <cedeon> how do i rewrite his on top of mine?
[23:02] <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:13] <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:14] <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:15] <cedeon> ok i think i get you