commiting while the current version is in conflict

Hi all,

I fooled around with git a liitle bit and noticed something rather strange. I merged two branches, creating a conflict on purpose. When I then did a

 git commit -a

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?

Also, I would be interested in the design decissions behind the current behaviour. Any pointers?

Thanks, Richard

On Fri, Oct 17, 2008 at 12:10:55AM +0200, Richard Hartmann <richih.mailinglist@gmail.com> wrote:

Write a pre-commit hook that checks for conflict markers?

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.

Miklos Vajna <vmiklos@frugalware.org> wrote:

The sample pre-commit hook checks for these.  Its really hande to
have enabled.
 

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.

On Fri, Oct 17, 2008 at 01:00, Shawn O. Pearce <spearce@spearce.org> wrote:

Thanks.

True, git add is an implicit resolving, I did not think about it this way. Personally, I think that git should break at this point, but that's just me.

The obvious fix would be a pre-add hook. Does anyone else think this would make sense?

Judging from the code in the pre-commit script, git does not keep conflict information in its metadata cache, but tries to guess conflicts from the file's contents/ This seems to be a strange thing to do, imo. What's the reason for this?

Richard

On Thu, Oct 16, 2008 at 7:26 PM, Richard Hartmann <richih.mailinglist@gmail.com> wrote:

That would be awesome. I've frequently been bitten by accidentally running "git add" on a file that I *think* I've resolved the conflicts on, but it turns out I missed a commit marker or two. And then the handy conflict-style "git diff" is no longer available, among other things. If "git add" could prevent me from adding the file at all, it might save me some trouble.

On the other hand, an even better alternative would be to have a way to "unadd" a file and bring back the conflict information, but I don't know how that would really work.

Have fun,

Avery

On Fri, Oct 17, 2008 at 00:48, Miklos Vajna <vmiklos@frugalware.org> wrote:

Doesn't git keep metadata about conflicts, as well?

Richard

Richard Hartmann <richih.mailinglist@gmail.com> wrote:

Yes, in the index. But it erases it when you stage the file with "git add".

Go look at my prior message about how "git commit -a" is staging the files prior to commit. That makes git commit think everything has been resolved, because you've told git, everything is resolved.

On Fri, Oct 17, 2008 at 01:23, Shawn O. Pearce <spearce@spearce.org> wrote:

This makes a good part of my latest email obsolete. Asynchronous communication ftw ;)

Richard

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

The default pre-commit hook shipped with git includes this check.  
All you have to do is enable it: it has to be named 'pre-commit' and
it has to be exacutable.  In older git version you would do:
  $ chmod a+x .git/hooks/pre-commit
while in never versions it would be
  $ mv .git/hooks/pre-commit.sample .git/hooks/pre-commit
 

It is a git policy that it ships with all hooks disabled.

P.S. You can always bypass pre-commit hook (for example if comitting AsciiDoc files, which may include something that looks like conflict markers, or if you are committing test which includes conflicted file as one of test vectors), by using `--no-verify' option to git-commit.

On Fri, Oct 17, 2008 at 01:42, Jakub Narebski <jnareb@gmail.com> wrote:

Thanks! 'Unfortunately', I figured all this out by myself, in the meantime, but I really appreciate that you took the time to explain all this .

Thanks! Richard

PS: Well, I lie, I did not figure out the mv $1.sample $1 bit
as my git version still uses the old format.