From: Jeff King <peff@peff.net>
To: Paul Tan <pyokagan@gmail.com>
Cc: Git List <git@vger.kernel.org>,
Junio C Hamano <gitster@pobox.com>,
Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>
Subject: Re: [PATCH v3 1/4] git-credential-store: support multiple credential files
Date: Sat, 14 Mar 2015 13:42:04 -0400 [thread overview]
Message-ID: <20150314174204.GA32706@peff.net> (raw)
In-Reply-To: <20150314173328.GA32599@peff.net>
On Sat, Mar 14, 2015 at 01:33:28PM -0400, Jeff King wrote:
> On Sat, Mar 14, 2015 at 04:15:53PM +0800, Paul Tan wrote:
>
> > Even though in this case the store_credential() function is not used
> > anywhere else, from my personal API design experience I think that
> > cementing the rule of "the first file in the list is the default" in
> > the behavior of the function is not a good thing. For example, in the
> > future, we may wish to keep the precedence ordering the same, but if
> > none of the credential files exist, we create the XDG file by default
> > instead. It's a balance of flexibility, but in this case I think
> > putting the default filename in a separate argument is a good thing.
>
> Yeah, I see your line of reasoning. I think this is probably a case of
> YAGNI, but it is really a matter of personal preference. It's not a big
> deal either way.
By the way, I hope this (and the other comment) do not come off as "you
are wrong, but I do not feel like arguing with you". I really do think
these are a matter of taste, and while we often express issues of taste
in reviews, it is ultimately up to the patch submitter (who is, after
all, doing most of the work) to have the final say on minor issues like
this. Sometimes the response to taste issue is "oh, I didn't think to
do that, thanks for the suggestion" and sometimes it is "nah, I like it
better my way". And both are OK.
Of course there are also taste issues where we insist (e.g., consistent
whitespace), but I do not think this is one of them. :)
Maybe that was all obvious, but since you are new to the list, I wanted
to make sure I was clear.
-Peff
next prev parent reply other threads:[~2015-03-14 17:44 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-11 6:49 [PATCH v3 0/4] git-credential-store: XDG user-specific config file support Paul Tan
2015-03-11 6:49 ` [PATCH v3 1/4] git-credential-store: support multiple credential files Paul Tan
2015-03-13 6:15 ` Jeff King
2015-03-14 8:15 ` Paul Tan
2015-03-14 17:33 ` Jeff King
2015-03-14 17:42 ` Jeff King [this message]
2015-03-14 22:14 ` Junio C Hamano
2015-03-15 11:44 ` Matthieu Moy
2015-03-15 20:03 ` Junio C Hamano
2015-03-18 6:39 ` Paul Tan
2015-03-11 6:49 ` [PATCH v3 2/4] git-credential-store: support XDG_CONFIG_HOME Paul Tan
2015-03-11 6:49 ` [PATCH v3 3/4] docs/git-credential-store: document XDG file and precedence Paul Tan
2015-03-11 7:47 ` Eric Sunshine
2015-03-12 9:50 ` Paul Tan
2015-03-11 6:49 ` [PATCH v3 4/4] t0302: test credential-store support for XDG_CONFIG_HOME Paul Tan
2015-03-11 8:40 ` Eric Sunshine
2015-03-12 9:32 ` Paul Tan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150314174204.GA32706@peff.net \
--to=peff@peff.net \
--cc=Matthieu.Moy@grenoble-inp.fr \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=pyokagan@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).