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 [off-list ref] 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?

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.

Miklos Vajna [off-list ref] wrote:

On Fri, Oct 17, 2008 at 12:10:55AM +0200, Richard Hartmann [off-list ref] wrote:

quoted

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.
 

quoted

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.

On Fri, Oct 17, 2008 at 00:48, Miklos Vajna [off-list ref] wrote:

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.

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


Richard

Richard Hartmann [off-list ref] wrote:

On Fri, Oct 17, 2008 at 00:48, Miklos Vajna [off-list ref] wrote:

quoted

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.

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

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.

-- 
Shawn.

On Fri, Oct 17, 2008 at 01:00, Shawn O. Pearce [off-list ref] wrote:

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

Thanks.

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

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 Fri, Oct 17, 2008 at 01:23, Shawn O. Pearce [off-list ref] 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.

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


Richard

"Richard Hartmann" [off-list ref] writes:

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?

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
 

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

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.

-- 
Jakub Narebski
Poland
ShadeHawk on #git

On Thu, Oct 16, 2008 at 7:26 PM, Richard Hartmann
[off-list ref] wrote:

On Fri, Oct 17, 2008 at 01:00, Shawn O. Pearce [off-list ref] wrote:

quoted

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

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?

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 01:42, Jakub Narebski [off-list ref] wrote:

[a lot of detailed information]

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.