Re: [PATCH] credential: let empty credential specs reset helper list

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

 



Jeff King <peff@xxxxxxxx> writes:

> I think there is another reason, which is that the interface we expose
> to config callbacks (and via "config --get-all") is to sequentially pass
> in all values. How does that interact with this "reset"? For example,
> what is the output of:
>
>   git config foo.bar one
>   git -c '!foo.bar' config --get-all foo.bar

The callback API needs to be extended to include this "reset" bit,
not just "var" and "value", obviously.  And then of course the users
of the API need to be updated to act on that "reset" thing.

That is what I meant by "multi-value things need custom code".  The
single-valued ones can do "last one wins", and "reset" can be turned
into "the initial state" assignment for the variable; multi-value
cumulative ones already have custom code to accumulate things into
list, and they need to learn to empty the list upon seeing the
"reset" bit.

But that is not as fundamental as "new syntax breaks old clients".
If we want our new code to do useful things, obviously we would need
to work on making it do so ;-)

> I think you could get away without changing the users of the multi-value
> variables, using the "negative" approach I mentioned above. Basically:
> ...
> But like I said, that does feel somewhat half-implemented to me, since
> it treats the command-line specially.

I agree with you that that is a kludge and not the right way
forward.
--
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]