On Mon, Jan 13, 2014 at 12:15:08PM -0800, Junio C Hamano wrote:
> Jeff King writes:
>
> > It does not matter for actually pushing, because to do a non-default
> > push, you must always specify a remote. But "@{publish}" will ask the
> > question "even if I am on 'side' now, what would happen if
Jeff King writes:
> It does not matter for actually pushing, because to do a non-default
> push, you must always specify a remote. But "@{publish}" will ask the
> question "even if I am on 'side' now, what would happen if I were to
> default-push on 'master'?".
In a similar wording to yours, it
On Mon, Jan 13, 2014 at 04:52:52PM +0530, Ramkumar Ramachandra wrote:
> Not sure I understand what the problem is. Let's say we have two
> branches: "master", and "side" with remote.pushdefault = ram,
> branch.*.remote = origin, and branch.side.pushremote = peff. Now, when
> I query master's pushr
Jeff King wrote:
> 2. If the current branch has a branch.*.pushremote set, but we want to
> know where a _different_ branch would be pushed, we have no way to
> access remote.pushdefault (it gets overwritten in the hunk above).
>
> @{upstream} does not have this problem, because it
On Sun, Jan 12, 2014 at 10:41:06PM +0530, Ramkumar Ramachandra wrote:
> When a caller uses branch_get() to retrieve a "struct branch", they get
> the per-branch remote name and a pointer to the remote struct. However,
> they have no way of knowing about the per-branch pushremote from this
> interf
When a caller uses branch_get() to retrieve a "struct branch", they get
the per-branch remote name and a pointer to the remote struct. However,
they have no way of knowing about the per-branch pushremote from this
interface. So, let's expose that information via fields similar to
"remote" and "remo
6 matches
Mail list logo
