Re: [PATCH v3 0/3] for-each-ref: add :remoteref and :remotename specifiers

[Junio C Hamano <gitster@pobox.com>]

Johannes Schindelin <johannes.schindelin@gmx.de> writes:

> Changes since v2:
>
> - fixed the commit message of 1/3 to no longer talk about :remote.

OK.  It now matches what we have had since October 5th in my tree.

> - used the push atom in 2/3, made the code look more as suggested by Junio.

I am pleasantly surprised (mostly because I didn't realize that the
code has already prepared all the info necessary to do this in the
atom enumeration phase) that this change was quite easy and doably
very cleanly.

> - fixed the oneline of 2/3 to use a verb ("report").
>
> - butchered Junio's proposed documentation update for 2/3 to hopefully make
>   the description of :remotename and :remoteref a lot clearer.

Well I wasn't attempting to propose anything---as I said, I couldn't
concisely phrase what the description in v2 wanted to say in clearer
terms, so I gave a lengthy and fuller description.

It feels a bit out-of-place to see "can be updated" in the
description of a read-only operation for-each-ref, as we see below:

>  -Also respects `:remotename` to state the name of the *remote* instead
>  -of the ref, and `:remoteref` to state the name of the *reference* as
>  -locally known by the remote.
>  +For any remote-tracking branch `%(upstream)`, `%(upstream:remotename)`
>  +and `%(upstream:remoteref)` refer to the name of the remote and the
>  +name of the tracked remote ref, respectively. In other words, the
>  +remote-tracking branch can be updated explicitly and individually by
>  +using the refspec `%(upstream:remoteref):%(upstream)` to fetch from
>  +`%(upstream:remotename)`.

but I think this should do for now.  It certainly is much clearer
than the previous round.

Will queue, and merge to 'next' soonish.

Thanks.