# [PATCH v2] for-each-ref: add %(upstream:gone) to mark missing refs 7 messages from 2016-08-22 to 2016-08-26. Participants: Øystein Walle, Jeff King, Karthik Nayak. Thread: https://gitlist.dev/t/43904 ## Øystein Walle, 2016-08-22 17:35 Subject: [PATCH v2] for-each-ref: add %(upstream:gone) to mark missing refs Message-ID: <20160822173528.755-1-oystwa@gmail.com> URL: https://gitlist.dev/e/20160822173528.755-1-oystwa%40gmail.com ``` git branch -vv will show "gone" next to a remote tracking branch if it does not exist. for-each-ref is suitable for parsing but had no way of showing this information. This introduces "%(upstream:gone)" to display "gone" in the formatted output if the ref does not exist or an empty string otherwise, analogous to git branch -vv. Signed-off-by: Øystein Walle --- I took the liberty of sending in a v2 on my own. Removed the last argument to stat_tracking_info() and used test_config instead of test_when_finished. Documentation/git-for-each-ref.txt | 5 +++-- ref-filter.c | 9 ++++++++- t/t6300-for-each-ref.sh | 11 +++++++++++ 3 files changed, 22 insertions(+), 3 deletions(-) diff --git a/Documentation/git-for-each-ref.txt b/Documentation/git-for-each-ref.txt index f57e69b..039a86b 100644 --- a/Documentation/git-for-each-ref.txt +++ b/Documentation/git-for-each-ref.txt @@ -114,8 +114,9 @@ upstream:: `refname` above. Additionally respects `:track` to show "[ahead N, behind M]" and `:trackshort` to show the terse version: ">" (ahead), "<" (behind), "<>" (ahead and behind), - or "=" (in sync). Has no effect if the ref does not have - tracking information associated with it. + or "=" (in sync) and `:gone` to show "gone" if the remote ref + does not exist, or an empty string if it does. Has no effect if + the ref does not have tracking information associated with it. push:: The name of a local ref which represents the `@{push}` location diff --git a/ref-filter.c b/ref-filter.c index bc551a7..757f473 100644 --- a/ref-filter.c +++ b/ref-filter.c @@ -37,7 +37,7 @@ static struct used_atom { union { char color[COLOR_MAXLEN]; struct align align; - enum { RR_NORMAL, RR_SHORTEN, RR_TRACK, RR_TRACKSHORT } + enum { RR_NORMAL, RR_SHORTEN, RR_TRACK, RR_TRACKSHORT, RR_GONE } remote_ref; struct { enum { C_BARE, C_BODY, C_BODY_DEP, C_LINES, C_SIG, C_SUB } option; @@ -67,6 +67,8 @@ static void remote_ref_atom_parser(struct used_atom *atom, const char *arg) atom->u.remote_ref = RR_TRACK; else if (!strcmp(arg, "trackshort")) atom->u.remote_ref = RR_TRACKSHORT; + else if (!strcmp(arg, "gone")) + atom->u.remote_ref = RR_GONE; else die(_("unrecognized format: %%(%s)"), atom->name); } @@ -923,6 +925,11 @@ static void fill_remote_ref_details(struct used_atom *atom, const char *refname, *s = ">"; else *s = "<>"; + } else if (atom->u.remote_ref == RR_GONE) { + if (stat_tracking_info(branch, &num_ours, &num_theirs, NULL) < 0) + *s = "gone"; + else + *s = ""; } else /* RR_NORMAL */ *s = refname; } diff --git a/t/t6300-for-each-ref.sh b/t/t6300-for-each-ref.sh index 19a2823..f99bfd0 100755 --- a/t/t6300-for-each-ref.sh +++ b/t/t6300-for-each-ref.sh @@ -383,6 +383,17 @@ test_expect_success 'Check that :track[short] works when upstream is invalid' ' test_cmp expected actual ' +test_expect_success 'Check that :gone produces expected results' ' + cat >expected <<-\EOF && +gone + EOF + test_config branch.master.merge refs/heads/does-not-exist && + git for-each-ref \ + --format="%(upstream:gone)" \ + refs/heads >actual && + test_cmp expected actual +' + test_expect_success 'Check for invalid refname format' ' test_must_fail git for-each-ref --format="%(refname:INVALID)" ' -- 2.9.2 ``` ## Jeff King, 2016-08-24 18:07 Subject: Re: [PATCH v2] for-each-ref: add %(upstream:gone) to mark missing refs Message-ID: <20160824180730.mqlvhkthg4imd2vy@sigill.intra.peff.net> URL: https://gitlist.dev/e/20160824180730.mqlvhkthg4imd2vy%40sigill.intra.peff.net In-Reply-To: <20160822173528.755-1-oystwa@gmail.com> ``` On Mon, Aug 22, 2016 at 07:35:28PM +0200, Øystein Walle wrote: > git branch -vv will show "gone" next to a remote tracking branch if it > does not exist. for-each-ref is suitable for parsing but had no way of > showing this information. > > This introduces "%(upstream:gone)" to display "gone" in the formatted > output if the ref does not exist or an empty string otherwise, analogous > to git branch -vv. > > Signed-off-by: Øystein Walle > --- > I took the liberty of sending in a v2 on my own. Removed the last argument to > stat_tracking_info() and used test_config instead of test_when_finished. Whoops, your v2 spurred me to review, but I accidentally read and responded to v1. I think test_config may not be the right thing here, though; see my other comments. -Peff ``` ## Øystein Walle, 2016-08-24 18:26 Subject: Re: [PATCH v2] for-each-ref: add %(upstream:gone) to mark missing refs Message-ID: URL: https://gitlist.dev/e/CAFaJEqvm9Xj34t%2BF%3DKMtwRDEYhwHZ7%3DMRwsZ22-Gt_UPd4r72A%40mail.gmail.com In-Reply-To: <20160824180730.mqlvhkthg4imd2vy@sigill.intra.peff.net> ``` Hi, Peff On 24 August 2016 at 20:07, Jeff King wrote > > Whoops, your v2 spurred me to review, but I accidentally read and > responded to v1. > Thanks for the review! I was worried this patch had been buried :-) In the mean time, however, I have discovered that this conflicts with kn/ref-filter-branch-list in pu. In that topic this specific feature is implemented as well. They incorporate it into %(upstream:track) instead of having a separate "sub-atom" (what's the correct nomenclature, by the way?) more in line with with branch -vv and your idea. I recall seeing discussions about this work earlier, but I based my patch on master and forgot to check pu. (It was a spur-of-the-moment thing fueled by a question in #git about how to parse branch -vv to delete all local branch who had their remote counter-parts removed after a fetch --prune.) Unless that topic gets rejected, or is known to not be merged for a _long_ while, my patch doesn't add much value. Regards, Øsse ``` ## Jeff King, 2016-08-24 18:33 Subject: Re: [PATCH v2] for-each-ref: add %(upstream:gone) to mark missing refs Message-ID: <20160824183358.ahxcgcrg7jo2rygp@sigill.intra.peff.net> URL: https://gitlist.dev/e/20160824183358.ahxcgcrg7jo2rygp%40sigill.intra.peff.net In-Reply-To: ``` On Wed, Aug 24, 2016 at 08:26:26PM +0200, Øystein Walle wrote: > In the mean time, however, I have discovered that this conflicts with > kn/ref-filter-branch-list in pu. In that topic this specific feature is > implemented as well. They incorporate it into %(upstream:track) instead > of having a separate "sub-atom" (what's the correct nomenclature, by the > way?) more in line with with branch -vv and your idea. Ah, right. I was feeling like this was all vaguely familiar. I think it would be better to push forward kn/ref-filter-branch-list. According to the last "what's cooking", I think that topic is waiting on more review. If you're willing and able to do so, that would be a big help. Thanks. -Peff ``` ## Karthik Nayak, 2016-08-25 05:56 Subject: Re: [PATCH v2] for-each-ref: add %(upstream:gone) to mark missing refs Message-ID: URL: https://gitlist.dev/e/CAOLa%3DZSVgm_J9n9wBp_cPWF4kWtvq_8DMLWGoYTSVetOpEJnAQ%40mail.gmail.com In-Reply-To: <20160824183358.ahxcgcrg7jo2rygp@sigill.intra.peff.net> ``` On Thu, Aug 25, 2016 at 12:03 AM, Jeff King wrote: > On Wed, Aug 24, 2016 at 08:26:26PM +0200, Øystein Walle wrote: > >> In the mean time, however, I have discovered that this conflicts with >> kn/ref-filter-branch-list in pu. In that topic this specific feature is >> implemented as well. They incorporate it into %(upstream:track) instead >> of having a separate "sub-atom" (what's the correct nomenclature, by the >> way?) more in line with with branch -vv and your idea. > I'm thinking more on the lines of `%(upstream)` being an atom and the `:track` being an option under that atom. I like sub-atom though ;) > Ah, right. I was feeling like this was all vaguely familiar. I think it > would be better to push forward kn/ref-filter-branch-list. According to > the last "what's cooking", I think that topic is waiting on more review. > If you're willing and able to do so, that would be a big help. > It's been waiting for review for a _long_ time now. -- Regards, Karthik Nayak ``` ## Øystein Walle, 2016-08-25 08:45 Subject: Re: [PATCH v2] for-each-ref: add %(upstream:gone) to mark missing refs Message-ID: URL: https://gitlist.dev/e/CAFaJEqs7vE4knXXOdKk%2BPxY2DZs%3D7BHGUJY_0a_aKF1ngnX%2BLg%40mail.gmail.com In-Reply-To: ``` On 25 August 2016 at 07:56, Karthik Nayak wrote: > > I'm thinking more on the lines of `%(upstream)` being an atom and the > `:track` being an option under that atom. I like sub-atom though ;) > On second thought maybe "quark" is better :P > On Thu, Aug 25, 2016 at 12:03 AM, Jeff King wrote: >> >> Ah, right. I was feeling like this was all vaguely familiar. I think >> it would be better to push forward kn/ref-filter-branch-list. >> According to the last "what's cooking", I think that topic is waiting >> on more review. If you're willing and able to do so, that would be a >> big help. >> > > It's been waiting for review for a _long_ time now. > To be perfectly honest my C skills and familiarity with the git source code is not much to speak of. I very much want to take a close look but I cannot promise anything worth your time... But if I do find something I'd like to point out should I just reply directly to the e-mails containing the patches as one usually does even though they're months old at this point? Øsse ``` ## Karthik Nayak, 2016-08-26 06:31 Subject: Re: [PATCH v2] for-each-ref: add %(upstream:gone) to mark missing refs Message-ID: URL: https://gitlist.dev/e/CAOLa%3DZTY0fM_Z_t8nk%2Bje4fao8ydF1dAXmG7RzgmJyoQUj7kSg%40mail.gmail.com In-Reply-To: ``` Hello, >> On Thu, Aug 25, 2016 at 12:03 AM, Jeff King wrote: >>> >>> Ah, right. I was feeling like this was all vaguely familiar. I think >>> it would be better to push forward kn/ref-filter-branch-list. >>> According to the last "what's cooking", I think that topic is waiting >>> on more review. If you're willing and able to do so, that would be a >>> big help. >>> >> >> It's been waiting for review for a _long_ time now. >> > > To be perfectly honest my C skills and familiarity with the git source > code is not much to speak of. I very much want to take a close look but > I cannot promise anything worth your time... > > But if I do find something I'd like to point out should I just reply > directly to the e-mails containing the patches as one usually does even > though they're months old at this point? > Not that your review would be absolute but it definitely would be a start. Replying directly to the patches is the way to go I feel. -- Regards, Karthik Nayak ```