Re: [GIT PULL] use generic pci_iomap on all architectures

Re: [GIT PULL] use generic pci_iomap on all architectures

[Linus Torvalds]

[-- Attachment #1: Type: text/plain, Size: 937 bytes --]

On Thu, Jan 5, 2012 at 1:47 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> On Fri, 6 Jan 2012 08:39:16 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>
>> So why does you pull request refer to "commit
>> 805a6af8dba5dfdd35ec35dc52ec0122400b2610", I wonder?  Is that just what
>> "git request-pull" produced?
>
> I see, "git request-pull" just puts in whatever you specify on the
> command line rather than the merge-base ...

.. and that is a fairly silly misfeature, since it makes the "since
commit xyz" largely meaningless.

I suspect we really should make "git request-pull" show the merge
base(s) as the "since commit", because that way the output of git
request-pull is "stable", and doesn't depend on what particular random
state you've synced up to since.

Junio, I think the patch would be as simple as the attached - totally
untested - one-liner? Comments?

                            Linus

[-- Attachment #2: patch.diff --]
[-- Type: text/x-patch, Size: 486 bytes --]

 git-request-pull.sh |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/git-request-pull.sh b/git-request-pull.sh
index d7ba1178ae75..64960d65a1c2 100755
--- a/git-request-pull.sh
+++ b/git-request-pull.sh
@@ -96,7 +96,7 @@ git show -s --format='The following changes since commit %H:
   %s (%ci)
 
 are available in the git repository at:
-' $baserev &&
+' $merge_base &&
 echo "  $url${ref+ $ref}" &&
 git show -s --format='
 for you to fetch changes up to %H:

Re: [GIT PULL] use generic pci_iomap on all architectures

[Junio C Hamano]

Linus Torvalds <torvalds@linux-foundation.org> writes:

> On Thu, Jan 5, 2012 at 1:47 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>> On Fri, 6 Jan 2012 08:39:16 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>>
>>> So why does you pull request refer to "commit
>>> 805a6af8dba5dfdd35ec35dc52ec0122400b2610", I wonder?  Is that just what
>>> "git request-pull" produced?
>>
>> I see, "git request-pull" just puts in whatever you specify on the
>> command line rather than the merge-base ...
>
> .. and that is a fairly silly misfeature, since it makes the "since
> commit xyz" largely meaningless.
>
> I suspect we really should make "git request-pull" show the merge
> base(s) as the "since commit", because that way the output of git
> request-pull is "stable", and doesn't depend on what particular random
> state you've synced up to since.
>
> Junio, I think the patch would be as simple as the attached - totally
> untested - one-liner? Comments?

I think it makes sense.

We use whatever garbage the user gave us (e.g. "origin/linus" which may
have been updated since the topic forked and be made irrelevant) only to
figure out where the history forked, and once we find that out we
consistently use the fork-point which has some meaning.

The parameter to "git shortlog" that appears later should also be updated
to match this, by the way, even though that should not affect the outcome
in any way.

I am however not sure what would happen when there are more than one merge
bases. I guess those who throw pull requests are not supposed to be doing
merges in reverse direction, so it should not matter ;-)

 git-request-pull.sh |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/git-request-pull.sh b/git-request-pull.sh
index d7ba117..38b68bb 100755
--- a/git-request-pull.sh
+++ b/git-request-pull.sh
@@ -96,7 +96,7 @@ git show -s --format='The following changes since commit %H:
   %s (%ci)
 
 are available in the git repository at:
-' $baserev &&
+' $merge_base &&
 echo "  $url${ref+ $ref}" &&
 git show -s --format='
 for you to fetch changes up to %H:
@@ -124,7 +124,7 @@ then
 	echo "----------------------------------------------------------------"
 fi &&
 
-git shortlog ^$baserev $headrev &&
+git shortlog $merge_base..$headrev &&
 git diff -M --stat --summary $patch $merge_base..$headrev || status=1
 
 if test -z "$ref"

Re: [GIT PULL] use generic pci_iomap on all architectures

[Linus Torvalds]

On Tue, Jan 10, 2012 at 6:38 PM, Junio C Hamano <gitster@pobox.com> wrote:
>
> The parameter to "git shortlog" that appears later should also be updated
> to match this, by the way, even though that should not affect the outcome
> in any way.

No, don't do that part.

Why?

Remember: there can be *multiple* merge bases. The expression

    git shortlog ^$baserev $headrev

always works, but changing "baserev" to "merge_base" will suddenly
break for the multiple merge-bases case.

> I am however not sure what would happen when there are more than one merge
> bases. I guess those who throw pull requests are not supposed to be doing
> merges in reverse direction, so it should not matter ;-)

The other cases don't really care. For them, "show one merge-base" is
fine, and they are "end-point" operations (like "diff") that really
cannot handle a set of commits anyway.

But for "git shortlog", switching to using the merge base would
actually start showing commits that shouldn't be shown. It's
fundamentally a set operator, and does the right thing in the presense
of multiple merge-bases (which "diff" and "since commit XYZ" are
clearly not set operators, although arguably you could try to show all
merge bases for the "since" case).

                       Linus