[GSoC] Git Blog 9

[GSoC] Git Blog 9

[ZheNing Hu]

My ninth week blog finished:
The web version is here:
https://adlternative.github.io/GSOC-Git-Blog-9/

## Week9 BUG REPORT

### BUG REPORT 1

* What did you do before the bug happened? (Steps to reproduce your issue)

Because someone told me that `git cherry-pick` can't gave useful
prompt information like `git rebase -i` does:

```
You can amend the commit now, with

git commit --amend

Once you are satisfied with your changes, run

git rebase --continue
```

I found that I can take use of "GIT_CHERRY_PICK_HELP" environment variable,

```
$ GIT_CHERRY_PICK_HELP="git cherry-pick --continue" ggg cherry-pick v1
```

which will output prompt information "git cherry-pick --continue", good!

* What did you expect to happen? (Expected behavior)

I could use `git cherry-pick --abort` to exit cherry-pick normally.

* What happened instead? (Actual behavior)

Then I couldn't use `git cherry-pick --abort` to exit cherry-pick normally.

* Anything else you want to add:

See the print_advice() in sequencer.c, `CHERRY_PICK_HEAD` will be removed
if we use the env "GIT_CHERRY_PICK_HELP". It is used by `git rebase
-i` and somewhere else.

Here may have two solutions:
1. Prevent users from using the environment variable "GIT_CHERRY_PICK_HELP".
2. check if we are truly cherry-pick.

```c
diff --git a/sequencer.c b/sequencer.c
index 0bec01cf38..c01b0b9e9c 100644
--- a/sequencer.c
+++ b/sequencer.c
@@ -409,8 +409,9 @@ static void print_advice(struct repository *r, int
show_hint,
* (typically rebase --interactive) wants to take care
* of the commit itself so remove CHERRY_PICK_HEAD
*/
- refs_delete_ref(get_main_ref_store(r), "", "CHERRY_PICK_HEAD",
- NULL, 0);
+ if (opts->action != REPLAY_PICK)
+ refs_delete_ref(get_main_ref_store(r), "", "CHERRY_PICK_HEAD",
+ NULL, 0);
return;
}
```

* [System Info]

```
git version:
git version 2.32.0
cpu: x86_64
no commit associated with this build
sizeof-long: 8
sizeof-size_t: 8
shell-path: /bin/sh
uname: Linux 5.12.15-arch1-1 #1 SMP PREEMPT Wed, 07 Jul 2021 23:35:29
+0000 x86_64
compiler info: gnuc: 11.1
libc info: glibc: 2.33
$SHELL (typically, interactive shell): /bin/zsh
```

* [Enabled Hooks]

None.

### BUG REPORT 2

* What did you do before the bug happened? (Steps to reproduce your issue)

Normally execute the test under git/t.

* What did you expect to happen? (Expected behavior)

Pass the test t/t0500-progress-display.sh.

* What happened instead? (Actual behavior)

```zsh
$ sh t0500-progress-display.sh -d -i -v
...
expecting success of 0500.3 'progress display breaks long lines #1':
sed -e "s/Z$//" >expect <<\EOF &&
Working hard.......2.........3.........4.........5.........6: 0%
(100/100000)<CR>
Working hard.......2.........3.........4.........5.........6: 1%
(1000/100000)<CR>
Working hard.......2.........3.........4.........5.........6: Z
10% (10000/100000)<CR>
100% (100000/100000)<CR>
100% (100000/100000), done.
EOF

cat >in <<-\EOF &&
progress 100
progress 1000
progress 10000
progress 100000
EOF
test-tool progress --total=100000 \
"Working hard.......2.........3.........4.........5.........6" \
<in 2>stderr &&

show_cr <stderr >out &&
test_cmp expect out

--- expect 2021-07-19 06:09:39.800189433 +0000
+++ out 2021-07-19 06:09:39.803522767 +0000
@@ -1,6 +1,5 @@
Working hard.......2.........3.........4.........5.........6: 0%
(100/100000)<CR>
Working hard.......2.........3.........4.........5.........6: 1%
(1000/100000)<CR>
-Working hard.......2.........3.........4.........5.........6:
- 10% (10000/100000)<CR>
- 100% (100000/100000)<CR>
- 100% (100000/100000), done.
+Working hard.......2.........3.........4.........5.........6: 10%
(10000/100000)<CR>
+Working hard.......2.........3.........4.........5.........6: 100%
(100000/100000)<CR>
+Working hard.......2.........3.........4.........5.........6: 100%
(100000/100000), done.
not ok 3 - progress display breaks long lines #1
#
# sed -e "s/Z$//" >expect <<\EOF &&
# Working hard.......2.........3.........4.........5.........6: 0%
(100/100000)<CR>
# Working hard.......2.........3.........4.........5.........6: 1%
(1000/100000)<CR>
# Working hard.......2.........3.........4.........5.........6: Z
# 10% (10000/100000)<CR>
# 100% (100000/100000)<CR>
# 100% (100000/100000), done.
# EOF
#
# cat >in <<-\EOF &&
# progress 100
# progress 1000
# progress 10000
# progress 100000
# EOF
# test-tool progress --total=100000 \
# "Working hard.......2.........3.........4.........5.........6" \
# <in 2>stderr &&
#
# show_cr <stderr >out &&
# test_cmp expect out
#
```

* What's different between what you expected and what actually happened?

It seems that the progress display is not working normally.

* Anything else you want to add:

I am thinking:
1. Is this bug caused by my own patches?
So I switched to other branches, including upstream/master, see the bug too.
2. Is this bug caused by zsh?
So I switched to bash, and saw the bug too.
3. Does this bug only appear on my Arch-Linux?
So I asked my classmates (who use arch linux too) to download git/git
from github and perform the test, see the bug too.
4. Does Ubuntu also have this bug?
No. In the case of using Ubuntu's docker and Centos's virtual machine,
after cloning git/git from github, they actually passed the test!!!

So what's wrong with Arch-Linux?

* [System Info]

```
git version:
git version 2.32.0
cpu: x86_64
no commit associated with this build
sizeof-long: 8
sizeof-size_t: 8
shell-path: /bin/sh
uname: Linux 5.12.15-arch1-1 #1 SMP PREEMPT Wed, 07 Jul 2021 23:35:29
+0000 x86_64
compiler info: gnuc: 11.1
libc info: glibc: 2.33
$SHELL (typically, interactive shell): /bin/zsh
```

* [Enabled Hooks]

None.


### project progress

I am still thinking about how to improve the performance of `git
cat-file --batch`.
This cannot be solved quickly, keep patient.

My mentors told me to split my main patch series into a few smaller
patch series, but how?
In other words, there is a certain correlation between these patches,
If they are really split into
multiple patches, how can I send them to the mailing list without repeating?

I just received half of the GSoC bonus, and felt a burden of responsibility...

Re: [GSoC] Git Blog 9

[Atharva Raykar]

On 19-Jul-2021, at 12:25, ZheNing Hu <adlternative@gmail.com> wrote:
> 
> [...]
> ### BUG REPORT 2
> 
> * What did you do before the bug happened? (Steps to reproduce your issue)
> 
> Normally execute the test under git/t.
> 
> * What did you expect to happen? (Expected behavior)
> 
> Pass the test t/t0500-progress-display.sh.
> 
> * What happened instead? (Actual behavior)
> 
> ```zsh
> $ sh t0500-progress-display.sh -d -i -v
> ...
> expecting success of 0500.3 'progress display breaks long lines #1':
> sed -e "s/Z$//" >expect <<\EOF &&
> Working hard.......2.........3.........4.........5.........6: 0%
> (100/100000)<CR>
> Working hard.......2.........3.........4.........5.........6: 1%
> (1000/100000)<CR>
> Working hard.......2.........3.........4.........5.........6: Z
> 10% (10000/100000)<CR>
> 100% (100000/100000)<CR>
> 100% (100000/100000), done.
> EOF
> 
> cat >in <<-\EOF &&
> progress 100
> progress 1000
> progress 10000
> progress 100000
> EOF
> test-tool progress --total=100000 \
> "Working hard.......2.........3.........4.........5.........6" \
> <in 2>stderr &&
> 
> show_cr <stderr >out &&
> test_cmp expect out
> 
> --- expect 2021-07-19 06:09:39.800189433 +0000
> +++ out 2021-07-19 06:09:39.803522767 +0000
> @@ -1,6 +1,5 @@
> Working hard.......2.........3.........4.........5.........6: 0%
> (100/100000)<CR>
> Working hard.......2.........3.........4.........5.........6: 1%
> (1000/100000)<CR>
> -Working hard.......2.........3.........4.........5.........6:
> - 10% (10000/100000)<CR>
> - 100% (100000/100000)<CR>
> - 100% (100000/100000), done.
> +Working hard.......2.........3.........4.........5.........6: 10%
> (10000/100000)<CR>
> +Working hard.......2.........3.........4.........5.........6: 100%
> (100000/100000)<CR>
> +Working hard.......2.........3.........4.........5.........6: 100%
> (100000/100000), done.
> not ok 3 - progress display breaks long lines #1
> #
> # sed -e "s/Z$//" >expect <<\EOF &&
> # Working hard.......2.........3.........4.........5.........6: 0%
> (100/100000)<CR>
> # Working hard.......2.........3.........4.........5.........6: 1%
> (1000/100000)<CR>
> # Working hard.......2.........3.........4.........5.........6: Z
> # 10% (10000/100000)<CR>
> # 100% (100000/100000)<CR>
> # 100% (100000/100000), done.
> # EOF
> #
> # cat >in <<-\EOF &&
> # progress 100
> # progress 1000
> # progress 10000
> # progress 100000
> # EOF
> # test-tool progress --total=100000 \
> # "Working hard.......2.........3.........4.........5.........6" \
> # <in 2>stderr &&
> #
> # show_cr <stderr >out &&
> # test_cmp expect out
> #
> ```
> 
> * What's different between what you expected and what actually happened?
> 
> It seems that the progress display is not working normally.
> 
> * Anything else you want to add:
> 
> I am thinking:
> 1. Is this bug caused by my own patches?
> So I switched to other branches, including upstream/master, see the bug too.
> 2. Is this bug caused by zsh?
> So I switched to bash, and saw the bug too.
> 3. Does this bug only appear on my Arch-Linux?
> So I asked my classmates (who use arch linux too) to download git/git
> from github and perform the test, see the bug too.
> 4. Does Ubuntu also have this bug?
> No. In the case of using Ubuntu's docker and Centos's virtual machine,
> after cloning git/git from github, they actually passed the test!!!
> 
> So what's wrong with Arch-Linux?

I noticed there's already a thread about this problem here:
https://lore.kernel.org/git/49498ed0-cfd5-2305-cee7-5c5939a19bcf@campoint.net/

This seems to be a bug with a recent bash, and a fix was suggested there.

> * [System Info]
> 
> ```
> git version:
> git version 2.32.0
> cpu: x86_64
> no commit associated with this build
> sizeof-long: 8
> sizeof-size_t: 8
> shell-path: /bin/sh
> uname: Linux 5.12.15-arch1-1 #1 SMP PREEMPT Wed, 07 Jul 2021 23:35:29
> +0000 x86_64
> compiler info: gnuc: 11.1
> libc info: glibc: 2.33
> $SHELL (typically, interactive shell): /bin/zsh
> ```
> 
> * [Enabled Hooks]
> 
> None.
> 
> [...]

---
Atharva Raykar
ಅಥರ್ವ ರಾಯ್ಕರ್
अथर्व रायकर

Re: [GSoC] Git Blog 9

[ZheNing Hu]

Hi,

Atharva Raykar <raykar.ath@gmail.com> 于2021年7月21日周三 上午1:22写道：
>
> On 19-Jul-2021, at 12:25, ZheNing Hu <adlternative@gmail.com> wrote:
> >
> > [...]
> > ### BUG REPORT 2
> >
> > * What did you do before the bug happened? (Steps to reproduce your issue)
> >
> > Normally execute the test under git/t.
> >
> > * What did you expect to happen? (Expected behavior)
> >
> > Pass the test t/t0500-progress-display.sh.
> >
> > * What happened instead? (Actual behavior)
> >
> > ```zsh
> > $ sh t0500-progress-display.sh -d -i -v
> > ...
> > expecting success of 0500.3 'progress display breaks long lines #1':
> > sed -e "s/Z$//" >expect <<\EOF &&
> > Working hard.......2.........3.........4.........5.........6: 0%
> > (100/100000)<CR>
> > Working hard.......2.........3.........4.........5.........6: 1%
> > (1000/100000)<CR>
> > Working hard.......2.........3.........4.........5.........6: Z
> > 10% (10000/100000)<CR>
> > 100% (100000/100000)<CR>
> > 100% (100000/100000), done.
> > EOF
> >
> > cat >in <<-\EOF &&
> > progress 100
> > progress 1000
> > progress 10000
> > progress 100000
> > EOF
> > test-tool progress --total=100000 \
> > "Working hard.......2.........3.........4.........5.........6" \
> > <in 2>stderr &&
> >
> > show_cr <stderr >out &&
> > test_cmp expect out
> >
> > --- expect 2021-07-19 06:09:39.800189433 +0000
> > +++ out 2021-07-19 06:09:39.803522767 +0000
> > @@ -1,6 +1,5 @@
> > Working hard.......2.........3.........4.........5.........6: 0%
> > (100/100000)<CR>
> > Working hard.......2.........3.........4.........5.........6: 1%
> > (1000/100000)<CR>
> > -Working hard.......2.........3.........4.........5.........6:
> > - 10% (10000/100000)<CR>
> > - 100% (100000/100000)<CR>
> > - 100% (100000/100000), done.
> > +Working hard.......2.........3.........4.........5.........6: 10%
> > (10000/100000)<CR>
> > +Working hard.......2.........3.........4.........5.........6: 100%
> > (100000/100000)<CR>
> > +Working hard.......2.........3.........4.........5.........6: 100%
> > (100000/100000), done.
> > not ok 3 - progress display breaks long lines #1
> > #
> > # sed -e "s/Z$//" >expect <<\EOF &&
> > # Working hard.......2.........3.........4.........5.........6: 0%
> > (100/100000)<CR>
> > # Working hard.......2.........3.........4.........5.........6: 1%
> > (1000/100000)<CR>
> > # Working hard.......2.........3.........4.........5.........6: Z
> > # 10% (10000/100000)<CR>
> > # 100% (100000/100000)<CR>
> > # 100% (100000/100000), done.
> > # EOF
> > #
> > # cat >in <<-\EOF &&
> > # progress 100
> > # progress 1000
> > # progress 10000
> > # progress 100000
> > # EOF
> > # test-tool progress --total=100000 \
> > # "Working hard.......2.........3.........4.........5.........6" \
> > # <in 2>stderr &&
> > #
> > # show_cr <stderr >out &&
> > # test_cmp expect out
> > #
> > ```
> >
> > * What's different between what you expected and what actually happened?
> >
> > It seems that the progress display is not working normally.
> >
> > * Anything else you want to add:
> >
> > I am thinking:
> > 1. Is this bug caused by my own patches?
> > So I switched to other branches, including upstream/master, see the bug too.
> > 2. Is this bug caused by zsh?
> > So I switched to bash, and saw the bug too.
> > 3. Does this bug only appear on my Arch-Linux?
> > So I asked my classmates (who use arch linux too) to download git/git
> > from github and perform the test, see the bug too.
> > 4. Does Ubuntu also have this bug?
> > No. In the case of using Ubuntu's docker and Centos's virtual machine,
> > after cloning git/git from github, they actually passed the test!!!
> >
> > So what's wrong with Arch-Linux?
>
> I noticed there's already a thread about this problem here:
> https://lore.kernel.org/git/49498ed0-cfd5-2305-cee7-5c5939a19bcf@campoint.net/
>
> This seems to be a bug with a recent bash, and a fix was suggested there.
>

Okay, it seems I need to have a related discussion here.

> > * [System Info]
> >
> > ```
> > git version:
> > git version 2.32.0
> > cpu: x86_64
> > no commit associated with this build
> > sizeof-long: 8
> > sizeof-size_t: 8
> > shell-path: /bin/sh
> > uname: Linux 5.12.15-arch1-1 #1 SMP PREEMPT Wed, 07 Jul 2021 23:35:29
> > +0000 x86_64
> > compiler info: gnuc: 11.1
> > libc info: glibc: 2.33
> > $SHELL (typically, interactive shell): /bin/zsh
> > ```
> >
> > * [Enabled Hooks]
> >
> > None.
> >
> > [...]
>
> ---
> Atharva Raykar
> ಅಥರ್ವ ರಾಯ್ಕರ್
> अथर्व रायकर
>

Thanks, it's helpful!
--
ZheNing Hu

Re: [GSoC] Git Blog 9

[Christian Couder]

On Mon, Jul 19, 2021 at 8:55 AM ZheNing Hu <adlternative@gmail.com> wrote:
>
> My ninth week blog finished:
> The web version is here:
> https://adlternative.github.io/GSOC-Git-Blog-9/

Thanks!

> ## Week9 BUG REPORT
>
> ### BUG REPORT 1

First, it would be better if these bugs were submitted to the mailing
list separately, one in each own email with a relevant subject, so
that people can more easily find and discuss them separately. It's ok
then if you link to these bug reports from, or copy parts of them to,
a blog post.

> * What did you do before the bug happened? (Steps to reproduce your issue)
>
> Because someone told me that `git cherry-pick` can't gave useful
> prompt information like `git rebase -i` does:
>
> ```
> You can amend the commit now, with
>
> git commit --amend
>
> Once you are satisfied with your changes, run
>
> git rebase --continue
> ```
>
> I found that I can take use of "GIT_CHERRY_PICK_HELP" environment variable,
>
> ```
> $ GIT_CHERRY_PICK_HELP="git cherry-pick --continue" ggg cherry-pick v1

Not sure what `ggg` is. Is it GitGitGadget, `git`, an alias with some
features turned on, or something else?

Not sure what is `v1` also. Is it a tag to a random commit?

> ```
>
> which will output prompt information "git cherry-pick --continue", good!
>
> * What did you expect to happen? (Expected behavior)
>
> I could use `git cherry-pick --abort` to exit cherry-pick normally.
>
> * What happened instead? (Actual behavior)
>
> Then I couldn't use `git cherry-pick --abort` to exit cherry-pick normally.

What happened when you tried to use it? Or what prevented you from using it?

> * Anything else you want to add:
>
> See the print_advice() in sequencer.c, `CHERRY_PICK_HEAD` will be removed
> if we use the env "GIT_CHERRY_PICK_HELP". It is used by `git rebase
> -i` and somewhere else.

So you got an error because `CHERRY_PICK_HEAD` had been removed?

> Here may have two solutions:
> 1. Prevent users from using the environment variable "GIT_CHERRY_PICK_HELP".

This means that we should remove it, right? Otherwise what's the
purpose of keeping it if users are prevented from using it? Or maybe
there is something I don't understand?

> 2. check if we are truly cherry-pick.
>
> ```c
> diff --git a/sequencer.c b/sequencer.c
> index 0bec01cf38..c01b0b9e9c 100644
> --- a/sequencer.c
> +++ b/sequencer.c
> @@ -409,8 +409,9 @@ static void print_advice(struct repository *r, int
> show_hint,
> * (typically rebase --interactive) wants to take care
> * of the commit itself so remove CHERRY_PICK_HEAD
> */
> - refs_delete_ref(get_main_ref_store(r), "", "CHERRY_PICK_HEAD",
> - NULL, 0);
> + if (opts->action != REPLAY_PICK)
> + refs_delete_ref(get_main_ref_store(r), "", "CHERRY_PICK_HEAD",
> + NULL, 0);
> return;
> }
> ```

So this solution means not removing CHERRY_PICK_HEAD if we are indeed
cherry-picking instead of rebasing. Yeah, this looks like a logical
solution to the issue to me. Could you send this in a separate patch
with a proper commit message?

> ### BUG REPORT 2

Thanks Atharva for replying to this bug report!

> ### project progress
>
> I am still thinking about how to improve the performance of `git
> cat-file --batch`.
> This cannot be solved quickly, keep patient.

Yeah, sure! In cases like this when the issue is not easy to
understand, it could be a good idea to keep some kind of research
journal where you describe the issue, the possible ways to solve it
and how your research to solve it goes. It could be a text or markdown
file in a branch, or a shared Google doc, for example.

> My mentors told me to split my main patch series into a few smaller
> patch series, but how?
> In other words, there is a certain correlation between these patches,
> If they are really split into
> multiple patches, how can I send them to the mailing list without repeating?

Yeah, I am not sure if it's possible and easy to send a patch series
based upon another one when using GitGitGadget. But you could perhaps
still send the first patch series, and then focus on getting it merged
and on performance issues. Discussing performance issues can probably
be done by only sending diffs in regular emails or RFC patches that
cannot be applied to the mailing list until a proper solution is
found.

> I just received half of the GSoC bonus, and felt a burden of responsibility...

No need to feel too much responsibility, we all share responsibility
in this. Also feel free to privately email me or Hariom and me (maybe
Kaartic too) if you want to discuss this further privately.

Re: [GSoC] Git Blog 9

[ZheNing Hu]

Christian Couder <christian.couder@gmail.com> 于2021年7月22日周四 下午3:50写道：
>
> On Mon, Jul 19, 2021 at 8:55 AM ZheNing Hu <adlternative@gmail.com> wrote:
> >
> > My ninth week blog finished:
> > The web version is here:
> > https://adlternative.github.io/GSOC-Git-Blog-9/
>
> Thanks!
>
> > ## Week9 BUG REPORT
> >
> > ### BUG REPORT 1
>
> First, it would be better if these bugs were submitted to the mailing
> list separately, one in each own email with a relevant subject, so
> that people can more easily find and discuss them separately. It's ok
> then if you link to these bug reports from, or copy parts of them to,
> a blog post.
>

You're right. Maybe the content of the blog did not attract everyone's
attention.

> > * What did you do before the bug happened? (Steps to reproduce your issue)
> >
> > Because someone told me that `git cherry-pick` can't gave useful
> > prompt information like `git rebase -i` does:
> >
> > ```
> > You can amend the commit now, with
> >
> > git commit --amend
> >
> > Once you are satisfied with your changes, run
> >
> > git rebase --continue
> > ```
> >
> > I found that I can take use of "GIT_CHERRY_PICK_HELP" environment variable,
> >
> > ```
> > $ GIT_CHERRY_PICK_HELP="git cherry-pick --continue" ggg cherry-pick v1
>
> Not sure what `ggg` is. Is it GitGitGadget, `git`, an alias with some
> features turned on, or something else?
>

Oh, it's just git/bin-wrappers/git.

> Not sure what is `v1` also. Is it a tag to a random commit?

Yeah.

>
> > ```
> >
> > which will output prompt information "git cherry-pick --continue", good!
> >
> > * What did you expect to happen? (Expected behavior)
> >
> > I could use `git cherry-pick --abort` to exit cherry-pick normally.
> >
> > * What happened instead? (Actual behavior)
> >
> > Then I couldn't use `git cherry-pick --abort` to exit cherry-pick normally.
>
> What happened when you tried to use it? Or what prevented you from using it?
>
> > * Anything else you want to add:
> >
> > See the print_advice() in sequencer.c, `CHERRY_PICK_HEAD` will be removed
> > if we use the env "GIT_CHERRY_PICK_HELP". It is used by `git rebase
> > -i` and somewhere else.
>
> So you got an error because `CHERRY_PICK_HEAD` had been removed?
>

Yeah, this is the situation I encountered.

> > Here may have two solutions:
> > 1. Prevent users from using the environment variable "GIT_CHERRY_PICK_HELP".
>
> This means that we should remove it, right? Otherwise what's the
> purpose of keeping it if users are prevented from using it? Or maybe
> there is something I don't understand?
>

Yeah, this may require rebase -i to use some new methods to achieve
the original functions.

> > 2. check if we are truly cherry-pick.
> >
> > ```c
> > diff --git a/sequencer.c b/sequencer.c
> > index 0bec01cf38..c01b0b9e9c 100644
> > --- a/sequencer.c
> > +++ b/sequencer.c
> > @@ -409,8 +409,9 @@ static void print_advice(struct repository *r, int
> > show_hint,
> > * (typically rebase --interactive) wants to take care
> > * of the commit itself so remove CHERRY_PICK_HEAD
> > */
> > - refs_delete_ref(get_main_ref_store(r), "", "CHERRY_PICK_HEAD",
> > - NULL, 0);
> > + if (opts->action != REPLAY_PICK)
> > + refs_delete_ref(get_main_ref_store(r), "", "CHERRY_PICK_HEAD",
> > + NULL, 0);
> > return;
> > }
> > ```
>
> So this solution means not removing CHERRY_PICK_HEAD if we are indeed
> cherry-picking instead of rebasing. Yeah, this looks like a logical
> solution to the issue to me. Could you send this in a separate patch
> with a proper commit message?
>

I haven't carefully verified its correctness. but okay, I will send it
separately.

> > ### BUG REPORT 2
>
> Thanks Atharva for replying to this bug report!
>
> > ### project progress
> >
> > I am still thinking about how to improve the performance of `git
> > cat-file --batch`.
> > This cannot be solved quickly, keep patient.
>
> Yeah, sure! In cases like this when the issue is not easy to
> understand, it could be a good idea to keep some kind of research
> journal where you describe the issue, the possible ways to solve it
> and how your research to solve it goes. It could be a text or markdown
> file in a branch, or a shared Google doc, for example.
>

Great, I happen to have the same idea as you. Some private attempts do
not seem to really improve the performance of ref-filters, maybe I should show
them to you.


> > My mentors told me to split my main patch series into a few smaller
> > patch series, but how?
> > In other words, there is a certain correlation between these patches,
> > If they are really split into
> > multiple patches, how can I send them to the mailing list without repeating?
>
> Yeah, I am not sure if it's possible and easy to send a patch series
> based upon another one when using GitGitGadget. But you could perhaps
> still send the first patch series, and then focus on getting it merged
> and on performance issues. Discussing performance issues can probably
> be done by only sending diffs in regular emails or RFC patches that
> cannot be applied to the mailing list until a proper solution is
> found.

Now I have an idea:
The latter patch will not be sent to the mailing list first, and we
can wait for the
previous patch merge to master first.
In the meantime, let us discuss performance solutions.

> > I just received half of the GSoC bonus, and felt a burden of responsibility...
>
> No need to feel too much responsibility, we all share responsibility
> in this. Also feel free to privately email me or Hariom and me (maybe
> Kaartic too) if you want to discuss this further privately.

I just think it seems that the "performance" problem seems to have not been
solved well by Olga at the time, so I feel a certain amount of pressure.

Thanks!!!
--
ZheNing Hu