On 2021-02-17 at 17:21:45, Alireza wrote:
> 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