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