Re: [PATCH/RFC] Color merge conflicts

On Mon, Jul 30, 2018 at 10:40 AM, Stefan Beller [off-list ref] wrote:

On Mon, Jul 30, 2018 at 9:00 AM Nguyễn Thái Ngọc Duy [off-list ref] wrote:

quoted

One of the things I notice when watching a normal git user face a
merge conflicts is the output is very verbose (especially when there
are multiple conflicts) and it's hard to spot the important parts to
start resolving conflicts unless you know what to look for.

I usually go by git-status, but I am not the watched normal user,
hopefully. Maybe we want to run git-status after a failed merge
for the user, too, though?

I'm a little worried the git status output may be long enough that
they miss all the conflict messages and don't even think to scroll
back and look at them.  Since not all conflict types are nicely
representable in git status output, that could be problematic.  (e.g.
renames aren't recorded in the index in any fashion, so git status
can't tell you a conflict was from a rename/delete or
rename/rename(1to2), for example; it's possible that information may
be important in helping the user track down why the working directory
ended up the way it did to help them resolve the conflict.)

If that extra information that is currently only reported in these
conflict messages were recorded somewhere -- either the index or the
working tree -- then it wouldn't be as much of a risk to hide it
behind git status.  In fact, it would seem safer and nicer in general
because users already run the risk of losing those conflict messages.

quoted

This is the start to hopefully help that a bit. One thing I'm not sure
is what to color because that affects the config keys we use for
this. If we have to color different things, it's best to go
"color.merge.<slot>" but if this is the only place to color, that slot
thing looks over-engineered.

Perhaps another piece to color is the conflicted path? Maybe. But on
the other hand, I don't think we want a chameleon output, just enough
visual cues to go from one conflict to the next...

I would think we would want to highlight the type of conflict as well,
e.g.

  <RED> CONFLICT> <RESET> \
  <BOLD;RED> (rename/rename): <RESET> \
  Rename a -> b in branch foo \
  rename a ->c in bar

but then again, this patch is better than not doing any colors.

I wonder if we want to have certain colors associated with certain
types of merge conflicts, e.g. anything involving a rename would
be yellow, any conflict with deletion to be dark red, regular merge
conflicts blue (and at the same time we could introduce coloring
of conflict markers to also be blue)

Providing extra hints might be good, but we'd need to flesh out this
idea to avoid edge and corner cases...

What do you do with mixtures, e.g. rename/delete conflicts?  Average
the colors?  Colorize the "rename" differently than the "delete"?

Also, by "regular conflicts" I think you mean the normal content-based
conflict markers we stick in files, rather than path-based conflicts
(like modify/delete or rename/add).  However, something could be both
-- e.g. for an add/add conflict we two-way merge the files so we have
both a path conflict (both sides added a file with that name) and a
content or "regular" conflict (most the files were the same but they
differ on these lines...).  Things could get even crazier with e.g.
rename/add/delete or rename/rename(2to1)/delete.  So, if you want to
colorize regular (or content) conflicts differently than path-based
ones, what do you do when you have both types present?  Does one win?
Do we print multiple conflict messages?  Something else?

(I am just making up colors, not seriously suggesting them)

I like the idea!

Thanks,
Stefan