* Automatically re-running commands during an interactive rebase or post commit
@ 2023-05-29 13:38 Paul Jolly
2023-05-29 13:41 ` rsbecker
` (3 more replies)
0 siblings, 4 replies; 13+ messages in thread
From: Paul Jolly @ 2023-05-29 13:38 UTC (permalink / raw)
To: git
Hi all,
I would appreciate some advice on the best way to solve the following problem.
As part of my project, I have a code generation script that sha256
hashes a number of files to another file. This produces a
deterministic "has this part of the project changed" indicator via the
code generated file's content, that I then use in various cache
invalidation steps.
This means, however, that I need to re-run that code generation script
as part of each commit in order to ensure that the code generated hash
file is current (I have a step in CI that detects if it is not, which
re-runs the code generation script to then see if the commit is
"clean").
As part of my development setup I do a lot of interactive rebasing to
edit earlier commits in a branch (these "stacks" of changes are
reviewed via Gerrit, which understands a relation chain of changes).
Via this workflow, I often do a git rebase and edit an earlier commit
in such a way that I need to re-run the code generation script.
The challenge is that any commit in such a "stack" of commits might
need me to re-run the code generation script. But I clearly don't want
to do this manually!
What I'm looking for is a way to automatically re-run this code
generation script when I commit changes, or perform a rebase-edit step
etc.
I've tried to experiment with how I might do this using git commit
hooks. But so far, my git foo is failing me. It mainly fails because
when doing an edit of an earlier commit via an interactive rebase,
later changes might well conflict (in the generated file) with the
results of the code generator having been re-run on the edited commit.
At this point, my git rebase --continue stops until I have fixed the
conflict. But in almost all situations, the conflict comes in the
generated hash file. Which I fix by simply re-running the code
generation script (I could optionally fix it by doing a git checkout
--theirs, and then re-running the code generation script).
This all feels tantalisingly close to being a perfect workflow! But I
can't quite figure out how to make the git hooks "work" in such a way
that doesn't require any intervention from me (except in those
situations where there is a conflict during the rebase that is _not_
in the code generated file and so does require my intervention).
The code generation step is incredibly fast if there is nothing to do,
and is quite fast even when there is something to do (in any case it
can't avoid doing this work).
Please can someone help nudge me in the right direction?
Many thanks,
Paul
^ permalink raw reply [flat|nested] 13+ messages in thread
* RE: Automatically re-running commands during an interactive rebase or post commit
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
` (2 subsequent siblings)
3 siblings, 1 reply; 13+ messages in thread
From: rsbecker @ 2023-05-29 13:41 UTC (permalink / raw)
To: 'Paul Jolly', git
>-----Original Message-----
On Monday, May 29, 2023 9:39 AM, Paul Jolly wrote:
>I would appreciate some advice on the best way to solve the following problem.
>
>As part of my project, I have a code generation script that sha256 hashes a number of
>files to another file. This produces a deterministic "has this part of the project
>changed" indicator via the code generated file's content, that I then use in various
>cache invalidation steps.
>
>This means, however, that I need to re-run that code generation script as part of each
>commit in order to ensure that the code generated hash file is current (I have a step
>in CI that detects if it is not, which re-runs the code generation script to then see if
>the commit is "clean").
>
>As part of my development setup I do a lot of interactive rebasing to edit earlier
>commits in a branch (these "stacks" of changes are reviewed via Gerrit, which
>understands a relation chain of changes).
>Via this workflow, I often do a git rebase and edit an earlier commit in such a way
>that I need to re-run the code generation script.
>
>The challenge is that any commit in such a "stack" of commits might need me to re-
>run the code generation script. But I clearly don't want to do this manually!
>
>What I'm looking for is a way to automatically re-run this code generation script
>when I commit changes, or perform a rebase-edit step etc.
>
>I've tried to experiment with how I might do this using git commit hooks. But so far,
>my git foo is failing me. It mainly fails because when doing an edit of an earlier
>commit via an interactive rebase, later changes might well conflict (in the generated
>file) with the results of the code generator having been re-run on the edited commit.
>At this point, my git rebase --continue stops until I have fixed the conflict. But in
>almost all situations, the conflict comes in the generated hash file. Which I fix by
>simply re-running the code generation script (I could optionally fix it by doing a git
>checkout --theirs, and then re-running the code generation script).
>
>This all feels tantalisingly close to being a perfect workflow! But I can't quite figure
>out how to make the git hooks "work" in such a way that doesn't require any
>intervention from me (except in those situations where there is a conflict during the
>rebase that is _not_ in the code generated file and so does require my intervention).
>
>The code generation step is incredibly fast if there is nothing to do, and is quite fast
>even when there is something to do (in any case it can't avoid doing this work).
>
>Please can someone help nudge me in the right direction?
I wonder whether setting up a clean/smudge filter might help. You might want to look into a clean filter that runs your code generator.
--Randall
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Automatically re-running commands during an interactive rebase or post commit
2023-05-29 13:41 ` rsbecker
@ 2023-05-29 14:01 ` Paul Jolly
0 siblings, 0 replies; 13+ messages in thread
From: Paul Jolly @ 2023-05-29 14:01 UTC (permalink / raw)
To: rsbecker; +Cc: git
> >Please can someone help nudge me in the right direction?
>
> I wonder whether setting up a clean/smudge filter might help. You might want to look into a clean filter that runs your code generator.
Thanks. I'm not clear that this will help, because the main problem is
that the rebase stops when trying to apply a later commit. In this
case, the previous commit will be "clean", but the commit the rebase
is trying to apply will conflict and the rebase process will stop
Reading elsewhere, I'm now looking into whether wrapping the default
mergetool will help provide the "hooks" I need.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Automatically re-running commands during an interactive rebase or post commit
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 16:02 ` Paul Jolly
2023-05-29 17:53 ` Phillip Wood
2023-05-30 7:22 ` Son Luong Ngoc
2023-05-30 9:44 ` Oswald Buddenhagen
3 siblings, 1 reply; 13+ messages in thread
From: Paul Jolly @ 2023-05-29 16:02 UTC (permalink / raw)
To: git
> I would appreciate some advice on the best way to solve the following problem.
Replying to self with some updates based on further investigations.
The lack of pre-commit like hook during a rebase is documented in a
few places (https://adamj.eu/tech/2022/11/07/pre-commit-run-hooks-rebase/
to list one). The -x flag provides a means by which I can
retrospectively amend the "previous" commit if that is not clean. Not
ideal, but a solution of sorts.
However, the main problem appears to be the lack of "hook" to do
something when git rebase detects conflicts.
Ideally, I would like to have a hook be called when git rebase detects
a conflict, a hook in which I could attempt to "recover" the
situation. If that hook failed to fully recover the situation, git
rebase would fail as it currently does. Otherwise, it would be able to
continue as normal.
My use of git is pretty basic, so part of me feels like I can't be the
first person to run into this problem!
As ever, any pointers are greatly appreciated.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Automatically re-running commands during an interactive rebase or post commit
2023-05-29 16:02 ` Paul Jolly
@ 2023-05-29 17:53 ` Phillip Wood
2023-05-29 19:08 ` Paul Jolly
0 siblings, 1 reply; 13+ messages in thread
From: Phillip Wood @ 2023-05-29 17:53 UTC (permalink / raw)
To: Paul Jolly, git
Hi Paul
On 29/05/2023 17:02, Paul Jolly wrote:
>> I would appreciate some advice on the best way to solve the following problem.
>
> Replying to self with some updates based on further investigations.
>
> The lack of pre-commit like hook during a rebase is documented in a
> few places (https://adamj.eu/tech/2022/11/07/pre-commit-run-hooks-rebase/
> to list one). The -x flag provides a means by which I can
> retrospectively amend the "previous" commit if that is not clean. Not
> ideal, but a solution of sorts.
>
> However, the main problem appears to be the lack of "hook" to do
> something when git rebase detects conflicts.
I think you could get around this by using a script that wraps "git
rebase". Something like
while true
do
if test -d "$(git rev-parse --git-path rebase-merge)"
then
git rebase --continue
else
git rebase "$@"
fi
if test $? -eq 0
then
exit 0
fi
# Handle conflicts here
if automatic-conflict-resolution-failed
then
exit 1
fi
done
You can get a list of the files that have conflicts with
git diff-index --name-only --diff-filter=U HEAD --
or by parsing the output of
git status --porcelain
I did wonder if you could use a custom merge driver (see man
gitattributes) for the file with the checksums but that would be run
before all the other files have been merged. Another alternative might
be to use a custom merge strategy that runs "git merge-ort" and then
cleans up the conflicts in the checksum file. You can specify a custom
strategy by naming your script "git-merge-foo" and passing "-s foo" to
git rebase.
Best Wishes
Phillip
> Ideally, I would like to have a hook be called when git rebase detects
> a conflict, a hook in which I could attempt to "recover" the
> situation. If that hook failed to fully recover the situation, git
> rebase would fail as it currently does. Otherwise, it would be able to
> continue as normal.
>
> My use of git is pretty basic, so part of me feels like I can't be the
> first person to run into this problem!
>
> As ever, any pointers are greatly appreciated.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Automatically re-running commands during an interactive rebase or post commit
2023-05-29 17:53 ` Phillip Wood
@ 2023-05-29 19:08 ` Paul Jolly
2023-05-29 19:48 ` Phillip Wood
0 siblings, 1 reply; 13+ messages in thread
From: Paul Jolly @ 2023-05-29 19:08 UTC (permalink / raw)
To: phillip.wood; +Cc: git
Hi Phillip,
Many thanks for your response.
> I think you could get around this by using a script that wraps "git
> rebase". Something like
That's an interesting thought. I will give this some thought, thank you.
> I did wonder if you could use a custom merge driver (see man
> gitattributes) for the file with the checksums but that would be run
> before all the other files have been merged. Another alternative might
> be to use a custom merge strategy that runs "git merge-ort" and then
> cleans up the conflicts in the checksum file. You can specify a custom
> strategy by naming your script "git-merge-foo" and passing "-s foo" to
> git rebase.
This approach with a custom merge strategy is very much closer to what
feels like it will work best.
I just gave this a try, and I seem to be falling at somewhat the first hurdle.
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.
Do you have any suggestions/pointers?
Best,
Paul
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Automatically re-running commands during an interactive rebase or post commit
2023-05-29 19:08 ` Paul Jolly
@ 2023-05-29 19:48 ` Phillip Wood
2023-05-31 4:14 ` Elijah Newren
0 siblings, 1 reply; 13+ messages in thread
From: Phillip Wood @ 2023-05-29 19:48 UTC (permalink / raw)
To: Paul Jolly, phillip.wood; +Cc: git, Elijah Newren
Hi Paul
On 29/05/2023 20:08, Paul Jolly wrote:
> Hi Phillip,
>
> Many thanks for your response.
>
>> I think you could get around this by using a script that wraps "git
>> rebase". Something like
>
> That's an interesting thought. I will give this some thought, thank you.
>
>> I did wonder if you could use a custom merge driver (see man
>> gitattributes) for the file with the checksums but that would be run
>> before all the other files have been merged. Another alternative might
>> be to use a custom merge strategy that runs "git merge-ort" and then
>> cleans up the conflicts in the checksum file. You can specify a custom
>> strategy by naming your script "git-merge-foo" and passing "-s foo" to
>> git rebase.
>
> This approach with a custom merge strategy is very much closer to what
> feels like it will work best.
>
> I just gave this a try, and I seem to be falling at somewhat the first hurdle.
>
> 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.
>
> 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.
Best Wishes
Phillip
> Best,
>
>
> Paul
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Automatically re-running commands during an interactive rebase or post commit
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 16:02 ` Paul Jolly
@ 2023-05-30 7:22 ` Son Luong Ngoc
2023-05-30 9:44 ` Oswald Buddenhagen
3 siblings, 0 replies; 13+ messages in thread
From: Son Luong Ngoc @ 2023-05-30 7:22 UTC (permalink / raw)
To: Paul Jolly; +Cc: git
Hey Paul,
On Mon, May 29, 2023 at 3:44 PM Paul Jolly <paul@myitcv.io> wrote:
>
> Hi all,
>
> I would appreciate some advice on the best way to solve the following problem.
>
...
>
> I've tried to experiment with how I might do this using git commit
> hooks. But so far, my git foo is failing me. It mainly fails because
> when doing an edit of an earlier commit via an interactive rebase,
> later changes might well conflict (in the generated file) with the
> results of the code generator having been re-run on the edited commit.
> At this point, my git rebase --continue stops until I have fixed the
> conflict. But in almost all situations, the conflict comes in the
> generated hash file. Which I fix by simply re-running the code
> generation script (I could optionally fix it by doing a git checkout
> --theirs, and then re-running the code generation script).
>
> This all feels tantalisingly close to being a perfect workflow! But I
> can't quite figure out how to make the git hooks "work" in such a way
> that doesn't require any intervention from me (except in those
> situations where there is a conflict during the rebase that is _not_
> in the code generated file and so does require my intervention).
>
> The code generation step is incredibly fast if there is nothing to do,
> and is quite fast even when there is something to do (in any case it
> can't avoid doing this work).
>
> Please can someone help nudge me in the right direction?
In general, there are 2 cases that you would want to handle:
1. Inserting format directive in between commit rebase that DOES NOT
come with merge conflicts
2. Same but DOES come with merge conflicts.
For (1), you might be interested in tools such as
- Git Absorb(a) that automatically fixup your stack of commits with your
current dirty changes.
- Git Branchless(b) "git test" feature
Both of these tools are heavily influenced by Meta's internal Phabricator
mercurial workflow. Since the release of these tools, Meta has also
open-sourced their internal tool at Sapling SCM(c) which they touted
to be git-compatible.
For (2), and if none of the tools above solve your problem,
then I recommend using git-rebase interactive with a vim macro to
generate the needed rebase todo. You can find my comment in (d)
to see what such a rebase todo list would look like.
Tools such as Restack (e) take it a step further by providing a custom Git
`sequence.editor` to programmatically generate the rebase todo for you.
This could be a bash script, or a perl script... or a custom Go binary of
your choosing. You might want to go down this route if a vim macro is
not sufficient and you require some custom logic.
Finally, I would recommend turning on rerere.enabled (f) config to store
the conflict resolution for subsequent rebase attempts. This way, you would
only need to resolve each rebase conflict once.
(a): https://github.com/tummychow/git-absorb
(b): https://github.com/arxanas/git-branchless/wiki/Command:-git-test#fixing-formatting-and-linting-issues
(c): https://sapling-scm.com/docs/commands/absorb
(d): https://github.com/arxanas/git-branchless/discussions/45#discussioncomment-3364792
(e): https://github.com/abhinav/restack
(f): https://git-scm.com/docs/git-config#Documentation/git-config.txt-rerereenabled
>
> Many thanks,
>
>
> Paul
Cheers,
Son Luong.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Automatically re-running commands during an interactive rebase or post commit
2023-05-29 13:38 Automatically re-running commands during an interactive rebase or post commit Paul Jolly
` (2 preceding siblings ...)
2023-05-30 7:22 ` Son Luong Ngoc
@ 2023-05-30 9:44 ` Oswald Buddenhagen
2023-05-30 10:27 ` Paul Jolly
3 siblings, 1 reply; 13+ messages in thread
From: Oswald Buddenhagen @ 2023-05-30 9:44 UTC (permalink / raw)
To: Paul Jolly; +Cc: git
On Mon, May 29, 2023 at 02:38:40PM +0100, Paul Jolly wrote:
>As part of my project, I have a code generation script that sha256
>hashes a number of files to another file. This produces a
>deterministic "has this part of the project changed" indicator via the
>code generated file's content, that I then use in various cache
>invalidation steps.
>
>This means, however, that I need to re-run that code generation script
>as part of each commit in order to ensure that the code generated hash
>file is current (I have a step in CI that detects if it is not, which
>re-runs the code generation script to then see if the commit is
>"clean").
>
i would recommend taking a step back and considering whether you're
actually trying to fix the right problem.
why are you checking in an auto-generated file, esp. given that it can
be generated very quickly as you report?
usually, this should be done by the build system.
if the used build tool really is too dumb to integrate it into the build
system, you might have luck with a post-checkout hook.
you can also obtain existing hashes directly from git, with ls-tree,
though this would again require some kind of integration with the build
or checkout process.
if you can't get around checking in the hash, i can think of hacking it
using rebase --exec. basically, before each pick you'd create a commit
that reverts the hash change (by checking out that path from the parent
of the last commit that touched it, found automatically with git log),
and after the pick you'd squash away the revert (using `reset HEAD~2 &&
commit -C @{1}` or something to that effect). very ugly, very fragile.
regards,
ossi
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Automatically re-running commands during an interactive rebase or post commit
2023-05-30 9:44 ` Oswald Buddenhagen
@ 2023-05-30 10:27 ` Paul Jolly
0 siblings, 0 replies; 13+ messages in thread
From: Paul Jolly @ 2023-05-30 10:27 UTC (permalink / raw)
To: Oswald Buddenhagen; +Cc: git
Hi ossi,
Thanks for the response.
> i would recommend taking a step back and considering whether you're
> actually trying to fix the right problem.
>
> why are you checking in an auto-generated file, esp. given that it can
> be generated very quickly as you report?
>
> usually, this should be done by the build system.
Thanks for asking about this and forcing me to think more on the point.
To add a bit more context, and explanation behind the current design decisions.
The system I have described is a pipeline that supports a
documentation site for https://cuelang.org/. The architecture I have
described is that of the preprocessor, a tool which helps to automate
the testing of examples in documentation. Content authors write
documentation in format X, the preprocessor validates (and runs, as
required) that content, and produces format Y. Format Y is the input
to a Hugo (https://gohugo.io/) static site; hugo processes format Y to
produce format Z, the HTML that then renders the site.
The generation of hashes that I referred to before relates to the
contents of format X. If when the preprocessor runs it detects
(according to the cache files commited with the content) a cache hit,
then there is no need to re-run an example in some documentation. We
commit those hashes for now to sidestep needing to create and maintain
a shared preprocessor cache (a cache that is shared between CI systems
and users). We might move to a system like that in the future; for now
this feels like a sufficient setup.
The cache right now is very dumb; well-known files are updated with
hash values. And this is what creates the git conflicts. One thing we
could do to eliminate the conflicts altogether is commit a
content-addressed cache. This would have the problem of growing over
time... but I think we could solve that problem a different way.
> if the used build tool really is too dumb to integrate it into the build
> system, you might have luck with a post-checkout hook.
>
> you can also obtain existing hashes directly from git, with ls-tree,
> though this would again require some kind of integration with the build
> or checkout process.
>
> if you can't get around checking in the hash, i can think of hacking it
> using rebase --exec. basically, before each pick you'd create a commit
> that reverts the hash change (by checking out that path from the parent
> of the last commit that touched it, found automatically with git log),
> and after the pick you'd squash away the revert (using `reset HEAD~2 &&
> commit -C @{1}` or something to that effect). very ugly, very fragile.
Thanks. I have a working setup now using a combination of git rebase
-x and a script that I run whenever git rebase fails because of a
conflict. This works but is not ideal for a couple of reasons:
1. Each interactive rebase is "littered" with exec lines which should
be a detail
2. I need to re-run the script manually when conflicts are detected
Point 1 would be nicely addressed by a git hook that fires "pre
commit" during a rebase.
Point 2 could be solved by a custom merge driver, but that's seemingly
not possible right now:
https://lore.kernel.org/git/ZHXFdRnrwzNCA227@ugly/T/#m14b204843fea1fe9ff1c7500244049a43ed610eb.
Alternatively it could be solved by another hook that fires when
rebase detects a conflict, a hook that attempts to "recover" the
situation before rebase actually fails.
Thanks again for asking about whether we are solving the right problem
here. Writing my response above prompted me to think again about
different solutions.
Best,
Paul
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Automatically re-running commands during an interactive rebase or post commit
2023-05-29 19:48 ` Phillip Wood
@ 2023-05-31 4:14 ` Elijah Newren
2023-06-02 9:57 ` Phillip Wood
2023-06-08 5:11 ` Paul Jolly
0 siblings, 2 replies; 13+ messages in thread
From: Elijah Newren @ 2023-05-31 4:14 UTC (permalink / raw)
To: phillip.wood; +Cc: Paul Jolly, git
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`.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Automatically re-running commands during an interactive rebase or post commit
2023-05-31 4:14 ` Elijah Newren
@ 2023-06-02 9:57 ` Phillip Wood
2023-06-08 5:11 ` Paul Jolly
1 sibling, 0 replies; 13+ messages in thread
From: Phillip Wood @ 2023-06-02 9:57 UTC (permalink / raw)
To: Elijah Newren, phillip.wood; +Cc: Paul Jolly, git
Hi Elijah
On 31/05/2023 05:14, Elijah Newren wrote:
>
> ... lots of helpful comments ...
>
> Anyway, if you want a low-level do-a-merge thing, use `git merge-tree`.
Thanks for taking the time to explain that, I hadn't really paid
attention to the changes to "git merge-tree" it looks nice - I should
switch a couple of scripts I've got from using "git merge-recursive"
over to that.
Best Wishes
Phillip
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Automatically re-running commands during an interactive rebase or post commit
2023-05-31 4:14 ` Elijah Newren
2023-06-02 9:57 ` Phillip Wood
@ 2023-06-08 5:11 ` Paul Jolly
1 sibling, 0 replies; 13+ messages in thread
From: Paul Jolly @ 2023-06-08 5:11 UTC (permalink / raw)
To: Elijah Newren; +Cc: phillip.wood, git
> Anyway, if you want a low-level do-a-merge thing, use `git merge-tree`.
Elijah - please accept my apologies for my belated reply.
Thank you very much for this detail. I will give the custom merge
strategy approach another whirl!
Best,
Paul
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2023-06-08 5:11 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
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
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).