Can git be stopped from inserting conflict markers during a merge?

Can git be stopped from inserting conflict markers during a merge?

[William Tanksley]

I started using Mercurial a while ago, and I'd like to move up to git (for a
number of reasons). The one thing that's stopping me is that (having recently
escaped subversion and cvs) I'm now used to NOT having to worry about conflict
markers being shoved into files. To put it simply, I really like how Mercurial
does that one thing.

So, given the git is probably the ultimate in configurability, what do I need to
do to make it not insert merge markers?

Thanks for a great VCS.

-Wm

Re: Can git be stopped from inserting conflict markers during a merge?

[Linus Torvalds]

On Sat, 8 Mar 2008, William Tanksley wrote:
>
> I started using Mercurial a while ago, and I'd like to move up to git (for a
> number of reasons). The one thing that's stopping me is that (having recently
> escaped subversion and cvs) I'm now used to NOT having to worry about conflict
> markers being shoved into files. To put it simply, I really like how Mercurial
> does that one thing.

Can you describe what "that one thing" is?

> So, given the git is probably the ultimate in configurability, what do I need to
> do to make it not insert merge markers?

Do you want to just have both (with the base version, all three?) versions 
of the file in your directory?

That's actually conceptually what you have with git, even though what git 
does is to keep the different untouched versions in the index. So with 
git, you actually have *four* different versions of a file when you have a 
conflict:

 - the working tree one (which has the conflict markers, because that's 
   traditional)
 - and index stages 1 (base) 2 (ours) and 3 (theirs)

which is why when you do

	git diff

on an unmerged file, you actually get something much more powerful than 
just the conflict entries - you get a git multi-version diff. It's 
*really* convenient when you get used to it, but I you actually seem to be 
wanting something much simpler.

			Linus

Re: Can git be stopped from inserting conflict markers during a merge?

[Martin Langhoff]

On Sun, Mar 9, 2008 at 9:51 AM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>  Do you want to just have both (with the base version, all three?) versions
>  of the file in your directory?

If that's what he is after, git-mergetool will do it - normally as a
preparation to call xxdiff or something similar. William, perhaps
git-mergetool is what you are after? You can look at the source --
it's shell -- if you want to tweak it.

But I think that what mercurial does is similar to Arch and Bazaar
behaviour: it will update the file following "one side" of the merge,
and then generate a .rej file with the unapplied hunks coming from the
'other side'.  This selection is arbitrary, and doesn't work on
octopus merges, so I end up not quite liking it. OTOH, if you open the
.rej file with emacs in diff mode, it's bloody useful for fixing up
patches so that they apply.

cheers,




m

Re: Can git be stopped from inserting conflict markers during a merge?

[Jakub Narebski]

William Tanksley <wtanksleyjr+git@gmail.com> writes:

> I started using Mercurial a while ago, and I'd like to move up to
> git (for a number of reasons). The one thing that's stopping me is
> that (having recently escaped Subversion and CVS) I'm now used to
> NOT having to worry about conflict markers being shoved into
> files. To put it simply, I really like how Mercurial does that one
> thing.
> 
> So, given the Git is probably the ultimate in configurability, what
> do I need to do to make it not insert merge markers?

First, if you simply enable installed by default (but not enabled)
pre-commit hook, by making it executable:

  $ chmod a+x .git/hooks/pre-commit

it would detect merge markers in changes, and would prevent committing
with "unresolved merge conflict (line <n>)" message[*1*].

You can of course bypass pre-comit and commit-msg hooks with
--no-verify option, for example if committing merge test case, or if
hooks misdetects asciidoc markup for merge conflict markers.


Second, you can change default file-level (file contents) merge driver
to the one used for binary files; it would leave 'ours' version on
disk instead of merged file with merge conflict markers[*2*][*3*] 

Simply add the following to the repository configuration in
'.git/config', or to global (user) git configuration in
'~/.gitconfig', or if you are admin you can even add it to system wide
git config '/etc/gitconfig' although I wouldn't recommend last one:

   [merge]
   	default = binary

Or if you prefer scripted solution,

  $ git config merge.default binary

(this would change repository config: read git-config(1)).


Footnotes:
==========
[*1*] It also detects "trailing whitespace" and "indent SP followed by
      a TAB" errors; whitespace errors can be detected by git-commit
      iself with --cleanup=<mode> option and/or gitattributes.
[*2*] Sample session below:

[master!test]$ git version
git version 1.5.4.2
[master!test]$ git show master:foo
HELLO
hello
[master!test]$ git show side:foo
HELLO
hello side
[master!test]$ git merge side
Auto-merged foo                           # [*4*]
CONFLICT (content): Merge conflict in foo
Automatic merge failed; fix conflicts and then commit the result.
[master!test]$ cat foo 
HELLO
<<<<<<< HEAD:foo
hello
=======
hello side
>>>>>>> side:foo
[master!test]$ git reset --hard HEAD
[master!test]$ git config merge.default binary
[master!test]$ git merge side
Auto-merged foo
CONFLICT (content): Merge conflict in foo
Automatic merge failed; fix conflicts and then commit the result.
[master!test]$ cat foo 
HELLO
hello

[*3*] If you want to do this only for some files, you can use
      gitattributes feature.
[*4*] I wonder about this "Auto-merged foo" message...

-- 
Jakub Narebski
Poland
ShadeHawk on #git