mhagger / git-imerge

Incremental merge for git
GNU General Public License v2.0
2.68k stars 126 forks source link

[Request] Keep diff3 conflictstyle as clear as without imerge #197

Open tuxayo opened 1 year ago

tuxayo commented 1 year ago

I don't know how feasible is that. To change the comments of the conflict markers. But diff3 conflictstyle is another must use next to imerge to handle as much conflicts as possible and reliably.

Take the following example, without imerge we would have in the end >>>>>>> 90ca41fd3 My new feature commit message so I would know that by diffing it with the middle section I will see what changes are introduced by my feature and then diffing the middle and 1st section I'll see the changes upstream since my feature branched out. Which is essential to decide what to keep and drop.

With imerge I have to guess from the changes which is my feature and as a consequence which is upstream. Which is harder and error prone, and much harder if rebasing someone else's work without knowing well the diffs of the feature.

A step forward (but that would still be less clear as without imerge) would be when outputting the original commits that conflict to output also (if conflictstyle is diff3) the start of the commit message of HEAD and the bottom section. To know which is upstream and the feature. But ideally there would be a way to change the conflict markers.

<<<<<<< HEAD
            [% IF whyicantreserve %]
                <button type="button" class="btn btn-info btn-sm" data-toggle="modal" data-target="#TODOmyModal">
                    Show holding rules
                </button>
            [% END %]
||||||| 5cd1896d7b
                [% IF whyicantreserve %]
                    <button type="button" class="btn btn-info btn-sm" data-toggle="modal" data-target="#TODOmyModal">
                        Show holding rules
                    </button>
                [% END %]
            </h1>
=======
                [% IF whyicantreserve %]
                    <button type="button" class="btn btn-info btn-sm" data-toggle="modal" data-target="#holdruleschecker">
                        [% t('Show holding rules') %]
                    </button>
                [% END %]
            </h1>
>>>>>>> 90ca41fd30b59be81f2ed85fb889a9e91e768222
mhagger commented 1 year ago

If I understand correctly, your main request here is to have the labels on the <<<<<<<, |||||||, and >>>>>>> lines set better. Currently, git-imerge does merges using git merge. I don't think that program allows those labels to be customized.

It is possible using git merge-file -L, but I'm not sure how much work it would be to base the merge on this lower-level command.

tuxayo commented 1 year ago

If I understand correctly, your main request here is to have the labels on the <<<<<<<, |||||||, and >>>>>>> lines set better.

That would be the best to not loose clarity when combining imerge and diff3 for the ultimate combo against conflicts (btw, are there more tools/techniques that you know?)

It is possible using git merge-file -L, but I'm not sure how much work it would be to base the merge on this lower-level command.

That might be a lot. Same for submitting patches to git to have git merge labels customizable. Too much for now until the whole world uses imerge :P

The only on-reach step forward would be when outputting the original commits that conflict to output also (if conflictstyle is diff3) the start of the commit message of HEAD (<<<<<<<) and the bottom section (>>>>>>>). To know which is upstream and the feature. Which section corresponds to which of the original commits.

hlovdal commented 4 months ago

" I have to guess from the changes which is my feature and as a consequence which is upstream."

@tuxayo unless you are using a proper 3-way merge program (i.e. a program that displays four panes/sub-windows) you are guessing in any case.

The default text conflict markers git injects are not a 3-way merge operation, and I see no reason to put effort into making something that is very sub-optimal slightly less very sub-optimal when there exist other way better alternatives.

I highly recommend using KDiff3.