=== r0bby is now known as robbyoconnor === zyga__ is now known as zyga === zyga is now known as zyga-food [09:00] morning [09:00] morning mgz [09:03] Oh, not again. [09:03] 'fraid so fullermd [09:03] So, I guess the lack of response means that nobody else is bothered by that wretched uncommit log output? [09:08] you mean the thing where it says from revX to revX that you posted? [09:08] Yah. [09:09] it's not great, don't think we have a neat way of printing rev ranges for logging, but adding three lines to fix it would be accepted if proposed I'd think [09:09] Well, I'd imagine not so much "add a neat way" as "fix the bug"... === zyga-food is now known as zyga [09:11] It's already obviously trying to print both. It's just failing. [09:12] hm, that's not how I saw it [09:13] looked like it was just handling the case where the first rev removed is the same as the last rev removed (ie, uncommiting one rev only) [09:14] I read the log message as [intending to be] meaning "uncommitting from [old head that's disappearing] to [new head]" [09:15] it's clearly not clear :) [09:19] If that's not what it's trying to express, definitely not... it hadn't occured to me that it _could_ be meaning anything else. === zyga_ is now known as zyga [10:42] what's the git equiv. of `bzr info`? [10:43] just bzr info should work, but bzr-git isn't showing me the origin url [10:43] I guess `cat .git/config` works [10:44] For showing locations, I think something under 'git remote'? [10:45] seems `git remote -v show` does something reasonable there [10:46] ...with show not being required [10:46] Now if you'll excuse me, I have to go cry in a corner at the realization that I had that bit of info in my head... === yofel_ is now known as yofel [12:47] quick stupid question (should be straightforward but just can't figure it out right now): i have a bare remote repo, which i want to revert to a previous revision [12:47] bzr push -r doesn't change the remote revision [12:48] update and revert also don't work since they only affect trees, not branches [12:48] how can this be done? [12:49] obviously i could delete the branch and re-create it, but i figured there must be an easier way? [12:50] ok, i could edit .bzr/branch/last-revision, but that seems even less straightforward [12:50] in case it matters: the branch is part of a tree-less shared repo [13:02] frathgeber: push --overwrite -r REV [13:06] nope, tried that [13:07] note that the local and remote branches haven't diverged [13:07] i just want go back to a previous revision on the remote branch [13:07] What happens when you try that? [13:08] behavious is the same as without --overwrite [13:08] (e.g. do you get an error or warning, or anything like that?) [13:08] actually thinking about it my question doesn't have anything to do with remote or bare branches [13:09] bzr push --overwrite -r REV LOCATION_OF_BRANCH [13:09] the same goes for a local branch: how do i revert to a previous revision? [13:09] (perhaps your default push location is not the location you want to change) [13:09] i know i can revert the tree using update -r or revert -r [13:09] no, also not the problem [13:09] I use push --overwrite or pull --overwrite to do that. [13:09] Does it give any output at all? [13:09] you're sure that works? [13:10] Yes, or I wouldn't keep suggesting it :) [13:10] it says no revisions to push [13:10] (This is exactly what the --overwrite option is for) [13:10] is your remote branch using a shared repo? [13:10] Ah, yes, but did you check if the branch changesd? [13:10] the overwrite option is for pushing despite the local and remote branches have diverged in my understanding [13:11] it doesn't [13:11] More generally, --overwrite is for forcing the branch's last-revision to change w/o the divergence or going-backwards check. [13:12] ok, that would make sense and suggest it should work for my case [13:12] odd [13:13] The "no revisions to push" message is a bug here, really. It's technically correct (to make the branch point to an older revision requires transferring no new revisions, because obviously they're already there), but gives a misleading impression. [13:13] i figured out the bug [13:13] the order of arguments matters [13:13] push -r --overwrite doesn't work, push --overwrite -r does [13:13] that is an actual bug [13:14] I really doubt that makes a difference. If it does then please do file a bug. [13:14] But that would be hugely surprising. [13:15] odd, can't reproduce it now [13:15] but it defintely didn't work when i tried it before [13:15] How were you verifying? [13:17] first of all it said 'no new revisions to push' in both cases, i still have it right there in my shell [13:18] also i checked .bzr/branch/last-revision [13:18] which was unchanged [13:19] Like I said, "no new revisions to push" is expected in this case. [13:20] Checking .bzr/branch/last-revision or the output of "bzr revision-info -d LOCATION" would be definitive. [13:22] in the successful case it prints 'pushed up to revision ' [13:27] can reproduce it now [13:28] and the order of parameters doesn't matter [13:28] it doesn't work either way [13:29] explicit push location doesn't help either [13:29] even more irritating: it works when i pushe the very same branch to the very same remote shared repo under a different name [13:30] subsequently i can revert the tip [13:32] now i can't any more, remains broken [13:33] frathgeber: please file a bug [13:33] frathgeber: --overwrite should work (or give a clear error if it needs to fail, e.g. because branch.conf has append_revisions_only = true. [13:34] (or whatever the spelling of that option is) [13:35] it's even more irritating [13:36] if i initially create the remote branch with a push -r [13:36] subsequent push --overwrite -r work [13:37] if i initially create the remote branch with a plain push subsequent push --overwrite -r do nothing [13:47] frathgeber: I strongly suspect there's something wrong in your diagnosis [13:48] frathgeber: because how a branch is created just doesn't vary interestingly because you used push vs push -r [13:49] frathgeber: but feel free to check by diff'ing the resulting .bzr/branch directories [13:49] frathgeber: unfortunately I need to sleep now so I can't help you narrow down your problem any further [13:49] frathgeber: good luck [13:53] how can I see the version from ~2003 of http://bazaar.launchpad.net/~openerp/openobject-server/6.1/files/head:/openerp/report/render/rml2pdf/ ? [13:54] i did [13:54] literally the only difference is .bzr/branch/last-revision [13:55] spiv: thanks for your help! [13:57] ciupicri: through the web UI alone: with difficulty (click "view branch changes" and page through the results and/or url hack) [13:58] ciupicri: with the bzr command line, something like "bzr log -r date:2003-01-01 lp:~openerp/openobject-server/6.1" (it won't be as fast as it could be in principle, but it should work) [13:59] ciupicri: (and then once you've found the rev using bzr log jump to that revision in the web site, or use other bzr commands to view the contents) [14:00] ciupicri: FWIW, the earliest rev in that branch dates to 2006 [14:00] spiv, the comand line is fine [14:00] ciupicri: http://bazaar.launchpad.net/~openerp/openobject-server/6.1/changes/1 [14:00] spiv, so I should check the trunk branch? [14:00] Perhaps, depends on how the branches were created [14:01] Or possibly that old history was discarded rather than imported into bzr [14:02] spiv, ok, I'll rephrase my request: how can I get the oldest code possible on my hard disk? I have run `bzr branch lp:openobject-server/6.1 6.1' and I would like to see how the project looked some time ago [14:02] -r 1 [14:03] Well, that's for a given branch [14:03] But how to find the branch with the oldest data is more a problem for Google than bzr... [14:03] bzr and what command? checkout? [14:03] Most bzr commands accept -r, including checkout and branch [14:04] Anyway, I really should sleep. [14:04] G'night all [14:04] thanks === deryck is now known as deryck[lunch] === deryck[lunch] is now known as deryck === abner` is now known as abner