Re: [PULL] Module fixes, and a virtio block fix.
On Sun, Jan 20, 2013 at 5:32 PM, Rusty Russell ru...@rustcorp.com.au wrote: Due to the delay on git.kernel.org, git request-pull fails. It *looks* like it succeeds, except the warning, but (as we learned last time I screwed up), it doesn't put the branchname because it can't know. I think this should be fixed in modern git versions. And it sure as hell knows the proper tag name, since you *gave* it the name and it used it for generating the actual contents. The fact that some versions then screw that up and re-write the tag-name to something randomly matching that isn't a tag was just a bug. For want of a better solution, I'll now resort to sending pull requests with the anti-social gitolite URL in it, like so: That's even worse, fwiw. It means that the pull request address makes no sense to anybody who doesn't have a kernel.org address, and then I'm forced to just edit things by hand instead to not pollute the kernel changelog history with crap. Junio, didn't git request-pull get fixed so that it *warns* about missing tagnames/branches, but never actually corrupts the pull request? Or did it just get fixed to be a hard error instead of corrupting things? Because this is annoying. Linus -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] Module fixes, and a virtio block fix.
Linus Torvalds torva...@linux-foundation.org writes: On Sun, Jan 20, 2013 at 5:32 PM, Rusty Russell ru...@rustcorp.com.au wrote: Due to the delay on git.kernel.org, git request-pull fails. It *looks* like it succeeds, except the warning, but (as we learned last time I screwed up), it doesn't put the branchname because it can't know. I think this should be fixed in modern git versions. ... Junio, didn't git request-pull get fixed so that it *warns* about missing tagnames/branches, but never actually corrupts the pull request? Or did it just get fixed to be a hard error instead of corrupting things? Because this is annoying. What you mean by corrupt is not clear to me, but the last change to the script is from 6 months ago to solve a related (perhaps the same?) problem, which should be in v1.7.11.2 and later: request-pull: really favor a matching tag After tagging the tip of dev branch with a for-linus tag and pushing both out, running $ git request-pull $url $last_release dev would produce an output asking the 'dev' branch of $url to be pulled, because that is what the user asked the message to say. We already detect this situation locally and include the contents of the tag in the output; if the $url has that tag, favor that tag (i.e. for-linus) in the generated message over the branch name the user gave us (i.e. dev) from the command line, to make the output look more consistent. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] Module fixes, and a virtio block fix.
On Sun, Jan 20, 2013 at 6:00 PM, Junio C Hamano gits...@pobox.com wrote: What you mean by corrupt is not clear to me Some versions would just silently change the actual name you were using. So if you said for-linus, it might change it to linus, just because that branch happened to have the same SHA1 commit ID. That's not right. Other versions would replace the for-linus with **missing-branch** because for-linus hadn't mirrored out yet. That's not right either. Basically, if git request-pull is given a branch/tag name, that is the only valid output (although going from branch-tag *might* be acceptable). The whole verify that it actually exists on the remote side must never *ever* actually change the message itself, it should just cause a warning outside of the message. I can't say from the commit message whether that's the thing that fixed it or not, but at least some people stopped sending me broken pull requests after updating to git. I'm just not sure which of the two different failure cases they happened to have (Rusty seems to have hit both) Linus -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] Module fixes, and a virtio block fix.
Linus Torvalds torva...@linux-foundation.org writes: On Sun, Jan 20, 2013 at 5:32 PM, Rusty Russell ru...@rustcorp.com.au wrote: Due to the delay on git.kernel.org, git request-pull fails. It *looks* like it succeeds, except the warning, but (as we learned last time I screwed up), it doesn't put the branchname because it can't know. I think this should be fixed in modern git versions. And it sure as hell knows the proper tag name, since you *gave* it the name and it used it for generating the actual contents. The fact that some versions then screw that up and re-write the tag-name to something randomly matching that isn't a tag was just a bug. I'm confused. The default argument is HEAD: what does it know about tag names? git request-pull master korg The bug is that if it can't find that commit at the remote end, it still generates a valid-looking request (with a warning at the end), where it guesses you're talking about the master branch. For want of a better solution, I'll now resort to sending pull requests with the anti-social gitolite URL in it, like so: That's even worse, fwiw. It means that the pull request address makes no sense to anybody who doesn't have a kernel.org address, and then I'm forced to just edit things by hand instead to not pollute the kernel changelog history with crap. Since I use a wrapper script now for your pull requests I can use sed to unscrew it: [alias] 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,gitol...@ra.kernel.org:/pub,git://git.kernel.org/pub, git log --stat --reverse master..$TAGNAME | emails-from-log | grep -v 'rusty@rustcorp' | grep -v 'sta...@kernel.org' | sed 's/^/Cc: /' Junio, didn't git request-pull get fixed so that it *warns* about missing tagnames/branches, but never actually corrupts the pull request? Or did it just get fixed to be a hard error instead of corrupting things? Because this is annoying. Here: git version 1.7.10.4 Cheers, Rusty. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] Module fixes, and a virtio block fix.
On Sun, Jan 20, 2013 at 6:57 PM, Rusty Russell ru...@rustcorp.com.au wrote: I'm confused. The default argument is HEAD: what does it know about tag names? Ugh. I actually thought that if you give it the tag name directly (as the end) it will use that. But no. It figures it out with git describe --exact internally. Regardless, if your HEAD is actually tagged, it *will* have the tag-name in git-request-pull. And it will have it based on your *local* repo, so the fact that it hasn't been mirrored out yet doesn't really matter. git request-pull knows that tag name regardless of mirroring issues. The bug is that if it can't find that commit at the remote end, it still generates a valid-looking request (with a warning at the end), where it guesses you're talking about the master branch. It really shouldn't do that any more, but you seem to have the older version with the bug. At least one of the annoying problems was fixed in the 1.7.11 series, you have 1.7.10. The nice thing about git is that it is *really* easy to upgrade. Just fetch the sources, do make; make install all as a normal user, and you do not need to worry about package management or distro issues or any crap like that. It installs into your $(HOME)/bin, and as long as your PATH has that first, you'll get it. I've long suggested that as the workaround for distros having old versions (some more so than others). Since I use a wrapper script now for your pull requests I can use sed to unscrew it: [alias] 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,gitol...@ra.kernel.org:/pub,git://git.kernel.org/pub, git log --stat --reverse master..$TAGNAME | emails-from-log | grep -v 'rusty@rustcorp' | grep -v 'sta...@kernel.org' | sed 's/^/Cc: /' Heh. Ok. That will at least hide the breakage. But I suspect you could fix it by just updating git. Linus -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
