0

In Git, is it possible to change the default conflict markers to something else?

By default they look like this:

<<<<<<< HEAD

    [some code]

||||||| merged common ancestors

    [some code]

=======

    [some code]

>>>>>>> some commit message

For instance, I was thinking it might be nice in C# files to have them start with comment characters:

// <<<<<<< HEAD

That way compile errors from the conflict markers wouldn't get in the way of compile errors from the code itself while I'm resolving a merge.

Is there a way to do this?

(Please don't give an answer that says "You shouldn't do this." I already know the ramifications, and I'm OK with them. Git is designed for flexibility.)

Ryan Lundy
  • 204,559
  • 37
  • 180
  • 211
  • Those who are downvoting need to ask themselves why it's so important to them that someone uses Git in only one specific way. Git wouldn't be as popular as it is if it wedged everyone into a single mold and required everyone to work a single way. – Ryan Lundy Jul 29 '11 at 18:14
  • Perhaps add a caution to the question with the ramifications? Probably most people that come across it are going to say "Geez, I hope some Git n00b isn't going to try this because they're annoyed with Resharper or something else crapping out due to syntax errors". The downvoting is probably mostly due to wanting to protect people that are just learning Git for the first time. I love git and hope you find a way to do this. – Adam Dymitruk Jul 29 '11 at 20:58
  • [See this question](http://stackoverflow.com/questions/1657017/git-squash-all-commits-into-a-single-commit) for an example of people answering a question by *answering* it, rather than answering by saying "Oh, no, you should never do such a thing." I miss the days when people only got upvotes for giving actual answers. – Ryan Lundy Sep 15 '11 at 20:55
  • The nature of your question begged to have this concern raised. I'm not sure why you're so angry and upset. – Adam Dymitruk Sep 16 '11 at 18:25
  • @Adam, among other things, your answer is pointless because there's no guarantee the merge characters really do cause anything to "fail spectacularly." You could be editing a .txt file, and all the unresolved merge characters do is sit there. – Ryan Lundy Sep 18 '11 at 15:04
  • I doubt most people on here are just editing text files. I'm not sure why you hate me to the level of saying things like "your answer is pointless". I've given the point quite clearly. Since this has gone way past the point of civilized discourse, I'll vote to have this question closed. – Adam Dymitruk Sep 19 '11 at 01:35
  • @Adam, if I give you an example from another question, will it help? I asked a question recently about using Git with Microsoft Dynamics NAV. One person answered...with words to the effect of "Git can handle anything you throw at it; but if you're on Windows, Mercurial is better." Note how that answer has nothing about NAV and nothing useful about Git. (He deleted the answer later.) I understand the impulse to look at a question and think "Why would you want to do *that?*" There's a place for such sentiments: Comments. Not answers. – Ryan Lundy Sep 19 '11 at 02:29
  • I've added what I would pursue. So you have another option to choose from. Hope the debacle in the comments will draw attention to what I feel is the real issue here. – Adam Dymitruk Sep 19 '11 at 02:59

4 Answers4

1

Here is how I would do it IF I HAD TO (proceed with caution):

add a precompile step in your projects (from your profile I assume you are using C#) to run sed (assuming you installed git with the bash commands available to everything). Have sed insert '//' markers where ever a conflict marker is found.

Why this is a bad idea:

I would not recommend this as the effect wouldn't give you any gain. You WANT to fail spectacularly when there is an unresolved conflict that was saved, added and committed. Doing what you are proposing here is asking for trouble. If you succeed, proceed with caution.

Hope this helps.

Adam Dymitruk
  • 124,556
  • 26
  • 146
  • 141
  • 1
    The OP did say "while I'm resolving a merge" - that is, it hasn't been added and committed. That said, I'm totally with you - this is a bad idea. If for some reason the code does compile even with two or three differing versions of a block there, there's *no way* it does anything useful. – Cascabel Jul 29 '11 at 01:28
  • I can see that the merge (or in my case, usually the rebase) failed from the messages in the command prompt. It's easy enough to search for ====== in the project files and find the place I have to fix. Git is very customizable, and there's no reason I shouldn't be able to customize this on my own box if that's the way I like to work. – Ryan Lundy Jul 29 '11 at 03:26
  • I would not want to encourage such practices. If you find a way, you can post your own answer as well and accept it. – Adam Dymitruk Jul 29 '11 at 17:14
  • I don't recall asking you to encourage such practices. In fact, I didn't even ask whether what I want to do is, in yours or other people's opinion, a good idea or not. All I asked is how to do it, a question your answer failed to answer. Let me repeat: **Git is flexible.** You can clone to multiple folders, or you can use local branches. You can always create merge commits, or only when you can't fast-forward, or you can always rebase instead of merging. You can use a GUI, or you can use the command line. It's not really up to you to tell me how I should or shouldn't use Git. – Ryan Lundy Jul 29 '11 at 18:11
  • Fair enough. But others reading this might go down a road where they will hurt themselves. This is a community based site. It's our responsibility to show pitfalls of certain practices. – Adam Dymitruk Jul 29 '11 at 20:51
  • That's a little extreme. Questions can imply abuse of tools. The answer is hardly useless. – Adam Dymitruk Aug 02 '11 at 15:09
1

What if you recompile your own fork of Git? The source code is here: http://git.kernel.org/?p=git/git.git;a=summary (via http://git-scm.com/).

fearmint
  • 5,276
  • 2
  • 33
  • 45
0

It's up to the individual merge driver. From man gitattributes(5):

There are a few built-in low-level merge drivers defined that can be asked for via the merge attribute.

text

Usual 3-way file level merge for text files. Conflicted regions are marked with conflict markers <<<<<<<, ======= and >>>>>>>. The version from your branch appears before the ======= marker, and the version from the merged branch appears after the ======= marker.

[…]

Defining a custom merge driver

The definition of a merge driver is done in the .git/config file, not in the gitattributes file, so strictly speaking this manual page is a wrong place to talk about it. However…

To define a custom merge driver filfre, add a section to your $GIT_DIR/config file (or $HOME/.gitconfig file) like this:

[merge "filfre"]
         name = feel-free merge driver
         driver = filfre %O %A %B
         recursive = binary

That is: the "text" merge driver does what you don't like, and cannot be configured as to what symbol to use (though you can configure it to use a bigger number of markers). But you can copy-paste the driver, rename it, replace the symbol with yours, and then configure git to use your driver.

nes1983
  • 15,209
  • 4
  • 44
  • 64
0

There's no existing way to do this. Git is indeed designed for flexibility, but in this instance it provides that flexibility by allowing people to provide their own custom merge drivers. That's not a trivial amount of work. Another option is to hack the source, which would not be much easier.

My recommendation for the easiest way would be to write a postprocessor program you can run on the source files separately after the merge. You could probably fit it in a one-liner sed script.

If you decide to go this route so you can compile during merge resolution, I would recommend instead of just commenting out the conflict markers, to comment out all the conflicted code except your local version of the changes. That way you have a better chance of producing something compilable. And maybe add a #warning pragma or similar to remind you in case you accidentally leave one in.

Karl Bielefeldt
  • 47,314
  • 10
  • 60
  • 94