| === ScottK2 is now known as ScottK | ||
| === Guest72551 is now known as maxb\ | ||
| === maxb\ is now known as maxb | ||
| delinquentme | bzr commit -m "yadda" /path/to/only/files/I/want/committed.rb | 11:59 |
|---|---|---|
| delinquentme | right? | 11:59 |
| jelmer | delinquentme: yes | 11:59 |
| janos | delinquentme: you might like this too: bzr ci -m 'yadda' -x /path/to/dir/i/want/to/EXCLUDE | 12:07 |
| delinquentme | janos, Ohh cool! TIL bzr has an exclude option | 12:18 |
| janos | ...and if you made a mistake with the list of files, you can "bzr uncommit" and try again. but prob you did know that | 12:22 |
| janos | (unless you're in a central workflow, in which case you should not uncommit...) | 12:23 |
| mnn | I'm getting an error while shelving changes | 14:30 |
| mnn | Was this fixed or not? https://bugs.launchpad.net/bzr/+bug/660125 | 14:31 |
| ubot5 | Ubuntu bug 660125 in Bazaar "shelve crashes with "Tree transform is malformed" when renamed file already exists" [Medium,Confirmed] | 14:31 |
| mnn | http://pastebin.com/vHeu7J7R | 14:31 |
| mnn | I don't know if it's same issue | 14:32 |
| jelmer | mnn: that bug isn't fixed going by the bug status | 14:32 |
| mnn | so, is there a workaround? | 14:33 |
| mnn | will commit work? | 14:33 |
| vila | wild guess: move the existing file out of the way before shelving (from the bug report the issue is about that existing file not being known by bzr) | 14:34 |
| mnn | well, I don't have any pending renames - only added files and modified | 14:35 |
| vila | ha, be looking at your paste, it may be a different issue | 14:35 |
| mnn | I've been shelving/unshelving stuff for long time now without any issues | 14:35 |
| vila | the pita with 'mzrlformed transform' is that, while it's clearly a bug in bzr, the error reported is so cryptic there is no way to diagnose without being able to debug locally :-/ | 14:36 |
| vila | so either you're able to 1) publish your branch and working tree 2) isolate a reproducible recipe | 14:36 |
| vila | 1) may not even be a good solution if too many files are involved (I've lost myself in several attempts already) | 14:37 |
| vila | mnn: yeah, that's what make bugs of this family so painful, there are less and less corner cases left unaddressed which make them harder to understand and fix :-/ | 14:38 |
| vila | mnn: I think there is another bug about pending adds causing trouble | 14:39 |
| vila | 'bzr st' would be a good start to check whether you still have unknowns or not or... | 14:40 |
| vila | mnn: 'will commit work?' It should ! | 14:41 |
| vila | hmm | 14:41 |
| vila | mnn1: what's the last message you read ? | 14:41 |
| mnn1 | "mnn: I think there is another bug about pending adds causing trouble" | 14:43 |
| mnn1 | got disconnected | 14:43 |
| vila | ok | 14:43 |
| vila | <vila> 'bzr st' would be a good start to check whether you still have unknowns or not or... | 14:43 |
| vila | <vila> mnn: 'will commit work?' It should ! | 14:43 |
| vila | in fact, I think it's a very good idea to start with 'bzr commit', | 14:44 |
| vila | from there it's possible that 'bzr uncommit; bzr shelve' *will* work | 14:44 |
| mnn1 | well this is even more weird - I have 3 modified files, 7 added files and 1 added folder | 14:44 |
| mnn1 | I can shelve all files without any problem and then separately shelve added folder - no crash | 14:45 |
| vila | shudder | 14:45 |
| mnn | well but after that qshelve crashes whenever I try to show contents of those shelves | 14:46 |
| mnn | well, I got something new - "bzr: ERROR: No final name for trans_id 'new-2'" | 14:47 |
| mnn | this error pops up when I try to unshelve added files | 14:48 |
| vila | at that point, trying to diagnose whether this a genuine bug or a fallout from the original one is... not worth it IMHO | 14:48 |
| vila | start by doing a backup of your whole working tree (*including* the '.bzr' directory) | 14:48 |
| vila | and try to get back to the point where the whole shelve was failing and try 'commit/uncommit/unshelve' instead | 14:49 |
| mnn | damn, I knew this would happen when I start using VCS | 14:49 |
| vila | jelmer: python-docutils-0.9.1 ? quantal ? | 14:58 |
| jelmer | vila: debian experimental | 14:58 |
| vila | jelmer: hmm, can you try just removing the leading space on that line 161 ? | 14:59 |
| vila | jelmer: (I know I suck for not having a debian experimental chroot ;) | 14:59 |
| vila | jelmer: the guess above is because emacs doesn't fontify this line like the other similar ones, cheap enough to try... | 15:00 |
| jelmer | vila: I'll try | 15:01 |
| vila | jelmer: wait, wrong guess, *adding* a space *after `fcgi` seem to to fontiry correctly | 15:01 |
| vila | i.e. a space after the closing ` | 15:01 |
| vila | I don't speak japanese but a space there shouldn't hurt ;) | 15:02 |
| jelmer | vila: that works \o/ | 15:04 |
| vila | jelmer: \o/ feels good :) | 15:04 |
| vila | jelmer: approved | 15:58 |
| lduros | hi, I have Contents conflict on directories that existed but don't exist anymore, and I actually don't have the files themselves in the tree anymore, but the Contents conflict are still there and I'm not sure how to resolve them when the files are gone? Any idea? Thanks! | 18:22 |
| mark06 | about my earlier question on uncommit, is it the same thing for push --overwrite in Launchpad? | 18:58 |
| mark06 | I mean, that push will overwrite the branch but previous versions will still remain in the repository (either local or in Launchpad) just like uncommitted commits? | 18:59 |
| === yofel_ is now known as yofel | ||
| fullermd | Yes. | 19:15 |
| mark06 | ok, thanks | 19:15 |
| fullermd | (though I have to scoff at the phrasing "uncomitted commit". It's thinking about things like that that get people committed :p) | 19:15 |
| mark06 | I've heard about some gc plugin but couldn't find it to test | 19:17 |
| mark06 | is there some bug to make uncommit, push --overwrite and the like to really do what they say? | 19:18 |
| fullermd | They do what they say; they make changes to branches. | 19:38 |
| fullermd | They just don't remove stuff from repositories. | 19:38 |
| mark06 | I knew you would disagree | 19:47 |
| mark06 | why not tweet my uncommits as well | 19:47 |
| fullermd | I'm sure someone has implemented `bzr push twitter://....` ;> | 19:49 |
| mark06 | :P | 20:02 |
| lduros | any idea how to remove "contents" conflicts for files that have now been physically removed? | 20:24 |
| jelmer | lduros: use "bzr resolved" | 20:24 |
| lduros | jelmer: with the d at the end? Hmm | 20:25 |
| lduros | jelmer: it tells me 0 conflicts auto-resolved. | 20:25 |
| jelmer | lduros: does "bzr conflicts" still report any conflicts? | 20:25 |
| lduros | jelmer: yes, it still mentions those files that are not present physically | 20:26 |
| lduros | jelmer: there are also some other text conflicts | 20:26 |
| lduros | which I need to work on | 20:26 |
| jelmer | lduros: have you tried "bzr resolved" with a filename? | 20:28 |
| lduros | jelmer: hmm let me try :-) | 20:32 |
| lduros | jelmer: ok looks like it's doing the trick! Thanks! :-) | 20:33 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!