From: Junio C Hamano <email@example.com> To: Martin von Zweigbergk <firstname.lastname@example.org> Cc: git <email@example.com> Subject: Re: Letting tools partially resolve conflicts in a file Date: Wed, 24 Nov 2021 13:20:58 -0800 [thread overview] Message-ID: <firstname.lastname@example.org> (raw) In-Reply-To: <CANiSa6iNpm6--qHpUFYhPfSi+ounGttA8=TAsep18A-=iyoFEQ@mail.gmail.com> (Martin von Zweigbergk's message of "Wed, 24 Nov 2021 08:31:19 -0800") Martin von Zweigbergk <email@example.com> writes: > I've searched the list and not found anything about this topic, but I > figured I'd ask to be sure. The question is not specific to Git, but > this seems like a forum where it might have been brought up. > > You could imagine having a merge tool that was specialized for some > purpose and only able to resolve a particular kind of conflict. An > example would be a tool that resolves conflicts in `#include` lines or > `import` lines. It could be useful to have such tools run as part of a > chain of merge tools, where the final merge tool is what users > normally have configured (such as `meld`, or the internal "attempt > merge, or leave conflict markers" tool). > > Has this problem come up before? I do not recall seeing such a topic, but I am not sure how practical your idea is to implement from the Git side. As a zeroth order approximation, instead of such a half-auto-merge tool, while resolving a conflicted merge with two conflicted hunks in a file, if you hand edit one conflicted hunk and then run "git mergetool", is your "half resolution by hand" seen by the mergetool backend correctly? I tried to follow from git-mergetool.sh::main() what happens. Each path is given to merge_file() helper function, and three temporary files, $BASE, $LOCAL, and $REMOTE, are prepared from the blob object registered in the index at stages #1, #2 and #3. A mergetool backend, e.g. mergetools/meld, looks at these three files in its merge_cmd() function. Notice that the contents in the working tree file after a conflicted auto-merge does not even get looked at by the mergetool backend in the above picture? I am not sure if replacing the contents of LOCAL with your half-resolved contents would give us the behaviour you want. If it were the case, perhaps vanilla "git mergetools" would have fed the current file in the working tree, which was half resolved by "git merge" with conflict markers, as LOCAL to the mergetool backend even before we started discussing this topic, so I am not that optimistic. I assume that your idea is that various small "I know how to resolve only this kind of conflicts" tools can plug into a larger merge helper framework to improve end-user experience, and I find the idea intriguing. I would be surprised if such an idea has never been discussed by folks in projects that develop and maintain merge helpers, like meld and kompare. But I am not convinced if it is a good idea to do that on our side, before we spawn these mergetool backends.
next prev parent reply other threads:[~2021-11-24 21:21 UTC|newest] Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-11-24 16:31 Martin von Zweigbergk 2021-11-24 21:20 ` Junio C Hamano [this message] 2021-11-24 22:03 ` Martin von Zweigbergk 2021-11-24 22:15 ` Junio C Hamano 2021-11-24 22:32 ` Martin von Zweigbergk
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style List information: http://vger.kernel.org/majordomo-info.html * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: Letting tools partially resolve conflicts in a file' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Code repositories for project(s) associated with this inbox: https://80x24.org/mirrors/git.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).