From: Junio C Hamano <email@example.com> To: Johannes Schindelin <firstname.lastname@example.org> Cc: email@example.com, J Wyman <firstname.lastname@example.org> Subject: Re: [PATCH 2/3] for-each-ref: let upstream/push optionally report merge name. Date: Wed, 04 Oct 2017 20:41:55 +0900 Message-ID: <email@example.com> (raw) In-Reply-To: <firstname.lastname@example.org> Junio C Hamano <email@example.com> writes: >> + if (explicit) >> + *s = xstrdup(merge); >> + else >> + *s = ""; > > Here is the same "who are we trying to help---users who want to know > where their push goes, or users who are debugging where the push > destination is defined?" question. I do not have a strong opinion > either way, but I think giving the end result with fallback (i.e. > not nullifying when the result is not explicit) may be easier to use > by "push" users. Now after thinking about it a bit more, I actually have a moderate preference to doing it the way your patches do. With programatic %(if)%(else)%(end) support we acquired recently, the fallback can be coded in the --format=... language if the user wanted to using the "internal fallbacks, explicit==0, are ignored" behaviour that are implemented by these two patches. The reverse is not true. I think the remaining points from my reviews are: - It would be better to compute precomputable stuff when used atoms are parsed, instead of running starts_with() in these functions; - We want to make sure there is no existing multi-word modifiers (in which case we can safely declare "multi-word" is the way we spell them from now on). Or if there are existing ones, they already spell themselves as "multi-word". I have nothing against "remote-name"; I just want to make sure we are not making things inconsistent. If there are only few (but non zero number of) multi-word modifiers that are not spelled "multi-word", as long as they are only few and their spelling are inferiour (e.g. concatenatedwords is much worse than concatenated-words), we could still declare "multi-word" is the right way to spell them going forward, declare that we will give them synonyms and deprecate the bad spelling out over time, and leave that plan as #leftover bits thing (i.e. not doing the deprecation of these other modifiers as part of this series. The only thing I want to happen in the scope of _this_ series, as due diligence, is to make sure we are happy with "multi-word", and also to know if we need a follow-up work (just yes/no, possibly with plans, but no actual work yet). Thanks.
next prev parent reply index Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-10-02 13:56 [PATCH 0/3] for-each-ref: add :remote-ref and :remote-name specifiers Johannes Schindelin 2017-10-02 13:56 ` [PATCH 1/3] for-each-ref: let upstream/push optionally report the remote name Johannes Schindelin 2017-10-04 7:14 ` Junio C Hamano 2017-10-04 9:08 ` Junio C Hamano 2017-10-05 12:20 ` Johannes Schindelin 2017-10-02 13:57 ` [PATCH 2/3] for-each-ref: let upstream/push optionally report merge name Johannes Schindelin 2017-10-04 9:12 ` Junio C Hamano 2017-10-04 11:41 ` Junio C Hamano [this message] 2017-10-05 9:14 ` Junio C Hamano 2017-10-02 13:57 ` [PATCH 3/3] for-each-ref: test :remote-name and :remote-ref Johannes Schindelin 2017-10-05 1:54 ` [PATCH 0/3] for-each-ref: add :remote-ref and :remote-name specifiers Junio C Hamano 2017-10-05 12:19 ` [PATCH v2 0/3] for-each-ref: add :remoteref and :remotename specifiers Johannes Schindelin 2017-10-05 12:19 ` [PATCH v2 1/3] for-each-ref: let upstream/push optionally report the remote name Johannes Schindelin 2017-10-10 9:35 ` Junio C Hamano 2017-10-11 2:07 ` Junio C Hamano 2017-10-05 12:19 ` [PATCH v2 2/3] for-each-ref: let upstream/push optionally remote ref name Johannes Schindelin 2017-10-06 5:10 ` Junio C Hamano 2017-10-11 5:58 ` Junio C Hamano 2017-10-12 19:13 ` Johannes Schindelin 2017-10-13 0:30 ` Junio C Hamano 2017-10-15 16:02 ` Johannes Schindelin 2017-10-13 16:39 ` Kevin Daudt 2017-10-14 2:08 ` Junio C Hamano 2017-10-15 16:05 ` Johannes Schindelin 2017-10-16 1:50 ` Junio C Hamano 2017-10-16 11:39 ` Johannes Schindelin 2017-10-05 12:19 ` [PATCH v2 3/3] for-each-ref: test :remotename and :remoteref Johannes Schindelin 2017-11-07 16:30 ` [PATCH v3 0/3] for-each-ref: add :remoteref and :remotename specifiers Johannes Schindelin 2017-11-07 16:30 ` [PATCH v3 1/3] for-each-ref: let upstream/push optionally report the remote name Johannes Schindelin 2017-11-07 16:31 ` [PATCH v3 2/3] for-each-ref: let upstream/push report the remote ref name Johannes Schindelin 2017-11-07 16:31 ` [PATCH v3 3/3] for-each-ref: test :remotename and :remoteref Johannes Schindelin 2017-11-08 1:36 ` [PATCH v3 0/3] for-each-ref: add :remoteref and :remotename specifiers Junio C Hamano
Reply instructions: You may reply publically 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 List information: http://vger.kernel.org/majordomo-info.html * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ /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
email@example.com mailing list mirror (one of many) Archives are clonable: git clone --mirror https://public-inbox.org/git git clone --mirror http://ou63pmih66umazou.onion/git git clone --mirror http://czquwvybam4bgbro.onion/git git clone --mirror http://hjrcffqmbrq6wope.onion/git Newsgroups are available over NNTP: nntp://news.public-inbox.org/inbox.comp.version-control.git nntp://ou63pmih66umazou.onion/inbox.comp.version-control.git nntp://czquwvybam4bgbro.onion/inbox.comp.version-control.git nntp://hjrcffqmbrq6wope.onion/inbox.comp.version-control.git nntp://news.gmane.org/gmane.comp.version-control.git note: .onion URLs require Tor: https://www.torproject.org/ or Tor2web: https://www.tor2web.org/ AGPL code for this site: git clone https://public-inbox.org/ public-inbox