=== Guest7726 is now known as wallyworld [00:55] how can I go back and correct a commit after adding a few more on top of it? With git I would just commit the fix, then use rebase -i to squash the fix into the original. [00:55] you can rebase if you want [00:55] or just fix it [00:59] how would I rebase it? I'd prefer to not clutter the history with the fix commit [01:00] by rebasing it? [01:01] http://wiki.bazaar.canonical.com/Rewrite [01:01] depends how much you care [01:03] do I have to branch into another directory first, then uncommit back to the problem commit, fix, recommit, then rebase the original branch onto this one? [01:03] or is there a way to do it in the current directory? [01:09] psusi: use the rebase command (from the bzr-rewrite plugin) [01:10] spiv, yea... how exactly? [01:10] Although maybe I'm wrong, and it still needs you to do it in another directory. [01:10] I'm sorry, my memory on using it is hazy :( [01:18] psusi: one of the reasons people don't care so much about this sort of thing in bzr is that most of the time one is working a branch that's going to be combined with trunk by "bzr merge" [01:18] you'll need to branch the rev you want to fix to a new branch, uncommit once and commit with the fixed message, then replay from the other branch [01:19] mwhudson: I think they do care, often, but we've filtered them out of the community; see my manifesto for my analysis about it ;) [01:19] psusi: and when people run "bzr log" in trunk, they only see the message that the branch was merged with by default [01:19] lifeless: well yes [01:19] mwhudson, that not only does not avoid cluttering the history with minor fixup commits, but clutters it even more with useless merges [01:20] psusi: you see, i don't think of them as 'useless merges' -- quite the opposite, they are actually the most important thing [01:21] psusi: not trying to convert you or say you are wrong, but different tools tend to be used in different ways [01:21] a merge that just fast forwards rather than actually merges concurrent development lines is a useless line in the history at best, and at worst, hides the actual development [01:21] It depends on what you value (and what the owners of the other branches value). [01:22] well, there aren't other branches [01:22] hence, why I don't want to add extra commits [01:22] I tend to value having a single, clear commit on my branch when a merge happens summarising the thing that landed (and then if I want to see details of how that got developed I dig into the history on that side). [01:23] But I understand other folks work differently or value different properties more. [01:23] that makes sense... if I branched and made several commits that all are part of one new feature... but I didn't... just several unrelated commits === zyga-afk is now known as zyga [07:28] morning all [08:32] morning [09:03] hello [09:09] hawdee === zyga is now known as zyga-afk === zyga-afk is now known as zyga [13:36] hey guys!! [13:36] hey [13:37] mgz i have some question about bzr think you can help out? [13:37] :D [13:49] Wiz_KeeD: don't ask to ask, just ask. [13:57] when I want to ammend the previous commit, if I uncommit, fix it, then recommit, I have to retype the log message. Is there a way to avoid that? [14:00] psusi: the commit message is saved in .bzr/branch/branch.conf if you have bzr-gtk or qbzr instaled [14:00] they will also suggest the old commit messages if you commit using 'bzr qcommit' or 'bzr gcommit' [14:00] 'bzr commit' doesn't have this functionality (yet) [14:00] doh [14:00] I just keep it on the clipboard generally... [14:01] problem with that is that if I look at the log, copy, and paste it back in, I have to manually delete the indentation from each line [14:01] which gets annoying [14:04] how can i browse bzr revisions? [14:04] Wiz_KeeD: bzr viz or bzr qlog [14:04] none work [14:04] wait [14:05] nop, neither work [14:05] Wiz_KeeD: you'll have to have either bzr-gtk or qbzr installed [14:05] unknwon command [14:07] * gour uses fish shell and it usually guess correct log message [14:07] it has installed olive bazzar gui [14:11] I did a bzr rebase and it shows up in the log as a merge.. what gives? [14:11] what does rebase do? [14:11] rewrites history to make commits appear as being based on a different starting point [14:13] being based on a different startying point? [14:14] instead of rev X, then A and B, it's rev Y, then A and B [14:14] ah... [14:14] littel wierd [15:07] * psusi beats bzr with a rubber hose... a rebase is NOT a merge! [15:08] psusi: hmm? [15:10] jelmer_: a few commits back, I fixed something wrong. So I branched, uncommitted back there, fixed it, committed it again, and am now trying to rebase the subsequent commits on top of the new fixed old commit so it looks like I got it right the first time [15:10] and when I bzr rebase -r 33.. fixed, rev 33 shows up as a MERGE [15:12] psusi: presumably because the old rev 33 was a merge commit? [15:14] nope [15:14] no merges anywhere [15:14] until after I try to rebase [15:15] err, actually it was rev 33 where the error was so I rebase -r 34.. to get all of the commits above there onto the new, corrected 33 [15:16] but after the rebase, r34 shows as a merge that has the description of the old r34, but merges the new, corrected r33 [15:17] ah, bzr-rebase probably doesn't handle the same revision being in the branch multiple times very well [15:19] argh... this is so easy in git [15:28] this is really broken... the history apparently was correctly rebased... it shows r34 following the new, corrected r33... it r34 also says it merged in the OLD r33 [15:28] which makes no sense at all [15:40] well, I guess it's back to my old method of uncommit, shelve, repeat, edit, recommit, unshelve, commit, repeat [15:40] Well, it's a parent of the old 34, so in that sense it could be part of the stuff to be brought over, given a certain interpretation. [15:41] the whole point of rebasing is to discard the old history [15:41] 'd probably have to poke around in the helpfile for the details; I don't know (or have it around to check myself) [15:41] and make 34+ as if they were originally done on top of the new 33 [15:41] A matter of interpretation. It would be just as valid to say the point is to take (history on that side that's not here) and stick it on the end of here. [15:42] and you obviously did not merge the old 33, since the state of the files reflects the contents of the new 33, but the log makes it look that way [15:43] no, that's what a merge is [15:43] Not really. Merge couldn't put them on the end. [15:43] merge always puts them on the end.... under a merge commit [15:43] new-33 isn't a parent of old-34, so merge couldn't make that happen; only a rebase could. [15:44] It has to create a new-34 to cause that. [15:44] Merge can only put them off to the side, then put something new on the end that connects the two. [15:44] right... rebase changes new-34 so it says its parent is new-33.. and that's all it should do [15:44] instead it seems to make new-34's parent new-33, AND merge in old-33 [15:45] you can't have both old and new 33, they conflict [15:45] Anyway. This is bootless. My point is that it's not immediately obvious to me whether the existing parent of 34 is part of what should be preserved or not in a rebase, and so I'd consider either behavior a sensible answer to the question. It would take digging into the details of what rebase does and what args it takes to know for sure, and I don't have any of that at my fingertips. [15:46] Semantically, yes; that's what you intend. The question is, is the command you're running expressing that as bzr expects. [15:47] It could be a bug "the default choices aren't what I expect", or a bug "the default choices aren't working as designed"; I don't know which. [15:47] how is it not obvious? the whole point of a rebase is to eliminate the existing parent and replace it with a new one [15:47] If the former, there's probably some arg you can find in help that will get you where you want to be. [15:48] * fullermd shrugs. [15:48] To me, in isolation, it's not obvious that one of the choices is obviously right and the other obviously wrong, so I couldn't express an opinion as to which way things are failing. [15:49] one of the choices follows the definition of rebase, the other does not [15:49] There is no "definition of rebase". [15:50] sure there is... to change the base revision on which a set of history started from [15:50] There's a "what _git_ does when you run rebase with -xyz", and a "what _bzr_ does when you run rebase with -xyz". Presumably they're _close_, but I don't see any reason to assume they're identical. [15:50] vila: I'd like to discuss bug #1015614 . Do you have a minute? [15:50] Launchpad bug 1015614 in Bazaar "Configuring local colocated branches matches too broadly" [Undecided,New] https://launchpad.net/bugs/1015614 [15:53] Wow, LP got into the millions there. [15:56] fullermd: Yep, about a month ago: http://blog.launchpad.net/general/one-in-a-million [15:58] The downside is that I'm really going to have to knuckle down and write some terrible code if we're going to hit the billion mark in my lifetime. Sigh. Back to the salt mines... [16:07] it's not enough just to be bad fullermd, you also have to be popular [16:08] Oh, I take _that_ part for granted. I mean, _look_ at me! [16:09] mgz: like nvidia? :-) [17:43] hey, someone just asked me why submit: and push: locations are two different things [17:44] and I don't know the answer [17:44] what's the answer? [19:07] jml: submit is what you want to submit merge proposals against [19:08] jml: e.g. in the case of bzr [19:08] you push your feature branch to lp:~jml/bzr/feature-branch [19:08] whereas the submit location is lp:bzr === yofel_ is now known as yofel === gour1 is now known as gour === jelmer_ is now known as jelmer