path: root/Documentation/MyFirstContribution.txt

My First Contribution to the Git Project
========================================
:sectanchors:

[[summary]]
== Summary

This is a tutorial demonstrating the end-to-end workflow of creating a change to
the Git tree, sending it for review, and making changes based on comments.

[[prerequisites]]
=== Prerequisites

This tutorial assumes you're already fairly familiar with using Git to manage
source code.  The Git workflow steps will largely remain unexplained.

[[related-reading]]
=== Related Reading

This tutorial aims to summarize the following documents, but the reader may find
useful additional context:

- `Documentation/SubmittingPatches`
- `Documentation/howto/new-command.txt`

[[getting-help]]
=== Getting Help

If you get stuck, you can seek help in the following places.

==== git@vger.kernel.org

This is the main Git project mailing list where code reviews, version
announcements, design discussions, and more take place. Those interested in
contributing are welcome to post questions here. The Git list requires
plain-text-only emails and prefers inline and bottom-posting when replying to
mail; you will be CC'd in all replies to you. Optionally, you can subscribe to
the list by sending an email to majordomo@vger.kernel.org with "subscribe git"
in the body. The https://lore.kernel.org/git[archive] of this mailing list is
available to view in a browser.

==== https://groups.google.com/forum/#!forum/git-mentoring[git-mentoring@googlegroups.com]

This mailing list is targeted to new contributors and was created as a place to
post questions and receive answers outside of the public eye of the main list.
Veteran contributors who are especially interested in helping mentor newcomers
are present on the list. In order to avoid search indexers, group membership is
required to view messages; anyone can join and no approval is required.

==== https://web.libera.chat/#git-devel[#git-devel] on Libera Chat

This IRC channel is for conversations between Git contributors. If someone is
currently online and knows the answer to your question, you can receive help
in real time. Otherwise, you can read the
https://colabti.org/irclogger/irclogger_logs/git-devel[scrollback] to see
whether someone answered you. IRC does not allow offline private messaging, so
if you try to private message someone and then log out of IRC, they cannot
respond to you. It's better to ask your questions in the channel so that you
can be answered if you disconnect and so that others can learn from the
conversation.

[[getting-started]]
== Getting Started

[[cloning]]
=== Clone the Git Repository

Git is mirrored in a number of locations. Clone the repository from one of them;
https://git-scm.com/downloads suggests one of the best places to clone from is
the mirror on GitHub.

----
$ git clone https://github.com/git/git git
$ cd git
----

[[dependencies]]
=== Installing Dependencies

To build Git from source, you need to have a handful of dependencies installed
on your system. For a hint of what's needed, you can take a look at
`INSTALL`, paying close attention to the section about Git's dependencies on
external programs and libraries. That document mentions a way to "test-drive"
our freshly built Git without installing; that's the method we'll be using in
this tutorial.

Make sure that your environment has everything you need by building your brand
new clone of Git from the above step:

----
$ make
----

NOTE: The Git build is parallelizable. `-j#` is not included above but you can
use it as you prefer, here and elsewhere.

[[identify-problem]]
=== Identify Problem to Solve

////
Use + to indicate fixed-width here; couldn't get ` to work nicely with the
quotes around "Pony Saying 'Um, Hello'".
////
In this tutorial, we will add a new command, +git psuh+, short for ``Pony Saying
`Um, Hello''' - a feature which has gone unimplemented despite a high frequency
of invocation during users' typical daily workflow.

(We've seen some other effort in this space with the implementation of popular
commands such as `sl`.)

[[setup-workspace]]
=== Set Up Your Workspace

Let's start by making a development branch to work on our changes. Per
`Documentation/SubmittingPatches`, since a brand new command is a new feature,
it's fine to base your work on `master`. However, in the future for bugfixes,
etc., you should check that document and base it on the appropriate branch.

For the purposes of this document, we will base all our work on the `master`
branch of the upstream project. Create the `psuh` branch you will use for
development like so:

----
$ git checkout -b psuh origin/master
----

We'll make a number of commits here in order to demonstrate how to send a topic
with multiple patches up for review simultaneously.

[[code-it-up]]
== Code It Up!

NOTE: A reference implementation can be found at
https://github.com/nasamuffin/git/tree/psuh.

[[add-new-command]]
=== Adding a New Command

Lots of the subcommands are written as builtins, which means they are
implemented in C and compiled into the main `git` executable. Implementing the
very simple `psuh` command as a built-in will demonstrate the structure of the
codebase, the internal API, and the process of working together as a contributor
with the reviewers and maintainer to integrate this change into the system.

Built-in subcommands are typically implemented in a function named "cmd_"
followed by the name of the subcommand, in a source file named after the
subcommand and contained within `builtin/`. So it makes sense to implement your
command in `builtin/psuh.c`. Create that file, and within it, write the entry
point for your command in a function matching the style and signature:

----
int cmd_psuh(int argc, const char **argv, const char *prefix)
----

We'll also need to add the declaration of psuh; open up `builtin.h`, find the
declaration for `cmd_pull`, and add a new line for `psuh` immediately before it,
in order to keep the declarations alphabetically sorted:

----
int cmd_psuh(int argc, const char **argv, const char *prefix);
----

Be sure to `#include "builtin.h"` in your `psuh.c`.

Go ahead and add some throwaway printf to that function. This is a decent
starting point as we can now add build rules and register the command.

NOTE: Your throwaway text, as well as much of the text you will be adding over
the course of this tutorial, is user-facing. That means it needs to be
localizable. Take a look at `po/README` under "Marking strings for translation".
Throughout the tutorial, we will mark strings for translation as necessary; you
should also do so when writing your user-facing commands in the future.

----
int cmd_psuh(int argc, const char **argv, const char *prefix)
{
	printf(_("Pony saying hello goes here.\n"));
	return 0;
}
----

Let's try to build it.  Open `Makefile`, find where `builtin/pull.o` is added
to `BUILTIN_OBJS`, and add `builtin/psuh.o` in the same way next to it in
alphabetical order. Once you've done so, move to the top-level directory and
build simply with `make`. Also add the `DEVELOPER=1` variable to turn on
some additional warnings:

----
$ echo DEVELOPER=1 >config.mak
$ make
----

NOTE: When you are developing the Git project, it's preferred that you use the
`DEVELOPER` flag; if there's some reason it doesn't work for you, you can turn
it off, but it's a good idea to mention the problem to the mailing list.

Great, now your new command builds happily on its own. But nobody invokes it.
Let's change that.

The list of commands lives in `git.c`. We can register a new command by adding
a `cmd_struct` to the `commands[]` array. `struct cmd_struct` takes a string
with the command name, a function pointer to the command implementation, and a
setup option flag. For now, let's keep mimicking `push`. Find the line where
`cmd_push` is registered, copy it, and modify it for `cmd_psuh`, placing the new
line in alphabetical order (immediately before `cmd_pull`).

The options are documented in `builtin.h` under "Adding a new built-in." Since
we hope to print some data about the user's current workspace context later,
we need a Git directory, so choose `RUN_SETUP` as your only option.

Go ahead and build again. You should see a clean build, so let's kick the tires
and see if it works. There's a binary you can use to test with in the
`bin-wrappers` directory.

----
$ ./bin-wrappers/git psuh
----

C