Add .gitconfig mergetool configuration

[zamber]

In short - how to get merge-confilcts to be the default conflict resolution app?

[smashwilson]

Ah, great question. Unfortunately you can't, yet, but it would be great to be able to.

This'll be a bit tricky to implement because mergetool expects a certain protocol for conflict resolution that merge-conflicts doesn't implement. Specifically, it expects to invoke the mergetool command once for each conflicting path and uses the exit status to determine whether or not a particular merge succeeded. Also, I believe git launches the tool instead of attempting to merge itself, although I haven't used it myself and I could be wrong. merge-conflicts processes all conflicts throughout the repository at once and relies on git to do the actual merging.

Here's how I might be able to make this work anyway:

• Read the ${BASE}, ${LOCAL}, ${REMOTE}, and ${MERGED} environment variables to tell that we're in "mergetool mode." Automatically invoke merge-conflicts:detect on load.
• If git doesn't actually write its own merge result to ${MERGED}, invoke git merging porcelain commands (assuming they exist) to do so.
• Create an empty dotfile somewhere consistent (/home or /tmp).
• As each file is resolved, write its path into the dotfile.
• On subsequent launches, check for the existence of the dotfile. If the ${MERGED} file is listed, immediately exit(0). Otherwise, launch and continue resolving as before.

I think that'll let you stop and resume resolving, but also not launch Atom over and over. If I can hook into Atom's startup before it starts loading and rendering its chrome, all the better, but I don't think I can run that early.

As an enhancement, I also think it'd be cool to have a package option you can check or uncheck to handle registering Atom with git.

[zamber]

AFAIK from using p4merge and kdiff3 it tries to merge by itself but if it bumps to conflicts it does not give you the state where it left off. Therefore we would have to get some automatic merge resolution (possibly git can do that) and then give the user a way to resolve the conflicts by hand.

As to exit codes why not use a proxy script that would eat the protocol, pass variables to Atom and then emit the required exit code after getting feedback? I hate the workflow where the editor gets spawned for each resolution though it makes sense if you use vim ;).

Check/uncheck would require editing ~/.gitconfig by Atom. This does not sound too safe to me, though having it as an option would be a considerable improvement over changing it by hand.

Nevertheless there will always pop up some use case where that would introduce chaos and mayhem. Rule of thumb - stick to your environment dotfiles ;).

[smashwilson]

AFAIK from using p4merge and kdiff3 it tries to merge by itself but if it bumps to conflicts it does not give you the state where it left off. Therefore we would have to get some automatic merge resolution (possibly git can do that) and then give the user a way to resolve the conflicts by hand.

Okay, I thought that might be the case. I'll investigate and check around the porcelain, then. :mag:

As to exit codes why not use a proxy script that would eat the protocol, pass variables to Atom and then emit the required exit code after getting feedback? I hate the workflow where the editor gets spawned for each resolution though it makes sense if you use vim ;).

Oh, hey, that's a much better idea. Any idea where I could host it? I wonder if packages know where they are in the filesystem... I could leave it in lib/ and install it on request.

Check/uncheck would require editing ~/.gitconfig by Atom. This does not sound too safe to me, though having it as an option would be a considerable improvement over changing it by hand.

Well, I'd probably shell out to git config --global. Also, you don't edit your .gitconfig by hand? :wink:

[zamber]

I usually do it by hand. I feel more comfortable in an editor when I can see what I'm changing to what and how it relates to the rest of the configuration ;).

[searls]

As a user I was pretty surprised that merge-conflicts didn't support git-mergetool integration. Disappointed :-/

[smashwilson]

As a user I was pretty surprised that merge-conflicts didn't support git-mergetool integration. Disappointed :-/

It's on my radar! As you can see above, it's a little more involved than you might expect at first glance.

In the meantime, I do accept pull requests :wink:

[searls]

Yeah understood, just wanted to +1 didn't mean to be a downer. Thanks for creating this, I just don't know how to really use it without merge tool support so I was disappointed

[smashwilson]

Yeah understood, just wanted to +1 didn't mean to be a downer. Thanks for creating this, I just don't know how to really use it without merge tool support so I was disappointed

Hehe, no worries. Consider it +1'd.

Generally, when I'm merging, I already have Atom open on the project I'm working in. I run git merge or git rebase in a terminal, and if I see conflicts in the output, I ctrl-command-m (or pick Detect Conflicts from the command palette) in Atom to kick things off. Once everything is resolved, I flip back to the terminal and git commit or git rebase --continue to finish it off.