| Noldorin | fullermd, incidentally, how exactly are pull and update related? they seem to do very similar things | 00:01 |
|---|---|---|
| fullermd | pull changes a branch (and possibly its WT) to match another branch. update changes a WT to [some rev along] its branch. | 00:04 |
| Noldorin | fullermd, ah. both do a merge though no? | 00:06 |
| fullermd | Not in the sense of the "merge" command. | 00:06 |
| fullermd | update does a merge in the conceptual sense, in that it tries to bring forward any uncommitted changes relative to the previous base rev to the new one. | 00:07 |
| fullermd | (and pull's internal 'update' if there's a WT does the same) | 00:07 |
| Noldorin | fullermd, ah so pull automatically does an update if there's a WT? | 00:07 |
| fullermd | Well, except the wacked-out bound-branch --local case, where it does crazy things to screw with you. | 00:07 |
| fullermd | But you asked for it, so you deserve it. | 00:08 |
| Noldorin | ha | 00:08 |
| Noldorin | fullermd, what's bound-branch --local case? :P | 00:08 |
| fullermd | Conceptually, yes. | 00:08 |
| Noldorin | hmm? | 00:08 |
| fullermd | ... you're probably too young to be told about it. | 00:08 |
| Noldorin | ha | 00:08 |
| Noldorin | i can handle it, try me! | 00:08 |
| fullermd | Y'know that feeling where you cough so hard your liver ends up dangling out of your mouth? It's kinda like that, except with version control. | 00:09 |
| Noldorin | nope… i'm pretty sure that's anatomically impossible! | 00:09 |
| fullermd | Exactly. | 00:09 |
| Noldorin | ha | 00:09 |
| Noldorin | fullermd, so if i just stay clear of it i'll be happy and missing out on nothing? | 00:10 |
| fullermd | Sadly, bzr's anatomy got rewired once so that it's possible. | 00:10 |
| Noldorin | heh okay | 00:10 |
| fullermd | Yes. Never ever type "ci" and "--local" at the same time. If you see anybody else do it or advocate it, beat them to death with a baseball bat. It's the only merciful thing to do. | 00:10 |
| Noldorin | and also, what's the diff between update and revert now… is it just that update chances the current revision number too? | 00:10 |
| Noldorin | heh okay, i will trust you on that | 00:11 |
| fullermd | Two... three... some number of things. | 00:11 |
| fullermd | First, yes, update changes the WT's idea of what rev it's based on; revert doesn't. | 00:11 |
| fullermd | Second, revert only puts a file/files exactly to the state of the given (or implicit) rev, not attempt to merge outstanding changes like update does. | 00:12 |
| fullermd | Third, update only makes sense on the whole WT; you can't update just one file. | 00:12 |
| fullermd | So update is more for things like "Hey, I want to step back and see what things were like in rev X". | 00:13 |
| fullermd | Whereas revert is more for cases like "throw away these changes I've made since last commit", or "stage up changes to this file to move it back to the state it was in at rev X" | 00:14 |
| fullermd | i.e., "bzr revert -rX file" is pretty much like "bzr diff -rX file | patch -R" | 00:14 |
| fullermd | (ignoring cases of renames etc) | 00:14 |
| Noldorin | ah | 00:15 |
| fullermd | There are a lot of cases where you _could_ use either, but the unfitting one is likely to make things squirrely down the line. | 00:16 |
| Noldorin | fullermd, but you said revert puts the file in the same exact state as the file at the specified revision? | 00:16 |
| Noldorin | squirrely. haha. got it | 00:16 |
| fullermd | Yes. | 00:17 |
| fullermd | An alternate expansion (again ignoring complications from renames) would bzr "bzr cat -rX file > file" | 00:17 |
| fullermd | Dur. "would be". Eye khan tipe. | 00:18 |
| Noldorin | fullermd, you just audibly ran together the be and the first syllable of bzr. understandable ;) | 00:20 |
| Noldorin | fullermd, okay… so does it warn you if the file has uncommitted changes? | 00:20 |
| Noldorin | or what | 00:20 |
| fullermd | No. After all, the overwhelming majority of uses are of the "throw away my uncommitted changes" variety. | 00:20 |
| fullermd | I can't remember the last time I used -r on revert. But the last time I used revert with no -r was less than an hour ago. | 00:21 |
| Noldorin | makes sense | 00:23 |
| Noldorin | fair enough | 00:23 |
| Noldorin | fullermd, thanks :) | 00:23 |
| Noldorin | fullermd, oh yeah, and last thing: i see trees mentioned every once in a while in relation ot bzr… i know what working trees are, but what about trees in general? | 00:24 |
| fullermd | Usually people mean the same thing. | 00:25 |
| fullermd | Sometimes you'll run into some propellerhead using it to talk about an internal data structure. | 00:25 |
| lifeless | flap flap flap | 00:26 |
| Noldorin | lifeless ? | 00:27 |
| Noldorin | fullermd, i see | 00:27 |
| Noldorin | fullermd, so what about these split/join commands that work with trees? | 00:28 |
| Noldorin | and yeah i know about tree data structures. assumed it wasn't them. :) | 00:28 |
| fullermd | join is a shortcut to merge-into-subdir (a previously unrelated branch) | 00:28 |
| fullermd | split is a shortcut to "branch ; rm everything else ; mv to root ; commit" | 00:29 |
| fullermd | (they're not really complementary operations, naming suggestiveness aside) | 00:29 |
| Noldorin | fullermd, oh cool. wish the help was that clear. i get it now | 00:29 |
| Noldorin | wish the help were* | 00:29 |
| fullermd | Well, you wouldn't want it to put me out of a job, would you? | 00:30 |
| Noldorin | of course not ;) | 00:30 |
| fullermd | Think what would happen to me standard of living if, say, I only got paid HALF as much to hang out on IRC. | 00:30 |
| Noldorin | fullermd, then you wouldn't be able to live the high life any more either! | 00:30 |
| Noldorin | ^ | 00:30 |
| Noldorin | heh | 00:30 |
| lifeless | fullermd: they aren't complementary? They reverse each other.... | 00:31 |
| fullermd | No they don't. If you join a branch in, then split it off, you don't get anything at ALL like the old branch. | 00:34 |
| lifeless | fullermd: oh? | 00:35 |
| fullermd | It gains like 2 kadnillion pounds, and the mainline history is completely different. | 00:35 |
| fullermd | (and those pounds are NEVER coming off, man! Even if Noldorin gets that gc command written!) | 00:35 |
| lifeless | fullermd: so the weight gain is directly analogous to an add/delete pair | 00:35 |
| lifeless | fullermd: however the mainline history is an interesting point | 00:36 |
| Noldorin | hah | 00:36 |
| lifeless | fullermd: since there can be only one at the joined point | 00:36 |
| fullermd | Also, if you ever go back and 'merge' that branch into the one you just did the join/split from, it's gonna delete everything. | 00:36 |
| lifeless | both operations drive time forward, yes. | 00:37 |
| lifeless | they are tree shape operations, not history edits. | 00:37 |
| lifeless | Both could be expressed as history edits. | 00:37 |
| fullermd | I guess you could call them complementary in that one kinda does the "opposite" of the other, but it doesn't do the "reverse" of the other, which is easy to misinfer from the names. | 00:42 |
| lifeless | so undo in every case is 'pull -r -2 . --overwrite' | 00:43 |
| lifeless | gc isn't semantic | 00:44 |
| fullermd | An extra sticky point is that split doesn't do what a lot of people would automatically think it does either. Not that I think it reasonably could, but it's a training wart. | 00:44 |
| fullermd | That's why it wouldn't take the pounds off 8-} | 00:44 |
| lifeless | so yeah, split isn't filter | 00:45 |
| lifeless | filtering is a history edit | 00:45 |
| lifeless | splitting isn't | 00:45 |
| fullermd | Yeah. Whereas on the "join" side, there's not so much confusion among things you could think of it as doing. | 00:45 |
| lifeless | I think split and join would be more clear if they only manipulated the current tree; I don't recall exactly whether they do or don't. | 00:46 |
| fullermd | Mmm, I dunno. split sorta has to make a new tree anyway to do its job. Or a new branch, at least. I s'pose in theory it could be implemented to not change the current tree/branch at all, and just make the new one --new-branch /somewhere/else | 00:47 |
| fullermd | But I think most uses of it would then go ahead and wax that subdir from the original branch anyway. | 00:48 |
| fullermd | And join, well, it _could_ leave that subtree/.bzr there, but that just means that 'ci' starts acting differently depending on where you are in your now-whole project. | 00:48 |
| fullermd | I think it's just an explanatory/training issue. I like making the non-complementary (not necessarily in those words) point just so it's easier to explain this command, and then that command. | 00:49 |
| fullermd | Rather than "this pair of commands", which I think confuses things more. | 00:50 |
| lifeless | fullermd: split doesn't have to make a new tree | 00:55 |
| lifeless | fullermd: it can be define in two parts; 'remove subtree' which is well known (rm -r) and 'promote a subtree to the root' which is this-tree-only. | 00:55 |
| lifeless | fullermd: join can just setup the tree ready to commit - do the merge etc | 00:56 |
| fullermd | It does, I think. | 00:57 |
| fullermd | Yep. | 00:57 |
| fullermd | Actually, looks like split doesn't create any of the revs either, just does the pre-manipulations. | 00:58 |
| fullermd | (leaving you two trees with uncommitted changes) | 00:58 |
| lifeless | good | 00:59 |
| lifeless | so, I don't see any reason they can't be complementary. It's what happens if you commit in the middle that is hairy :) | 01:00 |
| fullermd | You've been wallowing in git too long, soaking up that rancid "auto-commit merges" oil ;) | 01:00 |
| lifeless | fullermd: eww, I still hate that | 01:01 |
| lifeless | fullermd: I embrace history editing now; but then I embraced that before I stopped hackin on bzr (e.g. my manifesto on it...) | 01:01 |
| fullermd | I saw a thread on the git list just the last few days about a merge proposal (whatever they call it) to default-disable non-ff 'pull's too. | 01:01 |
| lifeless | yay | 01:02 |
| lifeless | that will avoid lots of omfg experiences | 01:02 |
| fullermd | http://thread.gmane.org/gmane.comp.version-control.git/233554 | 01:04 |
| fullermd | (I haven't watched it close enough to tell if it's going to land or not) | 01:05 |
| Noldorin | fullermd, interesting. bzr branch seems to do garbage collection already | 01:26 |
| Noldorin | fullermd, would seem like gc should effectively do a branch into itself then, conceptually | 01:29 |
| === thumper is now known as thumper-afk | ||
| === thumper-afk is now known as thumper | ||
| quicksilver | mathrick: I owe you a massive debt for showing me @emacsrocks and the author thereof. Just discovered his 'modern' string and functional programming libraries for elisp. Life-changing! | 10:23 |
| mathrick | quicksilver: you're welcome! I've only discovered him by accident myself and I've been using multiple-cursors constantly since then | 10:24 |
| quicksilver | mathrick: ( https://github.com/magnars/dash.el https://github.com/magnars/s.el ) | 10:25 |
| mathrick | yup, I haven't actually looked into them as libraries, but magnars's been astonishingly productive since he discovered emacs himself | 10:25 |
| mathrick | I think he's been using it for less than two years? | 10:25 |
| mathrick | quicksilver: oh heh, dash is actually named after RD, that's neat | 10:26 |
| quicksilver | mathrick: he'd been using it just a few weeks when he uploaded the first emacsrocks video (or that's what he said) | 10:29 |
| quicksilver | mathrick: I've been using emacs for 19 years. I feel kinda inadequate :) | 10:29 |
| mathrick | heh | 10:30 |
| mathrick | quicksilver: 15 here, and my first years with elisp were terrible, which I've been made acutely aware of recently when I cleaned it up | 10:30 |
| === deej` is now known as deej | ||
| tlonim | I am trying to ignore a directory from parent with bzrignore (during merge), but when I merge that directory is also included in conflicts, any way to avoid this? | 13:43 |
| mgz | tlonim: you should just be able to resolve the conflicts as you merge | 13:45 |
| mgz | so, eg, do the merge, `bzr mv` the files in the dir you want to keep somewhere else, delete or ignore the other bits, run `bzr resolve` on all the paths you've dealt with as listed in `bzr st` | 13:46 |
| tlonim | I did a bzr remove <dir> and then bzr resolve --all (since this directory's conflicts were the only ones left) | 13:48 |
| tlonim | that should do right? | 13:48 |
| mgz | you don't want --all probably... | 13:48 |
| mgz | it's dangerous | 13:48 |
| tlonim | the only conflicts remaining were for that ignored directory, other conflicts I had resolved by then | 13:49 |
| mgz | and you probably need to remove all the actual files, rather than leaving them around | 13:49 |
| mgz | anyway, provided the confict is resovled and the directory is unversioned when you commit, you should be fine | 13:52 |
| tlonim | yeah | 13:54 |
| tlonim | thanks | 13:54 |
| ovnicraft | hello, i have a doubt when merge braches i want to know with detail what means * prefix in output for each file | 16:31 |
| ovnicraft | i know +N means new | 16:31 |
| ovnicraft | i cant find documentation about it? anyone can help me with this ? | 16:31 |
| mgz | ovnicraft: it means the +x bit changed on the file | 16:34 |
| mgz | see `bzr help status` | 16:34 |
| ovnicraft | mgz, this +x change happens when C&P as usual ? | 16:54 |
| mgz | depending on your filesystem it might, yes | 16:55 |
| dpb1 | Hi -- we have a dependency branch that contained jar files and other binaries. Is there any way to purge the history of those files to speed up full checkouts? Or are the only options lightweight checkouts and starting over with a new branch? | 16:57 |
| mgz | as long as you don't have +x bit edit wars, you should be okay | 16:57 |
| mgz | dpb1: there aren't nice easy ways, unfortunately | 16:57 |
| mgz | you can rewrite them out of history, which is a somewhat manual process | 16:57 |
| mgz | you can also just try repacking the repo which may help checout speed | 16:58 |
| dpb1 | mgz: what is the rewrite option? does it involve contacting some bzr admin somewhere? :) | 16:58 |
| mgz | it would involve using something like the bzr-rewrite plugin to completely change the repo history, which would also mean everyone would need to recheckout that | 16:59 |
| dpb1 | ok, like git rebase | 17:00 |
| mgz | that might be an admin level thing, depending on how you're set up | 17:00 |
| mgz | yup. | 17:01 |
| dpb1 | mgz: thx, I'll look into it. I *think* we have a lot of jars in there, so it might be tedious, but it's worth learning about it. | 17:01 |
| dpb1 | I appreciate the help | 17:01 |
| ovnicraft | mgz, how i can revert the +x change in my merge, considering what i get others changes what i need ? be specific by file ? | 17:36 |
| lduros | hi, i'm trying to import a tar.bz2 file into a branch and merge it | 20:23 |
| lduros | isn't it bzr import my.tar.bz2 my-branch? | 20:23 |
| lduros | it tells me import doesn't work :\ | 20:23 |
| lduros | ah import-upstream | 20:31 |
| jelmer | lduros: "bzr import" is a part of bzrtools I think | 20:32 |
| jelmer | lduros: bzr import-upstream is for debian packages | 20:32 |
| lduros | aH | 20:32 |
| lduros | does it matter if I run import-upstream then? | 20:33 |
| lduros | or will import work for tarballs? | 20:33 |
| lduros | ah ok i got import now after installing bzrtools | 20:35 |
| lduros | i'm using an upstream branch (made from tarball) and trying to merge it in my own: I get the following error: | 20:43 |
| lduros | bzr: ERROR: The file id "nsiudpserversocket.i-20130905203643-hbkb6sb8s5pcmrpu-21924" is not present in the tree <bzrlib.inventory.CHKInventory object at 0x7f1850c2ff90>. | 20:43 |
| lduros | 20:43 | |
| lduros | i'm fine with replacing the file with whatever is in upstream | 20:43 |
| lduros | is there a way I can work around this when doing bzr merge? | 20:44 |
| lduros | trying bzr reconcile ../upstream | 20:52 |
| lduros | hopefully it will do something | 20:52 |
| lduros | hmm same error | 20:55 |
| mathrick | jelmer: is bzr diff showing nothing for raw git branches a known problem? | 22:18 |
| mathrick | working with git tools is annoying | 22:18 |
| mathrick | I really miss silverline view of merges | 22:19 |
| mathrick | throwing everything that ever crossed the DAG at me by default is not helpful when I'm trying to see the recent history and whether upstream has merged something | 22:19 |
| mathrick | fortunately bzr qlog works fine on git branches, but without diffs it's pretty hard to use it as my only view into them | 22:21 |
| Noldorin | hey fullermd, lifeless | 22:42 |
| Noldorin | hi jelmer, too | 22:58 |
| jelmer | Noldorin: hi | 23:38 |
| jelmer | Noldorin: not sure - if it doesn't work it should be giving you a backtrace I think | 23:39 |
| jelmer | what are you seeing? | 23:39 |
| Noldorin | jelmer, hmm, what are you replying to? :) | 23:39 |
| jelmer | Noldorin: sorry, EWRONGPERSON | 23:40 |
| Noldorin | heh k | 23:40 |
| jelmer | mathrick: not sure - if it doesn't work it should be giving you a backtrace I think | 23:40 |
| Noldorin | no prob | 23:40 |
| jelmer | what are you seeing? | 23:40 |
| jelmer | Noldorin: what's up? | 23:41 |
| Noldorin | jelmer, was wondering, were you ever involved in the gc functionality for bazaar? | 23:42 |
| Noldorin | fullermd was mentioning the other day there was some gc plugin someone was working on | 23:42 |
| jelmer | Noldorin: I think that might have been jam or lifeless | 23:53 |
| Noldorin | jelmer, ah okay. so you don't know anything about it? i was just curious, because it seems the branch cmd already does a fair bit of gc | 23:54 |
| jelmer | I've discussed it numerous times with people, but I don't think I ever wrote a single line of code :-) | 23:54 |
| Noldorin | could be adapter perhaps | 23:54 |
| Noldorin | ah :) | 23:54 |
| jelmer | Noldorin: where does the branch command do gc? | 23:54 |
| Noldorin | jelmer, i've no idea, but it's evident in practice! | 23:54 |
| Noldorin | no idea where in code that is... | 23:54 |
| Noldorin | jelmer, apparently it also helps slim down the metadata drastically after a split/join cmd | 23:55 |
| Noldorin | so yeah, the branch operation must do something good with respect to gc | 23:56 |
| jelmer | Noldorin: I think saying it does gc is confusing | 23:56 |
| Noldorin | why? | 23:56 |
| Noldorin | it evidently does | 23:56 |
| jelmer | it selectively copies data, that's a different thing than gc | 23:56 |
| Noldorin | jelmer, but that's *effectively* doing gc, if you know whati mean | 23:57 |
| jelmer | Noldorin: no, because you're not changing the base repository | 23:57 |
| Noldorin | consider a hypothetical branch onto itself | 23:57 |
| jelmer | Noldorin: have you seen doc/developers/gc.txt ? | 23:57 |
| Noldorin | jelmer, i disagree. conceptually it's like a gc | 23:57 |
| Noldorin | even if it's not in practice | 23:57 |
| Noldorin | jelmer, no, is that in the main bzr branch? | 23:58 |
| jelmer | Noldorin: I understand what you're getting at, but by that reasoning "bzr init" also does gc | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!