[00:00] fta: just commit them [00:00] fta: then pull them onto B, uncommit, and keep editing [00:01] i used to do that but it's not very handy [00:02] fta: what would you like to be able to do [00:02] ? [00:03] both A and B push to a central repository (not a working tree), so i have to uncommit there :( [00:03] well, you can just push --overwrite [00:03] when you're done on B [00:03] or push to a temp branch in the central repo, rather than your trunk [00:04] but if someone else pushed on central, it breaks [00:04] use a temp branch for sure then [00:05] i would like to export uncommitted changes from A to B or vice versa, without going to central, yet with preserving the resolve/conflicts facilities [00:05] merge --uncommitted would do that. [00:05] (though you can get ugly going back and forth with it; doing it once would be reasonable) [00:06] It would similarly benefit from a super-shelf that used real revisions to hold the shelved stuff. [00:06] A and B are owned only by the same user, central is shared [00:06] fta: I have a repo on a thumb that I commit to ; if I need to put that in a central repo I push from there [00:07] fullermd: Isn't "loom" a sort of super-shelf? [00:07] fta: uncommitted changes have no real representation in bzr [00:07] other than 'working tree' [00:07] fta: do you have NFS or similar between these two machines? [00:08] I think there is a valid use case here, in two different dimensions, but we don't have a good offering today [00:08] and it will take thought to avoid making a bad one :P [00:08] the two dimensions are collaborative conflict-resolution-in-N-steps [00:08] i used commit/uncommit/push override for a while, i ended up with lost commits. i also used scp/rsync between A and B, better but not very handy. [00:09] and helping people deal with transient commits more easily, I feel the two combined would do what you want [00:10] jam: so did I get a review of log ? [00:10] lifeless: I certainly hope so [00:10] I did it last night [00:10] ah yes found it [00:10] thanks [00:11] I've done one of your btree patches [00:11] other shortly [00:11] fta: merge --uncommitted would be much more handy than scp/rsync... [00:11] lifeless: I didn't get a chance to play with the toy, I've been debugging the fetch issues [00:11] jam: I integrated bzr-search with my patch last night - bzr log -m "\brobert\b" went from 12 seconds to 4 seconds [00:11] nicely done [00:12] awilkins: Not really, especially if you're not already using looms and on top of one... [00:12] jam: primary fetch issue is no streaming verb [00:12] jam: that I know of [00:12] (I mean, other than being-silly-with-object-lifetimes) [00:12] yeah, but there are oddities in the specifics [00:12] branch locally is 2+ times faster [00:13] fta: How about * Branch to no-trees repo in USB thumb * A and B take checkouts of branch in thumb * commit when changing location and take thumb with you * update at the location you moved to * keep working ? [00:13] fullermd: thanks. i'll give it a try for a while. thing is i'm an avid user of --remember so push/pull/merge are going to central by default.. merge --uncommitted will force me to specify A or B each time. [00:14] fta: Aliases and/or the bookmarks plugin can be a help there. [00:15] fta: This works well for me (I was pushing and pulling between network shares on my laptop and desktop for a while and I too got my knickers in a knot) [00:18] jam: try with btrees :P [00:20] awilkins, i'm not organized enough to depend on usb ;) it will stay connected on the other side, or i will simply forget. I expect bzr to do that for me as i can reach always reach A from B (reverse is not true) [00:20] fullermd, yep, one more alias, i like that [00:22] fta: How about keeping the branch on A and taking a checkout of it on A and B [00:22] If you use a heavy checkout you can still commit to one offline and merge it later [00:36] Here's one - operations on network shares on windows are treated just like local filesystems ; to the point where the client will do things like copy files from the tree rather than unpacking them from the content texts ; copying from the tree is slower over a network drive in many cases [00:36] It will also do heinous things like repacking an 11MB repo over a 256KBit/s link [00:37] you're using smb over adsl? [00:37] bob2: VPN [00:38] bob2: and cable not DSL (256 kbit is my upstream) [00:40] Short of setting up an HPSS (or even just SFTP), would it be possible to have a --network option or similar that had it do things like * not update remote tree when pushing * not repack * not copy files from remote branch but unpack them from local content texts [00:40] Well, if it helps, it would repack the 11MB repo over a 256Kb link if you were using SFTP too ;) [00:41] fullermd: That's nasty too :-) [00:42] I had the Windows bzr+ssh support all nicely patched and IT services refused to open port 22 [00:42] Alas, I've not quite cracked HPSS over IIS 6 (works nicely with IIS 7) [00:42] Well, it would repack the 11MB repo over a 256Kb link with bzr+ssh too... I mean, how consistent can you GET! [00:43] Yes, but the repack happens locally with an HPSS [00:43] No it doesn't. [00:43] Urgh! [00:43] You mean even on HPSS it pipes 22MB of data to the client? [00:43] (and from [00:44] Oh, no. I'm sure there's enough missing entropy that it can compress down to 21.5MB or so. [00:44] Surely that's a bug - it's hardly high-performance-optimized if the thing is asking the client to do all the work and abusing its bandwidth [00:45] FSVO 'bug'. [00:45] What happens if you access a MySQL repo over bzr+ssh and it decides to repack? Grit your teeth and wait a day? [00:46] (AFAIK you can just abort and nothing is hurt) [00:46] yes [00:46] Yuck [00:46] Well, if you get a big enough repo, you'll only ever have to do it once, 'cuz a repack verb (or better, elimination of a need for one) will have been added before it finishes... [00:47] hahaha [00:47] Why the hell would a client get to decide that the server needs to repack? [00:47] Screw repack verb, it's the servers job to manage it's own damn storage [00:48] That's crazy talk. Next you'll be saying the client shouldn't have to understand the low-level details of the server's repo format. [00:48] You could just have the server play back bzr-fast-export tapes :-) [00:49] Heck, you could write bzr HPSS servers for git [00:49] * fullermd summons jelmer :p [00:49] * awilkins summons Bahamut [00:49] See, if bzr-git just gets fast enough, we can just use central git repos and avoid all that unnecessary HPSS work. [00:50] * fullermd repacks a repo while waiting for the cutscene to finish. [00:50] you just need a hpss-optimisation montage [00:50] * awilkins takes 7 damage [00:51] Gotta remember to stop by a commit-point. [00:53] * awilkins takes a USB key and commits in the field [00:54] awilkins: spiv has a patch to repack remotely [00:54] Is it part of HPSS? [00:54] awilkins: but note that repack only repacks small packs most of the time; to repack the deep history of mysql you need to commit 10 times as many revisions as there are already [00:54] awilkins: yes, but not merged to bzr.dev yet [00:55] awilkins: so, to trigger a repack of the deep mysql history, commit, oh, 500000 times [00:55] I have a branch I'm using to deploy .jar files ; it only has about 10 revs and it go repacked into one pack over the VPN which is my 11MB case :-) [00:56] awilkins: ok, the next repack of those 10 will occur at 100 revs [00:56] and then at 1000 [00:56] I hope the deltas are nice and small now then, it's mostly one 1.2 MB jar that's changing incrementally [00:57] Would you get better packing by unzipping archives and them packing them> [00:57] a zip compresses badly unless you use --rsyncable, and as we don't use rdiff, we don't gain much then (though we may gain some - I haven't tested) [00:57] jars are zips [00:58] (delta compress obviously) [00:58] so yes, deltaing the contents would probably be a size win; though .java files may be questionable etc [01:04] * AfC wonders a bit why someone would ship .jar files with a version control system (unless this is a matter of using it to deploy artifacts to a production system, but even then) [01:05] Because it's easier to just have my users `bzr pull` than expect them to download an archive, unpack it, and not wipe out any of their own little scripts and things [01:08] Some of the stuff ronny brought up would be nice to have in bzr... like repo-level pull/push, and the ability to make new branches implicitly (like... "hg up -r 123 ; hack hack; hg commit" would make a new head) [01:08] A repo-level vis tool would be nice too. [01:09] I thought extending switch would be good [01:10] Let switch also push a new branch [01:10] bzr switch bar --branch [01:10] Instead of switching branches in-place like in that .wmv earlier, I find myself keeping an 'active' symlink in the repo to point at the branch I want to use. That doesn't quite work the same, though. [01:10] bzr switch bzr --branch -r 123 [01:11] hm, how about bzr switch --create newbranch? [01:11] THat might be clearer [01:11] fullermd, seems i can't merge --uncommitted from a bzr+ssh url [01:12] what's the rationale for not just commiting all these changes? [01:12] fta: sftp may work [01:12] not wanting them to show up in logs? no automatic handling of syncing multiple branches? [01:13] awilkins, same, "is not a local path" [01:13] awilkins: branch --switch would be my preference [01:13] ToyKeeper: bzr viz can do multiple branches [01:13] Oh, I forgot about that. WT access doesn't work remotely... [01:14] Well, so much for THAT beautiful idea. [01:14] that would be complicated with branch's existing positional arguments [01:14] ToyKeeper: but repos are just storage access, not semantic; I can buy 'viz all branches under URL' [01:14] lifeless: Would you include the current "sibling" logic that's in switch ; this seems to be something that those git people really like, the one-element-name of branching [01:14] bzr branch --switch . ../newfeature, and loses switch's "sibling" support [01:14] awilkins: yes, there is a bug open to propogate that [01:14] also, are you aware of cbranch [01:14] which already does much of this [01:15] No [01:15] ToyKeeper: we have 'repo' level push/pull with multi-push/multi-pull [01:16] cbranch is not mentioned on the BzrTools page [01:18] * markh hopes to hear someone lamenting the lack of a -r option to 'bzr up'... [01:18] * awilkins found that really counter-intuitive after using SVN for so lon [01:19] me too - and I have a patch - which is why I'm hoping to hear someone complain ;) [01:24] I resurrected a patch that was initially targetted at version 1.3! I fear it will similarly languish now... [01:26] would it do that in response to 'bzr up -r'? ;) [01:26] Oh, yeah, we need a VSS mode. %bzr commit Warning: This setting will store your changes without any corruption. Are you sure you want to proceed? (y/n) [01:26] lifeless: bzr+ssh:// uses the _create_pack_from_packs code, isn't that the same as local? [01:27] actually, my first response to a merge was "OMG, why does bzr think 1/2 this file is in conflict?". lifeless kindly then pointed out '--reprocess' which has become invaluable for me [01:28] I liked the merge I did from a branch that didn't even have a shared ancestry (but was a very similar tree) :-) [01:32] I've seen the awesomeness of bzr merging since then ;) [01:32] My users are getting to like it [01:46] Time for sleepsicles [01:50] markh: if its not in bundlebuggy, it won't get reviewed [01:51] being attached to a bug report is essentially useless [01:51] ok, I'll try that - thanks [02:02] jam: were you happy with my reply-to-your-review? [02:11] jml: please send your addCleanup improvements to bzr, or is that done ? === bigdog is now known as _bigdog [02:12] is there an operator.attrsetter I wonder... [02:13] bope [02:13] nope [02:13] there should be [02:13] Hmm, speaking of not using launchpad features... where should I send changes to bzr-merge-into? [02:14] functools.partial + setattr! [02:14] oh eep [02:14] lifeless: they were approved, but maybe not landed? [02:15] It appears to be jam's plugin, but I'm not sure what he uses for merge requests. [02:15] lifeless: I don't have commit privs. [02:15] self.addCleanup(functools.partial(setattr, bzrlib.btree_index, '_PAGE_SIZE'), original_size) [02:15] bob2: ^evil [02:16] ToyKeeper: I'd file a bug and attach a branch and propose for merging [02:16] I did. [02:16] cool === toytoy_ is now known as toytoy [02:17] It was a month ago, and there was no response, so I thought maybe it needed to go through BB or some other channel. [02:17] oh [02:17] hey may not be subscribed to the branch; when reviews were added that was not set as the default [02:18] drop him a mail ;) [02:18] ... just came to mind because of the mention earlier about not attaching patches to bug reports. :) [02:19] ToyKeeper: yah, plugins are not all in BB though [02:19] I saw some merge-into work last week or so [02:19] possibly he just missed your patch? [02:20] lifeless: do you want me to chase up whether the patch landed or do you want to? [02:20] jml: no need [02:20] ok. [02:20] * jml goes away [02:20] 11:15 < lifeless> self.addCleanup(functools.partial(setattr, bzrlib.btree_index, '_PAGE_SIZE'), original_size) [02:20] ^ thats too evil anyhow [02:23] Hmm, the last rev looks like it implements part of what I changed. I'll bug him about it later. [02:29] ToyKeeper: I certainly don't remember seeing any patches/branches for bzr-merge-into [02:29] lifeless: Your response to the log review was fine [02:30] lifeless: I would like a little bit more feedback on the btree stuff [02:30] jam: https://bugs.launchpad.net/bzr-merge-into/+bug/252188 [02:30] Launchpad bug 252188 in bzr-merge-into "subdir is always from repo root, not current dir" [Undecided,In progress] [02:30] ToyKeeper: hm... never saw that one. But I think it is already "fixed" [02:30] when I changed it to support the "canonical" form [02:30] ToyKeeper: can you check? [02:32] ToyKeeper: I think I did it by doing "WT.open_containing(join(this_location, subdir)) rather than the other way around [02:33] which also lets you do [02:33] jam: Just checked, and trunk r7 seems to fix that issue. [02:34] I fixed a couple other things too: I made the subdir parameter optional (default to basename of LOCATION), and added missing '\n's on the output. [02:34] jam: well, I'm happy - thus the :tweak [02:35] I've replied and said roughly that [02:35] lifeless: sure, just trying to get some ideas about how to actually update it [02:35] righto [02:35] uhm, see if my mail helps [02:35] otherwise, I'm probably missing what you're asking :) [02:36] ToyKeeper: sure, I'll merge it and then revert out the one change, it will probably conflict anyway [02:37] ToyKeeper: did you ever "request a review" ? Or just propose it for merging? [02:37] lifeless: And BB is still much better for code reviewing, as you can see the whole diff [02:37] jam: you're probably not subscribed to the branch fully [02:37] Though I guess abentley is improving that [02:37] jam: yeah it is [02:38] lifeless: yeah, I just "subscribed" to my branch [02:38] ToyKeeper: though you didn't add tests for your functionality :) [02:39] Hmm, I haven't used LP's code review features much yet. I thought making a merge request automatically requested review from the owner of the target branch. [02:42] well, it would probably send me an email if I was subscribed to the branch [02:42] (which i am now) [02:42] but it isn't quite the same [02:42] request-review is a bit more focused on a specific person to review [02:42] as opposed to "anyone who is around" [02:43] anyway, your changes are merged [02:44] I know they're pretty trivial changes... I had forgotten all about it until lifeless said something to remind me. [02:46] Anyway, thanks for the plugin. It's handy. :) [02:47] Now I just need a way to do the opposite of merge-into... split a subdir into a new branch with only that subdir's history. [02:47] ToyKeeper: with or without rebasing? [02:47] There is already "bzr split" which is a core command (it may only be exposed if you have -subtree formats) [02:48] But it still preserves *all* history [02:48] as you can't do otherwise without regenerating the history for those files [02:48] Doesn't matter to me. 'bzr split' plus 'bzr remove-revision' would be fine, except the latter doesn't work. [02:49] i don't know what 'remove-revision' would even be trying to do [02:50] It's at http://people.samba.org/bzr/jelmer/bzr-remove-revisions/trunk/ [02:51] ToyKeeper: that wouldn't do what you want anyway [02:51] It is only a "garbage collect" for unreferenced revisions [02:51] these are all referenced [02:51] Ah. [02:51] as part of the history of the split out branch [02:52] You would really need to rebase, in which case the split out project could no longer be merged back into the old project [02:52] which is still good enough for what some people want [02:52] it wouldn't be strictly hard to do, though you have to get a little bit tricky at merge times [02:52] Well, if you rebuilt the history with the same file-id's, you could do a null-merge right off the bat, and it would work going forward. [02:53] fullermd: yeah, I think so, but I wouldn't bet on it :) [02:53] Well, I've used --file-ids-from to do similar things on a smaller scale. [02:53] Yeah. I just wanted to break a branch into pieces, because it included things which shouldn't have been together. [02:53] lifeless: your final review is what I was looking for, thanks [02:54] ToyKeeper: then again, it would still be in the history of the parent project, unless you regenerated all of *those* revisions [02:55] jam: cool [02:56] I've occasionally seen svn people put every project into a giant shared repo, with /repo/trunk/project*/... seems better to do one repo per project instead. [02:57] I ran into something like that in bzr, and wanted to split the projects into completely independent repos. [03:15] I'd really like to be able to do bzr search -s "foo -bar" [03:15] but I need to think some more about how to do that elegantly [03:15] food first [03:16] lifeless: would you want a way to "refine" searches interactively [03:17] jam: like loggerhead does ? :) [03:17] union, intersection, etc [03:17] give me the revisions that match X [03:17] and then the subset that also match Y [03:17] meh, I meant to type 'bzr log -s "foo -bar"' [03:17] and as you mentioned [03:17] but *don't* match bar [03:18] jam: I am happy with google level complexity in the searches [03:18] jam: which is not much [03:18] jam: 'bzr search robert -collins' already works [03:18] back in 10, must eat food [03:33] so [03:34] jam: bzr search - I want to grow search types of date: (with before/after) and revision: etc, as well as handling NEWS and src/Makefile.am to match paths [03:34] ETIME [03:43] jelmer: what is "bzr svn-branching-scheme" for exactly? :) [03:43] rocky, it's what determines what in the repository bzr-svn considers a branch (a place where bzr revision can be found) [03:44] changing it will break your existing imports though (you'll get DivergedBranches errors) so you'd want to stay away from it [03:44] it'll be replaced by something simpler in 0.5 [03:44] well, the output from: bzr svn-branching-scheme https://dev.serverzen.com/svn/cluemapper/ClueMapper shows just ClueMapper which is odd since ClueMapper isn't a branch [03:46] rocky, it determines what branching scheme it'll use based on what location you branch [03:47] you'd probably want "bzr svn-branching-scheme https://dev.serverzen.com/svn/cluemapper/ClueMapper/trunk" [03:47] since you're branching trunk [03:47] right === wantok is now known as kgoetz [05:49] man [05:49] I want marks so bad [05:50] * lifeless starts on marks [05:50] * RAOF_ ponders what "marks" could mean in a lifeless-bzr context... [05:50] is it missing an apostrophe and "lovely hair" ? === RAOF_ is now known as RAOF [05:52] https://lists.ubuntu.com/archives/bazaar/2008q3/044481.html [05:53] * RAOF brushes his lovely hair. [05:53] Shoulder length or longer? [05:54] About sholder length. Slightly longer. [05:57] lifeless: (ref 'marks' vs hair) - sounds (hand wavy) loosely like my experience with svn merge conflict handling via eclipse? Sorta thing. ??? [05:57] * RAOF contends that his internet will _eventually_ connect to lists.ubunut.com. [05:58] ubunut ? [05:58] Yeah. It's like ubuntu, but for squirrels. [05:58] cool [05:59] So there are lots of long-term support releases, but you can't remember where you buried them? [05:59] spm: I don't know what your experience is [06:03] lifeless: marks? [06:03] Heh. [06:03] oh, link [06:03] * jml reads [06:04] Yes! I have lists.u.c connection. [06:14] jml: what do you think [06:15] lifeless: I think you should have someone who follows you around finishing the awesome stuff you start :) [06:16] That does look rather cool. [06:17] jml: that would be nice [06:17] lifeless: the design looks pretty good to me. [06:18] lifeless: IIUC, there are multiple named subsets of changes, one of which is selected? [06:19] some of which are [06:19] -Mreviewed,tests [06:20] lifeless: right, so what I mean is that I could select the 'tests' set of changes? [06:20] yes [06:20] or exclude it [06:21] right. [06:21] I'd love a web review ui for this [06:21] * jml is busy on other Bazaar hosting issue [06:21] *issues, rather [06:22] well [06:22] it needs core code first [06:22] but as an end goal [06:22] imagine going to launchpad [06:22] doing half a review [06:23] yeah, that'd be sweet. [06:24] or in emacs [06:29] ya [06:53] lifeless: the plugin I should use to perhaps improve my push speed, what was it called again? [06:59] index2 [06:59] which needs pybloom as well [08:54] folks, probably i dont write it right, but I can't create a branch... i use the following syntax: bzr branch trunk/ tags/version1.6 [08:55] and what happens? [08:56] in windows bzr: ERROR: Not a branch: "D:/MyProject/MyProject/" [08:56] well, is it a branch? [08:57] I have no idea, I'm a newbie :) [08:57] I init-ed the project [08:57] and commited it [08:57] ok [08:57] now I want to create a branch [08:57] where did you init ? [08:57] in the directory containing trunk/ [08:58] so the directory containing trunk is your first branch [08:58] init creates a branch [08:58] (the first one in a project) [08:58] so how do I create a branch tags/version1.6? [08:59] bzr branch tags/version1.6 [08:59] what does bzr info show ? [08:59] ok, parent of bersion1.6 doesn't exist [09:00] after I create the dir tags, to I add it via bzr add? [09:00] no [09:00] then I just md and create the branch? [09:01] loxs: reading of http://doc.bazaar-vcs.org/bzr.dev/en/user-reference/bzr_man.html#concepts might help you [09:02] I read that, but it's quite general :( [09:02] loxs: yes, you mkdir dir tags if it doesn't exist [09:02] loxs: then branch tags/version1.6 [09:04] and when I commit, the version1.6 branch won't go to the central repo? [09:04] hm, I think I start to understand the concepts now [09:04] ok, thanks folks [09:05] it's not svn ;) [09:07] yeah, i'm starting to realise it gour :) [09:08] loxs: yesterday, i tried for the first time bzr-svn...it's great. now i can use bzr to fetch from svn repos :-) [09:08] loxs: it's much more flexible when you get in. you'll see. good luck ;) [09:09] thanks :) [09:09] hey all, is there an equivalent to "svn status -u"? I want to see the changes on the remote branch before I pull them [09:10] for bazaar, of course :) [09:17] shodges: I'm not entirely sure what 'svn status -u' does. 'bzr missing' will give you the log between the current tree and the remote tree, though. [09:18] (bzr missing will check against the default pull branch, or you can 'bzr missing $OTHERBRANCH') [09:19] RAOF: or diff -rbranch:other [09:19] shodges: or status -rbranch:other [09:22] missing might be the right thing... [09:22] thanks everyone, i'll have a play around [09:34] ok i've had a go, bzr missing is definitely useful, but what I want right now is something that will tell me which files have been modified, rather than the pending commits [09:34] shodges: 'bzr st -rbranch:URL' [09:35] shodges: as I said before :P [09:36] yeah i thought so too lifeless, so i tried bzr status -rbranch, and i it threw a nasty stacktrace [09:36] really? [09:37] i typed: "bzr status -rbranch:../test/src" [09:37] which is a modified local branch i created for testing this out on [09:37] can you pastebin the traceback? [09:37] sure can, just a sec [09:39] this is the traceback: http://pastebin.com/d29ae0346 [09:41] shodges: can you upgrade bzr? [09:42] gour: will not help [09:42] it's an old bug [09:42] (design issue) [09:42] luks: using absolute path? [09:43] no, -rbranch: is broken [09:43] ahh [09:43] gour, i tried an absolute path as well, same output [09:44] * gour wonders why would lifeless recommend it then [09:47] i could try upgrading bazaar, but would i assume if the break is in my .bzr index then it will still throw the same error? [09:47] I found a work-around: bzr merge --preview ../test/src | grep "===" [09:47] not elegant, but does the job [09:54] shodges: at least, you can create alias for it :-) [09:56] good idea gour :) i like "bzr missing" tho, will find them both useful in the future [09:56] thanks for the help everyone [10:00] hmm [10:00] Its not a design bug [10:00] just needs to be fixed [10:01] either by upgrading the lock, allowing status to read from two sources, or similar === jrydberg_ is now known as jrydberg [10:05] lifeless: http://thread.gmane.org/gmane.comp.version-control.bazaar-ng.general/35853 [10:06] FF just bit it [10:06] I only saw the start of the page [10:06] jam had a similar fix for it, never merged too [10:07] I'm personally surprised that broken code is considered better than working code, even if following a bad design, but it's not my decision :) [10:07] uhm [10:07] you have a choice of break [10:07] broken on read only media [10:08] and broken when pull-is-needed [10:08] so its not 'broken vs working' [10:08] its 'broken in case A vs broken in case B' [10:08] and I think you're being rather judgemental saying the design is broken, when its not clearly a design issue [10:08] hello #bzr [10:09] lifeless: I was told that by jam and abentley [10:09] lifeless: the code needs to be rewritten to allow reading from remote repositories [10:09] I've got a branch, and I want to take one of the revisions and get rid of it. [10:10] luks: uhm I don't know if you're aware, but saying 'bad design' provokes a certain response [10:10] which is either agreement, or defense. I think the design is fine, thus you are getting defense [10:10] if you have a specific issue in the design, that would be worth talking about [10:10] jml: tip ? [10:10] lifeless: if two core devs tell me that it's was a bad choice to allow write operation on RevisionSpec, then I think it is a bad design [10:11] lifeless: is that a plugin? [10:11] jml: no, I'm asking if the revision is the tip revision [10:11] lifeless: oh, no. [10:11] in which case rebase is probably your easiest bet [10:11] lifeless: I know about uncommit :) [10:11] there was a thread recently [10:12] * jml searches [10:12] luks: you've just doubled the granularity from 'bad design' to 'write operations on revisionspec is a bad design choice' [10:12] thats massively more informative [10:12]