On 10/10/2022 20:35, Victoria Dye wrote:
Stefan Xenos via GitGitGadget wrote:
From: Stefan Xenos <sxenos@xxxxxxxxxx>
This document describes what a change graph for
git would look like, the behavior of the evolve command,
and the changes planned for other commands.
It was originally proposed in 2018, see
https://public-inbox.org/git/20181115005546.212538-1-sxenos@xxxxxxxxxx/
Signed-off-by: Stefan Xenos <sxenos@xxxxxxxxxx>
Signed-off-by: Chris Poucet <poucet@xxxxxxxxxx>
---
Documentation/technical/evolve.txt | 1070 ++++++++++++++++++++++++++++
1 file changed, 1070 insertions(+)
create mode 100644 Documentation/technical/evolve.txt
diff --git a/Documentation/technical/evolve.txt b/Documentation/technical/evolve.txt
new file mode 100644
index 00000000000..2051ea77b8a
--- /dev/null
+++ b/Documentation/technical/evolve.txt
...
+P0. Any commit that may be involved in a future evolve command should not be
+ garbage collected. Specifically:
+ - Commits that obsolete another should not be garbage collected until
+ user-specified conditions have occurred and the change has expired from
+ the reflog. User specified conditions for removing changes include:
+ - The user explicitly deleted the change.
+ - The change was merged into a specific branch.
+ - Commits that have been obsoleted by another should not be garbage
+ collected if any of their replacements are still being retained.
If the creation of these linkages is passive, but requires active user
intervention to clean up, this requirement could result in creating an
enormous amount of cruft in repositories. I might rebase a branch 10+ times
between pushes to make little tweaks to phrasing in commit messages, or fix
typos, etc. It sounds like I'd be pushing an order of magnitude more objects
than I am now, let alone the fact that they wouldn't be GC'd automatically.
That's an interesting point. When we push we only really need to push a
map of "commits we pulled" to "commits we're pushing", we don't need to
send all the intermediate changes. That would also help to address
Glen's review club concerns about accidentally pushing secret information.
One of the things which I hope comes out of having all the intermediate
changes tracked locally is a way to view the history of a particular
commit. If I make a mistake when rebasing and don't notice it for a
while it would be really helpful to be able to view the history and
figure out which change introduced the mistake (You can do something
similar with "git rev-list -g $branch | git log -p --stdin
^${branch}@{upstream}" but you have to wade through all the commits on
$branch).
...
+Similar technologies
+--------------------
+There are some other technologies that address the same end-user problem.
+
+Rebase -i can be used to solve the same problem, but users can't easily switch
+tasks midway through an interactive rebase or have more than one interactive
+rebase going on at the same time. It can't handle the case where you have
+multiple changes sharing the same parent when that parent needs to be rebased
+and won't let you collaborate with others on resolving a complicated interactive
+rebase. You can think of rebase -i as a top-down approach and the evolve command
+as the bottom-up approach to the same problem.
I think it's worth considering whether 'rebase' can be updated to handle
these cases (since it might simplify and/or pare down your proposed design).
1. Can't easily switch tasks midway through an interactive rebase
- I could imagine us introducing a 'git rebase pause' that does this,
although it would require changes to how rebases are tracked
internally.
I'm not sure how much of a problem this is in practice as one can use
"git worktree add" to work on a different branch or is the idea to be
able to start several rebases on the same branch? - That sounds like a
recipe for conflicts that cannot be resolved automatically unless the
user is very disciplined.
2. Can't have more than one interactive rebase going on at the same time
- Do you mean nested rebases, or just separate ones? I think both of them
could be possible (with the changes to rebase tracking in #1), but
nested ones might be tough to mentally keep track of.
3. Can't handle multiple changes sharing the same parent when the parent
needs to be rebased
- Since the introduction of '--update-refs' [1], this is technically
possible (although it needs a UI for the use case you mentioned).
'--update-refs' is more limited though I think. With evolve if I have
D (topic-2)
/
A - B - C (topic-1)
\
E (topic-3)
then if I checkout topic-1 and amend one of the commits I can run "git
evolve" to automatically rebase topic-2 & topic-3. One cannot do that
with "rebase --update-refs". We could extend rebase (or have a new
command) so that users can say "amend commit X and rebase all the
branches that contain it".
4. Won't let you collaborate with others on resolving a complicated
interactive rebase
- This is an interesting one, since it requires being able to push a
mid-merge state. However, if you're planning on solving that for 'git
evolve', a similar solution could probably be used for 'rebase'.
Pushing a whole rebase script, though, would be more complicated.
The "top-down"/"bottom-up" analogy is a bit lost on me, I'm afraid. Could
you clarify what you mean by that?
I was confused by that as well
[1] https://lore.kernel.org/git/pull.1247.v5.git.1658255624.gitgitgadget@xxxxxxxxx/
Best Wishes
Phillip
