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

From: Bill Priest <priestwilliaml@yahoo.com>
Date: Nov 30, 2007, 16:32 UTC
Message-ID: <379331.84167.qm@web55014.mail.re4.yahoo.com>

On Wed, 28 Nov 2007 12:08:40 -0800 Junio C Hamano <gitster@pobox.com> wrote:

> You can still do that by hand, by doing something

like:

Show 10 quoted lines

> 
> 	$ git merge --squash A
>         $ resolve only partly
>         $ git commit -m 'Prepare to merge A'
>         $ git reset --hard
>         $ git merge A
> 	$ resolve the rest
>         $ git commit -m 'Fully merged A'
> 
> For such a multi-step merge to make sense, the

change between B---M

> should make sense by itself for people who have to

read such a history

> later.  Such a half-a-squash-merge may probably not

make sense by itself

> in most cases, so I suspect the above workflow would

not be useful in

> general.
>

Junio,
	I resolved all the merges and then committed
different files as groups to make it easy to
cherry-pick after this merge.  Does this "mess up" the
merge info?  What does the "git reset --hard" do after
the commit (I'm assuming it throws away the
non-resolved changes not committed)?  But from my
experience git wouldn't let me do the commit above it
w/o first fixing the conflicts.

	Am I mis-interpreting your example or are you saying
that you think git would let me do the commit w/o
resolving all conflicts?

Bill

      ____________________________________________________________________________________
Get easy, one-click access to your favorites. 
Make Yahoo! your homepage.
http://www.yahoo.com/r/hs