Re: commiting while the current version is in conflict

From: Shawn O. Pearce <spearce@spearce.org>
Date: Oct 16, 2008, 23:00 UTC
Message-ID: <20081016230035.GC9877@spearce.org>
In-Reply-To: <20081016224808.GO536@genesis.frugalware.org>

Miklos Vajna <vmiklos@frugalware.org> wrote:

Show 7 quoted lines

> 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.

Show 6 quoted lines

> > 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.