Re: Considering merge --dry-run to foresee conflicts ahead of time

From: brian m. carlson <sandals@crustytoothpaste.net>
Date: Feb 19, 2021, 22:26 UTC
Message-ID: <YDA6+vm6GPQL3Jec@camp.crustytoothpaste.net>
In-Reply-To: <CAD9n_qiN+qXqR79z_4d+_8_mxa9eTFB42sTUT8CTF8=oQArQaA@mail.gmail.com>

On 2021-02-17 at 17:21:45, Alireza wrote:

Show 14 quoted lines

> I have a half baked alias for this and it proved to be extremely
> useful even in this state.
> 
> ```
> check = "!f() { BRANCH=${1:-HEAD}; BASE=${2:-origin/master}; git
> merge-tree $(git merge-base $BRANCH $BASE) $BRANCH $BASE | sed -n
> \"/+<<<<<<< .our/,/+>>>>>>> .their/p\"; }; f"
> ```
> 
> Of course with large conflicts it gets less useful. Getting only file
> names from the patch isn't straightforward either.
> 
> So my question is what are the downsides to introducing a `merge
> --dry-run` option and what would it look like?

There aren't really any, but the current implementation of the merge code makes it non-trivial, since it writes directly into the working tree. The new merge-ort code that Elijah Newren (CC'd) is working on should at least support writing conflicts only into the index, and if you didn't want to dirty the existing index, you could create a temporary one with GIT_INDEX_FILE and write to that. It may also support a dry-run mode natively, but I'm not following it closely enough to say. Hopefully Elijah can say a little bit more about things.

In the mean time, since this is a frequently requested feature, I have a Rust-based tool called git test-merge[0] that runs a test merge between two arbitrary trees and determines whether it succeeds or fails. It uses libgit2 under the hood.

[0] https://github.com/bk2204/scutiger

-- 
brian m. carlson (he/him or they/them)
Houston, Texas, US