{"thread":{"id":"11048","subject":"Re: can't commit files that have been git add'ed because \"fatal: you need to resolve your current index first\"","startedAt":"2007-11-28T18:11:07Z","lastAt":"2007-11-28T18:11:07Z","messageCount":1,"participants":["Jakub Narebski"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"61256","messageId":"200711281911.07522.jnareb@gmail.com","threadId":"11048","inReplyTo":"993937.9873.qm@web55013.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-28T18:11:07Z","receivedAt":"2007-11-28T18:11:07Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Bill Priest wrote:\n\n> I understand what git is doing in terms of trying to\n> merge.  But it sounds like it is enforcing policy on\n> the merge by not allowing me to check in files as I\n> resolve them.  I have two separate branches w/ a\n> similar but not identical hardware platform where I\n> will always get conflicts when I merge back and forth.\n>  Usually I cherry-pick between the two branches and\n> this works until there are massive changes on one\n> branch w/o time to move the changes to the other.  In\n> the latter case I do a merge and live w/ resolving\n> conflicts.I guess w/ this workflow I have more\n> conflicts than is \"normal\".  \n> \n> It seems pretty heavy handed to force all merges to be\n> complete before I can commit any files; git knows\n> which files are unmerged.  Does git track which files\n> have been merged w/ conflicts?  I'd like the option to\n> be able to check in files that I have indicated have\n> conflicts resolved (maybe w/ a flag to bypass the\n> checking).\n\nYes, git does track which files have conflict, but I don't\nthink it does track which files were merged on file-level\nwithout conflicts.\n\nThe problem is that git remember which files are yet not\nresolved, and remembers that it is in the middle of the\nmerge by remembering parents of a merge. So I think if you\nwant to commit before doing merge, you would have to move\nMERGE_HEAD away, and commit specifying paths using\n\"git commit <file1> <file2>\". Or you can always resort\nto low-level plumbing, for example creating temporary\nstaging area (index) etc.\n\nBut if you want to just make some commit to be cherry-picked\nfor example before merge, I think it would be easier to just\nstash away merge, do a commit, then unstash it.\n\n-- \nJakub Narebski\nPoland\n"}]}