Hello, List! 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. What is the evolve command? Imagine you have three dependent changes up for review and you receive feedback that requires editing all three changes. While you're editing one, more feedback arrives on one of the others. What do you do? The evolve command is a convenient way to work with chains of commits that are under review. Whenever you rebase or amend a commit, the repository remembers that the old commit is obsolete and has been replaced by the new one. Then, at some point in the future, you can run "git evolve" and the correct sequence of rebases will occur in the correct order such that no commit has an obsolete parent. Part of making the "evolve" command work involves tracking the edits to a commit over time, which could provide a lot of other benefits: - Systems like gerrit would no longer need to rely on "change-id" tags in commit comments to associate commits with the change that they edit, since git itself would have that information. - You could directly view the history of a commit over time (ie: the sequence of amends and rebases that occurred with that commit, orthogonal to the history of the branch it is on). If you've used mercurial, this would be a git equivalent to "hg obslog". If you've used gerrit, this would be like the gerrit "change log" but it would work for all commits and work offline. - You can easily list all the changes that you have as works-in progress. If you've used gerrit, this would be an offline equivalent to the gerrit dashboard. - You could choose to share the history of a commit with others, or collaborate on and merge different variants of the same change. Some information about Mercurial's evolve command can be found here: https://www.mercurial-scm.org/doc/evolution/ Other similar technologies: rebase -i can be used to solve the same problem, but you can't easily switch tasks midway through an interactive rebase or have more than one interactive rebase going on at the same time. It also can't handle the case where you have multiple changes sharing the same parent that needs to be rebased and won't let you collaborate with others on resolving a complicated interactive rebase. patch queues (topgit, stgit, quilt) address a very similar problem, however since they're built on top of git rather than integrated with it, most of them end up managing extra state that can get easily damaged whenever you run a native git command that doesn't know about the patch queue. Most of them also have various workflow problems that aren't present in hg evolve. Is anyone else interested in this? Please email me directly or on this list. Let's chat: I want to make sure that whatever we come up with is at least as good as any similar technology that has come before.
