| jelmer | not all that much before though, I think? | 00:00 |
|---|---|---|
| bob2 | maybe a couple of months | 00:00 |
| bob2 | feb iirc | 00:00 |
| bob2 | 2005-03-09 04:08:15 UTC <- selfhosting as of then | 00:02 |
| jelmer | ah, cool.. so about a month before LCA | 00:03 |
| bob2 | was in baz until then | 00:03 |
| * jelmer remembers meeting some baz developers back in the day.. :-) | 00:06 | |
| === Ursinha is now known as Ursinha-away | ||
| kbulgrien | So I used bzr to control files in my home dir... so I could save config for when I reload. | 03:38 |
| kbulgrien | I loaded a new system, now I'd like to use bzr to update files. | 03:39 |
| kbulgrien | what's the proper way to set connect to the repo? | 03:39 |
| mgrandi | update the | 03:39 |
| mgrandi | files on your new system? | 03:39 |
| bob2 | do you mean "check it out" | 03:39 |
| bob2 | bzr get someurl | 03:39 |
| bob2 | note that bzr doesn't version perms, so at least your .ssh needs fixing | 03:40 |
| kbulgrien | I guess, though in cvs land, checkout would tell me things "are in the way" | 03:40 |
| kbulgrien | I would imagine the already existing files are conflicted with what is in bzr | 03:40 |
| bob2 | what do you want it to do then | 03:40 |
| mgrandi | i thought it does version perms | 03:41 |
| mgrandi | or is that jsut attributes? | 03:41 |
| lifeless | it versions executability | 03:41 |
| bob2 | +x and that's it | 03:41 |
| mgrandi | ah | 03:41 |
| mgrandi | interesting | 03:41 |
| kbulgrien | well, I want the files to not be conflicted... so I can merge or whatever. | 03:41 |
| mgrandi | why only that? | 03:41 |
| mgrandi | well, you only want what is in the bzr repo right | 03:41 |
| mgrandi | you can just overwrite the old ones | 03:42 |
| kbulgrien | I want to compare with what is in bzr and maybe merge or replace. | 03:42 |
| mgrandi | you can check your repo to some tmp directory | 03:42 |
| mgrandi | run a diff | 03:43 |
| kbulgrien | So probably I should just checkout and then figure out from there. | 03:43 |
| mgrandi | yeah | 03:43 |
| mgrandi | checkout to ~/Desktop/tmp or whatever | 03:43 |
| mgrandi | diff the two directories, then merge if you want to | 03:43 |
| kbulgrien | I guess the thing is, I want to carry on version control ... so I want the actual directory linked to bzr | 03:44 |
| mgrandi | then you can branch the directory into your home folder | 03:45 |
| mgrandi | if they conflict, then bzr will make you resolve it | 03:45 |
| kbulgrien | still trying to wrap my head around "distributed" vcs | 03:46 |
| mgrandi | this part is still the same as a non distributed vcs | 03:48 |
| kbulgrien | well, now it moved existing stuff to .moved... not what I wanted. | 03:59 |
| kbulgrien | Conflict adding file blah. Moved existing file to blah.moved. | 04:00 |
| kbulgrien | That's a lot of busted stuff. | 04:00 |
| mgrandi | thats probably because the directory wasn't empty, hmm | 04:01 |
| mgrandi | but you want the files that you checked out anyway? | 04:02 |
| mgrandi | the only stuff in .moved are the things that it tried to add buty already existed | 04:02 |
| kbulgrien | well, I guess what I'm after is that I kind of want this virtual configuration that several different machines can reference. | 04:03 |
| kbulgrien | I | 04:03 |
| mgrandi | well, if you ever update the config | 04:03 |
| mgrandi | files you are keeping versioned | 04:04 |
| mgrandi | you simply commit that, and all the other machines will get it when they do bzr update | 04:04 |
| kbulgrien | well not really, I think I want each machine to be separate, but able to merge with others selectively... don't know if that makes sense or not | 04:05 |
| mgrandi | you can have a shared repo on a server, and a branch for each machine. | 04:06 |
| kbulgrien | I do have a shared repo set up. | 04:07 |
| mgrandi | so, make a branch for each machine | 04:07 |
| kbulgrien | I have a branch for this system, but now I want to re-associate these files with that repo and I'd rather it didn't do all the .moved stuff. | 04:08 |
| mgrandi | you checked out the files from that branch into your home dir right? | 04:08 |
| kbulgrien | I wiped the system and now am trying to reconnect to the repo. | 04:08 |
| kbulgrien | yes | 04:09 |
| mgrandi | so yeah, its already assosciated, you can do 'bzr bind <url>" | 04:09 |
| mgrandi | and that way when you commit, it will commit to the repo branch as well | 04:09 |
| kbulgrien | I guess it is a technicality that it made a mess by creating all those .moved files. | 04:09 |
| mgrandi | whats in the .moved files, the files that you are versioning? | 04:10 |
| mgrandi | (or the copies that were there hwen you checked out) | 04:10 |
| kbulgrien | find . -name "*.moved" -exec rm -f {} \; | 04:10 |
| mgrandi | yeah, you can just delete that folder or not version it, your choice | 04:10 |
| mgrandi | bzr doesn't want to wipe out files that exist when you check out, so its just being safe! | 04:10 |
| kbulgrien | but then I sort of think it would have made sense to be able to keep local create a conflict without renaming all the files. | 04:10 |
| kbulgrien | That's how cvs would have done it. | 04:11 |
| mgrandi | well it would of conflicted, but you checked out for the first time | 04:11 |
| mgrandi | into a directory that had non versioned files in it, so thats why it did that | 04:11 |
| mgrandi | now, if you update in the future, if it conflicts it will make you resolve the conflicts | 04:11 |
| kbulgrien | I think that's not friendly at all because that can make a big mess. | 04:13 |
| mgrandi | i mean, would you rather have it overwrite the files losing data? | 04:14 |
| kbulgrien | but maybe that is just me not being in the bzr mindset. | 04:14 |
| mgrandi | its just because you checked out data for the first time in a non empty directory | 04:14 |
| kbulgrien | No, I think it should decline to put them there and when I bzr status, it tells me that there is a conflict | 04:14 |
| kbulgrien | then I have to do something on a file by file basis to clear the conflict. As it is, it moved perfectly good files out of the way. | 04:15 |
| kbulgrien | I think I should be able to say, don't go moving my crap for me. | 04:15 |
| mgrandi | well, thats true, but all of those files were files that were in the branch that you checked out, you wanted ones from the repo anyway right? | 04:16 |
| mgrandi | i see your point | 04:16 |
| kbulgrien | not necessarily. | 04:16 |
| kbulgrien | This is a new install. | 04:16 |
| mgrandi | im not an expert, but either way, you have the original and the branch version, you can manually move them back, which is almost the same as resolving a conflict | 04:16 |
| kbulgrien | The repo might not match the new install. I'd rather deal with them one by one than the whole mess. | 04:16 |
| mgrandi | true | 04:17 |
| kbulgrien | sure, I know I can deal with it... I'd just rather not have a bazillion .moved files. I'd rather have some virtual indication of a conflict. | 04:18 |
| mgrandi | there might be a way to do that | 04:18 |
| mgrandi | im not a super expert at bzr | 04:18 |
| kbulgrien | So I guess, my question should have been... can I checkout without it moving all the preexisting files that will conflict when I checkout. | 04:20 |
| mgrandi | im not sure, maybe, maybe not, if someone else can weigh in | 04:21 |
| kbulgrien | I see I'm not the first to ask this question... stackoverflow has a post... someone said the poster could file a bug if he wanted to. | 04:24 |
| mgrandi | i can for you if you don't want to | 04:26 |
| mgrandi | link to the stackoverflow post would be good | 04:26 |
| kbulgrien | ah... was googling to see other people's threads that had more substance. | 04:31 |
| kbulgrien | http://stackoverflow.com/questions/2663846/stop-bazaar-bzr-from-making-moved-files | 04:32 |
| kbulgrien | Well, I don't want to come in a newbie and say bzr is broke without trying to think about it more. | 04:33 |
| kbulgrien | Its just I do not get amused when something renames dozens of files and I had no say about it. | 04:33 |
| spiv | kbulgrien: I think it's a legitimite gripe, bzr could probably do better here | 04:34 |
| spiv | Although judging from past discussions on the topic finding a strategy that always works well for everyone is probably impossible. | 04:35 |
| spiv | Scattering the .moved files everywhere without warning wouldn't be so bad if there were an easy way to get bzr to undo it | 04:36 |
| kbulgrien | well, even an option would help... newb is probably going to bzr help checkout... and then something in help could say or deal with that, but it doesn't | 04:36 |
| kbulgrien | There is no warning at all that if you do this, potentially hundreds of files will get renamed. | 04:37 |
| kbulgrien | I did that in a source tree a couple of weeks ago... not realizing. What a freaking mess | 04:37 |
| spiv | Right. | 04:37 |
| spiv | It's tedious at best to fix (whether by hand or writing some sort of script) | 04:37 |
| kbulgrien | I realize once I have experience hopefully I will know better, but then I also know even when I am experienced I make mistakes. | 04:38 |
| spiv | Indeed! | 04:38 |
| kbulgrien | and sometimes, the mistakes made by an experienced person are more huge than the ones made by newbies. | 04:39 |
| kbulgrien | :-) | 04:39 |
| spiv | Which is why ideally mistakes either shouldn't cost too much, and/or be easy to undo. | 04:39 |
| spiv | Hehe | 04:39 |
| spiv | And lots of version control features are great: you can revert, uncommit, in general look at old history etc | 04:39 |
| spiv | But the .moved behaviour really breaks you out of that | 04:40 |
| spiv | Because while in principle all your precious bytes are still intact somewhere it's a PITA to get them back in the shape you want them. | 04:40 |
| kbulgrien | cvs screams at me... there is a file in the way... and it does nothing except scream about a conflict until I resolve it. I kind of like that. | 04:40 |
| kbulgrien | but I suppose there will be people who feel the reverse. | 04:41 |
| spiv | So I find that fear of .moved really slows me down because I have to anticipate when it might happen so I can avoid it :( | 04:41 |
| mgrandi | well you can't really revert it becuase those files arn't in version control, but yeah | 04:42 |
| mgrandi | i feel bzr should warn, like the --use-existing-dir | 04:42 |
| spiv | "slows down" might be a bit of a strong claim, but it does feel like some sort of mental drag. | 04:42 |
| spiv | mgrandi: well, as a hypothetical, bzr could version them if it's worried you might lose them! | 04:42 |
| kbulgrien | maybe, but then that means it automatically creats a branch, right, and I'm not sure about that either. | 04:43 |
| spiv | (Perhaps in a separate temp repo to avoid polluting your main one if you want to be finicky etc, my point is the tool could be better) | 04:43 |
| spiv | I mean, here we have a tool that's all about saving history, that you can rely on to not lose old revisions | 04:44 |
| spiv | And has all sorts of clever code to do that nicely | 04:44 |
| kbulgrien | I wonder how etckeeper works. | 04:44 |
| spiv | And then for this case it's like you're dropped into the stone age of version control again | 04:44 |
| kbulgrien | I am also trying to version OS files. | 04:44 |
| spiv | Where people manually rename foo.txt to foo.txt.bak, or foo.txt.bak.bak.bak ;) | 04:45 |
| kbulgrien | perms saved me, but it did try to move boot to boot.moved. | 04:45 |
| spiv | IIRC etckeeper writes out the extra metadata about perms to a file and gets bzr to version that, and probably has a bunch of policy layered on top to give nicer merge defaults for config files | 04:46 |
| spiv | I expect its docs would explain :) | 04:46 |
| kbulgrien | yeah, just haven't got as far as installing it. | 04:46 |
| mgrandi | what is etckeeper? | 04:47 |
| kbulgrien | didn't realize it was a front end to vcs until just the other day. | 04:47 |
| kbulgrien | http://joey.kitenet.net/code/etckeeper/ | 04:47 |
| kbulgrien | I wish more distributions packaged it. | 04:47 |
| kbulgrien | more being more than fedora | 04:48 |
| kbulgrien | oh, i see debian and ubuntu package it but they are .deb. I think there are repackagers that can convert to .rpm and the like. | 04:49 |
| mgrandi | ah interesting. | 04:50 |
| kbulgrien | ( I tried to rebuild the rpm from el/fedora and it wouldn't due to .spec problem I didn't figure out) | 04:51 |
| mgrandi | ah | 04:53 |
| mgrandi | debs and rpms are black magic | 04:53 |
| kbulgrien | https://www.linux.com/learn/tutorials/512306-weekend-project-control-your-configuration-with-etckeeper | 04:54 |
| kbulgrien | anyway, etckeeper was a bit of a rabbit trail, but .moved is related because .moved in version controlled OS files is bad. | 04:57 |
| mgrandi | you can try posting on the mailing list about it | 04:58 |
| mgrandi | im curious on what other people say about it | 04:58 |
| wgz | pre morning all | 07:24 |
| mgrandi | hey wgz | 07:24 |
| mgrandi | it is technically morning i guess | 07:25 |
| mgrandi | i figured out one of the problems i was having with fastimport | 07:27 |
| vila | hi all ! | 07:40 |
| mgrandi | hi | 07:43 |
| vila | kbulgrien: I think what is you're after is getting your branch in some tmp dir *then* moving the '.bzr' directory (and only it) to '~' and *finally* do a 'bzr status' | 07:54 |
| poolie | hi vila, hi vgz, | 07:54 |
| poolie | mgrandi | 07:54 |
| mgrandi | still | 07:55 |
| mgrandi | vila, that seem slike a really hackish workaround =P | 07:55 |
| vila | mgrandi: it is :) But the point is to avoid generating '.moved' files ;) | 07:56 |
| mgrandi | i guess, i still think the workaround he said, where the files are just marked as conflicting if that happens | 07:56 |
| mgrandi | would be better | 07:57 |
| * vila nods | 07:57 | |
| vila | But how would you call such operation ? | 07:57 |
| vila | poolie: hey ! | 07:57 |
| mgrandi | what do you mean? | 07:57 |
| vila | checkout-in-an-existing-dir-but-please-dont-mess-it-up is a bit long ;) | 07:58 |
| vila | I mean bzr has no idea what the status of the existing file is | 07:59 |
| mgrandi | well it obviously knows if there is an existing file | 07:59 |
| mgrandi | cause it moves it | 08:00 |
| vila | but it cannot complete the checkout without moving it | 08:00 |
| vila | and merging requires some knowledge about the actual tree | 08:00 |
| vila | that knowledge is missing in this particular case | 08:01 |
| mgrandi | hmm | 08:01 |
| mgrandi | would it be possible to do a merge once it moved it to .moved? | 08:01 |
| vila | Note that I'm explaining what is happening, not denying the usefulness of the feature | 08:01 |
| vila | I have the same use case myself (maintaining config files across several machines), but I use a different workflow | 08:02 |
| mgrandi | that way it can complete the checkout | 08:03 |
| vila | short answer: no | 08:05 |
| vila | a checkout is a pristine copy of a given revision | 08:06 |
| vila | bzr *does* a merge when pulling if you have uncommitted changes but in this case it knows what have been changed | 08:06 |
| vila | s/have/has/ ? | 08:07 |
| mgrandi | yeah | 08:07 |
| mgrandi | here it doesn't because it moved the files | 08:08 |
| vila | yeah, I didn't check the code but roughly I suspect it consider them unknown and as such cannot merge their content with the ones that are checked out | 08:08 |
| mgrandi | in any case, id make the case for a option to warn before it moves the files | 08:10 |
| mgrandi | like --use-existing-dir | 08:10 |
| vila | Note that a 'bzr resolve --take-this' should restore some sanity by getting the .moved files back but will record a deletion of the versioned files (which is not what kbulgrien want I'm pretty sure) | 08:10 |
| vila | yup, worth a bug | 08:10 |
| mgrandi | cause i got bitten by that | 08:10 |
| mgrandi | sometime in the past | 08:10 |
| vila | yeah, I suspect most of bzr users don't fall into the trap which is why no bugs (that I know of) was ever filed | 08:11 |
| mgrandi | but like you said, i dunno how one would fix the problem other then having an option | 08:12 |
| vila | Also note that the actual behavior is a legitimate use case | 08:12 |
| mgrandi | someone mentioned creating a temporary repository | 08:12 |
| mgrandi | yeah, having an option to either move files, merge them or abort seems like the ideal case | 08:12 |
| vila | yup, warns if files are in the way an requires an option to complete sounds fine | 08:13 |
| mgrandi | would a temporary branch work, in some temp directry? | 08:14 |
| mgrandi | add the original files and then try to merge the ones that are incoming from the real branch operation? | 08:14 |
| vila | ha, you'll run into the 'parallel import' issues I think (I can never remember which command allows one to use existing file-ids...) | 08:15 |
| vila | right, 'bzr add' | 08:15 |
| mgrandi | parallel import issues? | 08:16 |
| vila | bzr internally use file-ids to track renames | 08:16 |
| vila | a file-id is associated to a relative path in the tree when the file is added, then the file can be renamed but keeps its file-id | 08:17 |
| mgrandi | ah | 08:17 |
| vila | if the same relative path is added in a different branch, it receives a different file-id | 08:17 |
| mgrandi | and that confuses things? | 08:17 |
| vila | when both branches are merged, the file-ids conflict: parallel import | 08:17 |
| vila | it's the weak point in the rename tracking and we haven't fixed it yet :-/ | 08:18 |
| mgrandi | how would it ideally be fixed? | 08:19 |
| vila | roughly by keeping track of aliases between file-ids so when looking at the history of a given file bzr an decide how to join/split the histories of different file-ids | 08:20 |
| vila | s/an/can/ | 08:20 |
| mgrandi | so it would be able to tell that two different file-ids came from the same path? (aka same file) | 08:20 |
| vila | yes | 08:21 |
| mgrandi | ah | 08:21 |
| mgrandi | sounds like a lot of internal hacking to get that to work, but it would pay off if just to fixed the first issue | 08:22 |
| vila | mgrandi: 'first issue' means ? | 08:24 |
| vila | parallel import of kbulgrien use case ? | 08:24 |
| mgrandi | yeah | 08:24 |
| mgrandi | was gonna say moving files when checking out and files conflict | 08:24 |
| vila | sort of, in this case, the existing files probably have *no* file-ids at all so using the existing ones should do | 08:26 |
| mgrandi | true | 08:26 |
| mgrandi | its 1 am, not thinking straight haha | 08:27 |
| vila | doing a tmp branch and 'bzr add --file-ids-from <tmp branch>' and then 'bzr merge' should also give better results but is almost as hackish as moving the '.bzr' directory and probably even scarier ;) | 08:27 |
| vila | mgrandi: well, parallel import is not something you want to think about without the clearest mind and a good understanding of the bzr merge internals ;-) | 08:28 |
| mgrandi | heh i guess not | 08:29 |
| mgrandi | on that note i head to bed. night | 08:29 |
| mgz | morning all! | 09:04 |
| === Ursinha-away is now known as Ursinha | ||
| * jelmer sees a fairly scary patch to bzrlib/win32utils.py | 12:32 | |
| mgz | hm, it's not really as bad as it looks, but I'm not sure Alexander's suggestion to add specific detection for argument skew was really the right thing | 12:40 |
| kbulgrien | vila: I don't mind hearing your workflow. I am just doing things the way I do them with the other vcs I use a lot. | 13:00 |
| kbulgrien | I also am not entirely opposed to idea given regarding moving of .bzr folder. It's not like I didnt do hackish stuff at times with the other vcs. | 13:01 |
| kbulgrien | I still think, however, that the .moved behavior is unpleasant. | 13:02 |
| kbulgrien | Anyway, work beckons and I have to go use my old vcs for a while until I get them to jump over to bzr (which I intend to do). | 13:03 |
| vila | my workflow involves a script that creates a bunch of symlinks (based on a textual description mapping a tree kept under version control ans symlinks under my home directory). The script makes backups when it encounters files or directories where it want to install the symlinks | 13:03 |
| vila | I agree the .moved behavior is unpleasant in your use case ;) | 13:03 |
| kbulgrien | I created a big script called os2cvs a long time ago. i have a very short os2bzr script that deals only with perms. I was hoping to not write my own big front end again. | 13:05 |
| vila | but really checkout doesn't expect anything in its way so what you may do is cheat: create a clean branch and working tree somewhere, move the '.bzr' and do 'bzr st' and/or 'bzr diff' | 13:05 |
| vila | s/the '.bzr'/& directory where you want it to live/ | 13:05 |
| kbulgrien | I will try that on for size. Thanks. | 13:07 |
| vila | kbulgrien: but are you interested in keeping your home directory under vc or /etc ? There are different issues for each | 13:07 |
| vila | my remarks above are for ~ | 13:07 |
| kbulgrien | both, but I deal with both differently. | 13:08 |
| kbulgrien | Part of my concern is for the day I switch over at work. | 13:08 |
| kbulgrien | When I convert the big giant repositories to bzr... everyone will have workspaces that are not in bzr, but are current works in progress | 13:09 |
| vila | right, etckeeper is probably what you want for etc (I have a completely different workflow for /etc myself coping with all OSes I had to admin and etckeeper didn't exist when I started) | 13:09 |
| kbulgrien | When they try to switch them over from old VCS to new VCS, bam. | 13:09 |
| vila | right | 13:09 |
| kbulgrien | Now I realize we probably have to checkout to different sandbox and manually merge, but that seems an unnecessary pain. | 13:10 |
| kbulgrien | Sure, re etckeeper. I only just realized a few days ago it was a front end that used bzr underneath. | 13:11 |
| vila | right, what you want is a way to say: here is a non-versioned tree, how does it compare to some versioned tree and how can I converge. Right ? | 13:11 |
| kbulgrien | I just had already started using my own process and haven't d/l and looked at it yet. | 13:11 |
| kbulgrien | That's right. | 13:11 |
| kbulgrien | I want to keep the pain factor low. My coworkers are going to hate moving as it is. | 13:12 |
| vila | but their trees are not under vc right now right ? | 13:12 |
| kbulgrien | another vc, not bzr, but I would convert the old vc repo to bzr. I tested that already. | 13:12 |
| vila | oh, things may be a bit different in this case | 13:13 |
| kbulgrien | I realize having used old vc, I may have a different world view that I am willing to adjust, except that one reason bzr made the cut was because of all the new vc, it let me change my worldview the least. | 13:13 |
| kbulgrien | I'm not really sure how they would be different. | 13:14 |
| vila | right, that's nice to say, and yes, some things are the same, others are different or new, so indeed your have some work/experiments to do to feel at ease | 13:15 |
| vila | http://wiki.bazaar.canonical.com/MatthewFuller/SpotDocs/PiecesInBrief have a good definition of some basic concepts | 13:15 |
| kbulgrien | ok. will look at it. right now I am late for work... too bad because this discussion is helful for work too. | 13:16 |
| kbulgrien | and I am not allowed to use resources like this there. | 13:16 |
| vila | :-/ | 13:16 |
| vila | Try the mailing list may be ? | 13:17 |
| kbulgrien | yeah, I need to do that. Besides, its more friendly that things worked out are then archived for others use. | 13:17 |
| kbulgrien | nothing like instant gratification though, eh? | 13:17 |
| kbulgrien | :-) | 13:18 |
| kbulgrien | anyway... later... and thanks. | 13:18 |
| vila | have a nice day ;) | 13:18 |
| === yofel_ is now known as yofel | ||
| dakira | hi. i'm new to collaborating so I have a question. I just pulled a project (which I'm not a member of) from launchpad and fixed a bug. Is there an automatic way to get my fix to the dev or do I have to manually create a patch, file a bugreport and attach the patch to the bugreport? | 16:19 |
| dakira | What is the proposed way to handle such things? | 16:20 |
| mgz | you push your branch up to your namespace, and propose a merge, generally | 16:32 |
| mgz | so, `bzr branch lp:foo` `cd foo` ...fix stuff in foo and commit... `bzr push lp:~/foo/name_for_your_changes` | 16:34 |
| mgz | then can do a merge proposal via the website, or `bzr lp-propose` | 16:35 |
| dakira | mgz: okay thanks! | 16:35 |
| mgz | working on ubuntu packaging rather than directly upstream with launchpad is a little different, but same general idea | 16:38 |
| === zyga is now known as zyga-food | ||
| === zyga-food is now known as zyga | ||
| mgrandi | hallo | 17:56 |
| m4n1sh | using bzrlib how can I find out the files changed for a particular commit if i have the revision number? | 19:16 |
| mgrandi | not sure, i dont know bzrlib that well, maybe someone else can answer | 19:18 |
| m4n1sh | jelmer: ping | 19:36 |
| === r0bby is now known as robbyoconnor | ||
| === r0bby is now known as robbyoconnor | ||
| bzrperson | If I bzr shelve something, does it get saved on the server with bzr push? | 22:26 |
| bzrperson | I'm moving HDs and don't want to commit the current things, but do want them saved | 22:27 |
| wgz | bzrperson: nope, it's local to the tree, not the branch | 22:33 |
| bzrperson | OK | 22:33 |
| wgz | bzrperson: just commit and push to another branch | 22:33 |
| wgz | leaving your main branch as is | 22:34 |
| bzrperson | Oh | 22:35 |
| bzrperson | Alright | 22:35 |
| wgz | you can cherrypick merge it back to your main branch later if you like :) | 22:37 |
| poolie | hi all | 22:44 |
| === mwhudson_ is now known as mwhudson | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!