Re: commiting while the current version is in conflict

From: Jakub Narebski <jnareb@gmail.com>
Date: Oct 17, 2008, 09:16 UTC
Message-ID: <m3d4hzk2du.fsf@localhost.localdomain>
In-Reply-To: <2d460de70810170021q5daa902er1e6e2fb6633400ec@mail.gmail.com>

"Richard Hartmann" <richih.mailinglist@gmail.com> writes:

> On Fri, Oct 17, 2008 at 01:39, Junio Hamano <junio@twinsun.com> wrote:

Show 12 quoted lines

> >  (2) pre-commit hook is a last ditch effort to help ignorant
> >     users who have already done "git add" without thinking and
> >     lost the "unmerged" state.  It has to look at and guess at
> >     the contents for that.
> 
> Ignoring the ad hominem attack, I would argue that the two
> distinct mental concepts of 'I want to commit this in the next
> commit' and 'I have resolved this conflict' should have two
> distinct commands.
>
> To err is human, which is why rm -i exists. Else, you could
> just use alias rm='rm -rf'.

>From time to time somebody proposes to add a command which is used

only to say that given conflict got resolved, i.e. yet another porcelain "around" git-update-index plumbing (in addition to git-add, git-mv and git-rm). One of problems is how to call it: git-resolve, git-resolved, git-mark-resolved?

BTW. while I usually use "git commit -a", when comitting merge commit I usually use explicit "git add" together "git commit" (without '-a').

-- 
Jakub Narebski
Poland
ShadeHawk on #git