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

From: Junio C Hamano <junkio@cox.net>
Date: Mar 29, 2006, 03:58 UTC
Message-ID: <7vlkutc36w.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <Pine.LNX.4.64.0603281749060.15714@g5.osdl.org>

Linus Torvalds <torvalds@osdl.org> 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 ;-).

Show 5 quoted lines

>   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.

Show 6 quoted lines

>   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.