[GSoC] Improvements to ref-filter #684

harry-hov · 2020-07-26T20:55:47Z

This is the first patch series that introduces some improvements and features to file ref-filter.{c,h}. These changes are useful to ref-filter, but in near future also will allow us to use ref-filter's logic in pretty.c

I plan to add more to format-support.{c,h} in the upcoming patch series. That will lead to more improved and feature-rich ref-filter.c

harry-hov · 2020-07-27T18:02:10Z

/preview

gitgitgadget · 2020-07-27T18:03:10Z

Preview email sent as [email protected]

harry-hov · 2020-07-27T20:42:21Z

/submit

gitgitgadget · 2020-07-27T20:43:23Z

Submitted as [email protected]

gitgitgadget · 2020-07-27T22:54:20Z

ref-filter.c

@@ -102,6 +102,10 @@ static struct ref_to_worktree_map {
 	struct worktree **worktrees;


On the Git mailing list, Junio C Hamano wrote (reply to this):

"Hariom Verma via GitGitGadget" <[email protected]> writes: > From: Hariom Verma <[email protected]> > > Currently, ref-filter only supports printing email with arrow brackets. This is the first time I heard the term "arrow bracket". Aren't they more commonly called angle brackets? > Let's add support for two more email options. > - trim : print email without arrow brackets. Why would this be useful? > - localpart : prints the part before the @ sign Meaning I'd get "<gitster" for me? Building small pieces of new feature in each patch is good, and adding tests to each step is also good. Why not do the same for docs? > +static struct email_option{ Missing SP. > + enum { EO_INVALID, EO_RAW, EO_TRIM, EO_LOCALPART } option; > +} email_option; > + > @@ -1040,10 +1044,26 @@ static const char *copy_email(const char *buf) > const char *eoemail; > if (!email) > return xstrdup(""); > - eoemail = strchr(email, '>'); The original code prepares to see NULL from this strchr(); that is why it checks eoemail for NULL and returns an empty string---the data is broken (i.e. not an address in angle brackets), which this code cannot do anything about---in the later part of the code. > + switch (email_option.option) { > + case EO_RAW: > + eoemail = strchr(email, '>') + 1; And this breaks the carefully laid out error handling by the original code. Adding 1 to NULL is quite undefined. > + break; > + case EO_TRIM: > + email++; > + eoemail = strchr(email, '>'); > + break; > + case EO_LOCALPART: > + email++; > + eoemail = strchr(email, '@'); The undocumented design here is that you want to return "hariom" for "<[email protected]>", i.e. out of the "trimmed" e-mail, the part before the at-sign is returned. If the data were "<hariom>", you'd still want to return "hariom" no? But because you do not check for NULL, you end up returning an empty string. I think you want to cut at the first '@' or '>', whichever comes first. > + break; > + case EO_INVALID: > + default: Invalid and unhandled ones are silently ignored and not treated as an error? I would have thought that at least the "default" one would be a BUG(), as you covered all the possible values for the enum with case arms. I wouldn't be surprised if seeing EO_INVALID is also a BUG(), i.e. the control flow that led to the caller to call this function with EO_INVALID in email_option.option is likely to be broken. It's not like you return "" to protect yourself when fed a bad data from objects---a bad value in .option can only come here if the parser you wrote for "--format=<string>" produced a wrong result. > + return xstrdup(""); > + } > + > if (!eoemail) > return xstrdup(""); > - return xmemdupz(email, eoemail + 1 - email); > + return xmemdupz(email, eoemail - email); > } > > static char *copy_subject(const char *buf, unsigned long len) > @@ -1113,7 +1133,7 @@ static void grab_person(const char *who, struct atom_value *val, int deref, void > continue; > if (name[wholen] != 0 && > strcmp(name + wholen, "name") && > - strcmp(name + wholen, "email") && > + !starts_with(name + wholen, "email") && > !starts_with(name + wholen, "date")) > continue; > if (!wholine) > @@ -1124,8 +1144,16 @@ static void grab_person(const char *who, struct atom_value *val, int deref, void > v->s = copy_line(wholine); > else if (!strcmp(name + wholen, "name")) > v->s = copy_name(wholine); > - else if (!strcmp(name + wholen, "email")) > + else if (starts_with(name + wholen, "email")) { > + email_option.option = EO_INVALID; > + if (!strcmp(name + wholen, "email")) > + email_option.option = EO_RAW; > + if (!strcmp(name + wholen, "email:trim")) > + email_option.option = EO_TRIM; > + if (!strcmp(name + wholen, "email:localpart")) > + email_option.option = EO_LOCALPART; The ref-filter formatting language already knows many "colon plus modifier" suffix like "refname:short" and "contents:body", but I do not think we have ugly repetition like the above code to parse them. Perhaps the addition for "email:<whatever>" can benefit from studying and mimicking existing practices a bit more?

On the Git mailing list, Hariom verma wrote (reply to this):

Hi, On Tue, Jul 28, 2020 at 4:21 AM Junio C Hamano <[email protected]> wrote: > > "Hariom Verma via GitGitGadget" <[email protected]> writes: > > > From: Hariom Verma <[email protected]> > > > > Currently, ref-filter only supports printing email with arrow brackets. > > This is the first time I heard the term "arrow bracket". Aren't > they more commonly called angle brackets? Yeah. Sorry about that. > > Let's add support for two more email options. > > - trim : print email without arrow brackets. > > Why would this be useful? It might be useful for using the ref-filter's logic in pretty.c (especially for `--pretty` formats like `%an` and `%cn`) > > - localpart : prints the part before the @ sign > > Meaning I'd get "<gitster" for me? No, you'll get "gitster". > Building small pieces of new feature in each patch is good, and > adding tests to each step is also good. Why not do the same for > docs? Yeah, I agree with you. I should have focused on documentation too. > > +static struct email_option{ > > Missing SP. I'll fix it. > > + enum { EO_INVALID, EO_RAW, EO_TRIM, EO_LOCALPART } option; > > +} email_option; > > + > > @@ -1040,10 +1044,26 @@ static const char *copy_email(const char *buf) > > const char *eoemail; > > if (!email) > > return xstrdup(""); > > - eoemail = strchr(email, '>'); > > The original code prepares to see NULL from this strchr(); that is > why it checks eoemail for NULL and returns an empty string---the > data is broken (i.e. not an address in angle brackets), which this > code cannot do anything about---in the later part of the code. I think this commit still takes care of NULL. After the switch-case statements, code consists of: ``` if (!eoemail) return xstrdup(""); ``` Which checks eoemail for NULL. And will return empty string if address is not in angle brackets. Same applies for local-part too. If '@' is not present in email address, it will still return empty string. > > + switch (email_option.option) { > > + case EO_RAW: > > + eoemail = strchr(email, '>') + 1; > > And this breaks the carefully laid out error handling by the > original code. Adding 1 to NULL is quite undefined. Yeah. I'll take care of it in the next version. > > + break; > > + case EO_TRIM: > > + email++; > > + eoemail = strchr(email, '>'); > > + break; > > + case EO_LOCALPART: > > + email++; > > + eoemail = strchr(email, '@'); > > The undocumented design here is that you want to return "hariom" for > "<[email protected]>", i.e. out of the "trimmed" e-mail, the part > before the at-sign is returned. > > If the data were "<hariom>", you'd still want to return "hariom" no? > But because you do not check for NULL, you end up returning an empty > string. I never heard of email address without '@' symbol. Thats why I returned empty string. Will fix that too. > I think you want to cut at the first '@' or '>', whichever comes > first. If email data can be without '@' symbol, then I guess "yes". > > + break; > > + case EO_INVALID: > > + default: > > Invalid and unhandled ones are silently ignored and not treated as > an error? I would have thought that at least the "default" one > would be a BUG(), as you covered all the possible values for the > enum with case arms. I wouldn't be surprised if seeing EO_INVALID > is also a BUG(), i.e. the control flow that led to the caller to > call this function with EO_INVALID in email_option.option is likely > to be broken. It's not like you return "" to protect yourself when > fed a bad data from objects---a bad value in .option can only come > here if the parser you wrote for "--format=<string>" produced a > wrong result. Christian <[email protected]> also suggested me the same. Will fix this too. BTW, on master "{author,committer,tagger}email:<xyz>" does not print any error. > > + return xstrdup(""); > > + } > > + > > if (!eoemail) > > return xstrdup(""); > > - return xmemdupz(email, eoemail + 1 - email); > > + return xmemdupz(email, eoemail - email); > > } > > > > static char *copy_subject(const char *buf, unsigned long len) > > @@ -1113,7 +1133,7 @@ static void grab_person(const char *who, struct atom_value *val, int deref, void > > continue; > > if (name[wholen] != 0 && > > strcmp(name + wholen, "name") && > > - strcmp(name + wholen, "email") && > > + !starts_with(name + wholen, "email") && > > !starts_with(name + wholen, "date")) > > continue; > > if (!wholine) > > @@ -1124,8 +1144,16 @@ static void grab_person(const char *who, struct atom_value *val, int deref, void > > v->s = copy_line(wholine); > > else if (!strcmp(name + wholen, "name")) > > v->s = copy_name(wholine); > > - else if (!strcmp(name + wholen, "email")) > > + else if (starts_with(name + wholen, "email")) { > > + email_option.option = EO_INVALID; > > + if (!strcmp(name + wholen, "email")) > > + email_option.option = EO_RAW; > > + if (!strcmp(name + wholen, "email:trim")) > > + email_option.option = EO_TRIM; > > + if (!strcmp(name + wholen, "email:localpart")) > > + email_option.option = EO_LOCALPART; > > The ref-filter formatting language already knows many "colon plus > modifier" suffix like "refname:short" and "contents:body", but I do > not think we have ugly repetition like the above code to parse them. > Perhaps the addition for "email:<whatever>" can benefit from > studying and mimicking existing practices a bit more? > For "email:<whatever>", even If I parse that <whatever>. I still make comparison something like: ``` if (!modifier) email_option.option = EO_RAW; else if (!strcmp(modifier, "trim")) email_option.option = EO_TRIM; else if (!strcmp(arg, "localpart")) email_option.option = EO_LOCALPART; ``` Thanks, Hariom

On the Git mailing list, Junio C Hamano wrote (reply to this):

Hariom verma <[email protected]> writes: >> The ref-filter formatting language already knows many "colon plus >> modifier" suffix like "refname:short" and "contents:body", but I do >> not think we have ugly repetition like the above code to parse them. >> Perhaps the addition for "email:<whatever>" can benefit from >> studying and mimicking existing practices a bit more? >> > > For "email:<whatever>", > even If I parse that <whatever>. I still make comparison something like: > ``` > if (!modifier) > email_option.option = EO_RAW; > else if (!strcmp(modifier, "trim")) > email_option.option = EO_TRIM; > else if (!strcmp(arg, "localpart")) > email_option.option = EO_LOCALPART; > ``` Somebody needs to do a comparison, but it should be done at parsing phase when the --format is grokked, not in grab phase that is run for each and every ref to be shown. These patches should only be done after looking at existing "<basicatom>:<modifiers>" like "objectname:short" etc are handled, not before, I think.

gitgitgadget · 2020-07-27T23:23:07Z

ref-filter.c

@@ -102,6 +102,10 @@ static struct ref_to_worktree_map {
 	struct worktree **worktrees;


On the Git mailing list, Junio C Hamano wrote (reply to this):

"Hariom Verma via GitGitGadget" <[email protected]> writes: > - if (!strcmp(name, "tree")) { > + if (!strcmp(name, "tree")) > v->s = xstrdup(oid_to_hex(get_commit_tree_oid(commit))); > - } > + else if (!strcmp(name, "tree:short")) > + v->s = xstrdup(find_unique_abbrev(get_commit_tree_oid(commit), DEFAULT_ABBREV)); Again, isn't this going in totally unacceptable direction? By the time grab_foo() helper functions are reached, the requested format should have been parsed to atom->u.foo.option and the only thing grab_foo() helper functions should look at are the option. Perhaps studying how "objectname" and its ":"-modified forms are handled before writing this series would be beneficial. - objectname_atom_parser() is called when the parser for --format notices "objectname:modifier"; it is responsible for setting up atom->u.objectname.option. Note that this is done only once at the very begining of processing - grab_objectname() is called for each and every object ref-filter iterates over and "objectname" and/or its modified form (e.g. "objectname:short") is requested. Since the modifier is already parsed, it can do a simple switch on the value in .option. I do not know if patches [3-5/5] follow the pattern used in [1-2/5], but if they do, then they all need to be fixed, I think. Thanks.

gitgitgadget · 2020-07-28T14:01:09Z

ref-filter.c

@@ -102,6 +102,10 @@ static struct ref_to_worktree_map {
 	struct worktree **worktrees;


On the Git mailing list, Đoàn Trần Công Danh wrote (reply to this):

[this is a resent, my previous mail couldn't reach the archive] On 2020-07-27 20:43:04+0000, Hariom Verma via GitGitGadget <[email protected]> wrote: > From: Hariom Verma <[email protected]> > > Currently, ref-filter only supports printing email with arrow brackets. > > Let's add support for two more email options. > - trim : print email without arrow brackets. > - localpart : prints the part before the @ sign > > Mentored-by: Christian Couder <[email protected]> > Mentored-by: Heba Waly <[email protected]> > Signed-off-by: Hariom Verma <[email protected]> > --- > ref-filter.c | 36 ++++++++++++++++++++++++++++++++---- > t/t6300-for-each-ref.sh | 16 ++++++++++++++++ > 2 files changed, 48 insertions(+), 4 deletions(-) > > diff --git a/ref-filter.c b/ref-filter.c > index 8447cb09be..8563088eb1 100644 > --- a/ref-filter.c > +++ b/ref-filter.c > @@ -102,6 +102,10 @@ static struct ref_to_worktree_map { > struct worktree **worktrees; > } ref_to_worktree_map; > > +static struct email_option{ > + enum { EO_INVALID, EO_RAW, EO_TRIM, EO_LOCALPART } option; > +} email_option; > + > /* > * An atom is a valid field atom listed below, possibly prefixed with > * a "*" to denote deref_tag(). > @@ -1040,10 +1044,26 @@ static const char *copy_email(const char *buf) > const char *eoemail; > if (!email) > return xstrdup(""); > - eoemail = strchr(email, '>'); > + switch (email_option.option) { > + case EO_RAW: > + eoemail = strchr(email, '>') + 1; > + break; > + case EO_TRIM: > + email++; > + eoemail = strchr(email, '>'); > + break; > + case EO_LOCALPART: > + email++; > + eoemail = strchr(email, '@'); > + break; This is not correct. RFC-822 allows @ in local part, albeit, that localpart must be quoted: addr-spec = local-part "@" domain local-part = dot-atom / quoted-string / obs-local-part quoted-string = [CFWS] DQUOTE *([FWS] qcontent) [FWS] DQUOTE [CFWS] qcontent = qtext / quoted-pair qtext = NO-WS-CTL / ; Non white space qtext = NO-WS-CTL / ; Non white space controls %d33 / ; The rest of the US-ASCII %d35-91 / ; characters not including "\" %d93-126 ; or the quote character quoted-pair = ("\" text) / obs-qp IOW, those below email addresses are valid email address, and the local part is `quoted@local' "quoted@local"@example.com quoted\@[email protected] Anyway, it seems like current Git strips first `"' from `"quoted@local"@example.com' -- Danh

On the Git mailing list, Junio C Hamano wrote (reply to this):

Đoàn Trần Công Danh <[email protected]> writes: > This is not correct. > RFC-822 allows @ in local part, > albeit, that localpart must be quoted: We do care about truly local e-mail addresses, without '@' anywhere inside <braket>, simply because they are common in the result of SCM conversion from CVS/SVN. But I do not think we are pedantic/academic enough to have cared about any local part that is unusual enough to require quoting; we instead relied on the fact that we live in real world with practical people who would avoid such an address ;-).

harry-hov · 2020-08-01T18:41:10Z

I am not sure that it is doing the same thing as the original for \n. If there is a reason, it should be stated in the commit message.

Yeah I will explain it in commit message properly.

gitgitgadget · 2020-08-04T17:50:05Z

There is an issue in commit 4595203:
Commit checks stopped - the message is too short

harry-hov · 2020-08-05T21:50:57Z

/submit

gitgitgadget · 2020-08-05T21:52:07Z

Submitted as [email protected]

gitgitgadget · 2020-08-05T22:07:35Z

On the Git mailing list, Junio C Hamano wrote (reply to this):

"Hariom Verma via GitGitGadget" <[email protected]> writes:

>      -@@ ref-filter.c: static struct ref_to_worktree_map {
>      - 	struct worktree **worktrees;
>      - } ref_to_worktree_map;
>      +@@ ref-filter.c: static struct used_atom {
>      + 			enum { O_FULL, O_LENGTH, O_SHORT } option;
>      + 			unsigned int length;
>      + 		} objectname;
>      ++		struct email_option {
>      ++			enum { EO_RAW, EO_TRIM, EO_LOCALPART } option;
>      ++		} email_option;
>      + 		struct refname_atom refname;
>      + 		char *head;
>      + 	} u;

I'll try to find enough time to read the body of the series sometime
later this week, but this interdiff alone smells that this is much
closer to being correct (no, I am not saying I spotted a bug, but it
certainly looks liek it is on the right track, relative to what I
saw the last time, to be right).

A good test for this new feature may be to try using

	"<%(authoremail:localpart)> <%(committeremail:trim)>"

as a format to make sure e-mail options are done per-atom.

Thanks.

gitgitgadget · 2020-08-06T17:23:48Z

On the Git mailing list, Hariom verma wrote (reply to this):

Hi,

On Thu, Aug 6, 2020 at 3:34 AM Junio C Hamano <[email protected]> wrote:
>
> "Hariom Verma via GitGitGadget" <[email protected]> writes:
>
> >      -@@ ref-filter.c: static struct ref_to_worktree_map {
> >      -        struct worktree **worktrees;
> >      - } ref_to_worktree_map;
> >      +@@ ref-filter.c: static struct used_atom {
> >      +                        enum { O_FULL, O_LENGTH, O_SHORT } option;
> >      +                        unsigned int length;
> >      +                } objectname;
> >      ++               struct email_option {
> >      ++                       enum { EO_RAW, EO_TRIM, EO_LOCALPART } option;
> >      ++               } email_option;
> >      +                struct refname_atom refname;
> >      +                char *head;
> >      +        } u;
>
> I'll try to find enough time to read the body of the series sometime
> later this week, but this interdiff alone smells that this is much
> closer to being correct (no, I am not saying I spotted a bug, but it
> certainly looks liek it is on the right track, relative to what I
> saw the last time, to be right).

Thanks. I'll wait for your review.

> A good test for this new feature may be to try using
>
>         "<%(authoremail:localpart)> <%(committeremail:trim)>"
>
> as a format to make sure e-mail options are done per-atom.

Yeah. This test will surely make its way to t6300 in the next version
of this patch series.

Thanks,
Hariom

Prepares `grab_objectname()` for more generic usage. This change will allow us to reuse `grab_objectname()` for the `tree` and `parent` atoms in a following commit. Mentored-by: Christian Couder <[email protected]> Mentored-by: Heba Waly <[email protected]> Signed-off-by: Hariom Verma <[email protected]>

As we plan to use `grab_objectname()` for `tree` and `parent` atom, it's better to parameterize the error messages in the function `grab_objectname()` where "objectname" is hard coded. Mentored-by: Christian Couder <[email protected]> Mentored-by: Heba Waly <[email protected]> Signed-off-by: Hariom Verma <[email protected]>

In previous commits, we prepared some `objectname` related functions for more generic usage, so that these functions can be used for `tree` and `parent` atom. But the name of some functions and fields may mislead someone. For ex: function `objectname_atom_parser()` implies that it is for atom `objectname`. Let's rename all such functions and fields. Mentored-by: Christian Couder <[email protected]> Mentored-by: Heba Waly <[email protected]> Signed-off-by: Hariom Verma <[email protected]>

Sometimes while using 'tree' atom, user might want to see abbrev hash instead of full 40 character hash. Just like 'objectname', it might be convenient for users to have the `:short` and `:short=<length>` option for printing 'tree' hash. Let's introduce `short` option to 'tree' atom. Mentored-by: Christian Couder <[email protected]> Mentored-by: Heba Waly <[email protected]> Signed-off-by: Hariom Verma <[email protected]>

Sometimes while using 'parent' atom, user might want to see abbrev hash instead of full 40 character hash. Just like 'objectname', it might be convenient for users to have the `:short` and `:short=<length>` option for printing 'parent' hash. Let's introduce `short` option to 'parent' atom. Mentored-by: Christian Couder <[email protected]> Mentored-by: Heba Waly <[email protected]> Signed-off-by: Hariom Verma <[email protected]>

The function 'format_sanitized_subject()' is responsible for sanitized subject line in pretty.c e.g. the subject line the-sanitized-subject-line It would be a nice enhancement to `subject` atom to have the same feature. So in the later commits, we plan to add this feature to ref-filter. Refactor `format_sanitized_subject()`, so it can be reused in ref-filter.c for adding new modifier `sanitize` to "subject" atom. Currently, the loop inside `format_sanitized_subject()` runs until `\n` is found. But now, we stored the first occurrence of `\n` in a variable `eol` and passed it in `format_sanitized_subject()`. And the loop runs upto `eol`. Mentored-by: Christian Couder <[email protected]> Mentored-by: Heba Waly <[email protected]> Signed-off-by: Hariom Verma <[email protected]>

Currently, subject does not take any arguments. This commit introduce `sanitize` formatting option to 'subject' atom. `subject:sanitize` - print sanitized subject line, suitable for a filename. e.g. %(subject): "the subject line" %(subject:sanitize): "the-subject-line" Mentored-by: Christian Couder <[email protected]> Mentored-by: Heba Waly <[email protected]> Signed-off-by: Hariom Verma <[email protected]>

gitgitgadget · 2020-08-21T21:29:21Z

This patch series was integrated into seen via git@b055fe9.

harry-hov · 2020-08-21T21:41:01Z

/submit

gitgitgadget · 2020-08-21T21:42:19Z

Submitted as [email protected]

To fetch this version into FETCH_HEAD:

git fetch https://github.com/gitgitgadget/git pr-684/harry-hov/only-rf6-v4

To fetch this version to local tag pr-684/harry-hov/only-rf6-v4:

git fetch --no-tags https://github.com/gitgitgadget/git tag pr-684/harry-hov/only-rf6-v4

gitgitgadget · 2020-08-24T23:08:49Z

This patch series was integrated into seen via git@a545a18.

gitgitgadget · 2020-08-25T01:03:10Z

This patch series was integrated into seen via git@1939e23.

gitgitgadget · 2020-08-26T22:08:05Z

This patch series was integrated into seen via git@a759e52.

gitgitgadget · 2020-08-27T21:49:02Z

This patch series was integrated into seen via git@a22e343.

gitgitgadget · 2020-08-27T21:49:03Z

This patch series was integrated into next via git@c015fa6.

gitgitgadget · 2020-08-29T07:24:28Z

This patch series was integrated into seen via git@c758384.

gitgitgadget · 2020-08-31T23:56:58Z

This patch series was integrated into seen via git@2611854.

gitgitgadget · 2020-09-02T22:39:11Z

This patch series was integrated into seen via git@4d58a7c.

gitgitgadget · 2020-09-02T22:39:12Z

This patch series was integrated into next via git@9a8bb84.

gitgitgadget · 2020-09-03T20:40:00Z

This patch series was integrated into seen via git@313cff1.

gitgitgadget · 2020-09-08T23:37:27Z

This patch series was integrated into seen via git@53a8aa4.

gitgitgadget · 2020-09-09T22:37:22Z

This patch series was integrated into seen via git@c25fba9.

gitgitgadget · 2020-09-09T22:37:23Z

This patch series was integrated into next via git@c25fba9.

gitgitgadget · 2020-09-09T22:37:24Z

This patch series was integrated into master via git@c25fba9.

gitgitgadget · 2020-09-09T22:37:27Z

Closed via c25fba9.

harry-hov changed the title ~~Improvements to ref-filter~~ [GSoC] Improvements to ref-filter Jul 26, 2020

gitgitgadget bot reviewed Jul 27, 2020

View reviewed changes

harry-hov closed this Jul 27, 2020

harry-hov reopened this Jul 27, 2020

gitgitgadget bot reviewed Jul 27, 2020

View reviewed changes

gitgitgadget bot reviewed Jul 28, 2020

View reviewed changes

harry-hov force-pushed the only-rf6 branch 2 times, most recently from ced66ab to 33f1404 Compare August 1, 2020 07:52

weekly-digest bot mentioned this pull request Aug 2, 2020

Weekly Digest (26 July, 2020 - 2 August, 2020) #690

Closed

harry-hov force-pushed the only-rf6 branch from 33f1404 to f9fafcb Compare August 4, 2020 17:49

harry-hov force-pushed the only-rf6 branch 8 times, most recently from bc74985 to feace82 Compare August 5, 2020 21:50

weekly-digest bot mentioned this pull request Aug 9, 2020

Weekly Digest (2 August, 2020 - 9 August, 2020) #697

Closed

harry-hov changed the title ~~[GSoC] Improvements to ref-filter~~ [Resend][GSoC] Improvements to ref-filter Aug 16, 2020

harry-hov added 7 commits August 21, 2020 04:43

harry-hov force-pushed the only-rf6 branch from 1ab35e9 to 7cba8d7 Compare August 20, 2020 23:15

harry-hov changed the title ~~[Resend][GSoC] Improvements to ref-filter~~ [GSoC] Improvements to ref-filter Aug 21, 2020

gitgitgadget bot added the next label Aug 27, 2020

gitgitgadget bot added the master label Sep 9, 2020

gitgitgadget bot closed this Sep 9, 2020

		@@ -102,6 +102,10 @@ static struct ref_to_worktree_map {
		struct worktree **worktrees;

[GSoC] Improvements to ref-filter #684

[GSoC] Improvements to ref-filter #684

Uh oh!

Conversation

harry-hov commented Jul 26, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

harry-hov commented Jul 27, 2020

Uh oh!

gitgitgadget bot commented Jul 27, 2020

Uh oh!

harry-hov commented Jul 27, 2020

Uh oh!

gitgitgadget bot commented Jul 27, 2020

Uh oh!

gitgitgadget bot Jul 27, 2020

Choose a reason for hiding this comment

Uh oh!

gitgitgadget bot Jul 28, 2020

Choose a reason for hiding this comment

Uh oh!

gitgitgadget bot Jul 28, 2020

Choose a reason for hiding this comment

Uh oh!

gitgitgadget bot Jul 27, 2020

Choose a reason for hiding this comment

Uh oh!

gitgitgadget bot Jul 28, 2020

Choose a reason for hiding this comment

Uh oh!

gitgitgadget bot Jul 28, 2020

Choose a reason for hiding this comment

Uh oh!

harry-hov commented Aug 1, 2020

Uh oh!

gitgitgadget bot commented Aug 4, 2020

Uh oh!

harry-hov commented Aug 5, 2020

Uh oh!

gitgitgadget bot commented Aug 5, 2020

Uh oh!

gitgitgadget bot commented Aug 5, 2020

Uh oh!

gitgitgadget bot commented Aug 6, 2020

Uh oh!

gitgitgadget bot commented Aug 21, 2020

Uh oh!

harry-hov commented Aug 21, 2020

Uh oh!

gitgitgadget bot commented Aug 21, 2020

Uh oh!

gitgitgadget bot commented Aug 24, 2020

Uh oh!

gitgitgadget bot commented Aug 25, 2020

Uh oh!

gitgitgadget bot commented Aug 26, 2020

Uh oh!

gitgitgadget bot commented Aug 27, 2020

Uh oh!

gitgitgadget bot commented Aug 27, 2020

Uh oh!

gitgitgadget bot commented Aug 29, 2020

Uh oh!

gitgitgadget bot commented Aug 31, 2020

Uh oh!

gitgitgadget bot commented Sep 2, 2020

Uh oh!

gitgitgadget bot commented Sep 2, 2020

Uh oh!

gitgitgadget bot commented Sep 3, 2020

Uh oh!

gitgitgadget bot commented Sep 8, 2020

Uh oh!

gitgitgadget bot commented Sep 9, 2020

Uh oh!

gitgitgadget bot commented Sep 9, 2020

Uh oh!

gitgitgadget bot commented Sep 9, 2020

Uh oh!

gitgitgadget bot commented Sep 9, 2020

harry-hov commented Jul 26, 2020 •

edited

Loading