[16:37] hi everyone [16:37] sorry if what follows sounds like a rant, but i'm also trying to solve a problem [16:38] a collegue pushed a new rev to trunk without pulling before, so everything newer than his local status got thrown together in a single "merge-commit" and history was rewritten [16:38] basically 2 commits incl. commit-messages were lost that way [16:39] so first question: how can i resolve that? can i revert those commits somehow in the remote repo? [16:39] 2nd question: why is it even possible for someone else to rewrite history that easily? theoretically you can destroy all commits by going to a very early revision, changing something and then pushing it (cause everything that came after will be squeezed in one merge-commit) [16:57] i'm new with bzr, but from man bzr: bzr revert [FILE...] Reverse all changes since the last commit. [16:57] ochosi: [16:58] does that also affect the remote repo? [16:58] ochosi: so, he didn't lose or change any history, just changed how the graph appears [16:59] mgz: well, the commit messages are lost, and since one commit (formerly known as rev182) fixed a specific bug, it's not very nice imo [17:00] ochosi: you can prevent accidents like this by setting a config 'append_revisions_only' on your master branhc [17:00] ochosi: they are not lost [17:00] thanks, that sounds useful [17:00] ochosi: to see, do `bzr log -n0 REMOTE` where REMOTE is your master branch [17:00] can i revert that stuff somehow? [17:00] and fixing this is easy, do [17:01] well two options [17:01] the non-history rewriting way is: [17:02] `bzr branch -r-2 REMOTE fixup_mainline; cd fixup_mainline` # get the last good mainline rev before the mistake [17:02] `bzr merge REMOTE; bzr commit -m "Merge so and so's changes with the mainline set correctly"; bzr push` [17:03] you can also just take the last good rev, merge his base branch properly, and push --overwrite it [17:03] ochosi: hope that helps [17:04] mgz: so going back to the last good commit and doing "bzr push :parent --overwrite" will do away with whatever followed? [17:04] (just to be sure, i dont wanna mess things up more than they already are) [17:04] yes, but that's the big hammer method, and you don't really need it [17:04] just flip the mainline back to the right thing [17:05] by getting the last mainline rev you want, and merging current tip into it and pushing [17:06] yeah, i can grab the commit that's there (before the merge), commit it locally and then push all that [17:06] thanks a lot mgz [17:06] last question, how do i quickly set the append_revision_only setting? [17:07] (sorry, usually using git, so i'm a bit new to bzr...) [17:08] ochosi: `bzr config -d REMOTE --scope=branch append_revisions_only=True` and test it by then doing `bzr uncommit REMOTE` which should complain at you [17:08] will do that, thanks a bunch for the super-fast and terrific support! [17:14] mgz: all sorted out, thanks again! [17:14] hey mgz :) [17:15] jelmer! :) [17:16] seem zygmynt's funny plan? [17:16] *seen === BasicMBP is now known as BasicOSX [18:33] mgz: hmm? [18:34] zyga: wondered is jelmer had seen your announcement, as it's one of the things we discussed with vila before xmas [18:35] (python 3) [18:35] mgz: oh, what do you think about that then? [18:35] mgz: I haven't touched bzr since weekend but I'm slowly inclined to go through 2.7 cleanup phase were I drop the level of flake8 noise before running 2to3 en-masse [18:36] (I had like three different attempts so far) [18:36] I think you worded it a little strongly initially, dropping python 2 and the whole test suite sounded silly, but there's no reason to treat this as a fork rather than bzr 3 I don't think [18:36] zyga: that does seem like a reasonable plan [18:36] I don't intend to drop the test suite, I certainly didn't meant that :) [18:36] right, you did clarify that :) [18:37] I meant that if I get to write new code I won't really go to that level of testing as bzr has now, because it's going to take even more time and I want to see if this idea can work or not faster than that [18:37] I do intend to keep the test suite :) [18:37] that would be pretty nutty to remove it [18:38] mgz: so what were your ideas for python3? [18:38] just slog through it, and don't try to maintain compat after a major release [18:38] 2.x compat? [18:39] there are old major releases for python 2 support [18:39] yeah, I think thats reasonable, python3 was around for a long time now [18:39] and it's far easier to remove various fallbacks and maybe, just maybe, use newer features [18:39] one thing I was thinking about later was launchpad [18:39] but since I explicitly forked launchpad can stayon bzr forever [18:40] I don't even imagine how big launchpad porting effort would be [18:58] zyga: sorry, what about launchpad? [19:36] rozzin: if bzr trunk and subsequent releases moved to 3.x, dropping 2.x support, lauchpad would be locked out [19:36] zyga: Ah. You meant "bzr" as opposed to "bzr3". [19:39] mgz: yeah, I did see the announcement! [19:39] rozzin: yeah [19:40] rozzin: looking at to what mgz mentioned, if bzr itself moved to python3 [19:40] mgz, zyga: I think dropping support for older formats is a good idea [19:40] not really convinced of the usefulness of porting to python3 at this point [19:40] jelmer: right, since they are obsolete and 2.6 can convert all the way to 2a [19:41] jelmer: it's for fun really, there's is some usefulness but more for what I need [19:41] zyga: ah, fair enough [19:42] looking at the code I think it's also reasonable to drop some transports [19:42] bzr really needs, local, http and ssh [19:42] zyga: it really depends on what your eventual goal is [19:42] the rest are probably dead as users anyway [19:43] jelmer: not sure yet, I have a pipe dream of git format as native bzr format [19:43] jelmer: immediate goal is bzrlib in python3 for my scripts / tools [19:43] zyga: If you're aiming for this to be a long-term project rather than an incidental hobby project, then I have other reservations too (-: [19:43] jelmer: shoot :) [19:43] jelmer: you never know [19:44] zyga: since moving it to a separate launchpad project (and dropping python2.x) would effectively split the already small community [19:53] jelmer: I see what you mean, I'm not saying no, right now there is no community for bzr3 that isn't the existing bzr community, if this works out I'll rethink how to continue, now I need to find a moment to work on the code [19:55] zyga: fair enough [20:58] jelmer: It seems like moving to python3 may be useful as a sort of social signal, even if that's all it is: people look at bzr/python2 and think "the project isn't even being kept up to date with the current Python", which supports "bzr is a dying/dead project". [21:29] jelmer: Ah, hi there ;) LTNS === lfaraone_ is now known as lfaraone