Hi Dscho, On 12/03/2018 11:37, Johannes Schindelin wrote: > > > If we are to extract further mentioned explicit old:new merge > > parameter mapping to a separate discussion point, what we`re > > eventually left with is just replacing this: > > > > merge -R -C <original--merge-commit> <merge-head> > > > > ... with this: > > > > pick <original--merge-commit> <merge-head> > > I see where you are coming from. > > I also see where users will be coming from. Reading a todo list in the > editor is as much documentation as it is a "program to execute". And I am > afraid that reading a command without even mentioning the term "merge" > once is pretty misleading in this setting. > > And even from the theoretical point of view: cherry-picking non-merge > commits is *so much different* from "rebasing merge commits" as discussed > here, so much so that using the same command would be even more > misleading. I would disagree here, as it seems you`re going too much into implementation and theory here, where it shouldn`t really matter from the user`s point of view - the point is to rebase a commit, `pick` it from one place and plant it elsewhere. Yes, some commits might have a bit different semantics then others (merge vs non-merge), but it should just be an implementation detail, in my opinion, no need to leak it in user`s face (more than necessary). I feel that "merge" is a command that works really well in the mindset of (re)creating merges. But if we are "only" rebasing an existing merge, `pick` seems much more appropriate (to me, at least), and it aligns with what I`m already expecting `pick` to be doing. Down below, if we are (re)creating the merge, or doing magic to somehow just port it over, should be irrelevant. So "rebase" equals "pick and plant" (port), not "merge". > > That is what I had in mind, seeming possibly more straightforward and > > beautifully aligned with previously existing (and well known) > > `rebase` terminology. > > > > Not to say this would make it possible to use other `rebase -i` todo > > list commands, too, like if you want to amend/edit merge commit after > > it was rebased, you would write: > > > > edit <original--merge-commit> <merge-head> > > > > ..., where in case you would simply like to reword its commit > > message, it would be just: > > > > reword <original--merge-commit> <merge-head> > > > > > > Even `squash` and `fixup` could have their place in combination with > > a (to be rebased) merge commit, albeit in a pretty exotic rebases, > > thus these could probably be just disallowed - for the time being, at > > least. > > Sure, for someone who read the manual, that would be easy to use. Of > course, that's the minority. I`m not following you here - the point is these are already existing commands, which would still fit in just nicely, so nothing new to learn nor read. Now, if we are to discuss use cases where people don`t even know what they`re doing, I would think that misses the point. Besides, it`s always easier to make more mistakes when you introduce yet more commands/semantics to think about/learn, and I think it can be avoided here, for the better. > Also: the `edit` command is poorly named to begin with. A much cleaner > design would be to introduce the `break` command as suggested by Stephan. This is orthogonal to what we`re discussing. Existing commands might not be perfect, but that`s what we have now, so let`s be consistent, not putting additional burden on the user there, at least. But for the record - I tend to agree, I often find myself wondering if `edit`-ed commit means `rebase` stops after applying the changes and _before_ making the commit itself (so we just edit and --continue), or _after_ it (so we edit, `commit --amend` and --continue). > > The real power would be buried in implementation, learning to rebase > > merge commits, so user is left with a very familiar interface, slightly > > adapted do accommodate a bit different nature of merge commit in > > comparison to an ordinary one, also to allow a bit more of interactive > > rebase functionality, but it would pretty much stay the same, without > > even a need to learn about new `merge`, `-R`, `-C`, and so on. > > > > Yes, those would have its purpose, but for real merging then > > (creating new merges, or recreating old ones), not necessarily for > > merge rebasing. > > > > With state of `merge -R -C ...` (that `-R` being the culprit), it > > kind of feels like we`re now trying to bolt "rebase merges" > > functionality onto a totally different one (recreate merges, serving > > a different purpose), making them both needlessly dependent on each > > other, further complicating user interface, making it more confusing > > and less tunable as per each separate functionality needs (rebase vs. > > recreate). > > > > I guess I`m the one to pretty much blame here, too, as I really > > wanted `--recreate-merges` to handle "rebase merges" better, only to > > later realize it might not be the best tool for the job, and that a > > more separate approach would be better (at least not through the same > > `merge` todo list command)... > > > > [1] https://public-inbox.org/git/f3872fb9-01bc-b2f1-aee9-cfc0e4db77d6@xxxxxxxxx/ > > Well, the `-R` option is no worse than `git merge`'s `-s <strategy>` > option (which *also* changes the strategies rather drastically). What I wrote above, -R seems unfitting for `merge`, as we are not really merging, but rebasing (conceptually, not implementation wise). And it makes even less sense in the light of that previous comment where "rebasing a merge" shouldn`t even allow selecting a specific strategy, as that would imply (re)creating the merge instead. So using `merge` for rebasing existing (merge) commit seems as rather misusing the concept of `merging`. I don`t know, I`m thinking if we are looking at todo list from different perspectives - to you, it seems to be a sequence of commands to create something new (yes, from something that already exists, but that`s implementation detail). In that context, using `merge` might have sense (even if still being a very special merge). But to me, as we already have `pick` and not `commit` to rebase commits, it means we are not creating but rather reusing what we have (being an important concept to reason about), thus `pick` would still fit in for picking a merge commit just nicely, and more naturally, too. *Maybe if* `-R` would be turned into a full fledged "rebase" (or "rebasing") merge strategy, written as: merge -s rebase -C <original--merge-commit> <merge-head> ..., might be it would make more sense to me (aligned with what `merge` is expected to do). But even then, I might prefer having `pick` as a syntactic sugar over `merge -s rebase`, at least. In the light of this, I _could_ even see `-R` as short for `-s rebase`, but it still seems a bit awkward and forced. Regards, Buga
