This adds "--intent-to-add" option to "git add".  This is to let the
system know that you will tell it the final contents to be staged later,
iow, just be aware of the presense of the path with the type of the blob
for now.  It is implemented by staging an empty blob as the content.

With this sequence:

    $ git reset --hard
    $ edit newfile
    $ git add -N newfile
    $ edit newfile oldfile
    $ git diff

the diff will show all changes relative to the current commit.  Then you
can do:

    $ git commit -a ;# commit everything

or

    $ git commit oldfile ;# only oldfile, newfile not yet added

to pretend you are working with an index-free system like CVS.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

This is the same fix for the issue of adding "sym/path" when "sym" is a
symblic link that points at a directory "dir" with "path" in it.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The earlier "git add -A" change was done in a quite inefficient
way (i.e. it is as unefficient as "git add -u && git add ." modulo
one fork/exec and read/write index).

When the user asks "git add .", we do not have to examine all paths
we encounter and perform the excluded() and dir_add_name()
processing, both of which are slower code and use slower data structure
by git standards, especially when the index is already populated.

Instead, we implement "git add $pathspec..." as:

 - read the index;

 - read_directory() to process untracked, unignored files the current
   way, that is, recursively doing readdir(), filtering them by pathspec
   and excluded(), queueing them via dir_add_name() and finally do
   add_files(); and

 - iterate over the index, filtering them by pathspec, and update only
   the modified/type changed paths but not deleted ones.

And "git add -A" becomes exactly the same as above, modulo:

 - missing $pathspec means "." instead of being an error; and

 - "iterate over the index" part handles deleted ones as well,
   i.e. exactly what the current update_callback() in builtin-add.c does.

In either case, because fill_directory() does not use read_directory() to
read everything in, we need to add an extra logic to iterate over the
index to catch mistyped pathspec.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

A private function add_files_to_cache() in builtin-add.c was borrowed by
checkout and commit re-implementors without getting properly refactored to
more library-ish place.  This does the refactoring.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

"git update-index --refresh", "git reset" and "git add --refresh" have
reported paths that have local modifications as "needs update" since the
beginning of git.

Although this is logically correct in that you need to update the index at
that path before you can commit that change, it is now becoming more and
more clear, especially with the continuous push for user friendliness
since 1.5.0 series, that the message is suboptimal.  After all, the change
may be something the user might want to get rid of, and "updating" would
be absolutely a wrong thing to do if that is the case.

I prepared two alternatives to solve this.  Both aim to reword the message
to more neutral "locally modified".

This patch is a more intrusive variant that changes the message for only
Porcelain commands ("add" and "reset") while keeping the plumbing
"update-index" intact.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

People sometimes find that "git add -u && git add ." are 13 keystrokes too
many.  This reduces it by nine.

The support of this has been very low priority for me personally, because
I almost never do "git add ." in a directory with already tracked files,
and in a new directory, there is no point saying "git add -u".

However, for two types of people (that are very different from me), this
mode of operation may make sense and there is no reason to leave it
unsupported.  That is:

 (1) If you are extremely well disciplined and keep perfect .gitignore, it
     always is safe to say "git add ."; or

 (2) If you are extremely undisciplined and do not even know what files
     you created, and you do not very much care what goes in your history,
     it does not matter if "git add ." included everything.

So there it is, although I suspect I will not use it myself, ever.

It will be too much of a change that is against the expectation of the
existing users to allow "git commit -a" to include untracked files, and
it would be inconsistent if we named this new option "-a", so the short
option is "-A".  We _might_ want to later add "git commit -A" but that is
a separate topic.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The implementation of "git add" has four major codepaths that are mutually
exclusive:

 - if "--interactive" or "--patch" is given, spawn "git add--interactive"
   and exit without doing anything else.  Otherwise things are handled
   internally in this C code;

 - if "--update" is given, update the modified files and exit without
   doing anything else;

 - if "--refresh" is given, do refresh and exit without doing anything
   else;

 - otherwise, find the paths that match pathspecs and stage their
   contents.

It led to an unholy mess in the code structure; each of the latter three
codepaths has a separate call to read_cache(), even though they are all
about "read the current index, update it and write it back", and logically
they should read the index once _anyway_.

This cleans up the latter three cases by introducing a pair of helper
variables:

 - "add_new_files" is set if we need to scan the working tree for paths
   that match the pathspec.  This variable is false for "--update" and
   "--refresh", because they only work on already tracked files.

 - "require_pathspec" is set if the user must give at least one pathspec.
   "--update" does not need it but all the other cases do.

This is in preparation for introducing a new option "--all", that does the
equivalent of "git add -u && git add ." (aka "addremove").
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

When you misuse a git command, you are shown the usage string.
But this is currently shown in the dashed form.  So if you just
copy what you see, it will not work, when the dashed form
is no longer supported.

This patch makes git commands show the dash-less version.

For shell scripts that do not specify OPTIONS_SPEC, git-sh-setup.sh
generates a dash-less usage string now.
Signed-off-by: NStephan Beyer <s-beyer@gmx.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The option -u stands for --update and it is a good idea to make it clear
especially because this is the only mode of operation of "git add" that
does something different from "adding".  Give longer --force synonym to -f
while we are at it as well.
Signed-off-by: NSZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Output format from "git add -n $path" lists path to blobs that are going
to be added on a single line, separated with SP.  On the other hand, the
suggested "git add -u -n" shows one path per line, like "add '<file>'\n".
Of course, these two are inconsistent.

Plain "git add -n" can afford to only say names of paths, as all it does
is to add (update).  However, "git add -u" needs to be able to express
"remove" somehow.  So if we need to have them formatted the same way, we
need to unify with the "git add -n -u" format.  Incidentally, this is
consistent with how 'update-index' says it.

This changes the output from "git add -n $paths" but as a general
principle, output from Porcelain commands is a fair game for improvements
and not for script consumption.
Signed-off-by: NGustaf Hendeby <hendeby@isy.liu.se>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NJunio C Hamano <gitster@pobox.com>

git_config() only had a function parameter, but no callback data
parameter.  This assumes that all callback functions only modify
global variables.

With this patch, every callback gets a void * parameter, and it is hoped
that this will help the libification effort.
Signed-off-by: NJohannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NAlex Riesen <raa.lkml@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NAlex Riesen <raa.lkml@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NAlex Riesen <raa.lkml@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Update the programs which used the function (as add_file_to_cache).
Signed-off-by: NAlex Riesen <raa.lkml@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

When get_pathspec() was originally made absolute-path capable,
we botched the interface to it, without dying inside the function
when given a path that is outside the work tree, and made it the
responsibility of callers to check the condition in a roundabout
way.  This is made unnecessary with the previous patch.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

We would need to notice and fail if command line had a nonsense pathspec.
Earlier get_pathspec() returned all the inputs including bad ones, but
the new one issues warnings and removes offending ones from its return
value, so the callers need to be adjusted to notice it.

Additional test scripts were initially from Robin Rosenberg, further fixed.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Remove remaining double close(2)'s.  i.e. close() before
commit_locked_index() or commit_lock_file().
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

When the "--patch" option is supplied, the patch_update_cmd() function is
called bypassing the main_loop() and exits.

Seeing as builtin-add is the only caller of git-add--interactive we can
impose a strict requirement on the format of the arguments to avoid
possible ambiguity: an "--" argument must be used whenever any pathspecs
are passed, both with the "--patch" option and without it.
Signed-off-by: NWincent Colaiuta <win@wincent.com>

This fixes the pathspec interactive_add() passes to the underlying
git-add--interactive helper.  When the command was run from a
subdirectory, cmd_add() already has gone up to the toplevel of the work
tree, and the helper will be spawned from there.  The pathspec given on
the command line from the user needs to be adjusted for this.

This adds "validate_pathspec()" function in the callchain, but it does
not validate yet.  The function can be changed to barf if there are
unmatching pathspec given by the user, but that is not strictly
necessary.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The earlier 7c0ab445 (Teach builtin-add
to pass multiple paths to git-add--interactive) did not allocate enough,
and had unneeded (void*) pointer arithmetic.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

This separates the logic to limit the extent of change to the
index by where you are (controlled by "prefix") and what you
specify from the command line (controlled by "pathspec").
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Instead of just accepting a single file parameter, git-add now accepts
any number of path parameters, fowarding them to git-add--interactive.
Signed-off-by: NWincent Colaiuta <win@wincent.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

There are inconsistencies in the way commands currently handle
the core.excludesfile configuration variable.  The problem is
the variable is too new to be noticed by anything other than
git-add and git-status.

 * git-ls-files does not notice any of the "ignore" files by
   default, as it predates the standardized set of ignore files.
   The calling scripts established the convention to use
   .git/info/exclude, .gitignore, and later core.excludesfile.

 * git-add and git-status know about it because they call
   add_excludes_from_file() directly with their own notion of
   which standard set of ignore files to use.  This is just a
   stupid duplication of code that need to be updated every time
   the definition of the standard set of ignore files is
   changed.

 * git-read-tree takes --exclude-per-directory=<gitignore>,
   not because the flexibility was needed.  Again, this was
   because the option predates the standardization of the ignore
   files.

 * git-merge-recursive uses hardcoded per-directory .gitignore
   and nothing else.  git-clean (scripted version) does not
   honor core.* because its call to underlying ls-files does not
   know about it.  git-clean in C (parked in 'pu') doesn't either.

We probably could change git-ls-files to use the standard set
when no excludes are specified on the command line and ignore
processing was asked, or something like that, but that will be a
change in semantics and might break people's scripts in a subtle
way.  I am somewhat reluctant to make such a change.

On the other hand, I think it makes perfect sense to fix
git-read-tree, git-merge-recursive and git-clean to follow the
same rule as other commands.  I do not think of a valid use case
to give an exclude-per-directory that is nonstandard to
read-tree command, outside a "negative" test in the t1004 test
script.

This patch is the first step to untangle this mess.

The next step would be to teach read-tree, merge-recursive and
clean (in C) to use setup_standard_excludes().
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

There are inconsistencies in the way commands currently handle
the core.excludesfile configuration variable.  The problem is
the variable is too new to be noticed by anything other than
git-add and git-status.

 * git-ls-files does not notice any of the "ignore" files by
   default, as it predates the standardized set of ignore files.
   The calling scripts established the convention to use
   .git/info/exclude, .gitignore, and later core.excludesfile.

 * git-add and git-status know about it because they call
   add_excludes_from_file() directly with their own notion of
   which standard set of ignore files to use.  This is just a
   stupid duplication of code that need to be updated every time
   the definition of the standard set of ignore files is
   changed.

 * git-read-tree takes --exclude-per-directory=<gitignore>,
   not because the flexibility was needed.  Again, this was
   because the option predates the standardization of the ignore
   files.

 * git-merge-recursive uses hardcoded per-directory .gitignore
   and nothing else.  git-clean (scripted version) does not
   honor core.* because its call to underlying ls-files does not
   know about it.  git-clean in C (parked in 'pu') doesn't either.

We probably could change git-ls-files to use the standard set
when no excludes are specified on the command line and ignore
processing was asked, or something like that, but that will be a
change in semantics and might break people's scripts in a subtle
way.  I am somewhat reluctant to make such a change.

On the other hand, I think it makes perfect sense to fix
git-read-tree, git-merge-recursive and git-clean to follow the
same rule as other commands.  I do not think of a valid use case
to give an exclude-per-directory that is nonstandard to
read-tree command, outside a "negative" test in the t1004 test
script.

This patch is the first step to untangle this mess.

The next step would be to teach read-tree, merge-recursive and
clean (in C) to use setup_standard_excludes().
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Earlier in commit 0781b8a9
(add_file_to_index: skip rehashing if the cached stat already
matches), add_file_to_index() were taught not to re-add the path
if it already matches the index.

The change meant well, but was not executed quite right.  It
used ie_modified() to see if the file on the work tree is really
different from the index, and skipped adding the contents if the
function says "not modified".

This was wrong.  There are three possible comparison results
between the index and the file in the work tree:

 - with lstat(2) we _know_ they are different.  E.g. if the
   length or the owner in the cached stat information is
   different from the length we just obtained from lstat(2), we
   can tell the file is modified without looking at the actual
   contents.

 - with lstat(2) we _know_ they are the same.  The same length,
   the same owner, the same everything (but this has a twist, as
   described below).

 - we cannot tell from lstat(2) information alone and need to go
   to the filesystem to actually compare.

The last case arises from what we call 'racy git' situation,
that can be caused with this sequence:

    $ echo hello >file
    $ git add file
    $ echo aeiou >file ;# the same length

If the second "echo" is done within the same filesystem
timestamp granularity as the first "echo", then the timestamp
recorded by "git add" and the timestamp we get from lstat(2)
will be the same, and we can mistakenly say the file is not
modified.  The path is called 'racily clean'.  We need to
reliably detect racily clean paths are in fact modified.

To solve this problem, when we write out the index, we mark the
index entry that has the same timestamp as the index file itself
(that is the time from the point of view of the filesystem) to
tell any later code that does the lstat(2) comparison not to
trust the cached stat info, and ie_modified() then actually goes
to the filesystem to compare the contents for such a path.

That's all good, but it should not be used for this "git add"
optimization, as the goal of "git add" is to actually update the
path in the index and make it stat-clean.  With the false
optimization, we did _not_ cause any data loss (after all, what
we failed to do was only to update the cached stat information),
but it made the following sequence leave the file stat dirty:

    $ echo hello >file
    $ git add file
    $ echo hello >file ;# the same contents
    $ git add file

The solution is not to use ie_modified() which goes to the
filesystem to see if it is really clean, but instead use
ie_match_stat() with "assume racily clean paths are dirty"
option, to force re-adding of such a path.

There was another problem with "git add -u".  The codepath
shares the same issue when adding the paths that are found to be
modified, but in addition, it asked "git diff-files" machinery
run_diff_files() function (which is "git diff-files") to list
the paths that are modified.  But "git diff-files" machinery
uses the same ie_modified() call so that it does not report
racily clean _and_ actually clean paths as modified, which is
not what we want.

The patch allows the callers of run_diff_files() to pass the
same "assume racily clean paths are dirty" option, and makes
"git-add -u" codepath to use that option, to discover and re-add
racily clean _and_ actually clean paths.

We could further optimize on top of this patch to differentiate
the case where the path really needs re-adding (i.e. the content
of the racily clean entry was indeed different) and the case
where only the cached stat information needs to be refreshed
(i.e. the racily clean entry was actually clean), but I do not
think it is worth it.

This patch applies to maint and all the way up.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NKristian Høgsberg <krh@redhat.com>
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

prune_directory and fill_directory allocated one byte per pathspec and never
freed it.
Signed-off-by: NBenoit Sigoure <tsuna@lrde.epita.fr>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

This refactors builtin-add.c a little to provide a unique entry point
for launching git add --interactive, which will be used by
builtin-commit too.  If we later want to make add --interactive a
builtin or change how it is launched, we just start from this function.

It also exports the private function update() which is used to
add all modified paths to the index as add_files_to_cache().
Signed-off-by: NKristian Høgsberg <krh@redhat.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NPierre Habouzit <madcoder@debian.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

An earlier commit fixed type-change case in "git add -u".
This adds a test to make sure we do not introduce regression.

At the same time, it fixes a stupid typo in the error message.
Signed-off-by: NBenoit Sigoure <tsuna@lrde.epita.fr>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Earlier, add_file_to_index() invalidated the path in the cache-tree
but remove_file_from_cache() did not, and the user of the latter
needed to invalidate the entry himself.  This led to a few bugs due to
missed invalidate calls already.  This patch makes the management of
cache-tree less error prone by making more invalidate calls from lower
level cache API functions.

The rules are:

 - If you are going to write the index, you should either maintain
   cache_tree correctly.

   - If you cannot, alternatively you can remove the entire cache_tree
     by calling cache_tree_free() before you call write_cache().

   - When you modify the index, cache_tree_invalidate_path() should be
     called with the path you are modifying, to discard the entry from
     the cache-tree structure.

 - The following cache API functions exported from read-cache.c (and
   the macro whose names have "cache" instead of "index")
   automatically call cache_tree_invalidate_path() for you:

   - remove_file_from_index();
   - add_file_to_index();
   - add_index_entry();

   You can modify the index bypassing the above API functions
   (e.g. find an existing cache entry from the index and modify it in
   place).  You need to call cache_tree_invalidate_path() yourself in
   such a case.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Currently the error message seems to imply (at least to me) that only
the listed files were withheld and the rest of the files was added to the
index, even though that's obviously not the case.
Signed-off-by: NPetr Baudis <pasky@suse.cz>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The usage string for the executable was missing --refresh.  In
addition, the documentation referred to "file", but the usage string
referred to "filepattern".  Updated the documentation to
"filepattern", as git-add does handle patterns.
Signed-off-by: NBrian Hetro <whee@smaertness.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

git-add -u also takes the path limiters, but unlike the
command without the -u option, the code forgot that it
could be invoked from a subdirectory, and did not correctly
handle the prefix.
Signed-off-by: NSalikh Zakirov <salikh@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

This applies to 'maint' to fix a rather serious data corruption
issue.  When "git add -u" affects a subdirectory in such a way
that the only changes to its contents are path removals, the
next tree object written out of that index was bogus, as the
remove codepath forgot to invalidate the cache-tree entry.

Reported by Salikh Zakirov.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

This allows to refresh only a subset of the project files, based on
the specified pathspecs.
Signed-off-by: NAlexandre Julliard <julliard@winehq.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Calling access(p, m) with p == NULL is not specified, so don't do that.  On
GNU/Hurd systems doing so will result in a SIGSEGV.
Signed-off-by: NThomas Schwinge <tschwinge@gnu.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>