- 13 11月, 2010 1 次提交
-
-
由 Nguyễn Thái Ngọc Duy 提交于
Commit c84de707 (excluded_1(): support exclude files in index - 2009-08-20) added support for excluded() where dtype can be NULL. It was designed specifically for index matching because there was no other way to extract dtype information from index. It did not support wildcard matching (for example, "a*/" pattern would fail to match). The code was probably misread when commit 108da0db (git add: Add the "--ignore-missing" option for the dry run - 2010-07-10) was made because DT_UNKNOWN happens to be zero (NULL) too. Do not pass DT_UNKNOWN/NULL to excluded(), instead pass a pointer to a variable that contains DT_UNKNOWN. The real dtype will be extracted from worktree by excluded(), as expected. Signed-off-by: NNguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 13 7月, 2010 1 次提交
-
-
由 Jens Lehmann 提交于
Sometimes it is useful to know if a file or directory will be ignored before it is added to the work tree. An example is "git submodule add", where it would be really nice to be able to fail with an appropriate error message before the submodule is cloned and checked out. Signed-off-by: NJens Lehmann <Jens.Lehmann@web.de> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 01 6月, 2010 1 次提交
-
-
由 Gary V. Vaughan 提交于
Unfortunately, there are still plenty of production systems with vendor compilers that choke unless all compound declarations can be determined statically at compile time, for example hpux10.20 (I can provide a comprehensive list of our supported platforms that exhibit this problem if necessary). This patch simply breaks apart any compound declarations with dynamic initialisation expressions, and moves the initialisation until after the last declaration in the same block, in all the places necessary to have the offending compilers accept the code. Signed-off-by: NGary V. Vaughan <gary@thewrittenword.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 23 2月, 2010 1 次提交
-
-
由 Linus Torvalds 提交于
This shrinks the top-level directory a bit, and makes it much more pleasant to use auto-completion on the thing. Instead of [torvalds@nehalem git]$ em buil<tab> Display all 180 possibilities? (y or n) [torvalds@nehalem git]$ em builtin-sh builtin-shortlog.c builtin-show-branch.c builtin-show-ref.c builtin-shortlog.o builtin-show-branch.o builtin-show-ref.o [torvalds@nehalem git]$ em builtin-shor<tab> builtin-shortlog.c builtin-shortlog.o [torvalds@nehalem git]$ em builtin-shortlog.c you get [torvalds@nehalem git]$ em buil<tab> [type] builtin/ builtin.h [torvalds@nehalem git]$ em builtin [auto-completes to] [torvalds@nehalem git]$ em builtin/sh<tab> [type] shortlog.c shortlog.o show-branch.c show-branch.o show-ref.c show-ref.o [torvalds@nehalem git]$ em builtin/sho [auto-completes to] [torvalds@nehalem git]$ em builtin/shor<tab> [type] shortlog.c shortlog.o [torvalds@nehalem git]$ em builtin/shortlog.c which doesn't seem all that different, but not having that annoying break in "Display all 180 possibilities?" is quite a relief. NOTE! If you do this in a clean tree (no object files etc), or using an editor that has auto-completion rules that ignores '*.o' files, you won't see that annoying 'Display all 180 possibilities?' message - it will just show the choices instead. I think bash has some cut-off around 100 choices or something. So the reason I see this is that I'm using an odd editory, and thus don't have the rules to cut down on auto-completion. But you can simulate that by using 'ls' instead, or something similar. Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 17 2月, 2010 1 次提交
-
-
由 Junio C Hamano 提交于
If a pathspec is supplied to 'git add -u' and no path matches the pattern, fail with an approriate error message and exit code. Tested-by: NChris Packham <judge.packham@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 22 1月, 2010 1 次提交
-
-
由 Linus Torvalds 提交于
Exal Sibeaz pointed out that some git files are way too big, and that add_files_to_cache() brings in all the diff machinery to any git binary that needs the basic git SHA1 object operations from read-cache.c. Which is pretty much all of them. It's doubly silly, since add_files_to_cache() is only used by builtin programs (add, checkout and commit), so it's fairly easily fixed by just moving the thing to builtin-add.c, and avoiding the dependency entirely. I initially argued to Exal that it would probably be best to try to depend on smart compilers and linkers, but after spending some time trying to make -ffunction-sections work and giving up, I think Exal was right, and the fix is to just do some trivial cleanups like this. This trivial cleanup results in pretty stunning file size differences. The diff machinery really is mostly used by just the builtin programs, and you have things like these trivial before-and-after numbers: -rwxr-xr-x 1 torvalds torvalds 1727420 2010-01-21 10:53 git-hash-object -rwxrwxr-x 1 torvalds torvalds 940265 2010-01-21 11:16 git-hash-object Now, I'm not saying that 940kB is good either, but that's mostly all the debug information - you can see the real code with 'size': text data bss dec hex filename 418675 3920 127408 550003 86473 git-hash-object (before) 230650 2288 111728 344666 5425a git-hash-object (after) ie we have a nice 24% size reduction from this trivial cleanup. It's not just that one file either. I get: [torvalds@nehalem git]$ du -s /home/torvalds/libexec/git-core 45640 /home/torvalds/libexec/git-core (before) 33508 /home/torvalds/libexec/git-core (after) so we're talking 12MB of diskspace here. (Of course, stripping all the binaries brings the 33MB down to 9MB, so the whole debug information thing is still the bulk of it all, but that's a separate issue entirely) Now, I'm sure there are other things we should do, and changing our compiler flags from -O2 to -Os would bring the text size down by an additional almost 20%, but this thing Exal pointed out seems to be some good low-hanging fruit. Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 13 9月, 2009 1 次提交
-
-
由 Jim Meyering 提交于
There were several unchecked use of fdopen(); replace them with xfdopen() that checks and dies. Signed-off-by: NJim Meyering <meyering@redhat.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 22 8月, 2009 2 次提交
-
-
由 Matthieu Moy 提交于
git reset without argument displays a summary of the local modification, like this: $ git reset Makefile: locally modified Some people have problems with this; they look like an error message. This patch makes its output mimic how "git checkout $another_branch" reports the paths with local modifications. "git add --refresh --verbose" is changed in the same way. It also adds a header to make it clear that the output is informative, and not an error. Signed-off-by: NMatthieu Moy <Matthieu.Moy@imag.fr>
-
由 Matthieu Moy 提交于
The change in the output is going to become more general than just saying "changed", so let's make the variable name more general too. Signed-off-by: NMatthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 15 8月, 2009 1 次提交
-
-
由 Thomas Rast 提交于
This moves the call setup for 'git add--interactive' to a separate function, as other users will call it without running validate_pathspec() first. Signed-off-by: NThomas Rast <trast@student.ethz.ch> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 09 7月, 2009 1 次提交
-
-
由 Linus Torvalds 提交于
Most of the users of "read_directory()" actually want a much simpler interface than the whole complex (but rather powerful) one. In fact 'git add' had already largely abstracted out the core interface issues into a private "fill_directory()" function that was largely applicable almost as-is to a number of callers. Yes, 'git add' wants to do some extra work of its own, specific to the add semantics, but we can easily split that out, and use the core as a generic function. This function does exactly that, and now that much simplified 'fill_directory()' function can be shared with a number of callers, while also ensuring that the rather more complex calling conventions of read_directory() are used by fewer call-sites. This also makes the 'common_prefix()' helper function private to dir.c, since all callers are now in that file. Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 28 6月, 2009 1 次提交
-
-
由 Thomas Rast 提交于
Lots of die() calls did not actually report the kind of error, which can leave the user confused as to the real problem. Use die_errno() where we check a system/library call that sets errno on failure, or one of the following that wrap such calls: Function Passes on error from -------- -------------------- odb_pack_keep open read_ancestry fopen read_in_full xread strbuf_read xread strbuf_read_file open or strbuf_read_file strbuf_readlink readlink write_in_full xwrite Signed-off-by: NThomas Rast <trast@student.ethz.ch> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 21 6月, 2009 1 次提交
-
-
由 Linus Torvalds 提交于
There are a few remaining ones, but this fixes the trivial ones. It boils down to two main issues that sparse complains about: - warning: Using plain integer as NULL pointer Sparse doesn't like you using '0' instead of 'NULL'. For various good reasons, not the least of which is just the visual confusion. A NULL pointer is not an integer, and that whole "0 works as NULL" is a historical accident and not very pretty. A few of these remain: zlib is a total mess, and Z_NULL is just a 0. I didn't touch those. - warning: symbol 'xyz' was not declared. Should it be static? Sparse wants to see declarations for any functions you export. A lack of a declaration tends to mean that you should either add one, or you should mark the function 'static' to show that it's in file scope. A few of these remain: I only did the ones that should obviously just be made static. That 'wt_status_submodule_summary' one is debatable. It has a few related flags (like 'wt_status_use_color') which _are_ declared, and are used by builtin-commit.c. So maybe we'd like to export it at some point, but it's not declared now, and not used outside of that file, so 'static' it is in this patch. Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 19 6月, 2009 1 次提交
-
-
由 Stephen Boyd 提交于
Don't call git_config after parsing the command line options, otherwise the config settings will override any settings made by the command line. This can be seen by setting add.ignore_errors and then specifying --no-ignore-errors when using git-add. Signed-off-by: NStephen Boyd <bebarino@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 25 5月, 2009 1 次提交
-
-
由 Stephen Boyd 提交于
To give OPT_FILENAME the prefix, we pass the prefix to parse_options() which passes the prefix to parse_options_start() which sets the prefix member of parse_opts_ctx accordingly. If there isn't a prefix in the calling context, passing NULL will suffice. Signed-off-by: NStephen Boyd <bebarino@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 09 5月, 2009 1 次提交
-
-
由 Jeff King 提交于
We try to warn the user if one of their pathspecs caused no matches, as it may have been a typo. However, we disable the warning if the pathspec points to an existing file, since that means it is not a typo but simply an empty directory. Unfortunately, the file_exists() test was broken for one special case: the pathspec of the project root is just "". This patch detects this special case and acts as if the file exists (which it must, since it is the project root). The user-visible effect is that this: $ mkdir repo && cd repo && git init && git add . used to complain like: fatal: pathspec '' did not match any files but now is a silent no-op. Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 13 4月, 2009 1 次提交
-
-
由 Johannes Schindelin 提交于
With "git add -e [<files>]", Git will fire up an editor with the current diff relative to the index (i.e. what you would get with "git diff [<files>]"). Now you can edit the patch as much as you like, including adding/removing lines, editing the text, whatever. Make sure, though, that the first character of the hunk lines is still a space, a plus or a minus. After you closed the editor, Git will adjust the line counts of the hunks if necessary, thanks to the --recount option of apply, and commit the patch. Except if you deleted everything, in which case nothing happens (for obvious reasons). Signed-off-by: NJohannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 25 2月, 2009 1 次提交
-
-
由 Felipe Contreras 提交于
Global static variables don't need to be initialized to 0/NULL. Signed-off-by: NFelipe Contreras <felipe.contreras@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 19 2月, 2009 1 次提交
-
-
由 Johannes Schindelin 提交于
By having flags represented as bits in the new member variable 'flags', it will be easier to use parse_options when dir_struct is involved. Signed-off-by: NJohannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 10 2月, 2009 1 次提交
-
-
由 Kjetil Barvik 提交于
Swap function argument pair (length, string) into (string, length) to conform with the commonly used order inside the GIT source code. Also, add a note about this fact into the coding guidelines. Signed-off-by: NKjetil Barvik <barvik@broadpark.no> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 06 1月, 2009 1 次提交
-
-
由 Johannes Schindelin 提交于
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: NJohannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 11 12月, 2008 1 次提交
-
-
由 Alexander Potashev 提交于
Reported-by: NTim Daly <daly@axiom-developer.org> Signed-off-by: NAlexander Potashev <aspotashev@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 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>
-