Re: can't commit files that have been git add'ed because "fatal: you need to resolve your current index first"

[Jakub Narebski <jnareb@gmail.com>]

Bill Priest wrote:

> I understand what git is doing in terms of trying to
> merge.  But it sounds like it is enforcing policy on
> the merge by not allowing me to check in files as I
> resolve them.  I have two separate branches w/ a
> similar but not identical hardware platform where I
> will always get conflicts when I merge back and forth.
>  Usually I cherry-pick between the two branches and
> this works until there are massive changes on one
> branch w/o time to move the changes to the other.  In
> the latter case I do a merge and live w/ resolving
> conflicts.I guess w/ this workflow I have more
> conflicts than is "normal".  
> 
> It seems pretty heavy handed to force all merges to be
> complete before I can commit any files; git knows
> which files are unmerged.  Does git track which files
> have been merged w/ conflicts?  I'd like the option to
> be able to check in files that I have indicated have
> conflicts resolved (maybe w/ a flag to bypass the
> checking).

Yes, git does track which files have conflict, but I don't
think it does track which files were merged on file-level
without conflicts.

The problem is that git remember which files are yet not
resolved, and remembers that it is in the middle of the
merge by remembering parents of a merge. So I think if you
want to commit before doing merge, you would have to move
MERGE_HEAD away, and commit specifying paths using
"git commit <file1> <file2>". Or you can always resort
to low-level plumbing, for example creating temporary
staging area (index) etc.

But if you want to just make some commit to be cherry-picked
for example before merge, I think it would be easier to just
stash away merge, do a commit, then unstash it.

-- 
Jakub Narebski
Poland