list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
From: ZheNing Hu <>
To: Git List <>
Cc: Junio C Hamano <>,
	Denton Liu <>,
	Hariom verma <>,
	Christian Couder <>,
	Eric Sunshine <>,
	Jiang Xin <>, Jeff King <>
Subject: [GSoC] Hello Git
Date: Tue, 18 May 2021 14:40:05 +0800	[thread overview]
Message-ID: <> (raw)


### Self introduction

I'm ZheNing Hu, I am very lucky to participate in the GSoC
git project this year. Many people in the git community already
have given me a lot of help in the past few months.
Junio, Christian, Peff, Eric, Denton..., it's great to get along with
you guys! Your review and guidance have greatly benefited
my growth.

In these days before GSoC, I learned some simple command
implementation and data structures of git, learned strict coding
standards and learned how to test, More importantly, I learned how
to communicate with these kind-hearted reviewers.

Of course, there are still many difficulties for me:
* My poor English sometimes can’t express the meaning clearly.
* The Git architecture is very large, even a small command may
require very complex logic to implement, I often feel very difficult
to find clues.

Therefore, during GSoC, I hope to overcome these difficulties and
learn more in-depth knowledge in git.

### How to complete my GSoC project

I don’t want to be rejected by Git after I have completed a lot of
content, as Olga once did, Therefore, I think it is best to move in
the right direction step by step under everyone's supervision.

Current condition:
1. In order to use a unified interface containing both short-named
and full-named atoms, inspired by the short name option and long name
option of "OPT_*" in `parse-options.h`,  I thought I should add a new short
name atom to `struct valid_atom` for expansion in `ref-filter.c`, In [1]:
Junio thinks that `--format` with two-letters short atoms should not be
implemented in `ref-filter.c`
and provided for the `for-each-ref` family. Instead, let the "log" family
learn the full-named atom. To ensure the consistency of `log --format`
and `for-each-ref --format`. But for now, It seems that the parsing of
full-named atoms in `pretty.c` is not very elegant.

   if (skip_prefix(placeholder, "(describe", &arg)) {

       if (skip_prefix(placeholder, "(trailers", &arg)) {

We should have an atom table like `valid_atom` in `ref-filter.c`,
but this is missing in `pretty.c`. So how do we complete the
unification of the two types of atoms now?

2. "50cfe1f([GSOC] ref-filter: introduce enum atom_type)" has
been merged into the `next` branch, should we focus on the
performance optimization of `ref-filter.c`? Finally, we can build a
`format_cat_file_item()` similar to `format_ref_array_item()`,
which should not be difficult. And we have to make sure that the
performance of `cat-file --batch` is not lower than before.

### The connection between Git and the file system

I am currently studying operating system course, git as a
file system on top of the file system.
There are many differences and similarities with ordinary
file systems. I am very curious about this knowledge, do
not know if there are any relevant reading materials?

### Motto

I remember I saw an interview about Junio and Dan Kogai before [2]:

Dan: What do you think is a "good engineer"?

Junio: When I took over the maintainer of Git, Linus told me that star
engineers have three qualities. The most important thing is to be able
to keep doing one thing all the time. In that sense, you can't be an
alpha geek. It's sharp and you can jump to a new one right away,
but don't get bored right away.

In other words, it’s one thing to have enthusiasm, but it’s more
important to persevere.

When I read the Git source code, I can see the code written by Peff
15 years ago and the code written by Peff a few months ago, which
is very touching. It's as if you guys can travel through time and space.

So, I hope I can also persevere and fight for interest. After 15 years,
let’s take a look at the code I wrote today :)


             reply	other threads:[~2021-05-18  6:40 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-18  6:40 ZheNing Hu [this message]
2021-05-18 14:32 ` Christian Couder
2021-05-20  7:14   ` ZheNing Hu
2021-05-20  8:00     ` Christian Couder
2021-05-20  8:09       ` ZheNing Hu
2021-05-20 14:59         ` Christian Couder
2021-05-19  7:19 ` Jiang Xin
2021-05-20  7:21   ` 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:

  List information:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='' \ \ \ \ \ \ \ \ \ \

* 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.
Code repositories for project(s) associated with this inbox:

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).