Re: [PATCH 1/2] Documentation: 'git add --all' can remove files

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Björn Gustavsson <bgustavsson@xxxxxxxxx> writes:

> diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt
> index e93e606..b7e8aa2 100644
> --- a/Documentation/git-add.txt
> +++ b/Documentation/git-add.txt
> @@ -16,6 +16,8 @@ DESCRIPTION
>  -----------
>  This command adds the current content of new or modified files to the
>  index, thus staging that content for inclusion in the next commit.
> +(Given the `--all` option, the `git add` command will also remove files
> +from the index that are no longer present in the working tree.)

The first paragraph says what "git add" does in general (does "something"
to the index) and continues to the second paragraph that describes what an
index is.

It is a good point that you noticed that the existing description of 'does
"something" to the index' covers only the "add as an entirety" and not the
whole range of what "git add" can be used for.  One thing that is missing
is a removal, and "-A" is one of the two options that lets you do so.

But "-u" is to match the index with the work tree contents (it does not
add untracked-so-far paths).  At least, "Given the `--all` option," part
needs to be rethought.

More importantly, 'does "something" to the index' is not limited to the
"add whole" and "remove path".  Perhaps we would want to update the first
paragraph like this to cover partial add while we are at it.

	This command updates the index using the current content found in
        the work tree, to prepare the content staged for the next commit.
        It typically adds the current content of existing paths as a whole
        but with some options, it can also be used to add a content with
        only part of the changes made to the work tree files applied, or
        remove paths that do not exist in the work tree anymore.

That way we also cover what "add -p" lets you do.

> ++
> +This option is especially useful after running the `rsync` command with
> +the working tree as the target to sync the index with the working tree.

I do not think mentioning `rsync` like this is helpful; I actually think
this clutteres the document and nudges people in a wrong direction at the
same time.  You usually don't overwrite your source tree you already have
under control with rsync.  Use cases that do not use "git" as a SCM but as
something else do have a valid reason to use rsync, but "git add -A" being
useful for that use case is a side effect, and I do not think we should
hint people who use "git" as a SCM into that direction, by casually
mentioning the use of `rsync` like the above as if it is a common and
encouraged thing to update your work tree from sideways.

> diff --git a/Documentation/git-rm.txt b/Documentation/git-rm.txt
> index 5afb1e7..b4dff5b 100644
> --- a/Documentation/git-rm.txt
> +++ b/Documentation/git-rm.txt
> @@ -81,6 +81,10 @@ two directories `d` and `d2`, there is a difference between
>  using `git rm \'d\*\'` and `git rm \'d/\*\'`, as the former will
>  also remove all of directory `d2`.
>  
> +To automatically remove all files from the index that are no longer
> +present in the working tree, see the `--all` option for
> +linkgit:git-add[1].

I think this change is a lot more harmful than being helpful.  Many lazy
readers would _not_ read "git add --help" but would think "git add -A"
would "automatically remove all files from the index that are no longer
present".  But "add -A" does a lot more than:

    git diff --name-only --diff-filter=D -z | xargs -0 rm -f

So overall I am happy with the issue you identified, but not very happy
with the proposed solution.

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]