| wolfrage | Hello, I was wondering what is the impact of using Bazaar Explorer on a Git repository. | 00:14 |
|---|---|---|
| wolfrage | I have all of the proper tools for bzr installed like bzr-git. So far I have just found that it could not pull down a git repository. | 00:14 |
| wolfrage | Is any one in here? | 00:22 |
| poolie | hi | 00:26 |
| poolie | yes | 00:26 |
| poolie | what specifically fails? | 00:26 |
| yhager | Are there any issues with python 2.7 (bzr, bzr-svn) - that should cause me to use python 2.6? | 00:38 |
| spiv | None that I know of | 00:40 |
| wolfrage | poolie: Sorry did not notice you responded. Well it appears that the git plugin is read only for git repos. | 00:42 |
| wolfrage | poolie: I was hoping to use a nice tool like Bazaar explorer to help me contribute to Telepathy | 00:43 |
| wolfrage | poolie: But I have not found a single complete GIT tool, so I guess I will just have to guess at it. and be CLI only. | 00:43 |
| poolie | wolfrage: i didn't think it was readonly | 00:44 |
| poolie | i think you do have to use 'dpush' rather than 'push', per http://doc.bazaar.canonical.com/migration/en/foreign/bzr-on-git-projects.html | 00:45 |
| wolfrage | poolie: http://doc.bazaar.canonical.com/plugins/en/git-plugin.html | 00:45 |
| poolie | ah, i think think title might just be a bit out of date | 00:47 |
| poolie | s//that title | 00:47 |
| poolie | the project homepage says "All operations except for "push" are supported" | 00:47 |
| wolfrage | hmmm ok, but with dpush I should be able to push the git repo to an online repository | 00:48 |
| poolie | what do you mean by online? | 00:48 |
| wolfrage | gitorious account | 00:49 |
| poolie | you want to push from a local git repo to a remote one? | 00:49 |
| poolie | what happens if you try just bzr push? | 00:49 |
| wolfrage | yes | 00:49 |
| wolfrage | poolie: stby, it seems to have not error'd this time, one sec. | 00:51 |
| RenatoSilva | anyone using bzr-hg can do a test to me? | 00:52 |
| wolfrage | poolie: bzr: ERROR: Unsupported protocol for url "git@gitorious.org:wolfrage-telepathy/otr.git" | 00:53 |
| wolfrage | poolie: Full out put: Run command: bzr push git@gitorious.org:wolfrage-telepathy/otr.git | 00:53 |
| wolfrage | bzr: ERROR: Unsupported protocol for url "git@gitorious.org:wolfrage-telepathy/otr.git" | 00:53 |
| spiv | wolfrage: bzr-git uses URLs like git://... | 00:56 |
| wolfrage | spiv: good catch that was for ssh | 00:57 |
| spiv | Or git+ssh:// | 00:58 |
| wolfrage | how would I have it do ssh on git, or is that not possible... | 00:58 |
| wolfrage | so this should work then? git+ssh://gitorious.org/wolfrage-telepathy/otr.git | 00:59 |
| spiv | Maybe git+ssh://git@gitorious.org/wolfrage-telepathy/otr.git | 00:59 |
| spiv | (I'm not a bzr-git expert) | 00:59 |
| wolfrage | spiv: k trying | 01:00 |
| wolfrage | spiv: Thanks that worked! | 01:01 |
| spiv | Great :) | 01:01 |
| wolfrage | OK one more question and then I will leave you guys alone for a little while. How can I pull and merge the revisions that have occurred in this repository: http://git.collabora.co.uk/?p=telepathy-spec.git;a=summary and merge them back into mine. More... explanation on the way. | 01:05 |
| wolfrage | Basically the repository I have has not been updated for nearly 3 months. I want it up to date before I being to much work on it. | 01:06 |
| wolfrage | Is that asking too much? | 01:07 |
| wolfrage | That would be a merge right? | 01:07 |
| spiv | pull if the revision history hasn't diverged, merge if they have. | 01:08 |
| spiv | i.e. pull is good for updating a mirror of another branch, merge is what you use when you have an independent branch and want to incorporate changes from another branch. | 01:09 |
| wolfrage | OK this one is independent and has been for almost a year, and last got a update three months ago | 01:09 |
| wolfrage | So I should go with a merge. | 01:09 |
| wolfrage | when I try to merge it fails with permission denied | 01:19 |
| === Ursinha-afk is now known as Ursinha | ||
| aj00200 | poolie: this is aj00200 with that Unicode bug. Thanks for all your help :) | 01:32 |
| yhager | poolie: the problem is that bzr tries to load the whole file into memory. This is a real blocker for our team to consider bzr.. :( | 02:06 |
| RenatoSilva | let's say I create a branch from upstream release 1.0, then commit my patches, then merge upstream changes, then improve my patches etc. Is there any way to generate a patch for 1.0 release, that is, a diff of the changes since release 1.0 but ignoring all merges? | 02:10 |
| fullermd | Not in any remotely automatic way. | 02:12 |
| RenatoSilva | I'm thinking on setting up two branches for that, one mypatch-r1.0 as main entry point for improving the patch, and other mypatch-dev from which I merge both upstream and mypatch-r1.0 changes | 02:12 |
| fullermd | You could attempt it by a series of cherrypicks. You could try finding (or building) a patch composition tool and doing the whole diff, then reverses of each merge (sorta the complement of the cherrypick method). | 02:13 |
| fullermd | More flippant-cum-HHOS'ly, you could convert it into darcs and then commute the patches ;) | 02:13 |
| spiv | HHOS? High Horse Of Silliness? | 02:14 |
| fullermd | Well, I was thinking Ha Ha Only Serious, but that works too :p | 02:15 |
| RenatoSilva | cherrypicks? flippant-cum-HHOS? darcs? | 02:18 |
| fullermd | RenatoSilva: Well, it's a bit yflurgic, but as a TRX it's less nurrific than your average KSTRN-ish arglefarx. :] | 02:20 |
| RenatoSilva | o.O, it seems easier just keeping the two branches | 02:20 |
| fullermd | Very probably. | 02:21 |
| RenatoSilva | I just thought if I could do something like bzr diff -r 1.. --ignore-merges | 02:22 |
| fullermd | That, no. Trying to actually do it would be decidedly Not That Simple(tm). | 02:23 |
| RenatoSilva | ok thanks fullermd | 02:29 |
| wolfrage | Wanted to stop back and thank you guys, now with a little bit of GIT on the command line I can run my repository with Bazaar, and do it smartly! | 02:55 |
| poolie | excellent | 03:00 |
| * spiv -> late lunch | 03:25 | |
| poolie | mkanat: nice essay :) | 06:15 |
| mkanat | poolie: Thanks! | 06:15 |
| === oubiwann-holiday is now known as oubiwann | ||
| === oubiwann is now known as oubiwann-holiday | ||
| vila | hi all | 07:37 |
| jelmer | g'morning Vincent | 07:38 |
| vila | jelmer: heya ! | 07:38 |
| vila | jelmer: I submitted a mp for bzr-search fixing the failing tests | 07:39 |
| jelmer | \o/ | 07:39 |
| jelmer | vila: I submitted a MP for most bzr-xmloutput test failures (only one left) earlier | 07:39 |
| vila | jelmer: I digged the xmloutput a bit more... and it's even more obscure now, I ... huh ? | 07:39 |
| vila | jelmer: meh, there was only one failure when I started... | 07:39 |
| vila | let me see your mp... | 07:40 |
| jelmer | vila: the daily build is failing with 4 | 07:41 |
| vila | meh, I was pretty sure the custom escape_data was already fixed.... | 07:41 |
| vila | mgz: escape_data xmloutput, can you refresh my memory ? | 07:42 |
| jelmer | vila: it may not be an issue when the in-tree elementtree is used | 07:42 |
| vila | hmm, could it be py27 related ? | 07:42 |
| vila | jelmer: or is it that you're using 0.8.6 and I use trunk ? | 07:44 |
| vila | jelmer: qlog says: look at revno 147 | 07:44 |
| jelmer | vila: I'm using lp:bzr-xmloutput and indeed python 2.7 | 07:46 |
| vila | jelmer: bzr-xmloutput-0.8.6+bzr148~ppa112+113~natty1 should include it which means... meh wth | 07:46 |
| vila | jelmer: right, which should mean the bzrlib.xml_serializer logic needs one more fix for 2.7 ? | 07:48 |
| vila | jelmer: and your remaining failure is for test_info (which is the one I'm digging) | 07:49 |
| jelmer | vila: the remaining failure for me is bzrlib.plugins.xmloutput.tests.test_info_xml.TestInfoXml.test_info_locking | 07:50 |
| vila | yup, a single test to test 8 combinations, I've got a parameterized version now with 2 failures and 3 errors | 07:51 |
| jelmer | vila: also, more test failures in the natty bzr daily build :-/ | 07:53 |
| wolfrage | I am using Bazaar Explorer with a GIT repo, and I am trying to push a commit to my remote branch, as an update. But I keep getting this: | 07:53 |
| wolfrage | Run command: bzr push | 07:53 |
| vila | but at this point I need to talk to verterok as the intent of the xmlinfo command is unclear | 07:53 |
| wolfrage | error: refusing to create funny ref 'None' remotely | 07:53 |
| wolfrage | bzr: ERROR: None failed to update | 07:53 |
| jelmer | vila: I see the timestamp error you mentioned earlier, but also: "AttributeError: 'InstrumentedTestResult' object has no attribute 'report_error'" | 07:54 |
| vila | jelmer: the later sounds like a testtools version mismatch | 07:54 |
| poolie | hi vila! | 07:55 |
| vila | poolie: hello ! | 07:55 |
| jelmer | vila: Ahm, hmm | 07:55 |
| jelmer | 'evening poolie | 07:55 |
| vila | jelmer: argh, you're using testtools trunk | 07:55 |
| vila | jelmer: did I complain yesterday about you *not* using trunk ? | 07:55 |
| vila | :D | 07:55 |
| vila | doomed if you do, doomed if you don't :D | 07:55 |
| jelmer | vila: :-) I'm surprised it only breaks on natty though, not on Maverick | 07:56 |
| jelmer | wolfrage: hi | 07:56 |
| jelmer | wolfrage: "bzr push" won't work for git branches, you can only "bzr dpush" (though arguably the error message should be clearer) | 07:56 |
| vila | jelmer: It's a zen thing, testtools failures causes are of an infinite nature | 07:56 |
| wolfrage | jelmer: Hi sorry about the interupt | 07:56 |
| vila | jelmer: that's because when you test, you want to always be prepared to accept new failures, zen thing... | 07:57 |
| wolfrage | jelmer: ahh, I see. I got confident as it was able to push it as a new branch. But I guess updates will not. Since I am using Explorer, if i run the command "bzr dpush" do I need any other parameters? | 07:58 |
| jelmer | wolfrage: I'd be very surprised if it was able to push it as a new branch | 07:59 |
| jelmer | wolfrage: bzr dpush requires the URL to the branch to push to | 07:59 |
| jelmer | vila: :) | 07:59 |
| wolfrage | jelmer: I was surprised too, but poolie was talking to me at the time that it did it. | Ok I will give it a go with the url attached. Thank you. | 08:00 |
| vila | jelmer: the daily builds are a nice complement to babune, but we face a common issue here: the combinations and their related failures can be daunting at times | 08:02 |
| wolfrage | jelmer: does the command need any dashes "bzr dpush --url" or just "bzr dpush url" | 08:03 |
| jelmer | wolfrage: just "bzr dpush <url>", much like you would use "bzr push" | 08:03 |
| jelmer | vila: The intent isn't really to provide CI but rather to allow users to more easily follow current trunk, I'd rather catch these errors before we'd actually get to the package building stage. | 08:04 |
| vila | jelmer: hehe, but isn't that the intent of CI ? :D | 08:04 |
| vila | jelmer: don't get me wrong, I'm very happy about the daily builds, they address combinations that I can't address so far in babune (not do I really plan to address ;) | 08:06 |
| vila | s/not do/nor do/ | 08:06 |
| wolfrage | jelmer: did not work is it ok to post the error? | 08:06 |
| jelmer | vila: Yeah, I guess that's also a form of QI :-) | 08:07 |
| jelmer | wolfrage: sure | 08:07 |
| jelmer | vila: Errhm, CI | 08:07 |
| * jelmer clearly has been watching too much QI lately | 08:07 | |
| wolfrage | jelmer: Run command: bzr dpush git+ssh://git@gitorious.org/wolfrage-telepathy/otr.git | 08:07 |
| wolfrage | bzr: ERROR: <LocalGitBranch('file:///home/wolfrage/Programing/git/telepathy/otr/', 'HEAD')> and <RemoteGitBranch('git+ssh://git@gitorious.org/wolfrage-telepathy/otr.git', 'HEAD')> are in the same VCS, lossy push not necessary. Please use regular push. | 08:07 |
| vila | jelmer: :) | 08:07 |
| * wolfrage thinks that is a good show. | 08:07 | |
| jelmer | wolfrage: ah, you've got a git repository locally that you're pushing from, not a bzr branch? | 08:07 |
| wolfrage | jelmer: Sorry thought I included that detail | 08:08 |
| jelmer | wolfrage: I figured you were pushing from a local bzr branch to a remote git branch, I didn't realise you had a git branch locally as well. | 08:08 |
| wolfrage | Yes using bzr-git to push my local git to a remote git | 08:08 |
| jelmer | vila: I'll chase down the testtools error. Do you have any idea about the timestamp? | 08:09 |
| jelmer | wolfrage: in that case "bzr push" is indeed the right thing to use, can you file a bug about the issue you saw? | 08:09 |
| vila | jelmer: not from the top of my head, pretty surprising | 08:09 |
| vila | jelmer: but I vaguely remember something like that happening in the past | 08:10 |
| wolfrage | jelmer: sure. I was wondering should it be filled under bzr on launchpad or is there a bzr-git | 08:10 |
| jelmer | wolfrage: there's a separate bzr-git project | 08:10 |
| wolfrage | jelmer: copy. | 08:11 |
| wolfrage | jelmer: Bug #690547 https://bugs.launchpad.net/bzr-git/+bug/690547 | 08:37 |
| ubot5 | Ubuntu bug 690547 in Bazaar Git Plugin "GIT to GIT bzr push Fails "funny ref 'None' remotely"" [Undecided,New] | 08:37 |
| ubot5 | Launchpad bug 690547 in Bazaar Git Plugin "GIT to GIT bzr push Fails "funny ref 'None' remotely"" [Undecided,New] https://launchpad.net/bugs/690547 | 08:37 |
| jelmer | wolfrage: any chance you can add the relevant error log in ~/.bzr.log as well? | 08:39 |
| jelmer | wolfrage: the fix is probably that we should push to refs/heads/master, something that we're not explicitly doing at the moment | 08:40 |
| wolfrage | jelmer: Working attachment. Interesting, It somehow committed a delete of the branch. It is ok, but not sure how that happened. Or maybe Gitorious just screwed up. GIT makes my head hurt | 08:41 |
| wolfrage | jelmer: Is it ok if I delete my email out of the logs. | 08:43 |
| jelmer | wolfrage: of course | 08:44 |
| wolfrage | jelmer: As soon as it finishes what it is doing currently I will submit the log. | 08:45 |
| wolfrage | jelmer: I wanted to know I see how to add files to a git with bzr but how do I remove them? | 08:49 |
| jelmer | wolfrage: it should be the same as regular bazaar | 08:52 |
| jelmer | wolfrage: please note though that bzr-git's main focus so far has been on interoperating with remote git repositories, the local support is still quite experimental - in particular as we can't really map the git index to anything in bzr | 08:53 |
| wolfrage | jelmer: I know I am asking alot of the software, unfortunately all of the other GIT tools can not stack up to Bazaar Explorer, which is sad considering it was made for bzr not GIT. But it is helping me to contribute to the community because of it's versatility. | 08:55 |
| wolfrage | jelmer: I do hope that you will not mind me making more bugs though as I find them. It seems that Add has no effect and Remove fails with permission denied which makes no sense as I own all of the files and directories. | 09:03 |
| jelmer | wolfrage: no, please do file more bugs | 09:05 |
| jelmer | wolfrage: please note though that these don't have a high priority for me at the moment, I'm mainly concentrating on the remote git repo use case | 09:06 |
| jelmer | wolfrage: patches are very much welcome though | 09:07 |
| wolfrage | jelmer: OK I understand priorities. I just appreciate that the Software has helped me along this far. I really was not impressed by the other GIT tools. | 09:07 |
| wolfrage | jelmer: LOL, After I get through with Telepathy, then I will come back over here. But I can only tackle so many bugs at once too. lol. | 09:08 |
| wolfrage | jelmer: Log is attached, The error is at least a few operations back. But it was attempted multiple times. | 09:10 |
| vila | spiv: changing signatures for branch creation broke looms :-/ | 12:03 |
| RenatoSilva | I have deleted the hg directory from plugins dir but it's still showing up in bzr plugins: hg 0.2.0dev in C:\Program Files\Bazaar\plugins\hg. | 13:07 |
| RenatoSilva | How to purge it? | 13:07 |
| RenatoSilva | bzr hg-import is even running. How can that be? It's like bzr-hg is cached somehwere?! | 13:10 |
| RenatoSilva | c:\>ls "C:\Program Files\Bazaar\plugins\hg" => __init__.pyo commands.pyo info.pyo revspec.pyo | 13:18 |
| RenatoSilva | c:\>dir "C:\Program Files\Bazaar\plugins\hg" => not found o.O | 13:18 |
| vila | RenatoSilva: 'bzr plugins -v' should tell you | 13:24 |
| RenatoSilva | vila: (11:07:02) RenatoSilva: [...] but it's still showing up in bzr plugins: hg 0.2.0dev in C:\Program Files\Bazaar\plugins\hg. | 13:32 |
| RenatoSilva | vila: where I got that path with -v | 13:33 |
| RenatoSilva | vila: seems a crazy windows 7 bug, I just rm -r'ed it | 13:33 |
| vila | RenatoSilva: then it's probably windows specific and the plugin may be in bzrlib.zip | 13:34 |
| vila | RenatoSilva: see if you can reinstall bzr without the plugin | 13:34 |
| RenatoSilva | vila: I removed it with rm -r | 13:34 |
| RenatoSilva | vila: bzr-hg now disappeared | 13:35 |
| vila | RenatoSilva: *I* understand and trust you, yet, bzr plugins -v seems to disagree with you | 13:35 |
| RenatoSilva | vila: it was like the hg dir was still existing in the filesystem "partially". For explorer and dir, it didn't exist, but for bzr and ls and rm it did | 13:36 |
| vila | RenatoSilva: try a reboot first to exclude nasty caches (doubtless) | 13:36 |
| jelmer | somebody else ran into similar problems | 13:36 |
| vila | meh, why do I say doubtless when I doubt... | 13:36 |
| vila | yup, as jelmer says, this rings a bell | 13:36 |
| RenatoSilva | vila: I removed hg dir yesterday, and turned pc on today, and the issue was there | 13:37 |
| vila | wowwwww | 13:37 |
| jelmer | I'm not sure if it was windows 7 as well, but it seems like the GUI doesn't always display the actual contents | 13:37 |
| RenatoSilva | vila: not sure if it's clear but after rm -r, bzr plugins doesn't list bzr-hg anymore | 13:37 |
| * vila blinks | 13:38 | |
| jelmer | RenatoSilva: what do you mean with rm -r though? | 13:38 |
| vila | RenatoSilva: no, it's not clear | 13:39 |
| RenatoSilva | jelmer: I thought about that, but I could create the hg dir in explorer! | 13:39 |
| RenatoSilva | jelmer: at the same time hg was already there (for some tools) | 13:39 |
| RenatoSilva | let me explain again form beginning. I removed bzr-hg yesterday by deleting C:\Program Files\Bazaar\plugins\hg. Today I turned computer on and noted that it was still there in bzr plugins. The -v options was showing that exact path. I went to explorer, and it wasn't there. I went to win32 terminal, and dir command couldn't find it. | 13:42 |
| RenatoSilva | But ls.exe could (I have MSYS)! And so rm.exe. Weirdly, I could create the hg dir again in explorer, even with it already existing for ls and bzr | 13:44 |
| RenatoSilva | So I just tried rm -r /c/Program Files/Bazaar/plugins/hg, and it worked, bzr plugins stopped showing bzr-hg in the list | 13:45 |
| RenatoSilva | * the -v option | 13:46 |
| === zyga is now known as zyga-food | ||
| === Ursinha is now known as Ursinha-lunch | ||
| === Ursinha-lunch is now known as Ursinha | ||
| awilkins | Is there a gitstats for Bazaar? If (e.g.) gitstats worked internally on git-fast-export format (don't know if it does), it would work for anything that had a fast-export frontend, no? | 15:45 |
| === Ursinha is now known as Ursinha-afk | ||
| === Ursinha-afk is now known as Ursinha | ||
| === tremolux_ is now known as tremolux | ||
| mgz | vila/jelmer: yes, that xmloutput thing was fixed on both trunks | 16:10 |
| mgz | I'm not sure what the failures were from | 16:10 |
| mgz | but looking at <https://code.launchpad.net/~jelmer/bzr-xmloutput/fix-tests/+merge/43738> I'm a little concerned | 16:10 |
| vila | mgz: including python 2.7 ? | 16:11 |
| vila | mgz: by the way, I nailed the last failures on osx 10.6 only to be bitten by a new one ;) | 16:11 |
| mgz | just seen that as well and will review. | 16:11 |
| jelmer | mgz: I still get them on trunk: | 16:11 |
| jelmer | TypeError: _escape_cdata() takes exactly 2 arguments (1 given) | 16:12 |
| vila | mgz: patch awaiting review... too fast :) | 16:12 |
| mgz | anyway, not using a function from bzrlib.xmlserialiser would be fine | 16:12 |
| mgz | but the one you've written in does less than the etree one, which was already insufficient | 16:12 |
| jelmer | mgz: the only difference with the etree one is that it doesn't take an encoding argument | 16:13 |
| mgz | right, so... passing non-ascii either unicode or bytes becomes risky. | 16:13 |
| mgz | it's a bad interface which doesn't help, but it's even easier to use incorrectly now. | 16:14 |
| jelmer | mgz: we weren't passing an encoding before either | 16:14 |
| jelmer | mgz: so that situation doesn't really change | 16:14 |
| mgz | no, but the etree 1.3 function defended against bad bytestrings | 16:14 |
| mgz | also, string.replace jelmer? how retro are we? :) | 16:14 |
| jelmer | mgz: I just took whatever etree was using :-) I guess that can be text.replace now, indeed... | 16:15 |
| mgz | the problem in the first place was etree changed this function, which python 2.7 picked up. | 16:15 |
| mgz | I'd like to just make xmloutput less retarded about xml generation, but that's a big job. | 16:16 |
| mgz | anyway, I'll look into why you were getting failures, I thought I'd checked different version combinations | 16:17 |
| mgz | wasn't helped by most of the bzr-xmloutput test suite failing here. | 16:18 |
| jelmer | mgz: FWIW I don't think we can use the stock _escape_cdata since it always encodes in python 2.7 | 16:19 |
| mgz | well, it's a question of which misuse we want to break | 16:19 |
| mgz | most of xmloutput happens to work because the data is ascii, it's not hard to break it. | 16:20 |
| jelmer | mgz: there are more than a few places where the text passed into _escape_cdata is unicode, and the caller expects it to come back as unicode too | 16:20 |
| mgz | okay, yep, this is a problem. | 16:22 |
| mgz | will put review in that mp. | 16:24 |
| === beuno is now known as beuno-lunch | ||
| RenatoSilva | mgz: what do you mean with xmloutput less retarded about xml generation? | 16:36 |
| mgz | it's doing the print statement and string interpolation approach | 16:38 |
| RenatoSilva | I think I've found a bug: http://pastie.org/1379843, that error pops up on a gui dialog and then qlog list commits without the messages | 16:39 |
| mgz | this can work if you're an expert about what the xml spec says, but anyone normal just gets it wrong in all kinds of edge cases. | 16:39 |
| mgz | vila: jam's reviewed your mp already, so I don't need to :) | 16:39 |
| vila | mgz: indeed :) | 16:39 |
| vila | jam: thanks and hi ! | 16:39 |
| RenatoSilva | mgz: I dealed with some xmloutput weaknesses some time ago, and some of them still exist | 16:40 |
| RenatoSilva | mgz: I contributed some patches for encoding fixes, but work is still needed | 16:41 |
| mgz | example of some wrongness: | 16:41 |
| mgz | except Exception, e: | 16:41 |
| mgz | xml += '<error><message>%s</message></error>' % \ | 16:41 |
| mgz | _escape_cdata(str(e)) | 16:41 |
| RenatoSilva | mgz: for example, bzr xmlstatus is putting cp1252 in the preamble, which is W3C invalid iirc | 16:41 |
| mgz | what happens if the exception instance stringifies to non-ascii? | 16:42 |
| RenatoSilva | well for sure, cp1252 is not a proper encoding | 16:42 |
| mgz | that depends on in iana. | 16:42 |
| mgz | some of the cp* encodings are listed, some (like cp932, which would actually be useful) aren't. | 16:42 |
| mgz | *on the iana. | 16:43 |
| mgz | http://www.iana.org/assignments/character-sets <- allows "windows-1252" | 16:43 |
| mgz | they should just add the "cp" prefix as an alias to all windows numbered encodings they list there | 16:45 |
| mgz | instead of it being pot-luck. | 16:45 |
| mgz | anyway, there's an easy fix xmloutput could use | 16:46 |
| mgz | the output-based-on-terminal-encoding is just daft. | 16:46 |
| mgz | should instead either do utf-8 with no prologue, iff the terminal is utf-8, or ascii with &#...; escaping. | 16:47 |
| mgz | but that means touching all the output code, which I don't want to do without actually making it robust. | 16:47 |
| awilkins | Some things don't even like UTF-8 AFAIK. The MS libraries had a bug where they would emit ¬ characters happily enough and then drop dead trying to parse their own output. | 16:48 |
| RenatoSilva | xml needs prologue | 16:49 |
| RenatoSilva | I mean, if you have a chance to tell what encoding it is, why not say? tools reading that output will need to guess it's utf-8 if you don't declare it | 16:50 |
| mgz | nope, it's speced very clearly. | 16:50 |
| mgz | without prologue, it depends on the bom, without bom it's utf-8 | 16:50 |
| RenatoSilva | mgz: what you're saying is addressed in bug 394943 | 16:50 |
| ubot5 | Launchpad bug 394943 in bzr-xmloutput "Declared and actual XML encoding should match, and the encoding should be XML valid" [High,Confirmed] https://launchpad.net/bugs/394943 | 16:50 |
| mgz | thus, if you want a utf-8 xml document, ommitting the prologue is fine. | 16:51 |
| awilkins | Indeed. Many things just use the platform encoding by default (esp Java which assumes that all InputStream is the JVM encoding - which is cp1252 (or whatever the equivalent is) on Windows | 16:51 |
| RenatoSilva | mgz: without bom it's utf-8? how can you guess that? you know because you make bzr-xmloutput do it, but apps doesn't have a way to know it | 16:51 |
| RenatoSilva | "without prologue, it depends on the bom, without bom it's utf-8", do you mean this is the XML spec? iirc it doesn't even allow you to remove the prologue | 16:52 |
| awilkins | BOMs are a PITA anyway ; so many tools don't handle them right, so many XML output encoders don't write one (although some do). | 16:54 |
| RenatoSilva | http://www.w3.org/TR/2008/REC-xml-20081126/#dt-xmldecl | 16:55 |
| mgz | note that's not a MUST. | 16:56 |
| awilkins | A SHOULD requirement is probably something you ... should .. make the effort to implement. The BOM thing is a MAY for UTF-8 ; and I'd prefer to see it left off because it will break casual compatibility with many tools if left in. | 16:56 |
| RenatoSilva | awilkins: why would xml generators choose BOM over preamble, specially when BOMs are a PITA, and W3C obligates you to write a preamble? :P | 16:56 |
| awilkins | RenatoSilva, Oh, quite - I'd rather not see BOM, and I'd prefer a preamble. | 16:57 |
| RenatoSilva | does it stand must != should? I didn't know that | 16:57 |
| RenatoSilva | because in dictionary, you must do it is the same as you should do it afaik | 16:58 |
| mgz | yes, and given the way things have developed, even SHOULD is a little strong. | 16:58 |
| awilkins | If you neglect a MUST you've not met the standard - missing a SHOULD will attract "tch, tch" and frowns but not get you labelled non-compliant. | 16:59 |
| awilkins | And a MAY is a nice-to-have. | 16:59 |
| mgz | see 4.3.3 as well, which has some encoding specific directives. | 17:00 |
| awilkins | AFAIK cp1252 is the same as ISO_8859_1 | 17:00 |
| mgz | anyway, for this plugin none of this should matter regardless of the terminal encoding | 17:00 |
| mgz | awilkins: nope, it swaps out the C1 control characters for some extra glyphs | 17:01 |
| awilkins | Gah, MS at their finest. | 17:01 |
| mgz | ^shouldn't matter, because unlike rio which causes issues here, xml *does* have a proper escpaing mechanism if the encoding can't represent a character | 17:02 |
| RenatoSilva | afaik cp1252 is a superset of latin1 | 17:02 |
| RenatoSilva | mgz: see comments 15-18 in bug 394943 | 17:03 |
| ubot5 | Launchpad bug 394943 in bzr-xmloutput "Declared and actual XML encoding should match, and the encoding should be XML valid" [High,Confirmed] https://launchpad.net/bugs/394943 | 17:03 |
| mgz | not printing mojibake is always worth while. | 17:05 |
| mgz | it's only hard to fix because the code is a mess, particularly over what's unicode, what are bytestrings, and so on. | 17:05 |
| RenatoSilva | anyway, does the xml spec stand that if an xml misses encoding declaration, you can use boms to inform the encoding, and does it say if there's no bom you shall read it as utf-8???? this sounds weird | 17:06 |
| mgz | yes, see 4.3.3 | 17:07 |
| RenatoSilva | mgz: yeah that bug is hard to fix because the whole code needs to be checked | 17:07 |
| mgz | it's worded at little backwards, but: | 17:07 |
| mgz | "...it is a fatal error for an entity including an encoding declaration to be presented to the XML processor in an encoding other than that named in the declaration, or for an entity which begins with neither a Byte Order Mark nor an encoding declaration to use an encoding other than UTF-8." | 17:07 |
| mgz | is there something more general as well... | 17:08 |
| RenatoSilva | mgz: "In the absence of external character encoding information (such as MIME headers), parsed entities which are stored in an encoding other than UTF-8 or UTF-16 MUST begin with a text declaration" | 17:11 |
| mgz | right, "other than" | 17:11 |
| mgz | so, utf encodings don't need it. | 17:11 |
| RenatoSilva | mgz: imho this is pretty much a fallback is case there's no way to know what encoding it is than it's stimulating you to not use the xml preamble. As the doc says, you must not, but you should, use preambles. Unless you have a specific good reason for not using: | 17:13 |
| RenatoSilva | mgz: "SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. " | 17:13 |
| mgz | right, and that was reasonable advice. | 17:14 |
| mgz | but in the years since the spec was written, no other version of xml has gained traction, and utf-8 is increasingly the default encoding everywhere. | 17:14 |
| mgz | so it's less important than it was to state the bleeding obvious. | 17:15 |
| RenatoSilva | well anyway, I'd recommend not removing the preamble, it doesn't hurt anyway. And I disagree, as I think you disagree too, with bzr-xmloutput trying to guess the output encoding to use. It should use a single static encoding, preferably utf8. | 17:16 |
| mgz | I'm not quite saying that. | 17:16 |
| mgz | There's no reason to print utf-8 to a non-utf-8 terminal, so it should just not do that. | 17:16 |
| mgz | which is trivial. | 17:17 |
| RenatoSilva | I don't get you | 17:17 |
| RenatoSilva | bzr-xmloutput is not supposed to be used in a terminal | 17:17 |
| mgz | the annotated xml spec is informative on the thinking at the time. | 17:18 |
| RenatoSilva | ? | 17:18 |
| mgz | http://www.xml.com/axml/notes/Enc1.html "Very little of the world's text is stored in Unicode encodings" | 17:18 |
| mgz | http://www.xml.com/axml/notes/ASCII.html "As the spec says, pure ASCII files are UTF-8 as they sit, and thus don't require an encoding declaration. The problem is that a lot of ASCII files are not quite pure." | 17:19 |
| mgz | ^ it's not intended to be, but these things do get used on the terminal, where's that version-info bug... | 17:19 |
| mgz | and as it's trivial to avoid printing junk to a terminal, it should. | 17:20 |
| RenatoSilva | why would one use bzr-xmloutput in terminal? examples? | 17:21 |
| Peng | Spent too much time working on web apps and can't read plain text anymore? :P | 17:23 |
| mgz | see bug 518609 | 17:23 |
| RenatoSilva | mgz: I personally don't like the idea of converting non-ascii to XML char entities | 17:23 |
| ubot5 | Launchpad bug 518609 in Bazaar "Unicode exception occurs by "version-info"" [Medium,Fix released] https://launchpad.net/bugs/518609 | 17:23 |
| mgz | there's no reason to use that command rather than one that works, but we got three bugs filed about it. | 17:24 |
| mgz | Renato, I think you're overestimating how hard it is to conditionally escape characters if a terminal is detected. | 17:25 |
| mgz | it's like, three lines of code in a well constructed program. | 17:25 |
| vila | mgz: for values of 'well' known long after the program has been written :-P | 17:26 |
| vila | mgz: not that I disagree ;-) | 17:26 |
| RenatoSilva | mgz: how about version-info, what does it have to do with xmloutput? | 17:28 |
| mgz | it's an internal-use command with escaping issues. | 17:28 |
| RenatoSilva | mgz: sorry, and how does this take you to "I must now use xmloutut"? | 17:29 |
| RenatoSilva | mgz: do you mean xmloutput has an xml version for that command and it does work? | 17:30 |
| mgz | no, I'm just pointing out that it's easier to write a command correctly than assume people won't try and break it. | 17:30 |
| mgz | anyway, I now need to go and clean the house before I get yelled at. | 17:32 |
| RenatoSilva | ok, but back to the question, why one would use bzr-xmloutput in terminal? it's not supposed to be used there. If you want to use it, then use a terminal with utf8 support. That won't be a problem for Linux users, not even for Windows users, they can chcp 650001 before command call. | 17:33 |
| vila | mgz: nah, nobody will yell at you for cleaning xmloutput :) | 17:33 |
| RenatoSilva | So I really see no reason for xmloutput caring about terminal encoding. It should use a static utf8 encoding, that will make the actual use of xmloutut a lot easier (in bzr-java-lib, bzr-eclipse etc) | 17:34 |
| mgz | I think you think I'm suggesting something I'm not. | 17:36 |
| === beuno-lunch is now known as beuno | ||
| vila | :) | 17:36 |
| RenatoSilva | what's funny about xmloutput at the moment is that it's more crazy than before, because it mostly used to declare utf-8 and write something else, but now it gets some system default encoding and writes based on the terminal encoding, or something like that (for example win32 console is cp850, and so it is xml output, but declared as cp1252) | 17:40 |
| RenatoSilva | (continuing the example, but if I use mintty, which is not a proper win32 console, it writes latin1 bytes) | 17:41 |
| mgz | I am getting yelled at. | 17:47 |
| mgz | look, all it needs is something like: | 17:47 |
| mgz | output = sys.stdout | 17:47 |
| mgz | if getattr(output, "encoding", None) != "utf-8": | 17:47 |
| mgz | output = codecs.lookup("ascii")[3](output, "xmlescape") | 17:47 |
| mgz | and a proper method of writing xml rather than the current mess. | 17:48 |
| mgz | (which is the hard bit) | 17:48 |
| mgz | writing that is easier than saying Don't Do That whenever someone accidentally uses an xml command on a non-utf terminal, and proper parsers are perfectly capable of handling numeric entities | 17:50 |
| RenatoSilva | I don't like escaping chars to xml entities | 17:50 |
| RenatoSilva | I'd rather go with just printing the actual char | 17:51 |
| jelmer | RenatoSilva: that may not be possible | 17:51 |
| RenatoSilva | jelmer: why not? | 17:51 |
| mgz | you prefer UnicodeEncodeError bug reports? | 17:51 |
| mgz | this sounds like a pretty irrational fear, and not one you'd ever actually encouter | 17:52 |
| RenatoSilva | mgz: iirc there's a way to print bytes to stdout, without encoding mess | 17:52 |
| mgz | either, as you say, no one ever prints this to a terminal, in which case you never see it | 17:52 |
| RenatoSilva | mgz: in a way that you delegate the encoding mess to the terminal or what reads stdout | 17:52 |
| mgz | or someone does try that, and you want bzr to break rather than show them something understandable. | 17:52 |
| jelmer | RenatoSilva: the characters might be utf8 while the terminal is iso8859-9, so some characters would not be printable. | 17:53 |
| mgz | anyway, this is trivia, and really didn't need this much discussion. | 17:54 |
| RenatoSilva | jelmer: there's no terminal, bzr xml-output is not to be used in a terminal | 17:54 |
| mgz | what we've been talking about for half an hour has nothing to do with the actual bug that exists, or what needs to be done to fix it. | 17:54 |
| RenatoSilva | jelmer: even if so, then the user just changes terminal's encoding before running xmloutput | 17:54 |
| mgz | so I'm really going/ | 17:54 |
| jelmer | RenatoSilva: So the user has to be told to change their encoding (which might be nontrivial) | 17:55 |
| RenatoSilva | mgz: I don't like your idea of entities that's why I'm discussing. I suspect it would break bzr-java-lib and bzr-eclipse more than they already are | 17:55 |
| jelmer | RenatoSilva: I don't see what is problematic about entities. | 17:56 |
| jelmer | RenatoSilva: Then we should fix them, don't they use standard XML parsing libraires? | 17:56 |
| RenatoSilva | jelmer: ok xml parsers should be ok with that, but not sure if bzr-java-lib and bzr-eclipse will be ok. Kind of a feeling from having writing some patches to them | 17:57 |
| RenatoSilva | jelmer: I'm not sure on the exact purpose of entities but why allow non-ascii in XML then? I mean, why not make XML standard ascii-only with using char entities for specifying non-ascii? | 17:59 |
| jelmer | RenatoSilva: If they don't use standard XML parsing libraries then I suspect we have worse things to worry about. | 17:59 |
| RenatoSilva | jelmer: I wouldn't be surprised if they don't, that's what I mean :) | 18:00 |
| jelmer | RenatoSilva: That's possible but can use significantly more disk space for some languages if e.g. the document is stored as UTF16. | 18:00 |
| RenatoSilva | jelmer: so it's an alternative for when there's a reason for using them | 18:02 |
| jelmer | RenatoSilva: and I think this is a perfectly valid situation to use them | 18:03 |
| RenatoSilva | jelmer: for example you need to send the xml somewhere but before it gets there something reads it and tries to decode it as it was ascii-only, raising errors. So you use entities as workaround for the xml passing fine over it and getting fine in the destination | 18:04 |
| RenatoSilva | jelmer: well I don't think making things pretty to crazy users reading xml output in terminal rather than using the regular bzr commands is a good reason, it's just that what I think. | 18:05 |
| jelmer | RenatoSilva: I don't think it's a very big deal, but it does mean we get to avoid a bunch of encoding-related issues. And I haven't heard any disadvantages of using entities yet. | 18:06 |
| * maxb skims scrollback and asks: Use entities for which characters, precisely? | 18:11 | |
| jelmer | maxb: characters that can't be represented using current terminal's encoding | 18:13 |
| maxb | That seems sane, just so long as the current encoding in the absence of a terminal being involved isn't affected by the system's terminal encoding | 18:14 |
| RenatoSilva | maxb: but the command in question is not supposed to be used in terminal, so why care so much about crazy users doing it? | 18:15 |
| maxb | RenatoSilva: because it's a hopefully simple way to do something reasonable in a terminal. Doing something reasonable rather than erroring outright is better. | 18:16 |
| RenatoSilva | maxb: as I said iirc there's a way to send raw bytes to stdout in python, so no exception would be raised. The only issue would be junk in terminal, but who cares? The user should not be doing that anyway. Besides, it's easy to fix, because Linux terminals support utf8, and in windows it's just chcp65001 | 18:18 |
| maxb | RenatoSilva: Your proposal would be acceptable behaviour, IMO, but if we can do better with little effort, why not do so? | 18:19 |
| RenatoSilva | maxb: the issues I have seen with bzr-xmloutput, bzr-java-lib and bzr-eclipse, were related to doing things wrong, not simply by the pure fact of not having chars represented as entities | 18:19 |
| maxb | OOI, what is the way to send raw bytes to stdout? | 18:19 |
| maxb | RenatoSilva: "Let's emit XML that is compatible with the terminal encoding" is not incompatible with "Let's do things right". You seem to be suggesting otherwise. | 18:21 |
| * jelmer -> foods | 18:22 | |
| RenatoSilva | maxb: "Let's emit XML that is compatible with the terminal encoding" | 18:24 |
| RenatoSilva | maxb: that's valid for commands supposed to be run in terminal, not bzr-xmloutput. Besides, I see it from the opposite perspective, like the natural, and hence good way is having the actual bytes, then I start to think of the advantages of converting to entities, and I see no reason for that, in the specific case of xmloutput :) | 18:26 |
| maxb | Your goal is to get valid data out for programmatic use. Other people may also have the goal of XML that is valid if copy/pasted from a terminal. The two goals are not incompatible | 18:29 |
| RenatoSilva | maxb: convert actual bytes to entities, then converting them back to the same actual bytes. I just think this is useless overhead (ok it's useful for displaying in terminal, but still useless, because terminals are not for xmloutput) | 18:29 |
| maxb | There is no useless overhead, because if you're writing to a pipe to another program, you'd be operating in UTF-8, and the only entities you'd be using are the five basic ones to escape characters that have meaning in XML itself | 18:31 |
| RenatoSilva | I may have the goal of xmloutput making some coffee, but that doesn't mean it makes sense so that developers should work on it :P | 18:31 |
| jelmer | RenatoSilva: if converting encoding and decoding special characters to entities has an overhead that's in any way noticable overhead then you're transmitting way too much data with XML anyway. | 18:36 |
| maxb | Anyone know a good document about the guts of python's stdout encoding handling I could read? | 18:37 |
| RenatoSilva | jelmer: I'm not sure if I understood correctly, but the idea is convert every non-ascii char into a xml char entity, right? So that the data is ascii-only, right? Well imagine you use bzr-eclipse to fetch the commit logs on a sufficiently big branch, it may become slow enough for being annoying. | 18:41 |
| maxb | RenatoSilva: no, only convert characters not representable in the target encoding | 18:44 |
| jelmer | RenatoSilva: Other things will hit you much much worse. | 18:44 |
| RenatoSilva | jelmer: I just had an insight, why discuss this so much, xmloutput could just have an argument for that :D like --use-entities or --use-actual-bytes :) | 18:44 |
| jelmer | RenatoSilva: the character conversion won't have any noticable impact | 18:44 |
| maxb | ew. NO> | 18:44 |
| jelmer | maxb: what are you saying no to ? :-) | 18:45 |
| maxb | Pointless options are fail, both for understandability and maintainability | 18:45 |
| RenatoSilva | maxb: ah ok so it's using entities only for unrecognized byte sequences? ok, but converting to entity doesn't really fix the problem, it just changes from python unicode exceptions from some more high level error in the application which will be fed with such crazy data | 18:48 |
| RenatoSilva | maxb: not that I disagree with that, but just noting | 18:49 |
| jelmer | RenatoSilva: The application is very likely able to deal with unicode | 18:50 |
| RenatoSilva | maxb: the proper fix is to find out why the xml is getting invalid chars inside it | 18:50 |
| jelmer | RenatoSilva: that's the point, the XML isn't getting invalid characters in it | 18:52 |
| jelmer | it's just getting characters that can't be encoded for the current terminal. | 18:52 |
| RenatoSilva | jelmer: but how about the invalid chars which were changed into entities. I'm not sure if parsers will convert those invalid-char entities back to the actual bytes, or will leave it out for who's reading, but either way, the application will get invalid input. Either with the data containing entities or the actual invalid bytes, the app will crash on processing it. | 18:53 |
| RenatoSilva | jelmer: ah ok, so the problem is parsing errors due to the actual bytes, I see | 18:54 |
| jelmer | RenatoSilva: which invalid characters are you talking about? | 18:54 |
| RenatoSilva | jelmer: (16:44:04) maxb: RenatoSilva: no, only convert characters not representable in the target encoding | 18:54 |
| jelmer | RenatoSilva: right, those are unprintable targets.. they're not invalid in any way | 18:55 |
| jelmer | and they're only unprintable in the context of the terminal | 18:55 |
| * RenatoSilva confused | 18:55 | |
| * jelmer really goes to get some food now | 18:59 | |
| RenatoSilva | I think I understand a bit better now | 19:01 |
| RenatoSilva | but I agree only if it's for terminal | 19:04 |
| RenatoSilva | in mgz's example, if getattr(output, "encoding", None) != "utf-8": output = codecs.lookup("ascii")[3](output, "xmlescape") | 19:08 |
| RenatoSilva | what if it's None, how will output behave, since there's no target encoding to check compatibility to | 19:08 |
| mgz | ...how is this conversation still going on? | 19:08 |
| lifeless | what if what is None ? | 19:09 |
| mgz | RenatoSilva: could make no encoding attribute do plain utf-8, it doesn't really matter. | 19:09 |
| mgz | would just involve changing the test and an else clause. | 19:10 |
| RenatoSilva | lifeless: the encoding returned by getattr(output, "encoding", None). Since there's no target encoding (it's None), I wonder how entities will be handled in that example, will they be generated for every non-ascii char or for no char at all? | 19:12 |
| RenatoSilva | lifeless: specially, it's None when redirecting to files, or using pipes I suppose, so I wonder what will be the behavior. Because if it's a pipe or file, there isn't really sense, imho, in generating the entities. But for terminals, ok, it doesn't hurt. | 19:15 |
| smoser | so on fresh lucid install: | 19:17 |
| smoser | $ bzr branch lp:qa-regression-testing | 19:17 |
| smoser | You have not informed bzr of your Launchpad ID, and you must do this to | 19:17 |
| smoser | write to Launchpad or access private data. See "bzr help launchpad-login". | 19:17 |
| smoser | bzr: ERROR: [Errno 4] Interrupted system call | 19:17 |
| smoser | i see evidence that this is fixed in 2.1.2. | 19:17 |
| lifeless | RenatoSilva: if its not, it will encode to an ascii encoding with xml escaping, no ? | 19:19 |
| smoser | evidence at http://doc.bazaar.canonical.com/development/en/release-notes/bzr-2.1.2.html . is there an explicit bug that i should ask be made available in -updates ? | 19:19 |
| RenatoSilva | lifeless: not sure if you followed but I was talking about mgz's example: if getattr(output, "encoding", None) != "utf-8": output = codecs.lookup("ascii")[3](output, "xmlescape") | 19:22 |
| RenatoSilva | lifeless: if it's not == if stdout is not a pipe/file? | 19:23 |
| RenatoSilva | how got another crazy error with bzr qlog in bzr-eclipse | 19:23 |
| RenatoSilva | looks like new versions of bzr have compatibility problems with old branches | 19:24 |
| RenatoSilva | s/how/wow | 19:24 |
| mgz | there's no need to get hung up on that example, as an exercise feel free to write your own version. | 19:26 |
| mgz | but this discussion ceased to be useful about... well, I'm not sure it was ever useful. | 19:26 |
| mgz | corner case behaviour with encoding attributes is not what's breaking things for you, nor is anything else we've talked about. | 19:27 |
| RenatoSilva | mgz: ok I just mean that would be interesting for non-utf8 terminals *only*, so it would need a way to check if stdout is a terminal, something like posix's isatty | 19:27 |
| mgz | as I said, feel free to write your own example. | 19:28 |
| RenatoSilva | ok | 19:28 |
| mgz | it's not actually making progress on fixing the bugs here, but whatever. | 19:28 |
| RenatoSilva | heh true | 19:29 |
| lifeless | mgz: hi | 19:33 |
| lifeless | mgz: can you reproduce jams testtools failures? | 19:34 |
| mgz | lifeless: no. see the log from the other day. | 19:38 |
| mgz | and he's not been on at the same time as me since so haven't been able to bug him further about it. | 19:38 |
| mgz | ah, I see he said 2.6.4 at three that morning, I could try backing up my build to that minor version. | 19:40 |
| wolfrage | So I have a small problem. I used Bazaar Log and reverted my Git Repo to an earlier revision, just one. But GIT on the command line still shows fine. But Bazaar explorer shows like there are uncommited files. | 19:40 |
| wolfrage | How do I get Bazaar Ecplorer to see that there are no changes to be made. | 19:41 |
| maxb | The meaning of "bzr revert" is quite different from "git revert" | 19:44 |
| wolfrage | ok How do i tell bzr to go back to where it was | 19:45 |
| wolfrage | even if i choose update, it says that it is up to date, but yet it differs from working branch | 19:49 |
| wolfrage | So did i change the branch some how | 19:49 |
| lifeless | wolfrage: if bzr diff shows changes, then the tip commit refers to different content than is in your working tree | 20:04 |
| lifeless | wolfrage: I don't understand how git is related to your question though | 20:05 |
| wolfrage | lifeless: it is a local git repository. I am using bazaar to work on it, because it seems to work great as compared to the other tools | 20:06 |
| wolfrage | I used Bazaar to work through a rebase in git, and it helped alot. | 20:06 |
| wolfrage | lifeless: But now I did this revert and Bazaar shows the working tree is different. I just want all of the error messages to go away so i can continue to use it on this GIT repo agian. i will not play around with it agian like that once I do | 20:07 |
| wolfrage | lifeless: So how do I move the tip back to the working tree | 20:09 |
| lifeless | what was the revert you did, in git? | 20:09 |
| lifeless | jelmer, the author of bzr-git would be a great person to ask about this (you are using bzr-git?) but hes not around right now | 20:10 |
| wolfrage | well I did it in Bazaar explorer, GIT still shows same status. In Bazaar I was in the log and told it to revert to the revision just before the last. | 20:11 |
| wolfrage | lifeless: I was talking to jelmer earlier about a seperate issue, he is very helpful, and yes I am using bzr-git | 20:11 |
| lifeless | ok, so in bzr-explorer you said 'revert' | 20:18 |
| lifeless | what that does is changes the working tree *only* | 20:18 |
| wolfrage | lifeless: yes | 20:18 |
| lifeless | if you reverted to a particular revision using bzr-explorer | 20:19 |
| lifeless | to under it, just do 'revert' without a particular revision, again using bzr explorer | 20:19 |
| wolfrage | lifeless: OK. I appreciate you taking the time to explian it to me also. | 20:19 |
| lifeless | this will force all your files to be the same as tip. | 20:19 |
| lifeless | then, if you want to rollback the branch to a particular revision, you can use uncommit, or pull | 20:20 |
| === Ursinha is now known as Ursinha-brb | ||
| RenatoSilva | is it normal to revolve functional merge conflicts on a following commit, not in the merge commit? | 20:21 |
| RenatoSilva | I think this helps clarifying things | 20:21 |
| RenatoSilva | the merge I did fixed a problem, but my patch made it come back again, so it's a merge issue. I'm thinking of uncommitting the merge (it's the last commit) and applying it there, or just commit a new change referring to the merge in comment | 20:24 |
| wolfrage | lifeless: It did not work, it says no revisions to be pulled and for the revert it just runs with no error, but Bazaar remains the same after a refresh. | 20:25 |
| wolfrage | lifeless: What if i deleted the bzr folder | 20:25 |
| RenatoSilva | it didn't exactly made it come back again, but sort of | 20:25 |
| wolfrage | lifeless: in the git repo, would that revert it? | 20:26 |
| wolfrage | lifeless: I take it back there is a bzr folder with in .git, but it is just file lock. | 20:27 |
| RenatoSilva | btw, is there any way to see only the merge changes? That is, when you click over the merge in bzr qlog, you see changes made by the merged branch and changes made due to the merge itself. I'd like to see only the latter | 20:28 |
| lifeless | RenatoSilva: yes, the difftastic plugin | 20:29 |
| lifeless | wolfrage: sorry, I'm not sure whats going on there | 20:29 |
| lifeless | 'revert' with no revision + bzr diff should always show nothing | 20:29 |
| lifeless | if its not, its a bzr-git interaction - could you file a bug on bzr-git? | 20:29 |
| RenatoSilva | lifeless: difftastic? ok thanks | 20:30 |
| RenatoSilva | lifeless: btw do you know how is bzr-hg, iirc you were the maintainer? I need it but it doesn't work, tried last from trunk too | 20:32 |
| lifeless | jelmer is looking after i tnow | 20:36 |
| wolfrage | lifeless: seems to be more of minor error. I will try the series of commands agian. | 20:41 |
| wolfrage | then i will just keep on, as it seems to not effect anything | 20:41 |
| wolfrage | Is there an easy way to convert to an from GIT - BZR? and will it maintain compatability when it goes back to GIT? | 20:42 |
| lifeless | wolfrage: bzr branch git://... destinationpath; read the bzr-git documentation | 20:45 |
| lifeless | please file a bug - something went wrong, we should fix it | 20:45 |
| wolfrage | lifeless: I am not sure if i could even reproduce it. This branch is volitile. It just got rebased twice and has been updated from almost 13 months of inactivity | 20:50 |
| lifeless | knowing that there was a problem is often most of the battle in fixing it :) | 20:51 |
| wolfrage | lifeless: I filled a bug on an issue earlier, and I will be hanging around here, so any errors I can reproduce I will be sure to file agianst. | 20:51 |
| radix | what's that configuration parser library that bzr uses? | 20:51 |
| lifeless | configobj ? | 20:52 |
| radix | yeah, probably | 20:52 |
| wolfrage | lifeless: OK I will file. I like Bazaar as a tool, lets me program and not get stuck on the command line trying to figure out Version Control Systems... | 20:52 |
| lifeless | thanks! | 20:53 |
| === jelmer is now known as Guest28766 | ||
| === Guest28766 is now known as jelmer-n900 | ||
| poolie | jam, spiv, jelmer, udd meeting is now | 21:03 |
| RenatoSilva | how do I specify the submit branch so that bzr diff -rsubmit: will use the right branch? | 21:09 |
| RenatoSilva | hmm a useless merge, nevermind | 21:10 |
| jelmer-n900 | renatosilva: you can edit .bzr/branch/branch.conf or perhaps use bzr config | 21:10 |
| mwhudson | yeah, merge --remember will do that | 21:11 |
| jelmer-n900 | hey mwhudson | 21:12 |
| mwhudson | jelmer-n900: hello | 21:12 |
| === Ursinha-brb is now known as Ursinha | ||
| spiv | poolie: I think https://code.launchpad.net/~mbp/bzr/687653-notbrancherror/+merge/43314 probably ought to be marked rejected (for 2.2 at least) | 23:14 |
| poolie | i agree | 23:15 |
| === oubiwann-holiday is now known as oubiwann | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!