{"thread":{"id":"32680","subject":"Re: [PULL] Module fixes, and a virtio block fix.","startedAt":"2013-01-21T01:45:33Z","lastAt":"2013-01-21T03:15:54Z","messageCount":5,"participants":["Linus Torvalds","Junio C Hamano","Rusty Russell"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"207354","messageId":"CA+55aFy1nW859yaGP17epRX8A+TaJ8APvb0-Ww1zw91dCAOhoQ@mail.gmail.com","threadId":"32680","inReplyTo":"87fw1vwcao.fsf@rustcorp.com.au","subject":"Re: [PULL] Module fixes, and a virtio block fix.","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2013-01-21T01:45:33Z","receivedAt":"2013-01-21T01:45:33Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"On Sun, Jan 20, 2013 at 5:32 PM, Rusty Russell <rusty@rustcorp.com.au> wrote:\n>\n> Due to the delay on git.kernel.org, git request-pull fails.  It *looks*\n> like it succeeds, except the warning, but (as we learned last time I\n> screwed up), it doesn't put the branchname because it can't know.\n\nI think this should be fixed in modern git versions.\n\nAnd it sure as hell knows the proper tag name, since you *gave* it the\nname and it used it for generating the actual contents. The fact that\nsome versions then screw that up and re-write the tag-name to\nsomething randomly matching that isn't a tag was just a bug.\n\n> For want of a better solution, I'll now resort to sending pull requests\n> with the anti-social gitolite URL in it, like so:\n\nThat's even worse, fwiw. It means that the pull request address makes\nno sense to anybody who doesn't have a kernel.org address, and then\nI'm forced to just edit things by hand instead to not pollute the\nkernel changelog history with crap.\n\nJunio, didn't \"git request-pull\" get fixed so that it *warns* about\nmissing tagnames/branches, but never actually corrupts the pull\nrequest? Or did it just get \"fixed\" to be a hard error instead of\ncorrupting things? Because this is annoying.\n\n                Linus\n"},{"id":"207358","messageId":"7vpq0zi9c7.fsf@alter.siamese.dyndns.org","threadId":"32680","inReplyTo":"CA+55aFy1nW859yaGP17epRX8A+TaJ8APvb0-Ww1zw91dCAOhoQ@mail.gmail.com","subject":"Re: [PULL] Module fixes, and a virtio block fix.","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-01-21T02:00:24Z","receivedAt":"2013-01-21T02:00:24Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds <torvalds@linux-foundation.org> writes:\n\n> On Sun, Jan 20, 2013 at 5:32 PM, Rusty Russell <rusty@rustcorp.com.au> wrote:\n>>\n>> Due to the delay on git.kernel.org, git request-pull fails.  It *looks*\n>> like it succeeds, except the warning, but (as we learned last time I\n>> screwed up), it doesn't put the branchname because it can't know.\n>\n> I think this should be fixed in modern git versions.\n> ...\n> Junio, didn't \"git request-pull\" get fixed so that it *warns* about\n> missing tagnames/branches, but never actually corrupts the pull\n> request? Or did it just get \"fixed\" to be a hard error instead of\n> corrupting things? Because this is annoying.\n\nWhat you mean by \"corrupt\" is not clear to me, but the last change\nto the script is from 6 months ago to solve a related (perhaps the\nsame?) problem, which should be in v1.7.11.2 and later:\n\n    request-pull: really favor a matching tag\n\n    After tagging the tip of \"dev\" branch with a \"for-linus\" tag and\n    pushing both out, running\n\n        $ git request-pull $url $last_release dev\n\n    would produce an output asking the 'dev' branch of $url to be\n    pulled, because that is what the user asked the message to say.\n\n    We already detect this situation locally and include the\n    contents of the tag in the output; if the $url has that tag,\n    favor that tag (i.e. \"for-linus\") in the generated message over\n    the branch name the user gave us (i.e. \"dev\") from the command\n    line, to make the output look more consistent.\n"},{"id":"207359","messageId":"CA+55aFw=8w8Eao3iA5F5-jFaO0MtcH+jivTD8SkDtMfrhQgWHg@mail.gmail.com","threadId":"32680","inReplyTo":"7vpq0zi9c7.fsf@alter.siamese.dyndns.org","subject":"Re: [PULL] Module fixes, and a virtio block fix.","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2013-01-21T02:14:06Z","receivedAt":"2013-01-21T02:14:06Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"On Sun, Jan 20, 2013 at 6:00 PM, Junio C Hamano <gitster@pobox.com> wrote:\n>\n> What you mean by \"corrupt\" is not clear to me\n\nSome versions would just silently change the actual name you were using.\n\nSo if you said \"for-linus\", it might change it to \"linus\", just\nbecause that branch happened to have the same SHA1 commit ID.\n\nThat's not right.\n\nOther versions would replace the \"for-linus\" with \"**missing-branch**\"\nbecause \"for-linus\" hadn't mirrored out yet.\n\nThat's not right either.\n\nBasically, if \"git request-pull\" is given a branch/tag name, that is\nthe only valid output (although going from branch->tag *might* be\nacceptable). The whole \"verify that it actually exists on the remote\nside\" must never *ever* actually change the message itself, it should\njust cause a warning outside of the message.\n\nI can't say from the commit message whether that's the thing that\nfixed it or not, but at least some people stopped sending me broken\npull requests after updating to git. I'm just not sure which of the\ntwo different failure cases they happened to have (Rusty seems to have\nhit both)\n\n            Linus\n"},{"id":"207361","messageId":"871udfw8e0.fsf@rustcorp.com.au","threadId":"32680","inReplyTo":"CA+55aFy1nW859yaGP17epRX8A+TaJ8APvb0-Ww1zw91dCAOhoQ@mail.gmail.com","subject":"Re: [PULL] Module fixes, and a virtio block fix.","fromName":"Rusty Russell","fromEmail":"rusty@rustcorp.com.au","sentAt":"2013-01-21T02:57:11Z","receivedAt":"2013-01-21T02:57:11Z","isPatch":false,"sender":{"key":"rusty@rustcorp.com.au","avatar":"https://gravatar.com/avatar/6b532b78e53abc4701523f6225607caa34fc0b5264600ce23bb5e3f537209fc6?d=mp&s=160"},"body":"Linus Torvalds <torvalds@linux-foundation.org> writes:\n\n> On Sun, Jan 20, 2013 at 5:32 PM, Rusty Russell <rusty@rustcorp.com.au> wrote:\n>>\n>> Due to the delay on git.kernel.org, git request-pull fails.  It *looks*\n>> like it succeeds, except the warning, but (as we learned last time I\n>> screwed up), it doesn't put the branchname because it can't know.\n>\n> I think this should be fixed in modern git versions.\n>\n> And it sure as hell knows the proper tag name, since you *gave* it the\n> name and it used it for generating the actual contents. The fact that\n> some versions then screw that up and re-write the tag-name to\n> something randomly matching that isn't a tag was just a bug.\n\nI'm confused.  The default argument is HEAD: what does it know about tag\nnames?\n\n        git request-pull master korg\n\nThe bug is that if it can't find that commit at the remote end, it\nstill generates a valid-looking request (with a warning at the end),\nwhere it guesses you're talking about the master branch.\n\n>> For want of a better solution, I'll now resort to sending pull requests\n>> with the anti-social gitolite URL in it, like so:\n>\n> That's even worse, fwiw. It means that the pull request address makes\n> no sense to anybody who doesn't have a kernel.org address, and then\n> I'm forced to just edit things by hand instead to not pollute the\n> kernel changelog history with crap.\n\nSince I use a wrapper script now for your pull requests I can use sed to\nunscrew it:\n\n[alias]\n\tfor-linus = !check-commits && TAGNAME=`git symbolic-ref HEAD | cut -d/ -f3`-for-linus && git tag -f -u D1ADB8F1 $TAGNAME HEAD && git push korg tag $TAGNAME && git request-pull master korg | sed s,gitolite@ra.kernel.org:/pub,git://git.kernel.org/pub, && git log --stat --reverse master..$TAGNAME | emails-from-log | grep -v 'rusty@rustcorp' | grep -v 'stable@kernel.org' | sed 's/^/Cc: /'\n\n> Junio, didn't \"git request-pull\" get fixed so that it *warns* about\n> missing tagnames/branches, but never actually corrupts the pull\n> request? Or did it just get \"fixed\" to be a hard error instead of\n> corrupting things? Because this is annoying.\n\nHere: git version 1.7.10.4\n\nCheers,\nRusty.\n"},{"id":"207362","messageId":"CA+55aFwNiKaWPTWuxvyud2jkpZgO8z0DGaof7icBDM1ycAFb_A@mail.gmail.com","threadId":"32680","inReplyTo":"871udfw8e0.fsf@rustcorp.com.au","subject":"Re: [PULL] Module fixes, and a virtio block fix.","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2013-01-21T03:15:54Z","receivedAt":"2013-01-21T03:15:54Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"On Sun, Jan 20, 2013 at 6:57 PM, Rusty Russell <rusty@rustcorp.com.au> wrote:\n>\n> I'm confused.  The default argument is HEAD: what does it know about tag\n> names?\n\nUgh. I actually thought that if you give it the tag name directly (as\nthe \"end\") it will use that.\n\nBut no. It figures it out with \"git describe --exact\" internally.\nRegardless, if your HEAD is actually tagged, it *will* have the\ntag-name in git-request-pull.\n\nAnd it will have it based on your *local* repo, so the fact that it\nhasn't been mirrored out yet doesn't really matter. git request-pull\nknows that tag name regardless of mirroring issues.\n\n> The bug is that if it can't find that commit at the remote end, it\n> still generates a valid-looking request (with a warning at the end),\n> where it guesses you're talking about the master branch.\n\nIt really shouldn't do that any more, but you seem to have the older\nversion with the bug.\n\nAt  least one of the annoying problems was fixed in the 1.7.11 series,\nyou have 1.7.10.\n\nThe nice thing about git is that it is *really* easy to upgrade. Just\nfetch the sources, do \"make; make install\" all as a normal user, and\nyou do not need to worry about package management or distro issues or\nany crap like that. It installs into your $(HOME)/bin, and as long as\nyour PATH has that first, you'll get it. I've long suggested that as\nthe workaround for distros having old versions (some more so than\nothers).\n\n> Since I use a wrapper script now for your pull requests I can use sed to\n> unscrew it:\n>\n> [alias]\n>         for-linus = !check-commits && TAGNAME=`git symbolic-ref HEAD | cut -d/ -f3`-for-linus && git tag -f -u D1ADB8F1 $TAGNAME HEAD && git push korg tag $TAGNAME && git request-pull master korg | sed s,gitolite@ra.kernel.org:/pub,git://git.kernel.org/pub, && git log --stat --reverse master..$TAGNAME | emails-from-log | grep -v 'rusty@rustcorp' | grep -v 'stable@kernel.org' | sed 's/^/Cc: /'\n\nHeh. Ok. That will at least hide the breakage. But I suspect you could\nfix it by just updating git.\n\n             Linus\n"}]}