Junio C Hamano wrote:
> Did you mean "I'm still resisting, but after reading [...] I think
> it makes sense"? If so, please discard my question.
Sorry about the lack of clarity. I agreed with most of what you said,
and I outlined how we could possibly turn it into an implementation.
Still haven'
Junio C Hamano writes:
> Ramkumar Ramachandra writes:
>
>> Junio C Hamano wrote:
>>
>>> [...]
>>
>> Okay, so what you're saying makes sense.
>
> That is not a very useful style of quoting; what did you just agree to?
Ahh.
I took your response as "I'm still resisting [to what was quoted
before
Ramkumar Ramachandra writes:
> Junio C Hamano wrote:
>
>> [...]
>
> Okay, so what you're saying makes sense.
That is not a very useful style of quoting; what did you just agree to?
I think we should step back and clarify the "to which repository the
push goes" and "what branch(es) in that chose
Junio C Hamano wrote:
> If you recall the earlier discussion on "@{publish} which is
> different from @{upstream}", one idea to allow mapping on the push
> end was to introduce "push.default = single" that would act as
> "upstream" when in "branch I fetch and integrate with is the same
> branch at
Ramkumar Ramachandra writes:
>> I am not saying that you have to pick one to use for push.default
>> among the remaining ones (i.e. matching, current, what else?). It
>> is very plausible that the triangular workflow wants a different
>> logic to pick what branches are to be updated and how. Pe
Junio C Hamano wrote:
> Only if I want to publish the result of the work forked from your
> "triangle" as my "triangle", but that is not the case. A fork to be
> integrated by other is by definition more specialized than the
> original, and I would publish my "pushbranch" subtopic as such, not
> a
Ramkumar Ramachandra writes:
> Junio C Hamano wrote:
>> The name under which the local branch is published needs a sensible
>> default (when branch.$name.push is not specified), and I agree that
>> you would get the name of the branch my work was forked from if you
>> reuse the "upstream" code.
Junio C Hamano wrote:
> The name under which the local branch is published needs a sensible
> default (when branch.$name.push is not specified), and I agree that
> you would get the name of the branch my work was forked from if you
> reuse the "upstream" code. I am saying that it does not necessar
Ramkumar Ramachandra writes:
> I don't understand why upstream/ simple should _not_ push to a
> different destination from the one being merged from. I'll repeat:
> push source/ destination is orthogonal to push refspec, and
> push.default modes dictate the refspec.
That is where we differ. Yo
Junio C Hamano wrote:
> I am not sure what you mean by artificial.
By artificial, I mean that the precondition is absolutely unnecessary
for the code following it to work. The precondition was introduced in
a separate commit, specifically denying one usecase because the author
(you) thought that
Ramkumar Ramachandra writes:
> rr/triangle (4d35924, 2013-04-07) introduced support for triangular
> workflows, but did not think through the effect of the new configuration
> variables in the upstream and simple modes. When remote.pushdefault or
> branch..pushremote is set, and push.default is
rr/triangle (4d35924, 2013-04-07) introduced support for triangular
workflows, but did not think through the effect of the new configuration
variables in the upstream and simple modes. When remote.pushdefault or
branch..pushremote is set, and push.default is set to upstream or
simple, this happens
12 matches
Mail list logo
