Re: How to switch kernel customizations from 2.6.15.6 to 2.6.16?

Linus Torvalds [off-list ref] writes:

  Personally, I think the rebase syntax sucks, because the _natural_ way 
  to do it is to just describe the set of commits to rebase the same way 
  we describe all _other_ commit sets: as a "begin..end" sequence.

I'd agree in general, and I am not happy about them.

But I have an excuse.

rev-parse's A..B notation was invented on June 13th (178cb24).
But format-patch was originally posted on May 30th:

	http://article.gmane.org/gmane.comp.version-control.git/4279

before the convenience of rev-parse was invented ;-).

  So I think rebase _should_ work something like this:

	git rebase origin.. [--onto] linus

  ie just giving an arbitrary range.

In addition, both rebase and format-patch does a bit more than
straight his..mine.

    *---x---x---o---o---o---o
     \                      ^mine
      .---.---.---.
                  ^his

We do _not_ want to process all six of his..mine commits when
doing "format-patch his mine" in the above picture, because
upstream might have accepted some of them already, and we filter
them out with git-cherry.  

  This is even more noticeable for "git-format-patch", where
  that insane "<his> [<mine>]" syntax is even worse, for no
  good reason, when again it should really just work like "git
  diff" where giving a single revision implies a single
  revision, and giving a range implies a range, and no strange
  "mine" vs "his" rules ]

Having said that, you have been able to say format-patch A..B
C..D E..F for quite some time (since November 21, 2005).

Rebase is even more strange, especially with --onto.  When you do

    $ rebase --onto his origin mine

in this picture,

    *---x---x---o---o---o---o
     \      ^origin         ^mine
      .---.---.---.
                  ^his

you are discarding two 'x' commits, and lost-found is the only
thing that would help you to recover them.

Unlike format-patch which takes ranges, rebase does not let you
say "rebase --onto base A..B C..D E..F"; what happens might be
too confusing, especially if B, D, F are not coming from the
current branch.  The current branch is rewound to base and then
the chosen sets of patches are applied, which is kind-of scary.
It would feel safer to do:

	$ git checkout -b newbranch base
        $ git format-patch --stdout A..B C..D E..F | git am -3

and after making sure the result is really what you want
resetting the original branch to the current (newbranch) head.