{"thread":{"id":"11042","subject":"can't commit files that have been git add'ed because \"fatal: you need to resolve your current index first\"","startedAt":"2007-11-28T15:48:27Z","lastAt":"2007-11-28T20:08:40Z","messageCount":3,"participants":["Bill Priest","Jakub Narebski","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"61221","messageId":"820179.5481.qm@web55002.mail.re4.yahoo.com","threadId":"11042","inReplyTo":null,"subject":"can't commit files that have been git add'ed because \"fatal: you need to resolve your current index first\"","fromName":"Bill Priest","fromEmail":"priestwilliaml@yahoo.com","sentAt":"2007-11-28T15:48:27Z","receivedAt":"2007-11-28T15:48:27Z","isPatch":false,"sender":{"key":"priestwilliaml@yahoo.com","avatar":null},"body":"All,\n  I merged from one branch to another and had lots of\nconflicts.  I've resolved a set of files from the\nconflicts (in a directory) and did a git-add on this\nset of files.  I wasn't able to commit these files. \nOn IRC I was told that all files must be resolved\nbefore I can commit any of them.  This seems pretty\nlimiting.  Why is a commit after a merge all or\nnothing; I thought that git  figured out merges and\nsuch by the differences between files??\n\nBill\n\n\n\n      ____________________________________________________________________________________\nBe a better sports nut!  Let your teams follow you \nwith Yahoo Mobile. Try it now.  http://mobile.yahoo.com/sports;_ylt=At9_qDKvtAbMuh1G1SQtBI7ntAcJ\n"},{"id":"61225","messageId":"fik2ua$i8b$1@ger.gmane.org","threadId":"11042","inReplyTo":"820179.5481.qm@web55002.mail.re4.yahoo.com","subject":"Re: can't commit files that have been git add'ed because \"fatal: you need to resolve your current index first\"","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-11-28T15:53:47Z","receivedAt":"2007-11-28T15:53:47Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Bill Priest wrote:\n\n> All,\n>   I merged from one branch to another and had lots of\n> conflicts.  I've resolved a set of files from the\n> conflicts (in a directory) and did a git-add on this\n> set of files.  I wasn't able to commit these files. \n> On IRC I was told that all files must be resolved\n> before I can commit any of them.  This seems pretty\n> limiting.  Why is a commit after a merge all or\n> nothing; I thought that git  figured out merges and\n> such by the differences between files??\n\nYou have to resolve _conflicts_ only. The rest is added\nautomatically. See git-status, git diff --merge,\ngit ls-files -u.\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"61280","messageId":"7v63zm5e0n.fsf@gitster.siamese.dyndns.org","threadId":"11042","inReplyTo":"820179.5481.qm@web55002.mail.re4.yahoo.com","subject":"Re: can't commit files that have been git add'ed because \"fatal: you need to resolve your current index first\"","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-11-28T20:08:40Z","receivedAt":"2007-11-28T20:08:40Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Bill Priest <priestwilliaml@yahoo.com> writes:\n\n>   I merged from one branch to another and had lots of\n> conflicts.  I've resolved a set of files from the\n> conflicts (in a directory) and did a git-add on this\n> set of files.  I wasn't able to commit these files. \n> On IRC I was told that all files must be resolved\n> before I can commit any of them.  This seems pretty\n> limiting.\n\nYou have two parallel development lines that lead to A and B and trying\nto come up with a \"merge\" M:\n\n         o---o---A\n        /         \\\n    ---o---o---B---M\n\nWhat property should the merge commit \"M\" have?  It must keep the\nchanges made on the upper line to make it better than B, and it must\nkeep the changes made on the lower line to make it better than A.\n\nLet's say both upper and lower lines of development touched files frotz\nand xyzzy in overlapping, different ways.  You try to merge A while you\nare at B and see conflicts in these two files.\n\nLet's say you resolved frotz; the contents in frotz is in a desired\nshape, i.e you have the changes you want from the line led to A and the\nother line led to B.  But you haven't resolved xyzzy yet.\n\nYou seem to want to make this half-resolved state as a commit.  First\nquestion: what contents would you want to commit for xyzzy?\n\nIf you commit the contents from B (because you started from it), then it\nshould not be recorded as a proper merge.  If you did so, merging that\nback to A would obliterate all the work done up to A to file xyzzy:\n\n         o---o---A...X\n        /         \\ .\n    ---o---o---B---*\n \nbecause merge base of A and * (I am marking it differently because such\nan incomplete merge should not be made) is A, so the result (X) will be\nthe half-merge * itself (fast forward).  That's not a merge as it is not\nbetter than A -- you discarded improvements made to xyzzy by people who\nbuilt up to A.\n\nThis is inherent to what a merge is.  With proper understanding of what\na merge is, you would not feel this limiting at all.\n\nHaving said that, I think something like the following _could_ be done,\nalthough I do not know if it makes much sense.\n\n(1) Try merge, see it conflict, resolve only a part of it, and record\n    the result as \"WIP to merge in A\".  Do not record it as a merge, as\n    it is not.  diff between B and M will contain a squash merge of A on\n    top of B minus the changes to the path xyzzy.\n\n         o---o---A\n        /         \n    ---o---o---B---M\n\n(2) Fix up the conflicts in xyzzy to resolve the conflicts fully, and\n    record the result as \"Final merge of A into B\".  This should be\n    recorded as a merge, as the result is \"keeping changes done on both\n    branches to come up with something better than either of them.\"\n\n         o---o---A---,\n        /             \\\n    ---o---o---B---M---N\n\nIf you look at the topology a bit differently, the above actually makes\nsome sense:\n\n         .---o---o---A\n        /             \\\n    ---o---o---B---M---N\n\nThat is, instead of merging A into B, you made \"preparatory changes\" to\nbranch B in order to make it easier to merge A.  That's what the commit\nM is about.\n\nThen you merge A on top of M.  In reality, because the difference\nbetween B to M contains most of the squash merge of A into B, such a\nmerge N will contain many accidental clean merges.  But in git,\naccidental clean merges are not a problem (people can apply the same\npatch to their trees and later their branches can be merged).\n\nBut \"git commit\" after a conflicted merge will always create a merge,\nand there is no canned option to do multi-step merge like the above.\n\nYou can still do that by hand, by doing something like:\n\n\t$ git merge --squash A\n        $ resolve only partly\n        $ git commit -m 'Prepare to merge A'\n        $ git reset --hard\n        $ git merge A\n\t$ resolve the rest\n        $ git commit -m 'Fully merged A'\n\nFor such a multi-step merge to make sense, the change between B---M\nshould make sense by itself for people who have to read such a history\nlater.  Such a half-a-squash-merge may probably not make sense by itself\nin most cases, so I suspect the above workflow would not be useful in\ngeneral.\n"}]}