On Wed, Feb 18, 2015 at 11:50:20AM -0800, Junio C Hamano wrote:
> Jeff King writes:
>
> > On Wed, Feb 18, 2015 at 11:08:34AM -0800, Junio C Hamano wrote:
> > ...
> >> Not very strongly either way. Seeing the above does not bother me
> >> too much, but I do not know how I would feel when I start
Jeff King writes:
> On Wed, Feb 18, 2015 at 11:08:34AM -0800, Junio C Hamano wrote:
> ...
>> Not very strongly either way. Seeing the above does not bother me
>> too much, but I do not know how I would feel when I start seeing
>>
>> val = git_config_book(k, v);
>> flip_bool(val, &flag
On Wed, Feb 18, 2015 at 11:08:34AM -0800, Junio C Hamano wrote:
> Jeff King writes:
>
> >> + if (!strcmp(k, "push.followtags")) {
> >> + if (git_config_bool(k, v))
> >> + *flags |= TRANSPORT_PUSH_FOLLOW_TAGS;
> >> + else
> >> + *flags &= ~TRAN
Jeff King writes:
>> +if (!strcmp(k, "push.followtags")) {
>> +if (git_config_bool(k, v))
>> +*flags |= TRANSPORT_PUSH_FOLLOW_TAGS;
>> +else
>> +*flags &= ~TRANSPORT_PUSH_FOLLOW_TAGS;
>> +return 0;
>> +}
>
> Did y
On Tue, Feb 17, 2015 at 02:16:30PM -0800, Junio C Hamano wrote:
> Do you want to resurrect that @{publish} stuff? I think it had
> sensible semantics, and I do not think we mind keeping the
> push_default configuration to be read from the default_config
> codepath.
I'll take a look at it and see
Jeff King writes:
>> So we probably would do something similar to @{push} side, which
>> would mean that push_default variable and the logic needs to be
>> visible to remote.c if we want to have the helper that is similar to
>> set_merge() that is used from branch_get() to support @{upstream}.
>
On Tue, Feb 17, 2015 at 09:45:07AM -0800, Junio C Hamano wrote:
> Jeff King writes:
>
> > If we wanted to implement "@{push}" (or "@{publish}") to mean "the
> > tracking ref of the remote ref you would push to if you ran git-push",
> > then this is a step in the wrong direction.
>
> Is that bec
Jeff King writes:
> If we wanted to implement "@{push}" (or "@{publish}") to mean "the
> tracking ref of the remote ref you would push to if you ran git-push",
> then this is a step in the wrong direction.
Is that because push_default variable needs to be looked at from
sha1_name.c when resolvin
On Mon, Feb 16, 2015 at 12:47:54AM -0500, Jeff King wrote:
> When the "push_default" flag was originally added, it was
> made globally visible to all code. This might have been
> useful if other commands or library calls ended up depending
> on it, but as it turns out, only builtin/push.c cares.
>
On Sun, Feb 15, 2015 at 9:47 PM, Jeff King wrote:
> When the "push_default" flag was originally added, it was
> made globally visible to all code. This might have been
> useful if other commands or library calls ended up depending
> on it, but as it turns out, only builtin/push.c cares.
> ...
> Si
When the "push_default" flag was originally added, it was
made globally visible to all code. This might have been
useful if other commands or library calls ended up depending
on it, but as it turns out, only builtin/push.c cares.
Let's make it a static variable in builtin/push.c. Since it
is no lo
11 matches
Mail list logo
