From: ZheNing Hu <adlternative@gmail.com>
To: Git List <git@vger.kernel.org>
Cc: Christian Couder <christian.couder@gmail.com>,
Junio C Hamano <gitster@pobox.com>, Jeff King <peff@peff.net>,
Hariom verma <hariom18599@gmail.com>
Subject: [GSoC] Git Blog 3
Date: Sun, 6 Jun 2021 23:21:06 +0800 [thread overview]
Message-ID: <CAOLTT8SJkVeSQKB7eN5Lw+OepeRXiZXWf_t-E09KxT1pmYBMag@mail.gmail.com> (raw)
My third week blog finished:
The web version is here:
https://adlternative.github.io/GSOC-Git-Blog-3/
-----
## Week3: Meticulousness is very important
### What happened this week
- I found a `git cat-file` bug this week, see:
```bash
git cat-file --batch=batman --batch-all-objects
batman
fatal: object 00345b5fe0aa8f45e9d1289ceb299f0489ea3fe1 changed type!?
```
It seems that Git died for a strange reason: the type of
an object changed? Is my Git object damaged? (Just like
a friend of mine, use `find . -type f -print0 | xargs -0 sed
-i "s/\r//g"` remove all the '\r' of all files in a Git repository,
this caused most of his Git commands to fail.) So I tested
it under different linux platforms, they all have this same
damage.
After a series of testing and debugging, I found that
`oid_object_info_extended()` did not get the type of
object.
So I submitted the patch for fix this bug to the Git mailing list in
[[PATCH] [GSOC] cat-file: fix --batch report changed-type
bug](https://lore.kernel.org/git/pull.965.git.1622363366722.gitgitgadget@gmail.com/),
Peff tell us the essential reason for this bug:
In `845de33a5b (cat-file: avoid noop calls to
sha1_object_info_extended, 2016-05-18)`, this patches
skips the call to `oid_object_info_extended()` entirely when
`--batch-all-objects` is in use, and the custom format does
not include any placeholders that require calling it. The correct
solution is to put checking if `object_info` is empty after
setting `object_info.typep`.
Finally, thanks to the help of Jeff, I summit final patch in
[[PATCH v2 1/2] [GSOC] cat-file: handle trivial --batch format with
--batch-all-objects](https://lore.kernel.org/git/4af3b958dd056e2162fdc5d7f6600bcedde210b8.1622737766.git.gitgitgadget@gmail.com/).
Talk of experience as a story: Even experienced programmers
make small mistakes, writing any code requires very careful thinking.
- The checkpoints for rejecting `%(raw)` and `--<lang>` are incorrect.
At Junio’s reminder, I changed the checkpoint from
`parse_ref_filter_atom()` to `verify_ref_format()`. My mentor Christian
pointed out some grammatical errors in the cover letter.
- At the suggestion of Junio, I rebased `0efed94 ([GSOC]
ref-filter: add %(raw) atom)` on `1197f1a (ref-filter: introduce
enum atom_type)`, they have a clash, after resolving the conflict,
it's better for me to consider the code I implemented before and
the code I wrote now at the same time, I can find more problems
and find better solutions.
- I submitted the patch about `%(rest)`, `%(raw:textconv)` and
`%(raw:filters)` for `ref-filter`, they are used to simulate some
functions of `git cat-file`, my mentor Hariom noticed one of the
formatting issues, I am waiting for more reviews for the time being.
### What's the next step
As long as new atoms `%(rest)`, `%(raw:textconv)` and `%(raw:filters)`
for `ref-filter` can be accepted by Git, We can start to let `cat-file` use
`ref-filter` logic on a large scale! Exciting! But the performance of
`ref-filter`
is still not good. Perhaps I need to find a new breakthrough in the
performance bottleneck of `ref-filter`.
Thanks!
--
ZheNing Hu
next reply other threads:[~2021-06-06 15:21 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-06 15:21 ZheNing Hu [this message]
2021-06-07 4:45 ` [GSoC] Git Blog 3 Christian Couder
2021-06-07 12:03 ` ZheNing Hu
Reply instructions:
You may reply publicly 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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAOLTT8SJkVeSQKB7eN5Lw+OepeRXiZXWf_t-E09KxT1pmYBMag@mail.gmail.com \
--to=adlternative@gmail.com \
--cc=christian.couder@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=hariom18599@gmail.com \
--cc=peff@peff.net \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.