summaryrefslogtreecommitdiff
path: root/builtin-add.c
AgeCommit message (Collapse)AuthorFilesLines
2008-08-27Merge branch 'jc/add-addremove'Libravatar Junio C Hamano1-69/+31
* jc/add-addremove: builtin-add.c: optimize -A option and "git add ." builtin-add.c: restructure the code for maintainability
2008-08-04add: refuse to add working tree items beyond symlinksLibravatar Junio C Hamano1-1/+11
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-07-25builtin-add.c: optimize -A option and "git add ."Libravatar Junio C Hamano1-12/+31
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-25builtin-add.c: restructure the code for maintainabilityLibravatar Junio C Hamano1-57/+0
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-20Merge branch 'jc/add-addremove'Libravatar Junio C Hamano1-33/+53
* 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"needs update" considered harmfulLibravatar Junio C Hamano1-1/+2
"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-19git-add --all: add all filesLibravatar Junio C Hamano1-2/+11
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-19builtin-add.c: restructure the code for maintainabilityLibravatar Junio C Hamano1-32/+43
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-13Make usage strings dash-lessLibravatar Stephan Beyer1-1/+1
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-06-14git add: add long equivalents of '-u' and '-f' optionsLibravatar SZEDER Gábor1-2/+2
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-05-25Merge branch 'js/config-cb'Libravatar Junio C Hamano1-3/+3
* js/config-cb: Provide git_config with a callback-data parameter Conflicts: builtin-add.c builtin-cat-file.c
2008-05-25Merge branch 'jc/add-n-u'Libravatar Junio C Hamano1-23/+11
* 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-23Make git add -n and git -u -n output consistentLibravatar Gustaf Hendeby1-15/+5
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-21"git-add -n -u" should not add but just reportLibravatar Junio C Hamano1-9/+13
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-14Provide git_config with a callback-data parameterLibravatar Johannes Schindelin1-1/+1
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-12Add a config option to ignore errors for git-addLibravatar Alex Riesen1-1/+10
Signed-off-by: Alex Riesen <raa.lkml@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-12Add --ignore-errors to git-add to allow it to skip files with read errorsLibravatar Alex Riesen1-2/+9
Signed-off-by: Alex Riesen <raa.lkml@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-12Extend interface of add_files_to_cache to allow ignore indexing errorsLibravatar Alex Riesen1-9/+28
Signed-off-by: Alex Riesen <raa.lkml@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-12Make the exit code of add_file_to_index actually usefulLibravatar Alex Riesen1-2/+4
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-03-07Revert part of 1abf095 (git-add: adjust to the get_pathspec() changes)Libravatar Junio C Hamano1-12/+0
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-02-05git-add: adjust to the get_pathspec() changes.Libravatar Junio C Hamano1-0/+12
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-01-16Improve use of lockfile APILibravatar Brandon Casey1-1/+1
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>
2007-11-25Add "--patch" option to git-add--interactiveLibravatar Wincent Colaiuta1-8/+16
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-25add -i: Fix running from a subdirectoryLibravatar Junio C Hamano1-4/+20
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-25builtin-add: fix command line building to call interactiveLibravatar Junio C Hamano1-2/+3
The earlier 7c0ab4458994aa895855abc4a504cf693ecc0cf1 (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-25Merge branch 'kh/commit' into wc/add-iLibravatar Junio C Hamano1-3/+5
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-22Fix add_files_to_cache() to take pathspec, not user specified list of filesLibravatar Junio C Hamano1-3/+5
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-22Teach builtin-add to pass multiple paths to git-add--interactiveLibravatar Wincent Colaiuta1-10/+13
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-14core.excludesfile clean-upLibravatar Junio C Hamano1-20/+2
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-14Merge branch 'jc/maint-add-sync-stat'Libravatar Junio C Hamano1-1/+1
* 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-10git-add: make the entry stat-clean after re-adding the same contentsLibravatar Junio C Hamano1-1/+1
Earlier in commit 0781b8a9b2fe760fc4ed519a3a26e4b9bd6ccffe (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-02Merge branch 'ph/parseopt'Libravatar Junio C Hamano1-46/+26
* 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-10-31Merge branch 'kh/commit'Libravatar Junio C Hamano1-9/+14
* 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-29Port builtin-add.c to use the new option parser.Libravatar Kristian Høgsberg1-46/+27
Signed-off-by: Kristian Høgsberg <krh@redhat.com> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-10-29Merge branch 'maint'Libravatar Junio C Hamano1-0/+2
* 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-29Fix a small memory leak in builtin-addLibravatar Benoit Sigoure1-0/+2
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-09-27Introduce entry point add_interactive and add_files_to_cacheLibravatar Kristian Høgsberg1-9/+14
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-18Use xmemdupz() in many places.Libravatar Pierre Habouzit1-6/+2
Signed-off-by: Pierre Habouzit <madcoder@debian.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-09-18Merge branch 'cr/reset'Libravatar Junio C Hamano1-1/+0
* 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-14Add test to check recent fix to "git add -u"Libravatar Benoit Sigoure1-1/+1
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-14Simplify cache APILibravatar Junio C Hamano1-1/+0
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-14git-add -u: do not barf on type changesLibravatar Junio C Hamano1-0/+1
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-08-28git-add: Make the "tried to add ignored file" error message less confusingLibravatar Petr Baudis1-3/+3
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-25Make usage documentation for git-add consistent.Libravatar Brian Hetro1-1/+1
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-15Merge branch 'maint' to sync with 1.5.2.5Libravatar Junio C Hamano1-4/+5
* maint: GIT 1.5.2.5 git-add -u paths... now works from subdirectory Fix "git add -u" data corruption.
2007-08-15git-add -u paths... now works from subdirectoryLibravatar Salikh Zakirov1-4/+4
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-15Fix "git add -u" data corruption.Libravatar Junio C Hamano1-0/+1
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: Junio C Hamano <gitster@pobox.com>
2007-08-13git-add: Add support for --refresh option.Libravatar Alexandre Julliard1-1/+27
This allows to refresh only a subset of the project files, based on the specified pathspecs. Signed-off-by: Alexandre Julliard <julliard@winehq.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-07-28Don't rely on unspecified behaviorLibravatar Thomas Schwinge1-1/+1
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: Thomas Schwinge <tschwinge@gnu.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-06-13builtin-add: simplify (and increase accuracy of) exclude handlingLibravatar Jeff King1-48/+21
Previously, the code would always set up the excludes, and then manually pick through the pathspec we were given, assuming that non-added but existing paths were just ignored. This was mostly correct, but would erroneously mark a totally empty directory as 'ignored'. Instead, we now use the collect_ignored option of dir_struct, which unambiguously tells us whether a path was ignored. This simplifies the code, and means empty directories are now just not mentioned at all. Furthermore, we now conditionally ask dir_struct to respect excludes, depending on whether the '-f' flag has been set. This means we don't have to pick through the result, checking for an 'ignored' flag; ignored entries were either added or not in the first place. We can safely get rid of the special 'ignored' flags to dir_entry, which were not used anywhere else. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Jonas Fonseca <fonseca@diku.dk> Signed-off-by: Junio C Hamano <gitster@pobox.com>