[09:38] hey, any help would be appreciated.. how is merge working with bzr? [09:38] my coworker, ed, has a branch. He wants to merge my work on it. bzr merge doesn't merge the commits but only the changes [09:39] is it possible to merge the commits and their messages? [09:40] or does he have to merge & commit for each of my commit? [09:41] merge _does_ merge the commits. [09:44] fullermd: http://pastie.org/10513117 [09:46] Thus the pending merge tip :) [09:46] niluje: "bzr merge" just stages the merge; you need to run "bzr commit" to commit it. [09:46] oh [09:47] yeah [09:47] but if I run "bzr commit -m 'whatever'" [09:47] niluje: "bzr merge" just stages the merge; you need to run "bzr commit" to commit it. [09:47] there only one commit with "whatever" as message [09:48] Merged revs are hidden away by default. Use -n0 to expand them out. [09:48] on which command should I use -n0? [09:48] log [09:48] oh, indeed [09:49] is there a great GUI tool on osx? [09:49] thanks a lot :) as a git user, I'm a bit confused with bzr :p [09:49] -n0 answers my questions [09:51] How well/deeply do you know git? [09:53] well :p [09:54] 'k. So in gittish terms, 'bzr log' by default only follows the first parents. Revs with more parents do get marked [merge], but you need -n[something] to expand those branches. [09:54] yep [09:54] so there no equivalent to fast forward merges, right? [09:55] The operative theory is... well, OK, the _proximate_ operative theory behind the change that made that happen, is that it's faster/not as painfully slow to do that. [09:56] But the _other_ operative theory is that generally, you don't care about the details of something merged. Merges tend to be stuff like "merge trunk [into this feature branch I'm still working on, to keep caught up]", or "land feature X [into trunk]". In either case, most of the time, just the fact of what happened is all you really care about. [09:56] It's only when you need to look at some detail along the way that you care about the individual revs inside it, so collapsing them away makes it easier to look at the history and find the bits you _do_ care about. [09:57] 'bzr pull' does fast forwards [only]. [09:57] There's also a 'merge --pull' that does fast forwards if it can. [09:58] It's a bit confusing using it IMO, though, since that means that sometimes it'll FF and you don't have to commit anything, but sometimes it can't and so you do have to commit the merge. [09:58] ok [09:58] what about rebasing? [09:58] if I'm on my feature branch and I want to rebase on the master branch, should I merge? [09:59] There's a 'rewrite' plugin that does [some subset of] that. I'm not sure how well it works. [09:59] In bzr world, people generally just merge stuff. [09:59] ok :) [10:00] thanks a lot for the explainations fullermd [10:00] what about a GUI on OSX? do you know a good one? [10:01] I don't think there's an integrated one. I imagine the bits of qbzr work there, which gives GUI's for certain commands. [10:01] There is/what a bzr-gtk too, that was similar. [10:02] let's stick with cli then :p [10:02] (is/was; at one point it fell into near-total disrepair, I don't recall if it was resurrected or not) [10:02] kk, thanks! [10:17] * fullermd pulls vila's plug a few more times, just for kicks. [10:19] fullermd: hehe, try again, I switched from desktop to laptop for an upgrade ;) [10:20] Upgrade? You mean you switched out that "Lunix" thing for a _real_ OS? ;> [10:22] hehe, real ? What's real and what's virtual... Do I still know... [10:22] Real is stuff you can eat. Virtual is just little bytes. [10:23] ha right, I should stop that diet then ;)