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

From: Bill Priest <[email-masked]>
Date: Fri, 30 Nov 2007 08:32:17 -0800 (PST)

On Wed, 28 Nov 2007 12:08:40 -0800
Junio C Hamano <[email-masked]> wrote:

> You can still do that by hand, by doing something
like:
> 
> 	$ 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