Re: Updated Kernel Hacker's guide to git

From: Junio C Hamano <junkio@cox.net>
Date: Dec 21, 2006, 07:32 UTC
Message-ID: <7vk60l1z7u.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <46a038f90612202304uabdffacld857cfcb90ec3e76@mail.gmail.com>

"Martin Langhoff" <martin.langhoff@gmail.com> writes:

Show 6 quoted lines

> On 12/21/06, Jay Cliburn <jacliburn@bellsouth.net> wrote:
>> $ git diff $(git merge-base master driver)..driver
>
> There is a nicer way to do it with 1.4.x git -- note the 3 dots:
>
> $ git diff master...driver

Careful.

I think Jay was looking at this kind of ancestry graph:

         *---*---*---* driver
        /
 --o---o---x---x---x---x master

There might be quite a few merges on either side, but the point is '*' are not yet 'in', and 'o' and 'x' are already in the 'upstream (but 'x' are not in Jay's driver yet).

The three dots would give both '*' and 'x'; I do not think that is what Jay wants. A submitter to mainline usually wants only '*' commits.

I've always thought that 'submission' is supposed to be done as a series of patches, in which case a reasonable way would be to do:

	git format-patch -n master driver

If on the other hand a single roll-up patch is desired, I think the most reasonable thing to do is to first merge the tip of the master to the tip of driver, resolve all the conflicts as needed, and take the diff between the 'master' and the result:

         *---*---*---*---y driver (y is the test merge)
        /               / 
 --o---o---x---x---x---x master

	git checkout driver
        git merge master
	... resolve conflicts if any, then "git commit"
	git diff master

This diff by definition should apply cleanly to the tip of 'master' and would result in the source that contains the updates for the driver.

When you are done, it would be advisable to do:

	git reset --hard HEAD^

to remove that 'y' merge, unless the merge involved a true conflict resolution.