- 03 3月, 2007 1 次提交
-
-
由 Johannes Sixt 提交于
Some file systems that can host git repositories and their working copies do not support symbolic links. But then if the repository contains a symbolic link, it is impossible to check out the working copy. This patch enables partial support of symbolic links so that it is possible to check out a working copy on such a file system. A new flag core.symlinks (which is true by default) can be set to false to indicate that the filesystem does not support symbolic links. In this case, symbolic links that exist in the trees are checked out as small plain files, and checking in modifications of these files preserve the symlink property in the database (as long as an entry exists in the index). Of course, this does not magically make symbolic links work on such defective file systems; hence, this solution does not help if the working copy relies on that an entry is a real symbolic link. Signed-off-by: NJohannes Sixt <johannes.sixt@telecom.at> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 01 3月, 2007 2 次提交
-
-
由 Junio C Hamano 提交于
Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 27 2月, 2007 1 次提交
-
-
由 Nicolas Pitre 提交于
We currently have two parallel notation for dealing with object types in the code: a string and a numerical value. One of them is obviously redundent, and the most used one requires more stack space and a bunch of strcmp() all over the place. This is an initial step for the removal of the version using a char array found in object reading code paths. The patch is unfortunately large but there is no sane way to split it in smaller parts without breaking the system. Signed-off-by: NNicolas Pitre <nico@cam.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 17 2月, 2007 1 次提交
-
-
由 Junio C Hamano 提交于
When we do not trust executable bit from lstat(2), we copied existing ce_mode bits without checking if the filesystem object is a regular file (which is the only thing we apply the "trust executable bit" business) nor if the blob in the index is a regular file (otherwise, we should do the same as registering a new regular file, which is to default non-executable). Noticed by Johannes Sixt. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 12 1月, 2007 1 次提交
-
-
由 Linus Torvalds 提交于
It is not used after getting written, and just is leaking every time we write the index out. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 09 1月, 2007 1 次提交
-
-
由 Andy Whitcroft 提交于
We have a number of badly checked write() calls. Often we are expecting write() to write exactly the size we requested or fail, this fails to handle interrupts or short writes. Switch to using the new write_in_full(). Otherwise we at a minimum need to check for EINTR and EAGAIN, where this is appropriate use xwrite(). Note, the changes to config handling are much larger and handled in the next patch in the sequence. Signed-off-by: NAndy Whitcroft <apw@shadowen.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 30 12月, 2006 2 次提交
-
-
由 Shawn O. Pearce 提交于
When I converted the mmap() call to xmmap() I failed to cleanup the way this routine handles errors and left some crufty code behind. This is a small cleanup, suggested by Johannes. Signed-off-by: NShawn O. Pearce <spearce@spearce.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Shawn O. Pearce 提交于
In some cases we did not even bother to check the return value of mmap() and just assume it worked. This is bad, because if we are out of virtual address space the kernel returned MAP_FAILED and we would attempt to dereference that address, segfaulting without any real error output to the user. We are replacing all calls to mmap() with xmmap() and moving all MAP_FAILED checking into that single location. If a mmap call fails we try to release enough least-recently-used pack windows to possibly succeed, then retry the mmap() attempt. If we cannot mmap even after releasing pack memory then we die() as none of our callers have any reasonable recovery strategy for a failed mmap. Signed-off-by: NShawn O. Pearce <spearce@spearce.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 17 12月, 2006 3 次提交
-
-
由 Junio C Hamano 提交于
When replacing an existing file A with a directory A that has a file A/B in it in the index, 'update-index --replace --add A/B' did not properly remove the file to make room for the new directory. There was a trivial logic error, most likely a cut & paste one, dating back to quite early days of git. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
When replacing an existing file A with a directory A that has a file A/B in it in the index, 'git add' did not succeed because it forgot to pass the allow-replace flag to add_cache_entry(). It might be safer to leave this as an error and require the user to explicitly remove the existing A first before adding A/B since it is an unusual case, but doing that automatically is much easier to use. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
When you remove a directory D that has a tracked file D/F out of the way to create a file D and try to "git update-index --add D", it used to say "cannot add" which was not very helpful. This issues an extra error message to explain the situation before the final "fatal" message. Since D/F conflicts are relatively rare event, extra verbosity would not make things too noisy. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 23 11月, 2006 1 次提交
-
-
由 Junio C Hamano 提交于
An earlier commit f28b34a broke symlinks when trust-executable-bit is not set because it incorrectly assumed that everything was a regular file. Reported by Juergen Ruehle. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 19 11月, 2006 1 次提交
-
-
由 Rene Scharfe 提交于
The declaration of discard_cache() in cache.h already has its "void". Signed-off-by: NRene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 27 9月, 2006 1 次提交
-
-
由 Shawn Pearce 提交于
If the user has configured core.filemode=0 then we shouldn't set the execute bit in the index when adding a new file as the user has indicated that the local filesystem can't be trusted. This means that when adding files that should be marked executable in a repository with core.filemode=0 the user must perform a 'git update-index --chmod=+x' on the file before committing the addition. Signed-off-by: NShawn O. Pearce <spearce@spearce.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 18 8月, 2006 1 次提交
-
-
由 David Rientjes 提交于
Introduces global inline: hashcmp(const unsigned char *sha1, const unsigned char *sha2) Uses memcmp for comparison and returns the result based on the length of the hash name (a future runtime decision). Acked-by: NAlex Riesen <raa.lkml@gmail.com> Signed-off-by: NDavid Rientjes <rientjes@google.com> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 16 8月, 2006 3 次提交
-
-
由 Junio C Hamano 提交于
The work-around should not be needed. Even if it turns out we would want it later, git will remember the patch for us ;-). Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
This will help counting the racily clean paths, but it should be useless for daily use. Do not even enable it in the makefile. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 David Rientjes 提交于
[jc: I needed to hand merge the changes to the updated codebase, so the result needs to be checked.] Signed-off-by: NDavid Rientjes <rientjes@google.com> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 15 8月, 2006 2 次提交
-
-
由 Junio C Hamano 提交于
On Solaris nanosleep(2) is not available in libc; you need to link with -lrt to get it. The purpose of the loop is to wait until the next filesystem timestamp granularity, and the code uses subsecond sleep in the hope that it can shorten the delay to 0.5 seconds on average instead of a full second. It is probably not worth depending on an extra library for this. We might want to yank out the whole "racy-git avoidance is costly later at runtime, so let's delay writing the index out" codepath later, but that is a separate issue and needs some testing on large trees to figure it out. After playing with the kernel tree, I have a feeling that the whole thing may not be worth it. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 David Rientjes 提交于
Removes conditional returns. Signed-off-by: NDavid Rientjes <rientjes@google.com> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 11 8月, 2006 1 次提交
-
-
由 Johannes Schindelin 提交于
Since add_cacheinfo() can be called without a mapped index file, discard_cache() _has_ to discard the entries, even when cache_mmap == NULL. Signed-off-by: NJohannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 09 8月, 2006 1 次提交
-
-
由 Junio C Hamano 提交于
Instead of looping over the entries and writing out, use a separate loop after all entries have been written out to check how many entries are racily clean. Make sure that the newly created index file gets the right timestamp when we check by flushing the buffered data by ce_write(). Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 07 8月, 2006 1 次提交
-
-
由 Junio C Hamano 提交于
Immediately after a bulk checkout, most of the paths in the working tree would have the same timestamp as the index file, and this would force ce_match_stat() to take slow path for all of them. When writing an index file out, if many of the paths have very new (read: the same timestamp as the index file being written out) timestamp, we are better off delaying the return from the command, to make sure that later command to touch the working tree files will leave newer timestamps than recorded in the index, thereby avoiding to take the slow path. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 01 8月, 2006 1 次提交
-
-
由 Linus Torvalds 提交于
Doing an "strace" on "git diff" shows that we close() a file descriptor twice (getting EBADFD on the second one) when we end up in ce_compare_data if the index does not match the checked-out stat information. The "index_fd()" function will already have closed the fd for us, so we should not close it again. Signed-off-by: NLinus Torvalds <torvalds@osdl.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 27 7月, 2006 2 次提交
-
-
由 Johannes Schindelin 提交于
This also moves add_file_to_index() to read-cache.c. Oh, and while touching builtin-add.c, it also removes a duplicate git_config() call. Signed-off-by: NJohannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Johannes Schindelin 提交于
This backports the pieces that are not uncooked from the merge-recursive WIP we have seen earlier, to be used in git-mv rewritten in C. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 14 7月, 2006 1 次提交
-
-
由 Johannes Schindelin 提交于
This is just an update for people being interested. Alex and me were busy with that project for a few days now. While it has progressed nicely, there are quite a couple TODOs in merge-recursive.c, just search for "TODO". For impatient people: yes, it passes all the tests, and yes, according to the evil test Alex did, it is faster than the Python script. But no, it is not yet finished. Biggest points are: - there are still three external calls - in the end, it should not be necessary to write the index more than once (just before exiting) - a lot of things can be refactored to make the code easier and shorter BTW we cannot just plug in git-merge-tree yet, because git-merge-tree does not handle renames at all. This patch is meant for testing, and as such, - it compile the program to git-merge-recur - it adjusts the scripts and tests to use git-merge-recur instead of git-merge-recursive - it provides "TEST", a script to execute the tests regarding -recursive - it inlines the changes to read-cache.c (read_cache_from(), discard_cache() and refresh_cache_entry()) Brought to you by Alex Riesen and Dscho Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 10 7月, 2006 1 次提交
-
-
由 Pavel Roskin 提交于
This doesn't make the code uglier or harder to read, yet it makes the code more portable. This also simplifies checking for other potential incompatibilities. "gcc -std=c89 -pedantic" can flag many incompatible constructs as warnings, but C99 comments will cause it to emit an error. Signed-off-by: NPavel Roskin <proski@gnu.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 20 6月, 2006 1 次提交
-
-
由 Florian Forster 提交于
ANSI C99 doesn't allow void-pointer arithmetic. This patch fixes this in various ways. Usually the strategy that required the least changes was used. Signed-off-by: NFlorian Forster <octo@verplant.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 29 5月, 2006 1 次提交
-
-
由 Dennis Stosberg 提交于
In the "next" branch, write_index_ext_header() writes garbage on a 64-bit big-endian machine; the written index file will be unreadable. I noticed this on NetBSD/sparc64. Reproducible with: $ git init-db $ :>file $ git-update-index --add file $ git-write-tree $ git-update-index error: index uses extension, which we do not understand fatal: index file corrupt Signed-off-by: NDennis Stosberg <dennis@stosberg.net> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 20 5月, 2006 1 次提交
-
-
由 Linus Torvalds 提交于
This cleans up and libifies the "git update-index --[really-]refresh" functionality. This will be eventually required for eventually doing the "commit" and "status" commands as built-ins. It really just moves "refresh_index()" from update-index.c to read-cache.c, but it also has to change the calling convention so that the function uses a "unsigned int flags" argument instead of various static flags variables for passing down the information about whether to be quiet or not, and allow unmerged entries etc. That actually cleans up update-index.c too, since it turns out that all those flags were really specific to that one function of the index update, so they shouldn't have had file-scope visibility even before. Signed-off-by: NLinus Torvalds <torvalds@osdl.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 19 5月, 2006 1 次提交
-
-
由 Linus Torvalds 提交于
With this one, it's now a fatal error to try to add a pathname that cannot be added with "git add", i.e. [torvalds@g5 git]$ git add .git/config fatal: unable to add .git/config to index and [torvalds@g5 git]$ git add foo/../bar fatal: unable to add foo/../bar to index instead of the old "Ignoring path xyz" warning that would end up silently succeeding on any other paths. Signed-off-by: NLinus Torvalds <torvalds@osdl.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 09 5月, 2006 1 次提交
-
-
由 Yakov Lerner 提交于
Elsewhere we use xcalloc(); we should consistently do so. Signed-off-by: NYakov Lerner <iler.ml@gmail.com> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 25 4月, 2006 1 次提交
-
-
由 Junio C Hamano 提交于
... and move the cache-tree data into it. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 24 4月, 2006 1 次提交
-
-
由 Junio C Hamano 提交于
read_cache_1() and write_cache_1() takes an extra parameter *sha1 that returns the checksum of the index file when non-NULL. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 13 2月, 2006 1 次提交
-
-
由 Junio C Hamano 提交于
The code was a bit unclear in expressing what it wants to compare. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 09 2月, 2006 1 次提交
-
-
由 Junio C Hamano 提交于
This adds "assume unchanged" logic, started by this message in the list discussion recently: <Pine.LNX.4.64.0601311807470.7301@g5.osdl.org> This is a workaround for filesystems that do not have lstat() that is quick enough for the index mechanism to take advantage of. On the paths marked as "assumed to be unchanged", the user needs to explicitly use update-index to register the object name to be in the next commit. You can use two new options to update-index to set and reset the CE_VALID bit: git-update-index --assume-unchanged path... git-update-index --no-assume-unchanged path... These forms manipulate only the CE_VALID bit; it does not change the object name recorded in the index file. Nor they add a new entry to the index. When the configuration variable "core.ignorestat = true" is set, the index entries are marked with CE_VALID bit automatically after: - update-index to explicitly register the current object name to the index file. - when update-index --refresh finds the path to be up-to-date. - when tools like read-tree -u and apply --index update the working tree file and register the current object name to the index file. The flag is dropped upon read-tree that does not check out the index entry. This happens regardless of the core.ignorestat settings. Index entries marked with CE_VALID bit are assumed to be unchanged most of the time. However, there are cases that CE_VALID bit is ignored for the sake of safety and usability: - while "git-read-tree -m" or git-apply need to make sure that the paths involved in the merge do not have local modifications. This sacrifices performance for safety. - when git-checkout-index -f -q -u -a tries to see if it needs to checkout the paths. Otherwise you can never check anything out ;-). - when git-update-index --really-refresh (a new flag) tries to see if the index entry is up to date. You can start with everything marked as CE_VALID and run this once to drop CE_VALID bit for paths that are modified. Most notably, "update-index --refresh" honours CE_VALID and does not actively stat, so after you modified a file in the working tree, update-index --refresh would not notice until you tell the index about it with "git-update-index path" or "git-update-index --no-assume-unchanged path". This version is not expected to be perfect. I think diff between index and/or tree and working files may need some adjustment, and there probably needs other cases we should automatically unmark paths that are marked to be CE_VALID. But the basics seem to work, and ready to be tested by people who asked for this feature. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 21 12月, 2005 2 次提交
-
-
由 Junio C Hamano 提交于
This is a tricky code and warrants extra commenting. I wasted 30 minutes trying to break it until I realized why it works. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
The previous round caught the most trivial case well, but broke down once index file is updated again. Smudge problematic entries (they should be very few if any under normal interactive workflow) before writing a new index file out. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-