list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
From: "brian m. carlson" <>
To: Alireza <>
Cc:, Elijah Newren <>
Subject: Re: Considering merge --dry-run to foresee conflicts ahead of time
Date: Fri, 19 Feb 2021 22:26:02 +0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

[-- Attachment #1: Type: text/plain, Size: 1511 bytes --]

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.

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 263 bytes --]

  parent reply	other threads:[~2021-02-19 22:29 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-17 17:21 Alireza
2021-02-17 18:39 ` Konstantin Tokarev
2021-02-19 22:26 ` brian m. carlson [this message]
2021-02-19 23:59   ` Elijah Newren

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:

  List information:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \
    --subject='Re: Considering merge --dry-run to foresee conflicts ahead of time' \

* 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:

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).