{"thread":{"id":"29337","subject":"Re: [GIT PULL] use generic pci_iomap on all architectures","startedAt":"2012-01-11T01:51:07Z","lastAt":"2012-01-11T02:52:25Z","messageCount":3,"participants":["Linus Torvalds","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"182295","messageId":"CA+55aFwXj2ELrTDSgFfSC2Usz99-24uFSznAP34feJiCttwayQ@mail.gmail.com","threadId":"29337","inReplyTo":"20120106084701.8f704542754db826deda318a@canb.auug.org.au","subject":"Re: [GIT PULL] use generic pci_iomap on all architectures","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2012-01-11T01:51:07Z","receivedAt":"2012-01-11T01:51:07Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"On Thu, Jan 5, 2012 at 1:47 PM, Stephen Rothwell wrote:\n> On Fri, 6 Jan 2012 08:39:16 +1100 Stephen Rothwell wrote:\n>>\n>> So why does you pull request refer to \"commit\n>> 805a6af8dba5dfdd35ec35dc52ec0122400b2610\", I wonder?  Is that just what\n>> \"git request-pull\" produced?\n>\n> I see, \"git request-pull\" just puts in whatever you specify on the\n> command line rather than the merge-base ...\n\n.. and that is a fairly silly misfeature, since it makes the \"since\ncommit xyz\" largely meaningless.\n\nI suspect we really should make \"git request-pull\" show the merge\nbase(s) as the \"since commit\", because that way the output of git\nrequest-pull is \"stable\", and doesn't depend on what particular random\nstate you've synced up to since.\n\nJunio, I think the patch would be as simple as the attached - totally\nuntested - one-liner? Comments?\n\n Linus\n\n\n git-request-pull.sh | 2 +-\n 1 files changed, 1 insertions(+), 1 deletions(-)\n\ndiff --git a/git-request-pull.sh b/git-request-pull.sh\nindex d7ba1178ae75..64960d65a1c2 100755\n--- a/git-request-pull.sh\n+++ b/git-request-pull.sh\n@@ -96,7 +96,7 @@ git show -s --format='The following changes since commit %H:\n %s (%ci)\n \n are available in the git repository at:\n-' $baserev &&\n+' $merge_base &&\n echo \" $url${ref+ $ref}\" &&\n git show -s --format='\n for you to fetch changes up to %H:\n"},{"id":"182298","messageId":"7vipkj7ykd.fsf@alter.siamese.dyndns.org","threadId":"29337","inReplyTo":"CA+55aFwXj2ELrTDSgFfSC2Usz99-24uFSznAP34feJiCttwayQ@mail.gmail.com","subject":"Re: [GIT PULL] use generic pci_iomap on all architectures","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-01-11T02:38:58Z","receivedAt":"2012-01-11T02:38:58Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> On Thu, Jan 5, 2012 at 1:47 PM, Stephen Rothwell wrote:\n>> On Fri, 6 Jan 2012 08:39:16 +1100 Stephen Rothwell wrote:\n>>>\n>>> So why does you pull request refer to \"commit\n>>> 805a6af8dba5dfdd35ec35dc52ec0122400b2610\", I wonder?  Is that just what\n>>> \"git request-pull\" produced?\n>>\n>> I see, \"git request-pull\" just puts in whatever you specify on the\n>> command line rather than the merge-base ...\n>\n> .. and that is a fairly silly misfeature, since it makes the \"since\n> commit xyz\" largely meaningless.\n>\n> I suspect we really should make \"git request-pull\" show the merge\n> base(s) as the \"since commit\", because that way the output of git\n> request-pull is \"stable\", and doesn't depend on what particular random\n> state you've synced up to since.\n>\n> Junio, I think the patch would be as simple as the attached - totally\n> untested - one-liner? Comments?\n\nI think it makes sense.\n\nWe use whatever garbage the user gave us (e.g. \"origin/linus\" which may\nhave been updated since the topic forked and be made irrelevant) only to\nfigure out where the history forked, and once we find that out we\nconsistently use the fork-point which has some meaning.\n\nThe parameter to \"git shortlog\" that appears later should also be updated\nto match this, by the way, even though that should not affect the outcome\nin any way.\n\nI am however not sure what would happen when there are more than one merge\nbases. I guess those who throw pull requests are not supposed to be doing\nmerges in reverse direction, so it should not matter ;-)\n\n git-request-pull.sh | 4 ++--\n 1 files changed, 2 insertions(+), 2 deletions(-)\n\ndiff --git a/git-request-pull.sh b/git-request-pull.sh\nindex d7ba117..38b68bb 100755\n--- a/git-request-pull.sh\n+++ b/git-request-pull.sh\n@@ -96,7 +96,7 @@ git show -s --format='The following changes since commit %H:\n %s (%ci)\n \n are available in the git repository at:\n-' $baserev &&\n+' $merge_base &&\n echo \" $url${ref+ $ref}\" &&\n git show -s --format='\n for you to fetch changes up to %H:\n@@ -124,7 +124,7 @@ then\n \techo \"----------------------------------------------------------------\"\n fi &&\n \n-git shortlog ^$baserev $headrev &&\n+git shortlog $merge_base..$headrev &&\n git diff -M --stat --summary $patch $merge_base..$headrev || status=1\n \n if test -z \"$ref\"\n"},{"id":"182301","messageId":"CA+55aFwxaGXkJrpKXRFWEamAyF+a2+ypm7B6LLRzT0JpZp_0pg@mail.gmail.com","threadId":"29337","inReplyTo":"7vipkj7ykd.fsf@alter.siamese.dyndns.org","subject":"Re: [GIT PULL] use generic pci_iomap on all architectures","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2012-01-11T02:52:25Z","receivedAt":"2012-01-11T02:52:25Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"On Tue, Jan 10, 2012 at 6:38 PM, Junio C Hamano wrote:\n>\n> The parameter to \"git shortlog\" that appears later should also be updated\n> to match this, by the way, even though that should not affect the outcome\n> in any way.\n\nNo, don't do that part.\n\nWhy?\n\nRemember: there can be *multiple* merge bases. The expression\n\n git shortlog ^$baserev $headrev\n\nalways works, but changing \"baserev\" to \"merge_base\" will suddenly\nbreak for the multiple merge-bases case.\n\n> I am however not sure what would happen when there are more than one merge\n> bases. I guess those who throw pull requests are not supposed to be doing\n> merges in reverse direction, so it should not matter ;-)\n\nThe other cases don't really care. For them, \"show one merge-base\" is\nfine, and they are \"end-point\" operations (like \"diff\") that really\ncannot handle a set of commits anyway.\n\nBut for \"git shortlog\", switching to using the merge base would\nactually start showing commits that shouldn't be shown. It's\nfundamentally a set operator, and does the right thing in the presense\nof multiple merge-bases (which \"diff\" and \"since commit XYZ\" are\nclearly not set operators, although arguably you could try to show all\nmerge bases for the \"since\" case).\n\n Linus\n"}]}