[02:23] <thomi> stupid question: if I did a 'bzr merge <some_other_branch>' without first committing my local changes, is there a way I can back-out the changes pulled in by the merge?
[02:23] <thomi> 'bzr revert' will undo all my local changes, which isn't what I want
[02:24] <thomi> and 'bzr revert --forget-merges' just removes the merge marker, not the changes that came with it
[02:27] <fullermd> merge wouldn't run in the first place unless you --force'd it.
[02:27] <thomi> fullermd: sorry, I just worked out, it was a 'merge' and then an 'unshelve'
[02:28] <fullermd> Ah.  Messy.  I'm not sure you could unwind that too easily...
[02:29] <fullermd> One possibility might be to try doing the merge over again in reverse, in the hopes that it'll squeeze out the 'merge' changes leaving just the 'unshelve' ones, then you can cleanup and retry from there.
[02:29] <thomi> fullermd: ok, thanks
[02:29] <fullermd> Another might be to try shelving the whole pile of changes (including the merge, so you're left with a clean tree).  Then do the merge again, and commit it.
[02:29] <fullermd> Then unshelve; that might leave the merge bits of it "unchanged" (from the now-committed merge) and include just the bits that were on the shelf before.  Or it might blow up messily; not really sure.
[02:31] <thomi> heh, ok
[02:57] <thumper> thomi: I'd also suggest what fullermd said, shelve the changes you want to keep
[04:38] <bob2> imho unshelve should need --force to restore to modified files
[04:48] <spiv> bob2: +1
[04:49] <lifeless> bob2: mmm, not merge in ?
[04:50] <bob2> lifeless, if you --force it, sure
[04:51] <bob2> otherwise it more or less can lose data
[04:59] <lifeless> bob2: mmm, or it could make a backup file.
[05:00] <bob2> it could
[05:05] <bob2> silently mashing up my data by default like 'svn up' is unfortunate
[05:09] <spiv> bob2: yeah, mashups are *so* 2009
[05:13] <bob2> haha
[10:41] <Zmanu> hello
[10:42] <Zmanu> i want to do a bzr up on one file, but when i do it, it update all commit file, what is the way to do it ?
[11:39] <lifeless> Zmanu: there isn't. bzr works on a full tree at a time for update/pull
[13:21] <Zmanu> lifeless: ok i see, we need to work with revision to be abble to up only some files instead of all files
[13:23] <Zmanu> lifeless: thanks for answer
[16:22] <xnox> can I do "merge-into" remotely to get left-right merge history correct
[16:22] <xnox> instead of cloning trunk, going into it, and doing bzr merge ../my-current-branch
[16:22]  * xnox simply wants $ bzr merge-into lp:trunk & bzr push :parent
[16:25] <fullermd> Not really.
[16:26] <fullermd> Well, I guess you could conceptually do it be [ab]using the terrifying auto-pivoting that bound branches do on divergence.  But I'm confident that will cause more problems than it solves, based on the nigh-infinite ratio of past experience.
[16:29] <xnox> =)))))
[20:51] <thumper> abentley: ping
[20:51] <thumper> abentley: got a question about reconfigure command
[20:51] <abentley> thumper: pong
[20:51] <abentley> Sure.
[20:52] <thumper> with --lightweight-checkout
[20:52] <thumper> so... I have this branch in my GOPATH
[20:52] <thumper> something like juju-core
[20:52] <thumper> and I'm not overly enamoured with cobzr
[20:52] <thumper> so I thought I'd use my normal layout and switch
[20:52] <thumper> so... ~/src/juju-core/trunk is a copy of trunk
[20:52] <thumper> in my normal layout
[20:52] <thumper> so my locations.conf is all set up etc
[20:52] <lifeless> branch or tree or both ?
[20:52] <thumper> lifeless: my ~/src/juju-core is a shared repo with trees
[20:53] <thumper> Ideally I'd like to work in a similar way I am with a virtual env I have
[20:53] <thumper> where I just switch the actual work branch
[20:53] <thumper> :~/go/src/launchpad.net/juju-core$ bzr reconfigure --lightweight-checkout ~/src/juju-core/trunk/
[20:53] <thumper> bzr: ERROR: Not a branch: "bzr+ssh://bazaar.launchpad.net/~thumper/juju-core/trunk/".
[20:53] <lifeless> so what I have is a treeless repo with N branches and a single working tree 'working' with a lightweight checkout of one of the branches
[20:54] <abentley> thumper: It sounds like ~/go/src/launchpad.net/juju-core is already a checkout and refers to bzr+ssh://bazaar.launchpad.net/~thumper/juju-core/trunk/ .
[20:55] <abentley> thumper: what does bzr info say?
[20:55] <thumper> lifeless: I used to work that way a long time back...
[20:55] <thumper> lifeless: just got into the habit now have having trees in ~sr
[20:55] <thumper> c
[20:55] <thumper> the trees in the repo aren't really an issue AFAICT
[20:55] <thumper> the parent branch for the existing juju-core branch is:
[20:55] <thumper> http://bazaar.launchpad.net/~gophers/juju-core/trunk/
[20:55] <thumper> why did reconfigure fail?
[20:55] <thumper> abentley: standalone tree
[20:56] <abentley> thumper: There's no reference to bzr+ssh://bazaar.launchpad.net/~thumper/juju-core/trunk/ in the "bzr info" output?
[20:56] <thumper> not that one, no
[20:56] <thumper> however...
[20:56] <thumper> ah...
[20:57] <thumper> that is the public branch specified for ~/src/juju-core/trunk
[20:57] <thumper> using my append path policy
[20:57] <thumper> the parent branch is  bzr+ssh://bazaar.launchpad.net/+branch/juju-core/
[20:57] <thumper> why is reconfigure looking at the public branch?
[20:58] <thumper> but ~/src/juju-core/trunk is a repository tree
[20:58] <abentley> thumper: It's been a few years since I wrote that.  Can you run reconfigure with -Derror so I can see where it's dying?
[20:58] <thumper> sure
[21:00] <thumper> abentley: http://paste.ubuntu.com/1653507/
[21:02] <thumper> abentley: perhaps I should just specify a public branch for the branch at ~/src/juju-core/trunk ?
[21:02] <thumper> abentley: but I'm not sure why it is even looking
[21:02] <abentley> thumper: So, I can delve into why, but by specifying --bind-to will override it, and you probably want that anyway.
[21:03] <thumper> abentley: ah...
[21:03] <thumper> didn't notice that
[21:03] <thumper> now it kinda makes sense...
[21:04] <thumper> oh...
[21:04] <thumper> NotBranchError: Not a branch: "/home/tim/go/src/launchpad.net/juju-core/~/src/juju-core/trunk/"
[21:04] <thumper> abentley: I can fix that one by providing a full path
[21:04] <thumper> but probably a bug
[21:04] <abentley> thumper: What was the commandline?
[21:04] <thumper> bzr reconfigure -Derror --lightweight-checkout --bind-to=~/src/juju-core/trunk/
[21:05] <mwhudson> yay bash!
[21:05] <abentley> thumper: ~ interpolation is done by the shell, which I guess wasn't smart enough to expand it in this case.
[21:05] <mwhudson> uh
[21:05] <mwhudson> no
[21:06] <mwhudson> oh yes, that is the problem
[21:06] <mwhudson> but bash is stranger than i thought:
[21:06] <abentley> thumper: bzr reconfigure -Derror --lightweight-checkout --bind-to= /src/juju-core/trunk/ should work.
[21:06] <mwhudson> mwhudson@narsil:highbank-support$ echo a=~/.bazaar
[21:06] <mwhudson> a=/home/mwhudson/.bazaar
[21:06] <mwhudson> mwhudson@narsil:highbank-support$ echo a-a=~/.bazaar
[21:06] <mwhudson> a-a=~/.bazaar
[21:06] <abentley> Or omit the = even.
[21:06] <thumper> mwhudson: wat?
[21:06] <thumper> that seems weird
[21:06] <abentley> i.e. bzr reconfigure -Derror --lightweight-checkout --bind-to /src/juju-core/trunk/
[21:07] <abentley> grr, where'd the ~ go?
[21:07] <mwhudson> thumper: i think it's so that you can write "a=~/foo"
[21:08] <abentley> bzr reconfigure -Derror --lightweight-checkout --bind-to ~/src/juju-core/trunk/
[21:08] <mwhudson> thumper: but yes, "wat"
[21:08] <thumper> abentley: ok, ta
[21:08] <thumper> now I just have the sync question...
[21:08] <thumper> in #juju-dev
[21:35] <thumper> $ bzr switch -b help-command
[21:35] <thumper> Tree is up to date at revision 894.
[21:35] <thumper> Switched to branch: /home/tim/src/juju-core/help-command/
[21:35] <thumper> awesome!
[21:35] <thumper> I love bzr
[21:36] <thumper> it's all working lovely jubley