Hi folks, I'm wondering whether it's possible to perform a (non-conflicting) cherry pick without impacting the working tree (or index). I understand Elijah Newren has been working on git-merge-tree changes that would allow for simulating (and even saving) merge commits without affecting the index or working tree, and I could imagine that's a piece of how such a thing could/should work, but I'm not terribly clear on the relationship between merges and cherry-picks. It *seems* as though I could enact something functionally equivalent to a cherry-pick by first creating a (temporary) "--ours" merge commit on the target branch, pretending to have merged the parent commit of the cherry-pickable one, and then merging the cherry-pick commit itself on top of that. The resulting tree could be used as the basis for a final commit on top of the original tip of the target branch, if that merge were clean, and otherwise fail saying "there are conflicts, go do things properly in a working tree pls". I'm not sure whether this is the right way to conceive of cherry-picking, however, or whether it makes more sense to conceive of it as a single-commit rebase. Is there a relationship between git-merge-tree and rebases? Is there an aspiration to develop "server side rebase" also at some stage? Thanks for any help understanding how cherry-picks conceptually "work". Thanks, Tao
