Re: [PATCH v3 7/8] push: add DWYM support for "git push refs/remotes/...:<dst>"

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

 



On Mon, Oct 29 2018, Junio C Hamano wrote:

> Ævar Arnfjörð Bjarmason  <avarab@xxxxxxxxx> writes:
>
>> Add DWYM support for pushing a ref in refs/remotes/* when the <dst>
>
> I think most people call it do-what-*I*-mean, not do-what-you-mean.

FWIW I picked this up from the perl list where both are used depending
on context. I.e. DW[IY]M depending on if the sentence is one where you'd
describe things from a first or second-person perspective "I implemented
this to DWIM, and it'll DWYM if you invoke it as...". Also
"dwimerry"[1].

>> ref is unqualified. Now instead of erroring out we support e.g.:
>>
>>     $ ./git-push avar refs/remotes/origin/master:upstream-master -n
>>     To github.com:avar/git.git
>>      * [new branch]            origin/master -> upstream-master
>>
>> Before this we wouldn't know what do do with
>> refs/remotes/origin/master, now we'll look it up and discover that
>> it's a commit (or tag) and add a refs/{heads,tags}/ prefix to <dst> as
>> appropriate.
>
> I am not sure if this is a good change, as I already hinted earlier.
> If I were doing "git push" to any of my publishing places, I would
> be irritated if "refs/remotes/ko/master:something" created a local
> "something" branch at the desitnation, instead of erroring out.
>
> On the other hand, I do not think I mind all that much if a src that
> is a tag object to automatically go to refs/tags/ (having a tag
> object in refs/remotes/** is rare enough to matter in the first
> place).

Yeah maybe this is going too far. I don't think so, but happy to me
challenged on that point :)

I don't think so because the only reason I've ever needed this is
because I deleted some branch accidentally and am using a push from
"remotes/*" to bring it back. I.e. I'll always want branch-for-branch,
not to push that as a tag.

Of course it isn't actually a "branch", but just a commit object
(depending on the refspec configuration), so we can't quite make that
hard assumption.

But I figured screwing with how refs/remotes/* works by manually adding
new refspecs is such an advanced feature that the people doing it are
probably all here on-list, and would be the sort of users advanced
enough to either know the semantics or try this with -n.

Whereas the vast majority of users won't ever screw with it, and if they
ever push from remotes/* to another remote almost definitely want a new
branch under the new name.

1. https://www.urbandictionary.com/define.php?term=DWYM



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

  Powered by Linux