On Mon, Jul 30, 2018 at 9:00 AM Nguyễn Thái Ngọc Duy <pclouds@xxxxxxxxx> wrote: > > 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? > 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) (I am just making up colors, not seriously suggesting them) I like the idea! Thanks, Stefan
