Граф коммитов

86 Коммитов

Автор SHA1 Сообщение Дата
Felipe Contreras 9ccb3bca57 git add: trivial codestyle cleanup
Global static variables don't need to be initialized to 0/NULL.

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-25 00:49:54 -08:00
Johannes Schindelin 2ce53f9b77 git add: do not add files from a submodule
It comes quite as a surprise to an unsuspecting Git user that calling
"git add submodule/file" (which is a mistake, alright) _removes_
the submodule in the index, and adds the file.  Instead, complain loudly.

While at it, be nice when the user said "git add submodule/" which is
most likely the consequence of tab-completion, and stage the submodule,
instead of trying to add the contents of that directory.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-05 10:48:32 -08:00
Alexander Potashev 71fe945131 Fix typo in comment in builtin-add.c
Reported-by: Tim Daly <daly@axiom-developer.org>
Signed-off-by: Alexander Potashev <aspotashev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-12-10 15:39:00 -08:00
Junio C Hamano 394258190c git-add --intent-to-add (-N)
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: Junio C Hamano <gitster@pobox.com>
2008-08-31 16:22:05 -07:00
Junio C Hamano b46f7e54fc Merge branch 'jc/add-addremove'
* jc/add-addremove:
  builtin-add.c: optimize -A option and "git add ."
  builtin-add.c: restructure the code for maintainability
2008-08-27 16:39:57 -07:00
Junio C Hamano 725b06050a add: refuse to add working tree items beyond symlinks
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: Junio C Hamano <gitster@pobox.com>
2008-08-04 23:31:23 -07:00
Junio C Hamano 1e5f764c93 builtin-add.c: optimize -A option and "git add ."
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: Junio C Hamano <gitster@pobox.com>
2008-07-25 21:14:21 -07:00
Junio C Hamano 041aee31be builtin-add.c: restructure the code for maintainability
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: Junio C Hamano <gitster@pobox.com>
2008-07-25 21:14:21 -07:00
Junio C Hamano 378335b37c Merge branch 'jc/add-addremove'
* jc/add-addremove:
  git-add --all: documentation
  git-add --all: tests
  git-add --all: add all files
  builtin-add.c: restructure the code for maintainability

Conflicts:
	builtin-add.c
2008-07-20 17:53:17 -07:00
Junio C Hamano d14e7407b3 "needs update" considered harmful
"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: Junio C Hamano <gitster@pobox.com>
2008-07-20 17:21:32 -07:00
Junio C Hamano 3ba1f11426 git-add --all: add all files
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: Junio C Hamano <gitster@pobox.com>
2008-07-19 23:08:58 -07:00
Junio C Hamano c972ec0420 builtin-add.c: restructure the code for maintainability
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: Junio C Hamano <gitster@pobox.com>
2008-07-19 23:08:58 -07:00
Stephan Beyer 1b1dd23f2d Make usage strings dash-less
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: Stephan Beyer <s-beyer@gmx.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-13 14:12:48 -07:00
SZEDER Gábor 69c61c4fa9 git add: add long equivalents of '-u' and '-f' options
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: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-06-14 12:47:31 -07:00
Junio C Hamano 9bd81e4249 Merge branch 'js/config-cb'
* js/config-cb:
  Provide git_config with a callback-data parameter

Conflicts:

	builtin-add.c
	builtin-cat-file.c
2008-05-25 14:25:02 -07:00
Junio C Hamano 0166592495 Merge branch 'jc/add-n-u'
* jc/add-n-u:
  Make git add -n and git -u -n output consistent
  "git-add -n -u" should not add but just report

Conflicts:

	builtin-add.c
	builtin-mv.c
	cache.h
	read-cache.c
2008-05-25 14:03:50 -07:00
Gustaf Hendeby 205ffa94be Make git add -n and git -u -n output consistent
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: Gustaf Hendeby <hendeby@isy.liu.se>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-23 14:47:02 -07:00
Junio C Hamano 38ed1d89f7 "git-add -n -u" should not add but just report
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-21 12:04:41 -07:00
Johannes Schindelin ef90d6d420 Provide git_config with a callback-data parameter
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: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-14 12:34:44 -07:00
Alex Riesen dad25e4a7c Add a config option to ignore errors for git-add
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-12 21:40:15 -07:00
Alex Riesen 984b83ef23 Add --ignore-errors to git-add to allow it to skip files with read errors
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-12 20:54:52 -07:00
Alex Riesen 7ae02a30e8 Extend interface of add_files_to_cache to allow ignore indexing errors
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-12 20:54:52 -07:00
Alex Riesen 960b8ad1b1 Make the exit code of add_file_to_index actually useful
Update the programs which used the function (as add_file_to_cache).

Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-12 20:54:46 -07:00
Junio C Hamano 6c53e7ac04 Revert part of 1abf095 (git-add: adjust to the get_pathspec() changes)
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: Junio C Hamano <gitster@pobox.com>
2008-03-07 00:14:43 -08:00
Junio C Hamano 1abf095063 git-add: adjust to the get_pathspec() changes.
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: Junio C Hamano <gitster@pobox.com>
2008-02-05 00:44:10 -08:00
Brandon Casey 4ed7cd3ab0 Improve use of lockfile API
Remove remaining double close(2)'s.  i.e. close() before
commit_locked_index() or commit_lock_file().

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-01-16 15:35:35 -08:00
Wincent Colaiuta b63e995001 Add "--patch" option to git-add--interactive
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: Wincent Colaiuta <win@wincent.com>
2007-11-25 11:37:55 -08:00
Junio C Hamano 3f061887c5 add -i: Fix running from a subdirectory
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: Junio C Hamano <gitster@pobox.com>
2007-11-25 10:23:13 -08:00
Junio C Hamano 324ccbd6a0 builtin-add: fix command line building to call interactive
The earlier 7c0ab44589 (Teach builtin-add
to pass multiple paths to git-add--interactive) did not allocate enough,
and had unneeded (void*) pointer arithmetic.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-25 10:23:10 -08:00
Junio C Hamano f64fe7b481 Merge branch 'kh/commit' into wc/add-i
This is to use a few functions refactored to use in the built-in
commit series.

* kh/commit: (28 commits)
  Add a few more tests for git-commit
  builtin-commit: Include the diff in the commit message when verbose.
  builtin-commit: fix partial-commit support
  Fix add_files_to_cache() to take pathspec, not user specified list of files
  Export three helper functions from ls-files
  builtin-commit: run commit-msg hook with correct message file
  builtin-commit: do not color status output shown in the message template
  file_exists(): dangling symlinks do exist
  Replace "runstatus" with "status" in the tests
  t7501-commit: Add test for git commit <file> with dirty index.
  builtin-commit: Clean up an unused variable and a debug fprintf().
  Call refresh_cache() when updating the user index for --only commits.
  builtin-commit: Add newline when showing which commit was created
  builtin-commit: resurrect behavior for multiple -m options
  builtin-commit --s: add a newline if the last line was not a S-o-b
  builtin-commit: fix --signoff
  git status: show relative paths when run in a subdirectory
  builtin-commit: Refresh cache after adding files.
  builtin-commit: fix reflog message generation
  launch_editor(): read the file, even when EDITOR=:
  ...
2007-11-25 08:46:29 -08:00
Junio C Hamano b6ec1d619f Fix add_files_to_cache() to take pathspec, not user specified list of files
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: Junio C Hamano <gitster@pobox.com>
2007-11-22 17:05:05 -08:00
Wincent Colaiuta 7c0ab44589 Teach builtin-add to pass multiple paths to git-add--interactive
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: Wincent Colaiuta <win@wincent.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-22 02:53:19 -08:00
Junio C Hamano 039bc64e88 core.excludesfile clean-up
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: Junio C Hamano <gitster@pobox.com>
2007-11-14 15:08:04 -08:00
Junio C Hamano c78a24986d Merge branch 'jc/maint-add-sync-stat'
* jc/maint-add-sync-stat:
  t2200: test more cases of "add -u"
  git-add: make the entry stat-clean after re-adding the same contents
  ce_match_stat, run_diff_files: use symbolic constants for readability

Conflicts:

	builtin-add.c
2007-11-14 14:15:40 -08:00
Junio C Hamano fb63d7f889 git-add: make the entry stat-clean after re-adding the same contents
Earlier in commit 0781b8a9b2
(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: Junio C Hamano <gitster@pobox.com>
2007-11-10 00:37:39 -08:00
Junio C Hamano 3d66dc9657 Merge branch 'ph/parseopt'
* ph/parseopt: (24 commits)
  gc: use parse_options
  Fixed a command line option type for builtin-fsck.c
  Make builtin-pack-refs.c use parse_options.
  Make builtin-name-rev.c use parse_options.
  Make builtin-count-objects.c use parse_options.
  Make builtin-fsck.c use parse_options.
  Update manpages to reflect new short and long option aliases
  Make builtin-for-each-ref.c use parse-opts.
  Make builtin-symbolic-ref.c use parse_options.
  Make builtin-update-ref.c use parse_options
  Make builtin-revert.c use parse_options.
  Make builtin-describe.c use parse_options
  Make builtin-branch.c use parse_options.
  Make builtin-mv.c use parse-options
  Make builtin-rm.c use parse_options.
  Port builtin-add.c to use the new option parser.
  parse-options: allow callbacks to take no arguments at all.
  parse-options: Allow abbreviated options when unambiguous
  Add shortcuts for very often used options.
  parse-options: make some arguments optional, add callbacks.
  ...

Conflicts:

	Makefile
	builtin-add.c
2007-11-02 16:42:23 -07:00
Junio C Hamano 37701381b6 Merge branch 'kh/commit'
* kh/commit:
  Export rerere() and launch_editor().
  Introduce entry point add_interactive and add_files_to_cache
  Enable wt-status to run against non-standard index file.
  Enable wt-status output to a given FILE pointer.
2007-10-31 23:53:22 -07:00
Kristian Høgsberg 5c46f75437 Port builtin-add.c to use the new option parser.
Signed-off-by: Kristian Høgsberg <krh@redhat.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-10-29 21:03:31 -07:00
Junio C Hamano e2b7eaf0ca Merge branch 'maint'
* maint:
  RelNotes-1.5.3.5: describe recent fixes
  merge-recursive.c: mrtree in merge() is not used before set
  sha1_file.c: avoid gcc signed overflow warnings
  Fix a small memory leak in builtin-add
  honor the http.sslVerify option in shell scripts
2007-10-29 12:53:54 -07:00
Benoit Sigoure 399f0a8eed Fix a small memory leak in builtin-add
prune_directory and fill_directory allocated one byte per pathspec and never
freed it.

Signed-off-by: Benoit Sigoure <tsuna@lrde.epita.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-10-29 11:39:07 -07:00
Kristian Høgsberg 5868016508 Introduce entry point add_interactive and add_files_to_cache
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: Kristian Høgsberg <krh@redhat.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-09-27 01:19:42 -07:00
Pierre Habouzit 182af8343c Use xmemdupz() in many places.
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-09-18 17:42:17 -07:00
Junio C Hamano 9346b4e1ad Merge branch 'cr/reset'
* cr/reset:
  Simplify cache API
  An additional test for "git-reset -- path"
  Make "git reset" a builtin.
  Move make_cache_entry() from merge-recursive.c into read-cache.c
  Add tests for documented features of "git reset".
2007-09-18 00:42:01 -07:00
Benoit Sigoure 43b98acc23 Add test to check recent fix to "git add -u"
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: Benoit Sigoure <tsuna@lrde.epita.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-09-14 14:30:05 -07:00
Junio C Hamano 09d5dc32fb Simplify cache API
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: Junio C Hamano <gitster@pobox.com>
2007-09-14 01:02:21 -07:00
Junio C Hamano 767c98a592 git-add -u: do not barf on type changes
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-09-14 00:45:29 -07:00
Petr Baudis b39c53e662 git-add: Make the "tried to add ignored file" error message less confusing
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: Petr Baudis <pasky@suse.cz>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-08-28 21:15:25 -07:00
Brian Hetro 480611d170 Make usage documentation for git-add consistent.
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: Brian Hetro <whee@smaertness.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-08-25 22:35:44 -07:00
Junio C Hamano c576304d51 Merge branch 'maint' to sync with 1.5.2.5
* maint:
  GIT 1.5.2.5
  git-add -u paths... now works from subdirectory
  Fix "git add -u" data corruption.
2007-08-15 21:38:38 -07:00
Salikh Zakirov 2ed2c222df git-add -u paths... now works from subdirectory
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: Salikh Zakirov <salikh@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-08-15 14:28:34 -07:00