Re: [PULL] Module fixes, and a virtio block fix.

On Sun, Jan 20, 2013 at 5:32 PM, Rusty Russell <rusty@rustcorp.com.au> wrote:

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.

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

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

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.

On Sun, Jan 20, 2013 at 6:00 PM, Junio C Hamano <gitster@pobox.com> wrote:

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

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

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.

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,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: /'

Here: git version 1.7.10.4

Cheers, Rusty.

On Sun, Jan 20, 2013 at 6:57 PM, Rusty Russell <rusty@rustcorp.com.au> wrote:

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.

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).

Heh. Ok. That will at least hide the breakage. But I suspect you could fix it by just updating git.

             Linus