From: Elijah Newren <newren@gmail.com>
To: phillip.wood@dunelm.org.uk
Cc: Paul Jolly <paul@myitcv.io>, git@vger.kernel.org
Subject: Re: Automatically re-running commands during an interactive rebase or post commit
Date: Tue, 30 May 2023 21:14:09 -0700 [thread overview]
Message-ID: <CABPp-BEAnB-6ogcohMWMmktr9SrwMtM0-dw1pypcJedcMMcsCg@mail.gmail.com> (raw)
In-Reply-To: <cc93b0ed-1167-a017-2138-181a490d26e2@gmail.com>
On Mon, May 29, 2023 at 12:48 PM Phillip Wood <phillip.wood123@gmail.com> wrote:
> On 29/05/2023 20:08, Paul Jolly wrote:
[...]
> > I have a custom merge strategy working, insofar as I've written a
> > script that is being called. The script simply wraps "git merge-ort"
> > as you suggest.
> >
> > But I can't seem to work out how to actually run 'git merge-ort'! I've
> > tried 'git merge -s "$@"' in my wrapper script, but doing so my custom
> > strategy behaves differently to if I use no strategy, which seems to
> > suggest I'm doing something wrong.
Don't call `git merge` from your custom merge strategy. That's just
asking for trouble; we should probably modify the code to throw huge
errors if people attempt that.
Use lower-level primitives, such as `git merge-tree`, `git
merge-file`, `git read-tree`, `git update-index`, `git merge-index`,
`git merge-one-file`, etc. Bias towards the first two of those.
> > Do you have any suggestions/pointers?
>
> Sorry, I'd assumed there was a merge-ort command in the same way as
> there is a merge-recursive command but it does not exist. I think the
> best you can do is run "git merge-recursive" rather than "git merge-ort"
> in your script. I've cc'd Elijah in case he has a better suggestion.
In short, I'd say use `git merge-tree` instead of `git
merge-recursive`, but the long story about the latter command is:
First of all, we _currently_ have a bunch of executables & scripts,
one per merge strategy:
* git-merge-octopus
* git-merge-resolve
* git-merge-recursive
* git-merge-ours
But, in this set, git-merge-recursive is builtin and isn't called as
an external program, so that's not a reason I think it should exist,
and we certainly shouldn't add another for `ort` based on this
rationale. (The others may also be replaced with builtins; there were
even patches in that direction, though they weren't followed up on.)
Second of all, we've had multiple ways to expose users to "doing a merge":
* git-merge
* git-merge-recursive
* git-merge-tree
The first is the one most users are familiar with, `git merge`. So,
about the others... Traditionally, git-merge-tree was a virtually
useless implementation that fell way short of the good idea to 'make a
merge without touching the worktree or index'. In contrast,
git-merge-recursive was in between git-merge-tree and git-merge in
terms of how low level it was. It still required updating the working
tree and index, which limited what could be built on top of it, but
unlike git-merge-tree it at least provided useful functionality in
that it could do-all-parts-of-the-merge-except-commit-and-update-branch.
While not optimal, that was enough that git-merge-recursive got used
in some places (such as one of the rebase backends once upon a time).
Nowadays, though, git-merge-tree is the correct low-level primitive --
it can do a merge without updating branches, creating a commit, or
updating the worktree or index. That means that git-merge-recursive
isn't really useful from this angle either; everything can be built on
top of something a little lower level.
The two angles above were the reasons that git-merge-recursive
existed, but neither is useful nowadays, so git-merge-recursive is
basically a historical relic (which we are keeping for backward
compatibility purposes, not for any intrinsic value I can see). I
don't want to add another useless historical relic, in the form of
`git-merge-ort`.
But there's a third reason to not provide `git-merge-ort` as well: The
plan has always been to use `ort` as a drop-in replacement for
`recursive` and make _all_ calls within the code unconditionally
translate requests for `recursive` to call the `ort` code instead. I
just haven't gotten around to finishing those plans yet. (In fact,
there are only two places in the code that still call the recursive
backend by default -- git-merge-recursive and git-am, both of which
I've been meaning to fix up). So, making a `git-merge-ort` would make
it really weird in the future in that we'd have both
`git-merge-recursive` and `git-merge-ort` calling the same thing.
Anyway, if you want a low-level do-a-merge thing, use `git merge-tree`.
next prev parent reply other threads:[~2023-05-31 4:14 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-29 13:38 Automatically re-running commands during an interactive rebase or post commit Paul Jolly
2023-05-29 13:41 ` rsbecker
2023-05-29 14:01 ` Paul Jolly
2023-05-29 16:02 ` Paul Jolly
2023-05-29 17:53 ` Phillip Wood
2023-05-29 19:08 ` Paul Jolly
2023-05-29 19:48 ` Phillip Wood
2023-05-31 4:14 ` Elijah Newren [this message]
2023-06-02 9:57 ` Phillip Wood
2023-06-08 5:11 ` Paul Jolly
2023-05-30 7:22 ` Son Luong Ngoc
2023-05-30 9:44 ` Oswald Buddenhagen
2023-05-30 10:27 ` Paul Jolly
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CABPp-BEAnB-6ogcohMWMmktr9SrwMtM0-dw1pypcJedcMMcsCg@mail.gmail.com \
--to=newren@gmail.com \
--cc=git@vger.kernel.org \
--cc=paul@myitcv.io \
--cc=phillip.wood@dunelm.org.uk \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).