Re: [RFC PATCH] push: start warning upcoming default change for push.default

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

 



Junio C Hamano <gitster@xxxxxxxxx> writes:

> Jeff King <peff@xxxxxxxx> writes:
>
>> ... This is not a push.default issue,
>> but I think it is somewhat related, and maybe worth discussing along
>> with the topic of asymmetry. ...
>> I've mostly trained my fingers to type "git push
>> <my-publish-repo>", but I do occasionally forget.
>
> In an assymmetric set-up, you would typically push into one place
> but update from one or more places, so it might make sense to make
> it easier to say "git push" and "git pull $there".  But that does
> not solve the fundamental issue, I would think.
>
>> Do other people with
>> asymmetric workflows find this annoying? Do they not care? Or are many
>> fewer people doing asymmetric things than I think?
>
> I think it is not "they do not care", but "they do not have a good
> solution".  I do not think of anything offhand, either.

Actually, we could introduce branch.$name.pushRemote that overrides
branch.$name.remote only for pushes.

Before anybody makes an ill-conceived comment, remote.$name.pushURL
is not to be used for this purpose.  It is only about how to get to
the named remote repository, and git still considers remote.$name to
be logically the same remote. "git push" into the named remote will
still update the remote tracking branch that we would update if we
were to immediately turn around and run "git fetch" from that same
remote, and abusing remote.$name.pushURL for triangular setup will
not give us a correct behaviour.
--
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]