All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Jean-Noël AVILA" <jn.avila@free.fr>
To: Julia Evans via GitGitGadget <gitgitgadget@gmail.com>,
	Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, Chris Torek <chris.torek@gmail.com>,
	"D. Ben Knoble" <ben.knoble@gmail.com>,
	Julia Evans <julia@jvns.ca>
Subject: Re: [PATCH v2 1/4] doc: git-add: start man page with an example
Date: Fri, 15 Aug 2025 15:34:41 +0200	[thread overview]
Message-ID: <5004213.GXAFRqVoOG@cayenne> (raw)
In-Reply-To: <xmqqikipv2p6.fsf@gitster.g>

On Friday, 15 August 2025 02:38:45 CEST Junio C Hamano wrote:
> "Julia Evans via GitGitGadget" <gitgitgadget@gmail.com> writes:
> > -git-add - Add file contents to the index
> > +git-add - Add new or changed files to the index
> 
> Does it add much value to say "new or changed" here?  The command can
> also be used to "stage" a removal of a path, e.g.
> 
>     $ rm tracked-file
>     $ git add -u
> 
> so if the updated text is an attempt to give more details on what
> kind of modifications are captured, it would be better to say "add
> new, removed, or modified files".
> 

The way I see it is that git add *captures* a part of the current state of the 
working tree (be it addition/removal of contents of files or subtrees of the 
working dir) for the next commit. A commit *is* a snapshot of the state of the 
project. The concept of snapshot is central to understanding the behavior of 
git and its internals.

> > +Add new or changed files to the index to prepare for a commit. The
> > +"index" (also known as "staging area") is where Git stores the changes
> > +that will be in the next commit.
> 
> I won't repeat myself about change-snapshot duality, but I do not
> think the new text is the best we can do.
> 
>     Update contents recorded in the index to prepare for the next
>     commit.  The index (also known as "staging area") is where Git
>     stores the contents that will be in the next commit.

Particularly, the "stores the changes that..." part is really not what the 
reader should remember.

> 
> > +By default, `git commit` only commits changes that you've added to the
> > +index.

I do not understand this addition. I may not be missing knowledge, but this 
behavior is not only "by default", it's the only behavior of git: commits are 
made with the content of the index. Let's not make it more complicated than it 
is already.

> > For example, if you've edited `file.c` and want to commit your
> 
> > +changes, you can run:
> Likewise.  "and want to record the resulting contents".
> 
> > ...
> > -Please see linkgit:git-commit[1] for alternative ways to add content to a
> > -commit.
> 
> In the original, this comment does look a bit out of place (as the
> text around there does not talk about `git commit`), but as you said
> that by default 'git commit' makes an as-is commit above, it may be
> a good idea to move this sentence there.  `git commit <pathspec>` is
> a handy thing to know even for beginners, and making your next commit
> is what the user is working towards by using "git add".





  reply	other threads:[~2025-08-15 13:34 UTC|newest]

Thread overview: 59+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-12 20:07 [PATCH 0/5] doc: git-add: clarify DESCRIPTION section Julia Evans via GitGitGadget
2025-08-12 20:07 ` [PATCH 1/5] doc: git-add: remove options from SYNOPSIS Julia Evans via GitGitGadget
2025-08-12 20:41   ` Junio C Hamano
2025-08-13 16:58     ` Julia Evans
2025-08-13 20:47   ` Jean-Noël AVILA
2025-08-12 20:07 ` [PATCH 2/5] doc: git-add: start man page with an example Julia Evans via GitGitGadget
2025-08-12 21:01   ` Junio C Hamano
2025-08-12 21:40     ` Julia Evans
2025-08-12 22:12       ` Junio C Hamano
2025-08-12 22:45         ` Julia Evans
2025-08-13 17:22       ` D. Ben Knoble
2025-08-14  0:41       ` Junio C Hamano
2025-08-14  2:59         ` Julia Evans
2025-08-15  5:38           ` Junio C Hamano
2025-08-12 20:07 ` [PATCH 3/5] doc: git-add: simplify discussion of ignored files Julia Evans via GitGitGadget
2025-08-13 17:24   ` D. Ben Knoble
2025-08-12 20:07 ` [PATCH 4/5] doc: git-add: make explanation less dry Julia Evans via GitGitGadget
2025-08-12 20:07 ` [PATCH 5/5] doc: git-add: explain inconsistent terminology Julia Evans via GitGitGadget
2025-08-12 20:51   ` Chris Torek
2025-08-12 21:36     ` Junio C Hamano
2025-08-12 21:43       ` Julia Evans
2025-08-13 23:20 ` [PATCH v2 0/4] doc: git-add: clarify DESCRIPTION section Julia Evans via GitGitGadget
2025-08-13 23:20   ` [PATCH v2 1/4] doc: git-add: start man page with an example Julia Evans via GitGitGadget
2025-08-15  0:38     ` Junio C Hamano
2025-08-15 13:34       ` Jean-Noël AVILA [this message]
2025-08-15 16:33         ` Junio C Hamano
2025-08-17 18:37           ` Jean-Noël AVILA
2025-08-19 20:01             ` Julia Evans
2025-08-13 23:20   ` [PATCH v2 2/4] doc: git-add: simplify discussion of ignored files Julia Evans via GitGitGadget
2025-08-14  0:59     ` D. Ben Knoble
2025-08-14 22:10     ` Junio C Hamano
2025-08-13 23:20   ` [PATCH v2 3/4] doc: git-add: make explanation less dry Julia Evans via GitGitGadget
2025-08-14 22:22     ` Junio C Hamano
2025-08-15 16:10       ` Julia Evans
2025-08-15 18:25         ` D. Ben Knoble
2025-08-15 20:01           ` Junio C Hamano
2025-08-16 14:15             ` D. Ben Knoble
2025-08-15 19:47         ` Junio C Hamano
2025-08-19 12:57           ` Julia Evans
2025-08-21 20:36             ` Jean-Noël AVILA
2025-08-13 23:20   ` [PATCH v2 4/4] doc: git-add: explain inconsistent terminology Julia Evans via GitGitGadget
2025-08-14 22:49     ` Junio C Hamano
2025-08-19 20:09       ` Julia Evans
2025-08-19 20:46   ` [PATCH v3 0/3] doc: git-add: clarify DESCRIPTION section Julia Evans via GitGitGadget
2025-08-19 20:46     ` [PATCH v3 1/3] Git 2.51 Junio C Hamano via GitGitGadget
2025-08-19 21:06       ` rsbecker
2025-08-19 21:37         ` Junio C Hamano
2025-08-19 21:44           ` D. Ben Knoble
2025-08-19 21:48             ` Julia Evans
2025-08-19 21:49           ` rsbecker
2025-08-19 20:46     ` [PATCH v3 2/3] doc: git-add: clarify intro & add an example Julia Evans via GitGitGadget
2025-08-21 20:08       ` Junio C Hamano
2025-08-22 20:37         ` Julia Evans
2025-08-19 20:46     ` [PATCH v3 3/3] doc: git-add: simplify discussion of ignored files Julia Evans via GitGitGadget
2025-08-21 20:09       ` Junio C Hamano
2025-08-29 11:55     ` [PATCH v4 0/2] doc: git-add: clarify DESCRIPTION section Julia Evans via GitGitGadget
2025-08-29 11:55       ` [PATCH v4 1/2] doc: git-add: clarify intro & add an example Julia Evans via GitGitGadget
2025-08-29 11:55       ` [PATCH v4 2/2] doc: git-add: simplify discussion of ignored files Julia Evans via GitGitGadget
2025-08-29 17:11       ` [PATCH v4 0/2] doc: git-add: clarify DESCRIPTION section Junio C Hamano

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=5004213.GXAFRqVoOG@cayenne \
    --to=jn.avila@free.fr \
    --cc=ben.knoble@gmail.com \
    --cc=chris.torek@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=gitster@pobox.com \
    --cc=julia@jvns.ca \
    /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.