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

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

[Linus Torvalds]

On Sun, Jan 20, 2013 at 5:32 PM, Rusty Russell <rusty@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

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

[Junio C Hamano]

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

> On Sun, Jan 20, 2013 at 5:32 PM, Rusty Russell <rusty@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.

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

[Linus Torvalds]

On Sun, Jan 20, 2013 at 6:00 PM, Junio C Hamano <gitster@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

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

[Rusty Russell]

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

> On Sun, Jan 20, 2013 at 5:32 PM, Rusty Russell <rusty@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,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: /'

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

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

[Linus Torvalds]

On Sun, Jan 20, 2013 at 6:57 PM, Rusty Russell <rusty@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,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: /'

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

             Linus