A Question from a Hopeful Future Contributor

A Question from a Hopeful Future Contributor

[Eric Frederickson]

Hello everyone,

I hope that this message finds you well! I'm a software developer and passionate
git user, and I'd like to try my hand at contributing to the project. I'm
sending this message in order to ask Junio and the team if there's anything that
would be particularly useful / appropriate for me to start looking into on that
front. (Reading through the last few "What's cooking" messages, I didn't see
anything that jumped out at me as needing a new contributor, which is why I'm
asking in a separate message instead of replying to one of those.)

(Some notes on my skills: working on docs or tests is always a favorite for me,
so things in those areas would be a great time. Also comfortable with low-level
code, and any kind of scripting. Note too that academic background centers
around programming language design and parsing related stuff, so I've got some
fluency in those areas that I could hopefully apply well to the project if ever
needed.)

Looking through the repo for a place to find todo items, I naturally stumbled
upon the TODO file in the origin/todo branch, and saw an item in there which
seemed like it could be a good place to start:

> * "git status" on intent-to-add index entries (say "I" in the first
>   column instead of "A" for short status, add "(needs 'git add')" at the
>   end of "new file: $path " in long status).

I am interpreting this todo message as meaning that the following behavior
should be implemented:

Given the initial conditions created by the following setup commands:

---
mkdir EXAMPLE
cd EXAMPLE

git init

touch a.txt b.txt c.txt

git add a.txt
git add --intent-to-add b.txt

# Leave c.txt untracked so that it shows up for reference in the git-status
# outputs below.
---

The goal of the todo item is to have the short git-status message change from
this:

---
A  a.txt
 A b.txt
?? c.txt
---

to this:

---
A  a.txt
 I b.txt
?? c.txt
---

and to have the long git-status message change from this:

---
On branch master

No commits yet

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)
	new file:   a.txt

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
	new file:   b.txt

Untracked files:
  (use "git add <file>..." to include in what will be committed)
	c.txt
---

to this:

---
On branch master

No commits yet

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)
	new file:   a.txt

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
	new file:   b.txt (needs 'git add')

Untracked files:
  (use "git add <file>..." to include in what will be committed)
	c.txt
---

Let me know if this would be a good change to pursue. Also open to trying
anything else that's needed!

Thank you for your time,
--
Eric Frederickson
ericfrederickson68@gmail.com
https://emfred.com

Re: A Question from a Hopeful Future Contributor

[Junio C Hamano]

Eric Frederickson <ericfrederickson68@gmail.com> writes:

> Looking through the repo for a place to find todo items, I naturally stumbled
> upon the TODO file in the origin/todo branch,...

Please disregard that file (I should remove it from the repository,
too).  It is not curated at all, and the last update to it is more
than 13 years ago.

>> * "git status" on intent-to-add index entries (say "I" in the first
>>   column instead of "A" for short status, add "(needs 'git add')" at the
>>   end of "new file: $path " in long status).
>
> I am interpreting this todo message as meaning that the following behavior
> should be implemented:

I think that was done long time ago.  The entry may have been a wish-item
in April 2011, but not anymore.

Sorry for wasting your time.  A better sources of inspiration might
come from list archive searches for the past 3 year or so.

https://lore.kernel.org/git/?q=%22%23leftoverbit%22+d%3A20220718..

But even then, many itches have already been scratched.

As is often said, in open source, the easiest is to start scratching
your own itch ;-)

Thanks.

Re: A Question from a Hopeful Future Contributor

[Eric Frederickson]

Junio C Hamano <gitster@pobox.com> writes:

> Eric Frederickson <ericfrederickson68@gmail.com> writes:
>
>> Looking through the repo for a place to find todo items, I naturally stumbled
>> upon the TODO file in the origin/todo branch,...
>
> Please disregard that file (I should remove it from the repository,
> too).  It is not curated at all, and the last update to it is more
> than 13 years ago.

I see -- sorry for the noise on that.

(Funnily enough, I had checked blame of those lines to (try to) make sure that
they were at least semi-recent, and took a glance at the commit that shipped
them, which I saw was dated from April. Somehow, I had assumed that "April"
meant "April of this year" and forgot to check the actual year... it was, as
you're indicating, from April 2011. (*facepalm*))

> Sorry for wasting your time.

The mistake was all mine. Lesson learned!

> A better sources of inspiration might
> come from list archive searches for the past 3 year or so.
>
> https://lore.kernel.org/git/?q=%22%23leftoverbit%22+d%3A20220718..
>
> But even then, many itches have already been scratched.

I've been enjoying looking through these "leftoverbits", and may take some up
soon.

> As is often said, in open source, the easiest is to start scratching
> your own itch ;-)

Indeed! And I have 2 things to bring up on that subject, which are also in reply to
Ayush's suggestions about trying out a micro-project:

Firstly, I was reading through git-bisect.adoc (on master, 90c0775e97) and
noticed a small error on line 146 (the entire paragraph, lines 146-148, is given
for context):

> To use "old" and "new" instead of "good" and bad, you must run `git
> bisect start` without commits as argument and then run the following
> commands to add the commits:

It seems that the word "bad" should be quoted there, resulting in this revised
version:

> To use "old" and "new" instead of "good" and "bad", you must run `git
> bisect start` without commits as argument and then run the following
> commands to add the commits:

Writing here to ask if a tiny fix like this would be a good thing to submit as a
first patch. (This feels like it would be an embarrassingly small patch, but you
have said prior [1] that "it is rare that anything is too trivial as a
microproject material", so perhaps I'm in-bounds here :)).

Secondly, and more substantially, there's an itch I'm thinking about trying to
scratch, which involves teaching git-diff some options which can enable it to
give more useful outputs when diffing binary files, and, moreover, to diff them
"natively" without converting them to line-oriented plaintext first (as that
behavior is already covered by use of the "textconv" config option).

I'm imagining a way for users to pass some information to git-diff which
specifies a concept of "logical lines", similar in concept to the "--word-diff"
option, but where what's parsed as a "word" / "line" / delimiter can be
specified by the user. A feature like this could enable users to have git do
things like diff an image file pixel by pixel, or diff an audio file second by
second ("second" meaning "1 real-time second in playback"), all without doing
any batch conversions. (Note that I'm not intending to denigrate the very useful
"textconv" option and its associated workflow; just proposing another way of
trying to work towards a similar ideal.)

This itch comes from my use of git repositories to manage audio files that I
publish on my website, and being unsatisfied with the "Binary files differ"
message while also not having anything available as a "textconv" worker program.
I feel like there's a lot of "potential energy" in these kinds of use-cases for
git to provide ways of (re)viewing changes to these files to users who work with
updating binary data.

Writing here to ask if pursuing this line of thought would be a good idea. I've
intentionally been light on concrete detail here, because I'm still working
things out myself and don't want to waste anyone's time with details that aren't
worth reading through. Something as simple as a "Yay" or "Nay" on this idea is
all I'd need to know if I'm walking a useful path here.

Thank you, and best wishes,
--
Eric Frederickson
ericfrederickson68@gmail.com
https://emfred.com

Re: A Question from a Hopeful Future Contributor

[D. Ben Knoble]

On Fri, Jul 18, 2025 at 7:16 PM Junio C Hamano <gitster@pobox.com> wrote:
>
> Eric Frederickson <ericfrederickson68@gmail.com> writes:
>
> > Looking through the repo for a place to find todo items, I naturally stumbled
> > upon the TODO file in the origin/todo branch,...
>
> Please disregard that file (I should remove it from the repository,
> too).  It is not curated at all, and the last update to it is more
> than 13 years ago.
>
> >> * "git status" on intent-to-add index entries (say "I" in the first
> >>   column instead of "A" for short status, add "(needs 'git add')" at the
> >>   end of "new file: $path " in long status).
> >
> > I am interpreting this todo message as meaning that the following behavior
> > should be implemented:
>
> I think that was done long time ago.  The entry may have been a wish-item
> in April 2011, but not anymore.

At least in 2.48.1 and in git version 2.50.0.rc0.48.g74dbe4346c, this
behavior isn't present. So I wouldn't call it "done"—maybe there was a
discussion that it shouldn't be done, though? I didn't search the
list.

>
> Sorry for wasting your time.  A better sources of inspiration might
> come from list archive searches for the past 3 year or so.
>
> https://lore.kernel.org/git/?q=%22%23leftoverbit%22+d%3A20220718..
>
> But even then, many itches have already been scratched.
>
> As is often said, in open source, the easiest is to start scratching
> your own itch ;-)
>
> Thanks.
>


-- 
D. Ben Knoble

Re: A Question from a Hopeful Future Contributor

[Junio C Hamano]

"D. Ben Knoble" <ben.knoble@gmail.com> writes:

>> >> * "git status" on intent-to-add index entries (say "I" in the first
>> >>   column instead of "A" for short status, add "(needs 'git add')" at the
>> >>   end of "new file: $path " in long status).
>> >
>> > I am interpreting this todo message as meaning that the following behavior
>> > should be implemented:
>>
>> I think that was done long time ago.  The entry may have been a wish-item
>> in April 2011, but not anymore.
>
> At least in 2.48.1 and in git version 2.50.0.rc0.48.g74dbe4346c, this
> behavior isn't present. So I wouldn't call it "done"—maybe there was a
> discussion that it shouldn't be done, though? I didn't search the
> list.

I didn't either, so this response may not be adding much value, but
I think the intent of the above entry is so that the output allows
users to tell between already added entries and about to be added
entries.  Perhaps in an ancient version of "git status" did not give
enough information to allow us to tell the status of the index entry
for the path and the status of the working tree file for the path
separately, or something?

In any case, we do not need to add anything to achieve that today.

    $ >P
    $ cp P Q
    $ git add -N P
    $ git add Q

The user expresses an intent to add P and actually adds Q.

    $ git status -suno
     A P
    A  Q

The first column of the output is about how the path in the index
compares with the HEAD, and the second column is about how working
tree file compares with the index.  A file that hasn't been added
(e.g., untracked cruft) is not even known to the index so the latter
is _usually_ only for tracked files.  The fact that P appears as
"_A" is a sign enough that its contents haven't been added to the
index, but only that the index has been made aware of the presence
of the path, which is exactly what intent-to-add is about.

If you further add P, this time for real, the status would become
"A_" (i.e. to the index, new contents added relative to HEAD; to the
working tree there is no change relative to the index), but the
intent-to-add bit is gone once the index has (a version of) contents
for the path P.

Normal output without "-s" is even easier to reason about.

    $ git status -uno
    On branch foo
    Changes to be committed:
      (use "git restore --staged <file>..." to unstage)
            new file:   Q

    Changes not staged for commit:
      (use "git add <file>..." to update what will be committed)
      (use "git restore <file>..." to discard changes in working directory)
            new file:   P

P is _known_ to the system but its contents is not added at all, so
it is "not staged for commit", and known as a "new" file.

Re: A Question from a Hopeful Future Contributor

[D. Ben Knoble]

On Mon, Jul 28, 2025 at 11:02 AM Junio C Hamano <gitster@pobox.com> wrote:
>
> "D. Ben Knoble" <ben.knoble@gmail.com> writes:
>
> >> >> * "git status" on intent-to-add index entries (say "I" in the first
> >> >>   column instead of "A" for short status, add "(needs 'git add')" at the
> >> >>   end of "new file: $path " in long status).
> >> >
> >> > I am interpreting this todo message as meaning that the following behavior
> >> > should be implemented:
> >>
> >> I think that was done long time ago.  The entry may have been a wish-item
> >> in April 2011, but not anymore.
> >
> > At least in 2.48.1 and in git version 2.50.0.rc0.48.g74dbe4346c, this
> > behavior isn't present. So I wouldn't call it "done"—maybe there was a
> > discussion that it shouldn't be done, though? I didn't search the
> > list.
>
> I didn't either, so this response may not be adding much value, but
> I think the intent of the above entry is so that the output allows
> users to tell between already added entries and about to be added
> entries.  Perhaps in an ancient version of "git status" did not give
> enough information to allow us to tell the status of the index entry
> for the path and the status of the working tree file for the path
> separately, or something?
>
> In any case, we do not need to add anything to achieve that today.

[snip examples

All fair points, and matches with what I see—I was expecting to find
something more explicit about intent in the output based on the todo
item ("_I" vs "_A"; "(needs 'git add')" or better verbiage), but
you're right that the existing output does indicate the state (if
indirectly).

-- 
D. Ben Knoble

Re: A Question from a Hopeful Future Contributor

[Ayush Chandekar]

Hi Eric,

On Sat, Jul 19, 2025 at 3:58 AM Eric Frederickson
<ericfrederickson68@gmail.com> wrote:
>
> Hello everyone,
>
> I hope that this message finds you well! I'm a software developer and passionate
> git user, and I'd like to try my hand at contributing to the project. I'm
> sending this message in order to ask Junio and the team if there's anything that
> would be particularly useful / appropriate for me to start looking into on that
> front. (Reading through the last few "What's cooking" messages, I didn't see
> anything that jumped out at me as needing a new contributor, which is why I'm
> asking in a separate message instead of replying to one of those.)
>

Welcome!

It's nice to see you excited about contributing to Git. To clear
things up, there isn't any team defined as such for Git, however ,
there are people working on it as volunteers or are employed by a
company (eg: GitHub, GitLab, etc) to work on Git.

If you want to know more about Git development and contribution
process, you can check it out here: [1]

> (Some notes on my skills: working on docs or tests is always a favorite for me,
> so things in those areas would be a great time. Also comfortable with low-level
> code, and any kind of scripting. Note too that academic background centers
> around programming language design and parsing related stuff, so I've got some
> fluency in those areas that I could hopefully apply well to the project if ever
> needed.)
>

Git has something called as a 'microproject'[2], which is a small and
a relatively simple patch meant to help new contributors get familiar
with the project. While microprojects are often done by students
applying for mentorship programs, they're a great way to get your
hands on Git development. They help you understand the codebase, and
the development and contribution workflow.

And as you mentioned that you like working on documentation or tests,
you'll find that most of the microproject ideas are based on these.

That said, you're more than encouraged to scratch your own itch as Junio said.

Thanks,
Ayush:)

[1]: https://git.github.io/Hacking-Git/
[2]: https://git.github.io/General-Microproject-Information/

Re: A Question from a Hopeful Future Contributor

[Lucas Seiki Oshiro]

> Hello everyone,
> 
> I hope that this message finds you well! I'm a software developer and passionate
> git user, and I'd like to try my hand at contributing to the project.

Hi!

The suggestions from Ayush are really helpful. In the last few months I helped
some people (a friend and some students from my university) to join the Git
community and to send their first patches.

I would start with the microproject. Some of them are really easy, but you'll
get familiar with the contribution process (i.e. sending patches, code
conventions, commit conventions, etc).

After that, follow the tutorials for creating a new command (MyFirstContribution,
MyFirstObjectWalk). Perhaps you'll find something outdated in them and that's 
another good opportunity to send another patch!

Another good reference is "First steps contributing to Git" [1]. It covers
everything that you need to know and to do to get started.

If you aren't familiar with the core concepts of Git (objects, index, references,
etc), read the chapter "Git Internals" from Pro Git [2].

I hope it helps you!

[1] https://matheustavares.dev/posts/first-steps-contributing-to-git
[2] https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Porcelain

Re: A Question from a Hopeful Future Contributor

[Eric Frederickson]

Lucas Seiki Oshiro <lucasseikioshiro@gmail.com> writes:

>> Hello everyone,
>> 
>> I hope that this message finds you well! I'm a software developer and passionate
>> git user, and I'd like to try my hand at contributing to the project.
>
> Hi!
>
> The suggestions from Ayush are really helpful.

Agreed! [1]

> In the last few months I helped some people (a friend and some students from
> my university) to join the Git community and to send their first patches.
>
> I would start with the microproject. Some of them are really easy, but you'll
> get familiar with the contribution process (i.e. sending patches, code
> conventions, commit conventions, etc).

Will do. And I think I've got one in mind :).

> After that, follow the tutorials for creating a new command (MyFirstContribution,
> MyFirstObjectWalk). Perhaps you'll find something outdated in them and that's 
> another good opportunity to send another patch!

Noted!

> Another good reference is "First steps contributing to Git" [1]. It covers
> everything that you need to know and to do to get started.
>
> If you aren't familiar with the core concepts of Git (objects, index, references,
> etc), read the chapter "Git Internals" from Pro Git [2].

Both of the resources you linked here are much appreciated.

> I hope it helps you!

Very much so!

> [1] https://matheustavares.dev/posts/first-steps-contributing-to-git
> [2] https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Porcelain

Thanks again, and best wishes,
--
Eric Frederickson
ericfrederickson68@gmail.com
https://emfred.com

[1] (I sent him a reply giving my thanks (but forgot to Cc the mailing list...))

Re: A Question from a Hopeful Future Contributor

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 2670 bytes --]

On 2025-07-18 at 22:26:31, Eric Frederickson wrote:
> Hello everyone,

Hi,

> I hope that this message finds you well! I'm a software developer and passionate
> git user, and I'd like to try my hand at contributing to the project. I'm
> sending this message in order to ask Junio and the team if there's anything that
> would be particularly useful / appropriate for me to start looking into on that
> front. (Reading through the last few "What's cooking" messages, I didn't see
> anything that jumped out at me as needing a new contributor, which is why I'm
> asking in a separate message instead of replying to one of those.)

It's great to hear that you want to contribute.

> (Some notes on my skills: working on docs or tests is always a favorite for me,
> so things in those areas would be a great time. Also comfortable with low-level
> code, and any kind of scripting. Note too that academic background centers
> around programming language design and parsing related stuff, so I've got some
> fluency in those areas that I could hopefully apply well to the project if ever
> needed.)

We have a Git FAQ because I answered questions on Stack Overflow and got
tired of answering the same question again and again, so if you want to
add any common problems there, that's of course welcome.  (Now, to be
clear, people did not stop asking those questions, but I had prepared
text and a link to provide to them, and then people _knew_ that we had a
FAQ and could refer to it.)  If there's anything that you think is
poorly documented and colleagues or people online have trouble with, we
would absolutely love for that documentation to be improved.

One thing I did to get started some years ago is to grep through the
codebase for TODO statements and to pick something that seemed simple
enough to do, and then send a patch.

If there are small functions that you think would benefit from unit
tests, we now have the framework for that that we lacked until recently.

If you see things in the tests marked test_expect_failure, then that
means that's a TODO test: it should pass, but it presently does not, and
that can sometimes be a source of good things to work on.  Some of those
things are kind of big (especially a lot of the submodule TODOs), but
sometimes they're small and approachable.

Hopefully one of these options bears fruit for you, and please don't get
discouraged if you wander into something that ends up being very
complicated at first.  We have lots of those in our codebase and with
time, you'll also feel more confident in tackling those.
-- 
brian m. carlson (they/them)
Toronto, Ontario, CA

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: A Question from a Hopeful Future Contributor

[Eric Frederickson]

"brian m. carlson" <sandals@crustytoothpaste.net> writes:

> On 2025-07-18 at 22:26:31, Eric Frederickson wrote:
>> Hello everyone,
>
> Hi,
>
>> I hope that this message finds you well! I'm a software developer and passionate
>> git user, and I'd like to try my hand at contributing to the project. I'm
>> sending this message in order to ask Junio and the team if there's anything that
>> would be particularly useful / appropriate for me to start looking into on that
>> front. (Reading through the last few "What's cooking" messages, I didn't see
>> anything that jumped out at me as needing a new contributor, which is why I'm
>> asking in a separate message instead of replying to one of those.)
>
> It's great to hear that you want to contribute.

Thank you for your welcoming response :). Excited for the journey!

>> (Some notes on my skills: working on docs or tests is always a favorite for me,
>> so things in those areas would be a great time. Also comfortable with low-level
>> code, and any kind of scripting. Note too that academic background centers
>> around programming language design and parsing related stuff, so I've got some
>> fluency in those areas that I could hopefully apply well to the project if ever
>> needed.)
>
> We have a Git FAQ because I answered questions on Stack Overflow and got
> tired of answering the same question again and again, so if you want to
> add any common problems there, that's of course welcome.

Noted.

> (Now, to be clear, people did not stop asking those questions, but I had
> prepared text and a link to provide to them, and then people _knew_ that we
> had a FAQ and could refer to it.) If there's anything that you think is poorly
> documented and colleagues or people online have trouble with, we would
> absolutely love for that documentation to be improved.

Sounds good. Would love to submit some patches to this effect at some point.

> One thing I did to get started some years ago is to grep through the
> codebase for TODO statements and to pick something that seemed simple
> enough to do, and then send a patch.
>
> If there are small functions that you think would benefit from unit
> tests, we now have the framework for that that we lacked until recently.
>
> If you see things in the tests marked test_expect_failure, then that
> means that's a TODO test: it should pass, but it presently does not, and
> that can sometimes be a source of good things to work on.  Some of those
> things are kind of big (especially a lot of the submodule TODOs), but
> sometimes they're small and approachable.

This was very helpful to learn!

I've been looking through them, and have found a pair that's drawn my eye: the
pair of known breakages in:

t3903-stash, tests 52 and 53
  ("stash directory to file" and "stash file to directory").

From some introductory exploration, it seems that that bug in git-stash that's
causing those breakages could also be causing the breakages in:

t2500-untracked-overwriting, tests 7 and 8
  ("git rebase --autostash and untracked files" and
   "git stash and untracked files")

So, a fix for the t3903 failures might net us a 4-for-2 deal. I've been looking
through the "git stash apply" source code and I think I've at least got a lead
on this. Will continue investigating, and hopefully I'll eventually end up with
a patch to send!

> Hopefully one of these options bears fruit for you, and please don't get
> discouraged if you wander into something that ends up being very
> complicated at first.

Got it. Hopefully the one I'm choosing here is one of the lucky picks. :)

> We have lots of those in our codebase and with time, you'll also feel more
> confident in tackling those.

Looking forward to it.

Thanks very much for your help, and best wishes,
--
Eric Frederickson
ericfrederickson68@gmail.com
https://emfred.com