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