source-1233101919.txt

   1 Progress with the interactive rebase preserving merges
   2
   3 I thought about the "dropped" commits a bit more, after all, and it is
   4 probably a good thing to substitute them by their parent, as Stephen did it.
   5
   6 Imagine that you have merged a branch with two commits.  One is in upstream,
   7 and you want to rebase (preserving merges) onto upstream.  Then you still
   8 want to merge the single commit.
   9
  10 Even better, if there is no commit left, the ''$REWRITTEN'' mechanism will
  11 substitute the commit onto which we are rebasing, so a merge will just
  12 result in a fast-forward!
  13
  14 Oh, another thing: merge commits can never be dropped (as that would mean
  15 that the patch id of that commit is identical to a patch id of a commit in
  16 the upstream branch; but merge commits do not have a single patch, let alone
  17 a patch id).  So we can be certain that a dropped commit always has at most
  18 one parent.
  19
  20 So what about a root commit?  If that was dropped, we will just substitute
  21 it with the commit onto which we rebase.
  22
  23 The thing that upset me a bit when I found out about it, is what t3410 is
  24 all about.  It speaks about dropping local merges together with their
  25 _whole_ branches when an upstream has the same "merge resolution".
  26
  27 To my surprise, Stephen had no objections to remove that stuff, so I think
  28 I'll be able to submit something usable tomorrow.
  29
  30 Or maybe I will start to use it first...
  31
  32 Another thought that occurred to me is that I could include the output of
  33 ''git log --graph''.  This cannot be done in the rebase script directly,
  34 as there are "goto" and "merge" statements disrupting the graph, and
  35 besides, it would look ugly if you reordered commits without adjusting the
  36 graph, so I may include the graph (for ''-p'' only) in the comment section.