Re: Git Evolve

[Derrick Stolee <stolee@gmail.com>]

On 9/29/2018 7:00 PM, Stefan Xenos wrote:
> Hello, List!

Hello! Welcome.

> I'm interested in porting something like Mercurial's evolve command to
> Git. I'll be following up with a formal proposal shortly, but before I
> do I thought I'd introduce myself to the list and find out if anyone
> else is interested in this topic.

I'm CC'ing some contributors who have also expressed interest in this topic.

> What is the evolve command?

I'm snipping the rest of your thread because I'm vaguely familiar with 
how this is used in hg, but I haven't used it myself. Instead, I'm going 
to ask you the same questions I asked the last time I had a conversation 
about this with someone. In my opinion, these questions should have good 
answers before we start working on the solution, or else we could paint 
ourselves into a corner as we build the first pieces.

---

What would the command-line experience look like for this workflow? Be 
specific, including examples!

How does one create a commit that obsoletes another? Are we in the 
middle of an interactive rebase, or are we simply checking out the 
commit? How does a use keep track of their progress in a topic?

How do I view which commits in my topic are obsolete, and to what commits?

If I want to obsolete commits on one machine and then finish the work on 
another machine, how do I do that? Similarly: how can I share obsolete 
commits with other users so they can apply them (or not)?

Do obsolescence markers live in the ref space? (This is one way to help 
answer the question above.)

Can I make multiple commits obsolete into one commit (merge patches)? 
Can I make my commit obsolete in multiple ways (split a patch)? How is 
this communicated to the user?

---

In my opinion, a good way to move forward is to create a patch that adds 
a design document to Documentation/technical that answers these 
questions. Then we can dig in more to make the vision clearer.

I'm not a UX expert, but this seems like a place where we could use 
someone with expertise in the area. If we are not careful, we could end 
up with something even harder to use than interactive rebase. The main 
goal here is to make it easy to rewrite a topic (plus, the ability to do 
so in stages).

I look forward to see what goes on in this space. Count me in to review 
the technical details.

Thanks,
-Stolee