Re: [PATCH v2 01/10] technical doc: add a design doc for the evolve command

[Phillip Wood <phillip.wood123@gmail.com>]

On 10/10/2022 20:35, Victoria Dye wrote:
> Stefan Xenos via GitGitGadget wrote:
>> From: Stefan Xenos <sxenos@google.com>
>>
>> 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@google.com/
>>
>> Signed-off-by: Stefan Xenos <sxenos@google.com>
>> Signed-off-by: Chris Poucet <poucet@google.com>
>> ---
>>   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@gmail.com/

Best Wishes

Phillip