Re: [RFC PATCH] Make 'git request-pull' more strict about matching local/remote branches

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

 



On Wed, Jan 22, 2014 at 2:14 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
>
> I looked at 5150.4 and found that what it attempts to do is halfway
> sensible.

I agree that it is "half-way sensible". The important bit being the HALF part.

The half part is why we have the semantics we have. There's no
question about that.

The problem is, the *other* half is pure and utter crap. The "half-way
sensible" solution then generates pure and utter garbage in the
"totally sensible" case.

And that's why I think it needs to be fixed. Not because the existing
behavior can never make sense in some circumstances, but because the
existing behavior can screw up really really badly in other (arguably
more common, and definitely real) circumstances.

For the kernel, the broken "missing branch name" situation has come up
pretty regularly. This is definitely not a one-time event, it's more
like "almost every merge window somebody gets screwed by this and I
have to guess what the branch name should have been".

I think that we could potentially do a "local:remote" syntax for that
half-way sensible case, so that if you do

   git push .. master:for-linus

then you have to do

   git request-pull .. master:for-linus

to match the fact that you renamed your local branch on the remote.

              Linus
--
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]