"Martin Langhoff" <martin.langhoff@xxxxxxxxx> writes:
> On 12/21/06, Jay Cliburn <jacliburn@xxxxxxxxxxxxx> 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.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html