{"thread":{"id":"1902","subject":"Please undo \"Use git-merge instead of git-resolve in git-pull\"","startedAt":"2005-09-21T20:15:39Z","lastAt":"2005-09-23T00:28:44Z","messageCount":10,"participants":["Linus Torvalds","Junio C Hamano","David S. Miller","Olivier Galibert","Martin Langhoff","Petr Baudis"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"9066","messageId":"Pine.LNX.4.58.0509211310150.2553@g5.osdl.org","threadId":"1902","inReplyTo":null,"subject":"Please undo \"Use git-merge instead of git-resolve in git-pull\"","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-09-21T20:15:39Z","receivedAt":"2005-09-21T20:15:39Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\nThe new merge is totally unusable in real life.\n\nI get \n\n\tNeed real merge but the working tree has local changes.\n\nwhich is totally bogus. Sure, my working tree has local changes, but they \nhave absolutely nothing to do with the stuff I merge. I almost _always_ \nkeep local changes in my tree, and I worked hard to make sure that merging \nworks well even despite that, and does the right thing.\n\nLocal changes are a problem ONLY IF THOSE LOCAL CHANGES INTERFERE WITH THE \nMERGE.\n\nIf the new merge policies do not allow that, then the new merge policies \nare incredibly broken. The old one did exactly the right thing for this \ncase, and \"git-read-tree -m\" did\n\n\tEntry '%s' would be overwritten by merge. Cannot merge.\n\nonly if a file that actually needed merging was different.\n\n\t\t\tLinus\n"},{"id":"9068","messageId":"Pine.LNX.4.58.0509211318550.2553@g5.osdl.org","threadId":"1902","inReplyTo":"Pine.LNX.4.58.0509211310150.2553@g5.osdl.org","subject":"Re: Please undo \"Use git-merge instead of git-resolve in git-pull\"","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-09-21T20:20:34Z","receivedAt":"2005-09-21T20:20:34Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 21 Sep 2005, Linus Torvalds wrote:\n> \n> If the new merge policies do not allow that, then the new merge policies \n> are incredibly broken.\n\nI just checked.\n\nIt _is_ incredibly broken. \n\nIt will do \n\n\techo \"Rewinding the tree to pristine...\"\n\tgit reset --hard $head\n\nif any merge strategy every fails, so that check is needed for the new \nmerger.\n\nThis makes merges totally unusable. It feels like the dark ages.\n\n\t\tLinus\n"},{"id":"9075","messageId":"7vu0genlc1.fsf@assigned-by-dhcp.cox.net","threadId":"1902","inReplyTo":"Pine.LNX.4.58.0509211310150.2553@g5.osdl.org","subject":"Re: Please undo \"Use git-merge instead of git-resolve in git-pull\"","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-09-21T21:48:46Z","receivedAt":"2005-09-21T21:48:46Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> Local changes are a problem ONLY IF THOSE LOCAL CHANGES INTERFERE WITH THE \n> MERGE.\n\nTrue, sorry, and reverted.\n\n* Regardless of whatever else, we could detect when there is\n only one strategy applicable and bypass that check -- \"reset\n --hard\" should never happen in that case and 'git pull -s\n stupid' would regain the traditional behaviour and we should\n probably make this the default for 'git pull'.\n\n* Otherwise, if the user wants it to try multiple strategies, we\n need to detect the local changes in the tree that _could_\n interfere with the merge more precisely.\n\n In order for that, we need to have a way to figure out the set\n of paths that _could_ potentially be involved in the merge.\n Once we have that set, we can just check if we have local\n changes on those paths, and the \"restoring to the pre-merge\n state\" currently done with \"reset --hard\" kludge could just\n restore those paths from the pre-merge HEAD.\n\n This is however harder than it sounds once we start allowing\n renaming merges. If the ancestor had A/foo, you kept it and\n have an addition of A/bar as a local change, and the head that\n is being merged renames stuff in A/ to B/A/, it is more likely\n than not that you would want to have A/bar moved to B/A/bar in\n your merge result. Once we go this route, the only thing it\n makes sense would be to make it responsibility for each merge\n strategy to preserve before starting its work and to restore\n after it has failed.\n\n* I thought you do not multitask and wonder why you are merging\n while you still have local changes, but that does not justify\n this regression.\n"},{"id":"9076","messageId":"Pine.LNX.4.58.0509211501130.2553@g5.osdl.org","threadId":"1902","inReplyTo":"7vu0genlc1.fsf@assigned-by-dhcp.cox.net","subject":"Re: Please undo \"Use git-merge instead of git-resolve in git-pull\"","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-09-21T22:03:39Z","receivedAt":"2005-09-21T22:03:39Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 21 Sep 2005, Junio C Hamano wrote:\n> \n> * I thought you do not multitask and wonder why you are merging\n> while you still have local changes, but that does not justify\n> this regression.\n\nI've always multi-tasked, but when I started git I was ready to drop it. \nThen I came up with that wonderful \"merge in the index\" approach, and I \ncould do it again, and I was _soo_ happy.\n\nI often have local changes in my tree that I don't want to commit but that \nI'm testing out. Havign them interfere with merging other peoples work \nwould mean that I'd have to have a totally separate tree for that, which I \ncould do, but I'm much much happier not having to.\n\n\t\tLinus\n"},{"id":"9081","messageId":"20050921.172849.103555057.davem@davemloft.net","threadId":"1902","inReplyTo":"Pine.LNX.4.58.0509211501130.2553@g5.osdl.org","subject":"Re: Please undo \"Use git-merge instead of git-resolve in git-pull\"","fromName":"David S. Miller","fromEmail":"davem@davemloft.net","sentAt":"2005-09-22T00:28:49Z","receivedAt":"2005-09-22T00:28:49Z","isPatch":false,"sender":{"key":"davem@davemloft.net","avatar":null},"body":"From: Linus Torvalds \nDate: Wed, 21 Sep 2005 15:03:39 -0700 (PDT)\n\n> I've always multi-tasked, but when I started git I was ready to drop it. \n> Then I came up with that wonderful \"merge in the index\" approach, and I \n> could do it again, and I was _soo_ happy.\n> \n> I often have local changes in my tree that I don't want to commit but that \n> I'm testing out. Havign them interfere with merging other peoples work \n> would mean that I'd have to have a totally separate tree for that, which I \n> could do, but I'm much much happier not having to.\n\nYou know, I personally was unaware that this was supported until now.\nI have been always reverting local debugging changes in order to merge\nother people's work in, then reapply the debugging changes afterwards.\n\nI guess I won't have to do that any more. :-)\n\nSo as long as they don't interfere, you can keep local debugging\nchanges out of GITs way for just about anything right? For example,\nas long as you don't \"git-update-cache foo.c\" those files in your\nlocal debugging hack, you can just \"git commit\" afterwards and\nonly put in the changes you want. It won't myseriously find those\nmodified files and what to do something with them right?\n\nThis goes with the idea that GIT only works with what you tell it\nabout, I suppose.\n"},{"id":"9082","messageId":"Pine.LNX.4.58.0509211730560.2553@g5.osdl.org","threadId":"1902","inReplyTo":"20050921.172849.103555057.davem@davemloft.net","subject":"Re: Please undo \"Use git-merge instead of git-resolve in git-pull\"","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-09-22T00:39:53Z","receivedAt":"2005-09-22T00:39:53Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 21 Sep 2005, David S. Miller wrote:\n> \n> You know, I personally was unaware that this was supported until now.\n> I have been always reverting local debugging changes in order to merge\n> other people's work in, then reapply the debugging changes afterwards.\n> \n> I guess I won't have to do that any more. :-)\n\nAbsolutely. \n\nIt will happily merge a dirty tree, as long as none of the dirty files \nwere modified.\n\nAnd by \"dirty\" I mean \"index matches HEAD, but contents do not match \nindex\".\n\nIt's very convenient. I usually have my local Makefile updated for the\nnext version for a few days before actually committing it, and I tend to\nhave any experimental patches that I sent out to people uncommitted in my\ntree too, just to remind me and to test them.\n\n> So as long as they don't interfere, you can keep local debugging\n> changes out of GITs way for just about anything right? For example,\n> as long as you don't \"git-update-cache foo.c\" those files in your\n> local debugging hack, you can just \"git commit\" afterwards and\n> only put in the changes you want. It won't myseriously find those\n> modified files and what to do something with them right?\n\nThat's correct. Also, since this is how I work, I've tried to make sure \nthat the tools I work with are \"safe\". For example, git-applymbox will \nhappily apply patches to a dirty tree, because it uses \"git-apply --index\" \nthat refuses to apply a patch to a file that is modified. \n\nSo it's perfectly safe to merge somebody elses _patch_ too - even with a\ntree with patches. But git-applymbox will refuse to apply patches on a\ntree where your index doesn't match the HEAD commit. So it's safe to have\na _dirty_ tree, but if you've done an \"update-cache\" and have an index\nthat doesn't match the parent any more, git-applymbox will refuse to run.\n\n(Btw, that's something that I haven't checked whether I verified properly\nin git-read-tree.. I basically never have my index out of sync with my\nHEAD, but I should probably verify).\n\n\t\t\tLinus\n"},{"id":"9083","messageId":"20050922005455.GA93041@dspnet.fr.eu.org","threadId":"1902","inReplyTo":"20050921.172849.103555057.davem@davemloft.net","subject":"Re: Please undo \"Use git-merge instead of git-resolve in git-pull\"","fromName":"Olivier Galibert","fromEmail":"galibert@pobox.com","sentAt":"2005-09-22T00:54:55Z","receivedAt":"2005-09-22T00:54:55Z","isPatch":false,"sender":{"key":"galibert@pobox.com","avatar":null},"body":"On Wed, Sep 21, 2005 at 05:28:49PM -0700, David S. Miller wrote:\n> You know, I personally was unaware that this was supported until now.\n> I have been always reverting local debugging changes in order to merge\n> other people's work in, then reapply the debugging changes afterwards.\n\nWhy don't you commit the debugging changes, go back one step in the\ntree (reverting them through git in practice), merge other's people\nwork then merge the debugging changes back in ? You never know when\nthe debug changes will be useful again, so it's nice to have them in\nyour private tree, and this method makes it reasonably automatic.\n\n OG.\n"},{"id":"9084","messageId":"46a038f905092118464b98e149@mail.gmail.com","threadId":"1902","inReplyTo":"20050921.172849.103555057.davem@davemloft.net","subject":"Re: Please undo \"Use git-merge instead of git-resolve in git-pull\"","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2005-09-22T01:46:55Z","receivedAt":"2005-09-22T01:46:55Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 9/22/05, David S. Miller wrote:\n> From: Linus Torvalds \n> > I often have local changes in my tree that I don't want to commit but that\n> > I'm testing out. Havign them interfere with merging other peoples work\n> > would mean that I'd have to have a totally separate tree for that, which I\n> > could do, but I'm much much happier not having to.\n>\n> You know, I personally was unaware that this was supported until now.\n> I have been always reverting local debugging changes in order to merge\n> other people's work in, then reapply the debugging changes afterwards.\n>\n> I guess I won't have to do that any more. :-)\n\nUsing Cogito, we've found a couple of cases where merging on a dirty\ntree messed things up. The local changes were lost after the merge.\n\nI didn't bother to investigate further, because I didn't know whether\nit was supported \"formally\", or meant to be supported for long.\nInstead, I added a check in cg-merge that refuses to run on a dirty\ntree.\n\nI guess I'll take that out, and try and debug any future sightings of\nthe problem...\n\n\nmartin\n"},{"id":"9085","messageId":"Pine.LNX.4.58.0509211902010.2553@g5.osdl.org","threadId":"1902","inReplyTo":"46a038f905092118464b98e149@mail.gmail.com","subject":"Re: Please undo \"Use git-merge instead of git-resolve in git-pull\"","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-09-22T02:10:08Z","receivedAt":"2005-09-22T02:10:08Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 22 Sep 2005, Martin Langhoff wrote:\n>\n> Using Cogito, we've found a couple of cases where merging on a dirty\n> tree messed things up. The local changes were lost after the merge.\n\nHmm. I merge a ton of stuff, and as mentioned, I probably have a dirty \ntree at least half the time. I don't think I've seen a problem yet.\n\nBut cogito at least _used_ to have some special logic for moving patches\nforward. git-resolve-script never had that - it only ever did the per-file\nthree-way merge, and refused to touch dirty state except for the\n\"everything stays the same\" case.\n\nOh. I'm looking at the current cg-merge thing, and I think I see the\nproblem: it's doing\n\n\tgit-checkout-index -f -u -a\n\nat the end. That's not only unnecessary, since it uses the \"-u\" flag to \n\"git-read-tree\", but it will force an overwrite of the working tree, and \nis thus actively incorrect.\n\nPasky?\n\n\t\tLinus\n"},{"id":"9148","messageId":"20050923002844.GO21019@pasky.or.cz","threadId":"1902","inReplyTo":"Pine.LNX.4.58.0509211902010.2553@g5.osdl.org","subject":"Re: Please undo \"Use git-merge instead of git-resolve in git-pull\"","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-09-23T00:28:44Z","receivedAt":"2005-09-23T00:28:44Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Thu, Sep 22, 2005 at 04:10:08AM CEST, I got a letter\nwhere Linus Torvalds told me that...\n> But cogito at least _used_ to have some special logic for moving patches\n> forward.\n\nYes, but it is used only in case of fast-forward commits.\n\n> git-resolve-script never had that - it only ever did the per-file\n> three-way merge, and refused to touch dirty state except for the\n> \"everything stays the same\" case.\n> \n> Oh. I'm looking at the current cg-merge thing, and I think I see the\n> problem: it's doing\n> \n> \tgit-checkout-index -f -u -a\n> \n> at the end. That's not only unnecessary, since it uses the \"-u\" flag to \n> \"git-read-tree\", but it will force an overwrite of the working tree, and \n> is thus actively incorrect.\n> \n> Pasky?\n\nOops. How brown-paper-bag-ish. Thanks for pointing this out, that was\nobviously horribly wrong, and it was indeed apparently happily trashing\nall the local changes. I've removed it, and added proper handling for\ncases when conflicts arise from merge over a tree with local changes -\nthat was troublesome since cg-commit after resolving the conflicts would\ncommit the local changes too. It won't anymore, and cg-status will mark\nthose files appropriately. Woohoo.\n\nI've also added a rather elaborate regression testing for cg-merge, so I\nhope that will help catch any future breakages. Hmm, I have to say that\nwhile I find writing those tests incredibly boring and annoying, it is\npretty nice when I already have them. ;-)\n\nThis fix alone is worthy a release, so I'll do one tomorrow.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nVI has two modes: the one in which it beeps and the one in which\nit doesn't.\n"}]}