CODEWITHSUNDEEP
git
Abram
Abram

Reputation: 41884

Shortcut for git add --ignore-removal?

I have been typing git add . for years before commiting changes. From what I understand (from the message below) the modern equivalent would be git add --ignore-removal <pathspec> which is slightly more verbose. Is there a way to revert to the old behavior in the upcoming version 2.0 of git or at least silence this message in the current version?

$ git add .
warning: You ran 'git add' with neither '-A (--all)' or '--ignore-removal',
whose behaviour will change in Git 2.0 with respect to paths you removed.
Paths like 'log/sunspot-solr-development.log.lck' that are
removed from your working tree are ignored with this version of Git.

* 'git add --ignore-removal <pathspec>', which is the current default,
  ignores paths you removed from your working tree.

* 'git add --all <pathspec>' will let you also record the removals.

Run 'git status' to check the paths you removed from your working tree.

Upvotes: 7

Views: 4902

Answers (1)

VonC
VonC

Reputation: 1324278

The warning you see is from commit ccc663b, which refines commit 45c45e3.

That second commit does mention:

git add: start preparing for "git add <pathspec>..." to default to "-A"

Plan to eventually make "git add" pretend as if "-A" is given when there is a pathspec on the command line.

For that transition to work, people need to learn either to say "git add --no-all subdir/" when they want to ignore the removed paths like "subdir/z", or to say "git add -A subdir/" when they want to take the state of the directory as a whole.

"git add" without any argument will continue to be a no-op.

So the modern equivalent of git add . would actually be git add -A .: see "How to make Git “add --all” by default?".

Meltemi comments

I'm not even sure what that means? Anyone know why they've made this change?

The commit I mentioned above illustrates the --ignore-removal option:

When "git add subdir/" is run without "-u" or "-A" option, e.g.

$ edit subdir/x
$ create subdir/y
$ rm subdir/z
$ git add subdir/

the command does not notice removal of paths (e.g. subdir/z) from the working tree.
This sometimes confuses new people, as arguably "git add" is told to record the current state of "subdir/" as a whole, not the current state of the paths that exist in the working tree that matches that pathspec (the latter by definition excludes the state of "subdir/z" because it does not exist in the working tree).

Upvotes: 5

Related Questions