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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> writes:

> On Sun, Jan 20, 2013 at 5:32 PM, Rusty Russell <rusty@xxxxxxxxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]