git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
* Considering merge --dry-run to foresee conflicts ahead of time
@ 2021-02-17 17:21 Alireza
  2021-02-17 18:39 ` Konstantin Tokarev
  2021-02-19 22:26 ` brian m. carlson
  0 siblings, 2 replies; 4+ messages in thread
From: Alireza @ 2021-02-17 17:21 UTC (permalink / raw)
  To: git

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?

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Considering merge --dry-run to foresee conflicts ahead of time
  2021-02-17 17:21 Considering merge --dry-run to foresee conflicts ahead of time Alireza
@ 2021-02-17 18:39 ` Konstantin Tokarev
  2021-02-19 22:26 ` brian m. carlson
  1 sibling, 0 replies; 4+ messages in thread
From: Konstantin Tokarev @ 2021-02-17 18:39 UTC (permalink / raw)
  To: Alireza, git



17.02.2021, 20:25, "Alireza" <rezaxm@gmail.com>:
> 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?

As a git user, I would very much welcome this addition, and similar for cherry-pick,
provided they don't modify any files in working copy.


-- 
Regards,
Konstantin

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Considering merge --dry-run to foresee conflicts ahead of time
  2021-02-17 17:21 Considering merge --dry-run to foresee conflicts ahead of time Alireza
  2021-02-17 18:39 ` Konstantin Tokarev
@ 2021-02-19 22:26 ` brian m. carlson
  2021-02-19 23:59   ` Elijah Newren
  1 sibling, 1 reply; 4+ messages in thread
From: brian m. carlson @ 2021-02-19 22:26 UTC (permalink / raw)
  To: Alireza; +Cc: git, Elijah Newren

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

[0] https://github.com/bk2204/scutiger
-- 
brian m. carlson (he/him or they/them)
Houston, Texas, US

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Considering merge --dry-run to foresee conflicts ahead of time
  2021-02-19 22:26 ` brian m. carlson
@ 2021-02-19 23:59   ` Elijah Newren
  0 siblings, 0 replies; 4+ messages in thread
From: Elijah Newren @ 2021-02-19 23:59 UTC (permalink / raw)
  To: brian m. carlson, Alireza, Git Mailing List, Elijah Newren

On Fri, Feb 19, 2021 at 2:26 PM brian m. carlson
<sandals@crustytoothpaste.net> wrote:
>
> 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.

I don't have that exact feature implemented, but I've got something
that could easily be reused to provide this functionality.  In my
remerge-diff branch, I've got a --remerge-diff option for log (and
show), that for any merge commit will redo the merge in-memory (not
touching the working copy or index), and then show the diff between
that result (possibly including conflict markers) and what was
actually recorded in the merge.  If the merge was clean and the user
didn't amend any changes into the merge commit, then the diff will be
empty.  If the user moved around files, added changes, or just ripped
out conflict markers, then you see all that in the diff.

One could use the same logic to make a merge --dry-run option that
would show the diff between the commit before merging and the
auto-merged state.  It probably wouldn't even be all that much code;
may half a day's worth of work.

But, it does rely on getting merge-ort reviewed and merged.  We're 6
months into that process so far.  I was hoping we'd finish it before
git-2.32 is released (note that git-2.31 isn't released yet either),
but right now git-2.33 is looking more probable.  See
https://lore.kernel.org/git/pull.844.git.1613289544.gitgitgadget@gmail.com/
and https://github.com/gitgitgadget/git/pulls?q=is%3Apr+author%3Anewren+Optimization+batch
if you'd like to help review and/or test the portions that are ready
for review.  (Or try the 'ort' or 'remerge-diff' branches of
https://github.com/newren/git if you want to try out the full set of
changes, including bits that haven't been nicely broken up in
preparation for upstream review.)

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2021-02-20  0:02 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-02-17 17:21 Considering merge --dry-run to foresee conflicts ahead of time Alireza
2021-02-17 18:39 ` Konstantin Tokarev
2021-02-19 22:26 ` brian m. carlson
2021-02-19 23:59   ` Elijah Newren

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