threads / discuss / 29337

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

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

## tl;dr

3 messages between Jan 11, 2012 and Jan 11, 2012.

replies: 2people: 2as markdown or json

Linus Torvalds· Jan 11, 2012, 01:51 UTC · lore

On Thu, Jan 5, 2012 at 1:47 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:

Show 8 quoted lines

> 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

 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:

Junio C Hamano· Jan 11, 2012, 02:38 UTC · re: Linus Torvalds · lore

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

Show 20 quoted lines

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

Linus Torvalds· Jan 11, 2012, 02:52 UTC · re: Junio C Hamano · lore

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