Hi Philip, On Sun, 22 Apr 2018, Philip Oakley wrote: > From: "Johannes Schindelin" <johannes.schindelin@xxxxxx> > > Once upon a time, this here developer thought: wouldn't it be nice if, > > say, Git for Windows' patches on top of core Git could be represented as > > a thicket of branches, and be rebased on top of core Git in order to > > maintain a cherry-pick'able set of patch series? > > > > The original attempt to answer this was: git rebase --preserve-merges. > > > > However, that experiment was never intended as an interactive option, > > and it only piggy-backed on git rebase --interactive because that > > command's implementation looked already very, very familiar: it was > > designed by the same person who designed --preserve-merges: yours truly. > > > > Some time later, some other developer (I am looking at you, Andreas! > > ;-)) decided that it would be a good idea to allow --preserve-merges to > > be combined with --interactive (with caveats!) and the Git maintainer > > (well, the interim Git maintainer during Junio's absence, that is) > > agreed, and that is when the glamor of the --preserve-merges design > > started to fall apart rather quickly and unglamorously. > > > > The reason? In --preserve-merges mode, the parents of a merge commit (or > > for that matter, of *any* commit) were not stated explicitly, but were > > *implied* by the commit name passed to the `pick` command. > > > Aside: I think this para should be extracted to the --preserve-merges > documentation to highlight what it does / why it is 'wrong' (not what would be > expected in some case). It may also need to discuss the (figurative) Cousins > vs. Siblings distinction [merge of branches external, or internal, to the > rebase. Quite honestly, I'd much rather spend time improving --rebase-merges than improving --preserve-merges documentation. In my mind, the latter is pretty useless, especially once the former lands in an official Git version. Of course, feel free to disagree with me by sending a patch to improve the documentation of --preserve-merges ;-) > "In --preserve-merges, the commit being selected for merging is implied by the > commit name passed to the `pick` command (i.e. of the original merge commit), > not that of the rebased version of that parent." It is much, much worse: In --preserve-merges, no commit can change its ancestry. Every rebased commit's parents will be the rebased original parents. Or some such. But really, why bother describing something *that* broken? Why not work toward a solution that makes that broken option obsolete? Like, say, --rebase-merges? ;-) > A similar issue occurs with (figuratively) '--ancestry-path --first parent' > searches which lacks the alternate '--lead parent' post-walk selection. [1]. I > don't think there is a dot notation to select the merge cousins, nor merge > siblings either A.,B ? (that's dot-comma ;-) I actually had missed `--ancestry-path`... I should probably use it in the description of the "cousins". > [... lots of quoted text...] Could I ask you to make it easier for me by cutting quoted text that is irrelevant to your reply? The way I read mails forces me to scroll down (sometimes on a phone) all the way to the end, just to find that that time was spent in vain. Thanks, Dscho
