fix(hooks): use same branchless dir for all worktrees
#1095
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
arxanas
force-pushed
the
arxanas/worktree
branch
from
c981148
to
d839967
Compare
miquella
reviewed
Oct 11, 2023
arxanas
force-pushed
the
arxanas/worktree
branch
2 times, most recently
from
3381acc
to
9e0f970
Compare
arxanas
force-pushed
the
arxanas/worktree
branch
2 times, most recently
from
90f2178
to
4c039c5
Compare
To silence the warnings about using resolver v1 by default.
If tracing is installed, the `warn!` call will attempt to write to `ErrorStream`, which seems to cause a deadlock when we are destroying the `ErrorStream`.
Previously, all worktrees would have their own event log, which means that they wouldn't agree on the set of visible commits. They would also have to recalculate the same DAG, etc. After this commit, they all share the same event log, etc. This creates a temporary regression in the Phabricator forge for `git submit`, fixed in the next commit. The problem is that the rewrite events in the test run invoking `arc` shouldn't be propagated to the parent event log.
arxanas
force-pushed
the
arxanas/worktree
branch
2 times, most recently
from
7251b72
to
7a7c61c
Compare
`arc diff` will amend the current commit as part of the submit process (primarily to create the change ID/embed the review URL in the commit message), but we don't want those changes to be available in the regular event log. My solution is to create a special event transaction ID that indicates that events should not be added to the event log. Another solution could be to allow events to created in a transaction, and then roll back the transaction rather than commit it. (Currently, "transactions" only refer to groups of events, and are always committed.) Normally, SQLite (which we use for the event log) would expose this kind of transactional functionality, but we can't use database-level transactions because the events span multiple process calls (such as Git hooks that are invoked as child processes), so we can't use the normal database mechanisms for this. It would be a lot of work to implement our own transaction system, so it just seems simpler to suppress all events immediately. One consequence is that users who create or rewrite commits inside `git test` calls will not have the events be preserved, which hopefully does not happen often in practice. Note that `git test fix` would still look at the resulting commits and apply the tree-level fixes, even though the original rewrite events in the worktrees wouldn't be preserved.
arxanas
force-pushed
the
arxanas/worktree
branch
from
7a7c61c
to
40cdcab
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Closes #928.