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

1 messages from 2007-11-30 to 2007-11-30. Participants: Bill Priest.
Thread: https://gitlist.dev/t/11068

## Bill Priest, 2007-11-30 16:32

Subject: Re: can't commit files that have been git add'ed because "fatal: you need to resolve your current index first"
Message-ID: <379331.84167.qm@web55014.mail.re4.yahoo.com>
URL: https://gitlist.dev/e/379331.84167.qm%40web55014.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:
> 
> 	$ 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 

```