- 01 9月, 2008 1 次提交
-
-
由 Junio C Hamano 提交于
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>
-
- 05 8月, 2008 1 次提交
-
-
由 Junio C Hamano 提交于
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>
-
- 26 7月, 2008 2 次提交
-
-
由 Junio C Hamano 提交于
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>
-
由 Junio C Hamano 提交于
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>
-
- 21 7月, 2008 1 次提交
-
-
由 Junio C Hamano 提交于
"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>
-
- 20 7月, 2008 2 次提交
-
-
由 Junio C Hamano 提交于
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>
-
由 Junio C Hamano 提交于
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>
-
- 14 7月, 2008 1 次提交
-
-
由 Stephan Beyer 提交于
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>
-
- 15 6月, 2008 1 次提交
-
-
由 SZEDER Gábor 提交于
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>
-
- 24 5月, 2008 1 次提交
-
-
由 Gustaf Hendeby 提交于
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>
-
- 22 5月, 2008 1 次提交
-
-
由 Junio C Hamano 提交于
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 15 5月, 2008 1 次提交
-
-
由 Johannes Schindelin 提交于
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>
-
- 13 5月, 2008 4 次提交
-
-
由 Alex Riesen 提交于
Signed-off-by: NAlex Riesen <raa.lkml@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Alex Riesen 提交于
Signed-off-by: NAlex Riesen <raa.lkml@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Alex Riesen 提交于
Signed-off-by: NAlex Riesen <raa.lkml@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Alex Riesen 提交于
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>
-
- 07 3月, 2008 1 次提交
-
-
由 Junio C Hamano 提交于
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>
-
- 05 2月, 2008 1 次提交
-
-
由 Junio C Hamano 提交于
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>
-
- 17 1月, 2008 1 次提交
-
-
由 Brandon Casey 提交于
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>
-
- 26 11月, 2007 3 次提交
-
-
由 Wincent Colaiuta 提交于
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>
-
由 Junio C Hamano 提交于
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>
-
由 Junio C Hamano 提交于
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>
-
- 23 11月, 2007 1 次提交
-
-
由 Junio C Hamano 提交于
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>
-
- 22 11月, 2007 1 次提交
-
-
由 Wincent Colaiuta 提交于
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>
-
- 17 11月, 2007 1 次提交
-
-
由 Junio C Hamano 提交于
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>
-
- 15 11月, 2007 1 次提交
-
-
由 Junio C Hamano 提交于
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>
-
- 10 11月, 2007 1 次提交
-
-
由 Junio C Hamano 提交于
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>
-
- 30 10月, 2007 2 次提交
-
-
由 Kristian Høgsberg 提交于
Signed-off-by: NKristian Høgsberg <krh@redhat.com> Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Benoit Sigoure 提交于
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>
-
- 27 9月, 2007 1 次提交
-
-
由 Kristian Høgsberg 提交于
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>
-
- 19 9月, 2007 1 次提交
-
-
由 Pierre Habouzit 提交于
Signed-off-by: NPierre Habouzit <madcoder@debian.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 15 9月, 2007 1 次提交
-
-
由 Benoit Sigoure 提交于
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>
-
- 14 9月, 2007 2 次提交
-
-
由 Junio C Hamano 提交于
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>
-
由 Junio C Hamano 提交于
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 29 8月, 2007 1 次提交
-
-
由 Petr Baudis 提交于
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>
-
- 26 8月, 2007 1 次提交
-
-
由 Brian Hetro 提交于
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>
-
- 16 8月, 2007 2 次提交
-
-
由 Salikh Zakirov 提交于
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>
-
由 Junio C Hamano 提交于
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>
-
- 14 8月, 2007 1 次提交
-
-
由 Alexandre Julliard 提交于
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>
-
- 29 7月, 2007 1 次提交
-
-
由 Thomas Schwinge 提交于
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>
-