| RenatoSilva | I think if it doesn't conflict with any further revision, there could be a way to do it, it's just reverting the diff (because of no conflicts, it'd be just like undoing the revision manually) | 00:00 |
|---|---|---|
| Noldorin_ | explain what you mean first | 00:00 |
| RenatoSilva | Noldorin_: I'm not NES. Non-last is one that is not the last, that is, one from 1..-2 | 00:01 |
| RenatoSilva | revert is undoing the changes | 00:01 |
| Noldorin_ | RenatoSilva, "revert a revision" is not well-defined though... we normally talk about "revert a working-tree" :-) | 00:01 |
| RenatoSilva | Noldorin_: imagine revisions 1..230 | 00:01 |
| RenatoSilva | Noldorin_: the changes made by revision 222 need to be undone. I don't want to do this manually | 00:02 |
| RenatoSilva | Noldorin_: that is, if the diff was -foo+bar, I need to -bar+foo, got it? | 00:02 |
| Noldorin_ | RenatoSilva, ah i see | 00:02 |
| Noldorin_ | RenatoSilva, so not "Revert" in ths bzr sense | 00:03 |
| Noldorin_ | RenatoSilva, no that is not possible | 00:03 |
| Noldorin_ | with any VCS i know | 00:03 |
| RenatoSilva | Noldorin_: no, not $bzr revert | 00:03 |
| fullermd | A better term would be 'reverse'. | 00:03 |
| Noldorin_ | it would require major changes to the way DVCS branches work. | 00:03 |
| Noldorin_ | fullermd, indeed | 00:03 |
| fullermd | You can do it with merge. | 00:03 |
| fullermd | You can't _remove_ the rev. But you can make a new rev that _reverses_ it. | 00:03 |
| Noldorin_ | RenatoSilva, just commit the "un-diff" of that changeset | 00:04 |
| Noldorin_ | fullermd, oh, with merge? | 00:04 |
| RenatoSilva | what's the diff between revert and reverse terms? Revert is rollback to a previous state, reverse is inverting/undoing? | 00:04 |
| fullermd | The change you want to reverse is describable as "221..222" in this case. So the reverse of it is "222..221" | 00:04 |
| Noldorin_ | RenatoSilva, pretty much correct, yes | 00:04 |
| fullermd | So a `bzr merge -r222..221 .` (don't miss that last '.', to tell it 'merging from myself') would use the merge logic to reverse the changes, taking into account the stuff since then. | 00:04 |
| RenatoSilva | fullermd: I don't want to remove the rev, ok with new rev undoing it | 00:04 |
| Noldorin_ | there's inverse, converse, reverse...it's a bit confusing even to a NES sometimes! | 00:05 |
| fullermd | (which may Just Work all shiny, or may have a giant pile of conflicts, depending on what all has happened since. Luck of the draw.) | 00:05 |
| RenatoSilva | what if I miss the dot? | 00:05 |
| Noldorin_ | fullermd, self-merging? and that simply modifies the working-tree? | 00:05 |
| Noldorin_ | RenatoSilva, command won't run | 00:06 |
| Noldorin_ | you need a merge source | 00:06 |
| fullermd | It'll run, it'll just try to use the existing default merge source. Which may not be what you want. | 00:06 |
| Noldorin_ | oh, fair point | 00:06 |
| Noldorin_ | but yeah, not appropiate. | 00:06 |
| fullermd | Conceptually, it'll do the same thing as `bzr diff -r222..221 | patch` (a.k.a, diff -r221..222 | patch -R; same thing). So it leaves changes int he working tree. | 00:06 |
| RenatoSilva | so "dot matters" | 00:07 |
| Noldorin_ | yes | 00:07 |
| Noldorin_ | it's crucial. | 00:07 |
| fullermd | (it's better than just diff | patch of course. It'll take into account renames since then, for instance, and deal with lots of shifted-around lines. But if the lines in question are themselves changed, it's gonna get ugly and rely on Natural Intelligence resolution methods) | 00:07 |
| fullermd | It would still work right if, for instance, the default merge source were the parent branch, which was just an exact mirror. | 00:08 |
| fullermd | Or any time when 221 and 222 in whatever branch is resolves to are the same as the ones you have here. | 00:08 |
| Noldorin_ | fullermd, to clarify: bzr merge -r -1..221 is equivalent to bzr revert -r 221 right? | 00:08 |
| Noldorin_ | or bzr revert -r 220 perhaps | 00:08 |
| fullermd | But it would take way longer to check if that was true than to just give it the . ;) | 00:08 |
| fullermd | It would be 221; remember that revs denote _states_, not _changes_. | 00:09 |
| RenatoSilva | Natural Intelligence resolution methods => it will just point out conflicts to be solved manually right? or is it worse? | 00:09 |
| fullermd | I'd certainly call it 'roughly equivalent' at least. I'd have to think a lot more to convince myself the end result would be exactly the same. | 00:09 |
| fullermd | It'd certainly be slower anyway... you could use merge (with --force) to have uncommitted changes kept around. | 00:09 |
| Noldorin_ | fullermd, yeah...interesting. if there are differences, they must be subtle... | 00:10 |
| fullermd | RenatoSilva: Yah. I was being a bit whimsical, compared to Artifical Intelligence. Merges are just textual, and if they don't just resolve, it would take an entity understanding the code semantics (e.g., the programmer) to make it right. | 00:10 |
| RenatoSilva | fullermd: ok fullermd, big thanks. It's nice to think something could exist and it actually does :) | 00:12 |
| Noldorin_ | anyone here got bzr-git working on Windows? | 00:14 |
| RenatoSilva | here's the issue (three last comments): https://code.launchpad.net/~renatosilva/bzr-eclipse/cleanup/+merge/68626 | 00:18 |
| RenatoSilva | done, thanks all! https://code.launchpad.net/~renatosilva/bzr-eclipse/cleanup/+merge/68626 | 00:36 |
| Noldorin_ | jelmer, bug report at https://bugs.launchpad.net/bzr-git/+bug/818318. | 01:11 |
| ubot5 | Ubuntu bug 818318 in Bazaar Git Plugin "Error using dpush" [Undecided,New] | 01:11 |
| Noldorin | hey jelmer | 06:51 |
| bogglin | when I run bzr branch bzr://bzr.savannah.gnu.org/emacs/trunk emacs I get the following error: bzr: ERROR: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist. | 09:25 |
| bogglin | how can i fix that? | 09:25 |
| bogglin | this is bzr from macports on OS X | 09:26 |
| === yofel_ is now known as yofel | ||
| jelmer | bogglin: hi | 10:26 |
| jelmer | does "bzr revno bzr://bzr.savannah.gnu.org/emacs/trunk" work? | 10:27 |
| bogglin | jelmer: thanks for your help - but I switched to git clone and that worked, so I guess this is a solved problem | 10:27 |
| Lekensteyn | Is it possible to ignore certain files when checking out, or even checkout a single directory without having to download the whole history? http://stackoverflow.com/q/6870801/427545 | 10:56 |
| jelmer | Lekensteyn: it's not possible to check out a single directory or anything like that | 10:59 |
| jelmer | Lekensteyn: that said, it seems like a bug that it needs that much traffic | 11:00 |
| Lekensteyn | This is a related bug: https://bugs.launchpad.net/loggerhead/+bug/240580 | 11:01 |
| ubot5 | Ubuntu bug 240580 in loggerhead "Ability to download a tarball for a revision" [Low,In progress] | 11:01 |
| === Lekensteyn is now known as Lekensteyn|away | ||
| kgoetz | bzr does sometimes use bizzare amounts of bandwidth for stuff :/ | 11:06 |
| jelmer | 2.4 should be a lot better in that regard | 11:07 |
| kgoetz | would hte server need to be 2.4 too? | 11:13 |
| jelmer | I'm not sure | 11:18 |
| kgoetz | ok. i'll see next time i do 'stuff' with savannah :) | 11:19 |
| kgoetz | thanks | 11:19 |
| jelmer | kgoetz: oh, that reminds me | 11:36 |
| jelmer | I need to upload some bzr backports for squeeze | 11:37 |
| === Lekensteyn|away is now known as Lekensteyn | ||
| idnar | why is bzr rebase telling me "No revisions to rebase"? | 14:54 |
| idnar | I think this has something to do with having merged from the target branch, but I'm not sure what to do now | 14:54 |
| jelmer | idnar: yeah, you can't rebase after merging because the changes are already present | 14:54 |
| idnar | so... I guess I don't understand rebasing then | 14:55 |
| jelmer | is there a particular reason you want to rebase? | 14:56 |
| idnar | I decided to extract some changes from this branch into another one, and now I want to rebase on that, so I thought the conflicts might be easier to deal with if I rebased on trunk first | 14:57 |
| idnar | anyway I guess I'll just do the other rebase directly | 14:59 |
| idnar | (maybe I should always rebase feature branches instead of merging from trunk) | 14:59 |
| jelmer | idnar: merging trunk should work better than rebase to prevent conflicts | 15:01 |
| idnar | well, I managed to do this replay anyway, but I had some really weird conflicts | 15:05 |
| idnar | I guess that's mostly due to hand-cherry-picking stuff into the other branch to separate it out | 15:06 |
| === in3xes_ is now known as in3xes | ||
| === in3xes_ is now known as in3xes | ||
| Noldorin | hi jelmer | 20:28 |
| Noldorin | jelmer, hopefully you're around now.. | 20:31 |
| === yofel_ is now known as yofel | ||
| Noldorin | jelmer, ? | 21:20 |
| jelmer | Noldorin: hi | 21:57 |
| jelmer | Noldorin: just popping in for a minute or so, will be out for most of the night | 21:58 |
| jelmer | Noldorin: can you file a bug about the issue you saw? I can reproduce it here | 21:58 |
| === medberry is now known as med_out | ||
| Noldorin_ | jelmer, i already did :-P | 22:28 |
| Noldorin_ | jelmer, i linked you to it | 22:28 |
| Noldorin_ | jelmer, https://bugs.launchpad.net/bzr-git/+bug/818318 | 22:29 |
| ubot5 | Ubuntu bug 818318 in Bazaar Git Plugin "Error using dpush" [Undecided,New] | 22:29 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!