From: Shawn O. Pearce <spearce@spearce.org>
Date: Thu, 16 Oct 2008 23:00:35 GMT
Subject: Re: commiting while the current version is in conflict
Message-ID: <20081016230035.GC9877@spearce.org>
In-Reply-To: <20081016224808.GO536@genesis.frugalware.org>

Miklos Vajna <vmiklos@frugalware.org> wrote:
> On Fri, Oct 17, 2008 at 12:10:55AM +0200, Richard Hartmann <richih.mailinglist@gmail.com> wrote:
> > all changes were submitted. Of course, I now have a
> > file with the conflict markers inlined in my repository. Not
> > a good thing, imo. Is there a way to make git block all
> > conflicting versions?
> 
> Write a pre-commit hook that checks for conflict markers?

The sample pre-commit hook checks for these.  Its really hande to
have enabled.
 
> > Also, I would be interested in the design decissions
> > behind the current behaviour. Any pointers?
> 
> Not sure, but in general blocking conflict markers by default would be a
> bad idea IMHO, several markup language (asciidoc, for example) makes use
> of the >>>, === and such character sequences.

Not only that, but "git commit -a" did exactly what you asked it to do:

	git add -u
	git commit

and git add -u is basically a faster way to do something like this pseudo-shell:

	for path in $(git status | grep modified:)
	do
		git add $path
	done

and merge conflicts are "resolved" by you running "git add $path"
after you have finished fixing that path.

Moral of the story is, don't use "git commit -a".  Use only "git commit"
and stage files individually.  That way when you are in a merge conflict
you won't be in the habit of writing "git commit -a" and staging everything
from the working tree implicitly.

-- 
Shawn.