2005-04-08 06:16:10 +08:00
|
|
|
/*
|
|
|
|
* GIT - The information manager from hell
|
|
|
|
*
|
|
|
|
* Copyright (C) Linus Torvalds, 2005
|
|
|
|
*/
|
2005-04-08 06:13:13 +08:00
|
|
|
#include "cache.h"
|
2006-04-25 12:18:58 +08:00
|
|
|
#include "cache-tree.h"
|
2007-04-10 12:20:29 +08:00
|
|
|
#include "refs.h"
|
2006-04-25 12:18:58 +08:00
|
|
|
|
|
|
|
/* Index extensions.
|
|
|
|
*
|
|
|
|
* The first letter should be 'A'..'Z' for extensions that are not
|
|
|
|
* necessary for a correct operation (i.e. optimization data).
|
|
|
|
* When new extensions are added that _needs_ to be understood in
|
|
|
|
* order to correctly interpret the index file, pick character that
|
|
|
|
* is outside the range, to cause the reader to abort.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#define CACHE_EXT(s) ( (s[0]<<24)|(s[1]<<16)|(s[2]<<8)|(s[3]) )
|
|
|
|
#define CACHE_EXT_TREE 0x54524545 /* "TREE" */
|
2005-04-08 06:13:13 +08:00
|
|
|
|
2006-08-16 01:23:48 +08:00
|
|
|
struct cache_entry **active_cache;
|
Racy GIT
This fixes the longstanding "Racy GIT" problem, which was pretty
much there from the beginning of time, but was first
demonstrated by Pasky in this message on October 24, 2005:
http://marc.theaimsgroup.com/?l=git&m=113014629716878
If you run the following sequence of commands:
echo frotz >infocom
git update-index --add infocom
echo xyzzy >infocom
so that the second update to file "infocom" does not change
st_mtime, what is recorded as the stat information for the cache
entry "infocom" exactly matches what is on the filesystem
(owner, group, inum, mtime, ctime, mode, length). After this
sequence, we incorrectly think "infocom" file still has string
"frotz" in it, and get really confused. E.g. git-diff-files
would say there is no change, git-update-index --refresh would
not even look at the filesystem to correct the situation.
Some ways of working around this issue were already suggested by
Linus in the same thread on the same day, including waiting
until the next second before returning from update-index if a
cache entry written out has the current timestamp, but that
means we can make at most one commit per second, and given that
the e-mail patch workflow used by Linus needs to process at
least 5 commits per second, it is not an acceptable solution.
Linus notes that git-apply is primarily used to update the index
while processing e-mailed patches, which is true, and
git-apply's up-to-date check is fooled by the same problem but
luckily in the other direction, so it is not really a big issue,
but still it is disturbing.
The function ce_match_stat() is called to bypass the comparison
against filesystem data when the stat data recorded in the cache
entry matches what stat() returns from the filesystem. This
patch tackles the problem by changing it to actually go to the
filesystem data for cache entries that have the same mtime as
the index file itself. This works as long as the index file and
working tree files are on the filesystems that share the same
monotonic clock. Files on network mounted filesystems sometimes
get skewed timestamps compared to "date" output, but as long as
working tree files' timestamps are skewed the same way as the
index file's, this approach still works. The only problematic
files are the ones that have the same timestamp as the index
file's, because two file updates that sandwitch the index file
update must happen within the same second to trigger the
problem.
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-20 16:02:15 +08:00
|
|
|
static time_t index_file_timestamp;
|
2006-08-16 01:23:48 +08:00
|
|
|
unsigned int active_nr, active_alloc, active_cache_changed;
|
2005-04-08 06:13:13 +08:00
|
|
|
|
2006-08-16 01:23:48 +08:00
|
|
|
struct cache_tree *active_cache_tree;
|
2006-04-25 12:18:58 +08:00
|
|
|
|
2006-08-16 01:23:48 +08:00
|
|
|
static void *cache_mmap;
|
|
|
|
static size_t cache_mmap_size;
|
2006-07-26 12:32:18 +08:00
|
|
|
|
2005-05-16 05:23:12 +08:00
|
|
|
/*
|
|
|
|
* This only updates the "non-critical" parts of the directory
|
|
|
|
* cache, ie the parts that aren't tracked by GIT, and only used
|
|
|
|
* to validate the cache.
|
|
|
|
*/
|
|
|
|
void fill_stat_cache_info(struct cache_entry *ce, struct stat *st)
|
|
|
|
{
|
|
|
|
ce->ce_ctime.sec = htonl(st->st_ctime);
|
|
|
|
ce->ce_mtime.sec = htonl(st->st_mtime);
|
2005-05-23 06:08:15 +08:00
|
|
|
#ifdef USE_NSEC
|
2005-05-16 05:23:12 +08:00
|
|
|
ce->ce_ctime.nsec = htonl(st->st_ctim.tv_nsec);
|
|
|
|
ce->ce_mtime.nsec = htonl(st->st_mtim.tv_nsec);
|
|
|
|
#endif
|
|
|
|
ce->ce_dev = htonl(st->st_dev);
|
|
|
|
ce->ce_ino = htonl(st->st_ino);
|
|
|
|
ce->ce_uid = htonl(st->st_uid);
|
|
|
|
ce->ce_gid = htonl(st->st_gid);
|
|
|
|
ce->ce_size = htonl(st->st_size);
|
2006-02-09 13:15:24 +08:00
|
|
|
|
|
|
|
if (assume_unchanged)
|
|
|
|
ce->ce_flags |= htons(CE_VALID);
|
2005-05-16 05:23:12 +08:00
|
|
|
}
|
|
|
|
|
Racy GIT
This fixes the longstanding "Racy GIT" problem, which was pretty
much there from the beginning of time, but was first
demonstrated by Pasky in this message on October 24, 2005:
http://marc.theaimsgroup.com/?l=git&m=113014629716878
If you run the following sequence of commands:
echo frotz >infocom
git update-index --add infocom
echo xyzzy >infocom
so that the second update to file "infocom" does not change
st_mtime, what is recorded as the stat information for the cache
entry "infocom" exactly matches what is on the filesystem
(owner, group, inum, mtime, ctime, mode, length). After this
sequence, we incorrectly think "infocom" file still has string
"frotz" in it, and get really confused. E.g. git-diff-files
would say there is no change, git-update-index --refresh would
not even look at the filesystem to correct the situation.
Some ways of working around this issue were already suggested by
Linus in the same thread on the same day, including waiting
until the next second before returning from update-index if a
cache entry written out has the current timestamp, but that
means we can make at most one commit per second, and given that
the e-mail patch workflow used by Linus needs to process at
least 5 commits per second, it is not an acceptable solution.
Linus notes that git-apply is primarily used to update the index
while processing e-mailed patches, which is true, and
git-apply's up-to-date check is fooled by the same problem but
luckily in the other direction, so it is not really a big issue,
but still it is disturbing.
The function ce_match_stat() is called to bypass the comparison
against filesystem data when the stat data recorded in the cache
entry matches what stat() returns from the filesystem. This
patch tackles the problem by changing it to actually go to the
filesystem data for cache entries that have the same mtime as
the index file itself. This works as long as the index file and
working tree files are on the filesystems that share the same
monotonic clock. Files on network mounted filesystems sometimes
get skewed timestamps compared to "date" output, but as long as
working tree files' timestamps are skewed the same way as the
index file's, this approach still works. The only problematic
files are the ones that have the same timestamp as the index
file's, because two file updates that sandwitch the index file
update must happen within the same second to trigger the
problem.
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-20 16:02:15 +08:00
|
|
|
static int ce_compare_data(struct cache_entry *ce, struct stat *st)
|
|
|
|
{
|
|
|
|
int match = -1;
|
|
|
|
int fd = open(ce->name, O_RDONLY);
|
|
|
|
|
|
|
|
if (fd >= 0) {
|
|
|
|
unsigned char sha1[20];
|
2007-03-01 03:52:04 +08:00
|
|
|
if (!index_fd(sha1, fd, st, 0, OBJ_BLOB, ce->name))
|
2006-08-18 02:54:57 +08:00
|
|
|
match = hashcmp(sha1, ce->sha1);
|
2006-08-01 00:55:15 +08:00
|
|
|
/* index_fd() closed the file descriptor already */
|
Racy GIT
This fixes the longstanding "Racy GIT" problem, which was pretty
much there from the beginning of time, but was first
demonstrated by Pasky in this message on October 24, 2005:
http://marc.theaimsgroup.com/?l=git&m=113014629716878
If you run the following sequence of commands:
echo frotz >infocom
git update-index --add infocom
echo xyzzy >infocom
so that the second update to file "infocom" does not change
st_mtime, what is recorded as the stat information for the cache
entry "infocom" exactly matches what is on the filesystem
(owner, group, inum, mtime, ctime, mode, length). After this
sequence, we incorrectly think "infocom" file still has string
"frotz" in it, and get really confused. E.g. git-diff-files
would say there is no change, git-update-index --refresh would
not even look at the filesystem to correct the situation.
Some ways of working around this issue were already suggested by
Linus in the same thread on the same day, including waiting
until the next second before returning from update-index if a
cache entry written out has the current timestamp, but that
means we can make at most one commit per second, and given that
the e-mail patch workflow used by Linus needs to process at
least 5 commits per second, it is not an acceptable solution.
Linus notes that git-apply is primarily used to update the index
while processing e-mailed patches, which is true, and
git-apply's up-to-date check is fooled by the same problem but
luckily in the other direction, so it is not really a big issue,
but still it is disturbing.
The function ce_match_stat() is called to bypass the comparison
against filesystem data when the stat data recorded in the cache
entry matches what stat() returns from the filesystem. This
patch tackles the problem by changing it to actually go to the
filesystem data for cache entries that have the same mtime as
the index file itself. This works as long as the index file and
working tree files are on the filesystems that share the same
monotonic clock. Files on network mounted filesystems sometimes
get skewed timestamps compared to "date" output, but as long as
working tree files' timestamps are skewed the same way as the
index file's, this approach still works. The only problematic
files are the ones that have the same timestamp as the index
file's, because two file updates that sandwitch the index file
update must happen within the same second to trigger the
problem.
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-20 16:02:15 +08:00
|
|
|
}
|
|
|
|
return match;
|
|
|
|
}
|
|
|
|
|
2007-03-07 09:44:37 +08:00
|
|
|
static int ce_compare_link(struct cache_entry *ce, size_t expected_size)
|
Racy GIT
This fixes the longstanding "Racy GIT" problem, which was pretty
much there from the beginning of time, but was first
demonstrated by Pasky in this message on October 24, 2005:
http://marc.theaimsgroup.com/?l=git&m=113014629716878
If you run the following sequence of commands:
echo frotz >infocom
git update-index --add infocom
echo xyzzy >infocom
so that the second update to file "infocom" does not change
st_mtime, what is recorded as the stat information for the cache
entry "infocom" exactly matches what is on the filesystem
(owner, group, inum, mtime, ctime, mode, length). After this
sequence, we incorrectly think "infocom" file still has string
"frotz" in it, and get really confused. E.g. git-diff-files
would say there is no change, git-update-index --refresh would
not even look at the filesystem to correct the situation.
Some ways of working around this issue were already suggested by
Linus in the same thread on the same day, including waiting
until the next second before returning from update-index if a
cache entry written out has the current timestamp, but that
means we can make at most one commit per second, and given that
the e-mail patch workflow used by Linus needs to process at
least 5 commits per second, it is not an acceptable solution.
Linus notes that git-apply is primarily used to update the index
while processing e-mailed patches, which is true, and
git-apply's up-to-date check is fooled by the same problem but
luckily in the other direction, so it is not really a big issue,
but still it is disturbing.
The function ce_match_stat() is called to bypass the comparison
against filesystem data when the stat data recorded in the cache
entry matches what stat() returns from the filesystem. This
patch tackles the problem by changing it to actually go to the
filesystem data for cache entries that have the same mtime as
the index file itself. This works as long as the index file and
working tree files are on the filesystems that share the same
monotonic clock. Files on network mounted filesystems sometimes
get skewed timestamps compared to "date" output, but as long as
working tree files' timestamps are skewed the same way as the
index file's, this approach still works. The only problematic
files are the ones that have the same timestamp as the index
file's, because two file updates that sandwitch the index file
update must happen within the same second to trigger the
problem.
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-20 16:02:15 +08:00
|
|
|
{
|
|
|
|
int match = -1;
|
|
|
|
char *target;
|
|
|
|
void *buffer;
|
|
|
|
unsigned long size;
|
2007-02-27 03:55:59 +08:00
|
|
|
enum object_type type;
|
Racy GIT
This fixes the longstanding "Racy GIT" problem, which was pretty
much there from the beginning of time, but was first
demonstrated by Pasky in this message on October 24, 2005:
http://marc.theaimsgroup.com/?l=git&m=113014629716878
If you run the following sequence of commands:
echo frotz >infocom
git update-index --add infocom
echo xyzzy >infocom
so that the second update to file "infocom" does not change
st_mtime, what is recorded as the stat information for the cache
entry "infocom" exactly matches what is on the filesystem
(owner, group, inum, mtime, ctime, mode, length). After this
sequence, we incorrectly think "infocom" file still has string
"frotz" in it, and get really confused. E.g. git-diff-files
would say there is no change, git-update-index --refresh would
not even look at the filesystem to correct the situation.
Some ways of working around this issue were already suggested by
Linus in the same thread on the same day, including waiting
until the next second before returning from update-index if a
cache entry written out has the current timestamp, but that
means we can make at most one commit per second, and given that
the e-mail patch workflow used by Linus needs to process at
least 5 commits per second, it is not an acceptable solution.
Linus notes that git-apply is primarily used to update the index
while processing e-mailed patches, which is true, and
git-apply's up-to-date check is fooled by the same problem but
luckily in the other direction, so it is not really a big issue,
but still it is disturbing.
The function ce_match_stat() is called to bypass the comparison
against filesystem data when the stat data recorded in the cache
entry matches what stat() returns from the filesystem. This
patch tackles the problem by changing it to actually go to the
filesystem data for cache entries that have the same mtime as
the index file itself. This works as long as the index file and
working tree files are on the filesystems that share the same
monotonic clock. Files on network mounted filesystems sometimes
get skewed timestamps compared to "date" output, but as long as
working tree files' timestamps are skewed the same way as the
index file's, this approach still works. The only problematic
files are the ones that have the same timestamp as the index
file's, because two file updates that sandwitch the index file
update must happen within the same second to trigger the
problem.
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-20 16:02:15 +08:00
|
|
|
int len;
|
|
|
|
|
|
|
|
target = xmalloc(expected_size);
|
|
|
|
len = readlink(ce->name, target, expected_size);
|
|
|
|
if (len != expected_size) {
|
|
|
|
free(target);
|
|
|
|
return -1;
|
|
|
|
}
|
2007-02-27 03:55:59 +08:00
|
|
|
buffer = read_sha1_file(ce->sha1, &type, &size);
|
Racy GIT
This fixes the longstanding "Racy GIT" problem, which was pretty
much there from the beginning of time, but was first
demonstrated by Pasky in this message on October 24, 2005:
http://marc.theaimsgroup.com/?l=git&m=113014629716878
If you run the following sequence of commands:
echo frotz >infocom
git update-index --add infocom
echo xyzzy >infocom
so that the second update to file "infocom" does not change
st_mtime, what is recorded as the stat information for the cache
entry "infocom" exactly matches what is on the filesystem
(owner, group, inum, mtime, ctime, mode, length). After this
sequence, we incorrectly think "infocom" file still has string
"frotz" in it, and get really confused. E.g. git-diff-files
would say there is no change, git-update-index --refresh would
not even look at the filesystem to correct the situation.
Some ways of working around this issue were already suggested by
Linus in the same thread on the same day, including waiting
until the next second before returning from update-index if a
cache entry written out has the current timestamp, but that
means we can make at most one commit per second, and given that
the e-mail patch workflow used by Linus needs to process at
least 5 commits per second, it is not an acceptable solution.
Linus notes that git-apply is primarily used to update the index
while processing e-mailed patches, which is true, and
git-apply's up-to-date check is fooled by the same problem but
luckily in the other direction, so it is not really a big issue,
but still it is disturbing.
The function ce_match_stat() is called to bypass the comparison
against filesystem data when the stat data recorded in the cache
entry matches what stat() returns from the filesystem. This
patch tackles the problem by changing it to actually go to the
filesystem data for cache entries that have the same mtime as
the index file itself. This works as long as the index file and
working tree files are on the filesystems that share the same
monotonic clock. Files on network mounted filesystems sometimes
get skewed timestamps compared to "date" output, but as long as
working tree files' timestamps are skewed the same way as the
index file's, this approach still works. The only problematic
files are the ones that have the same timestamp as the index
file's, because two file updates that sandwitch the index file
update must happen within the same second to trigger the
problem.
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-20 16:02:15 +08:00
|
|
|
if (!buffer) {
|
|
|
|
free(target);
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
if (size == expected_size)
|
|
|
|
match = memcmp(buffer, target, size);
|
|
|
|
free(buffer);
|
|
|
|
free(target);
|
|
|
|
return match;
|
|
|
|
}
|
|
|
|
|
2007-04-10 12:20:29 +08:00
|
|
|
static int ce_compare_gitlink(struct cache_entry *ce)
|
|
|
|
{
|
|
|
|
unsigned char sha1[20];
|
|
|
|
|
|
|
|
/*
|
|
|
|
* We don't actually require that the .git directory
|
|
|
|
* under DIRLNK directory be a valid git directory. It
|
|
|
|
* might even be missing (in case nobody populated that
|
|
|
|
* sub-project).
|
|
|
|
*
|
|
|
|
* If so, we consider it always to match.
|
|
|
|
*/
|
|
|
|
if (resolve_gitlink_ref(ce->name, "HEAD", sha1) < 0)
|
|
|
|
return 0;
|
|
|
|
return hashcmp(sha1, ce->sha1);
|
|
|
|
}
|
|
|
|
|
Racy GIT
This fixes the longstanding "Racy GIT" problem, which was pretty
much there from the beginning of time, but was first
demonstrated by Pasky in this message on October 24, 2005:
http://marc.theaimsgroup.com/?l=git&m=113014629716878
If you run the following sequence of commands:
echo frotz >infocom
git update-index --add infocom
echo xyzzy >infocom
so that the second update to file "infocom" does not change
st_mtime, what is recorded as the stat information for the cache
entry "infocom" exactly matches what is on the filesystem
(owner, group, inum, mtime, ctime, mode, length). After this
sequence, we incorrectly think "infocom" file still has string
"frotz" in it, and get really confused. E.g. git-diff-files
would say there is no change, git-update-index --refresh would
not even look at the filesystem to correct the situation.
Some ways of working around this issue were already suggested by
Linus in the same thread on the same day, including waiting
until the next second before returning from update-index if a
cache entry written out has the current timestamp, but that
means we can make at most one commit per second, and given that
the e-mail patch workflow used by Linus needs to process at
least 5 commits per second, it is not an acceptable solution.
Linus notes that git-apply is primarily used to update the index
while processing e-mailed patches, which is true, and
git-apply's up-to-date check is fooled by the same problem but
luckily in the other direction, so it is not really a big issue,
but still it is disturbing.
The function ce_match_stat() is called to bypass the comparison
against filesystem data when the stat data recorded in the cache
entry matches what stat() returns from the filesystem. This
patch tackles the problem by changing it to actually go to the
filesystem data for cache entries that have the same mtime as
the index file itself. This works as long as the index file and
working tree files are on the filesystems that share the same
monotonic clock. Files on network mounted filesystems sometimes
get skewed timestamps compared to "date" output, but as long as
working tree files' timestamps are skewed the same way as the
index file's, this approach still works. The only problematic
files are the ones that have the same timestamp as the index
file's, because two file updates that sandwitch the index file
update must happen within the same second to trigger the
problem.
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-20 16:02:15 +08:00
|
|
|
static int ce_modified_check_fs(struct cache_entry *ce, struct stat *st)
|
|
|
|
{
|
|
|
|
switch (st->st_mode & S_IFMT) {
|
|
|
|
case S_IFREG:
|
|
|
|
if (ce_compare_data(ce, st))
|
|
|
|
return DATA_CHANGED;
|
|
|
|
break;
|
|
|
|
case S_IFLNK:
|
2007-03-07 09:44:37 +08:00
|
|
|
if (ce_compare_link(ce, xsize_t(st->st_size)))
|
Racy GIT
This fixes the longstanding "Racy GIT" problem, which was pretty
much there from the beginning of time, but was first
demonstrated by Pasky in this message on October 24, 2005:
http://marc.theaimsgroup.com/?l=git&m=113014629716878
If you run the following sequence of commands:
echo frotz >infocom
git update-index --add infocom
echo xyzzy >infocom
so that the second update to file "infocom" does not change
st_mtime, what is recorded as the stat information for the cache
entry "infocom" exactly matches what is on the filesystem
(owner, group, inum, mtime, ctime, mode, length). After this
sequence, we incorrectly think "infocom" file still has string
"frotz" in it, and get really confused. E.g. git-diff-files
would say there is no change, git-update-index --refresh would
not even look at the filesystem to correct the situation.
Some ways of working around this issue were already suggested by
Linus in the same thread on the same day, including waiting
until the next second before returning from update-index if a
cache entry written out has the current timestamp, but that
means we can make at most one commit per second, and given that
the e-mail patch workflow used by Linus needs to process at
least 5 commits per second, it is not an acceptable solution.
Linus notes that git-apply is primarily used to update the index
while processing e-mailed patches, which is true, and
git-apply's up-to-date check is fooled by the same problem but
luckily in the other direction, so it is not really a big issue,
but still it is disturbing.
The function ce_match_stat() is called to bypass the comparison
against filesystem data when the stat data recorded in the cache
entry matches what stat() returns from the filesystem. This
patch tackles the problem by changing it to actually go to the
filesystem data for cache entries that have the same mtime as
the index file itself. This works as long as the index file and
working tree files are on the filesystems that share the same
monotonic clock. Files on network mounted filesystems sometimes
get skewed timestamps compared to "date" output, but as long as
working tree files' timestamps are skewed the same way as the
index file's, this approach still works. The only problematic
files are the ones that have the same timestamp as the index
file's, because two file updates that sandwitch the index file
update must happen within the same second to trigger the
problem.
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-20 16:02:15 +08:00
|
|
|
return DATA_CHANGED;
|
|
|
|
break;
|
2007-04-10 12:20:29 +08:00
|
|
|
case S_IFDIRLNK:
|
|
|
|
/* No need to do anything, we did the exact compare in "match_stat_basic" */
|
|
|
|
break;
|
Racy GIT
This fixes the longstanding "Racy GIT" problem, which was pretty
much there from the beginning of time, but was first
demonstrated by Pasky in this message on October 24, 2005:
http://marc.theaimsgroup.com/?l=git&m=113014629716878
If you run the following sequence of commands:
echo frotz >infocom
git update-index --add infocom
echo xyzzy >infocom
so that the second update to file "infocom" does not change
st_mtime, what is recorded as the stat information for the cache
entry "infocom" exactly matches what is on the filesystem
(owner, group, inum, mtime, ctime, mode, length). After this
sequence, we incorrectly think "infocom" file still has string
"frotz" in it, and get really confused. E.g. git-diff-files
would say there is no change, git-update-index --refresh would
not even look at the filesystem to correct the situation.
Some ways of working around this issue were already suggested by
Linus in the same thread on the same day, including waiting
until the next second before returning from update-index if a
cache entry written out has the current timestamp, but that
means we can make at most one commit per second, and given that
the e-mail patch workflow used by Linus needs to process at
least 5 commits per second, it is not an acceptable solution.
Linus notes that git-apply is primarily used to update the index
while processing e-mailed patches, which is true, and
git-apply's up-to-date check is fooled by the same problem but
luckily in the other direction, so it is not really a big issue,
but still it is disturbing.
The function ce_match_stat() is called to bypass the comparison
against filesystem data when the stat data recorded in the cache
entry matches what stat() returns from the filesystem. This
patch tackles the problem by changing it to actually go to the
filesystem data for cache entries that have the same mtime as
the index file itself. This works as long as the index file and
working tree files are on the filesystems that share the same
monotonic clock. Files on network mounted filesystems sometimes
get skewed timestamps compared to "date" output, but as long as
working tree files' timestamps are skewed the same way as the
index file's, this approach still works. The only problematic
files are the ones that have the same timestamp as the index
file's, because two file updates that sandwitch the index file
update must happen within the same second to trigger the
problem.
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-20 16:02:15 +08:00
|
|
|
default:
|
|
|
|
return TYPE_CHANGED;
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2005-12-21 04:12:18 +08:00
|
|
|
static int ce_match_stat_basic(struct cache_entry *ce, struct stat *st)
|
2005-04-10 00:48:20 +08:00
|
|
|
{
|
|
|
|
unsigned int changed = 0;
|
|
|
|
|
2005-05-05 20:38:25 +08:00
|
|
|
switch (ntohl(ce->ce_mode) & S_IFMT) {
|
|
|
|
case S_IFREG:
|
|
|
|
changed |= !S_ISREG(st->st_mode) ? TYPE_CHANGED : 0;
|
2005-10-12 09:45:33 +08:00
|
|
|
/* We consider only the owner x bit to be relevant for
|
|
|
|
* "mode changes"
|
|
|
|
*/
|
|
|
|
if (trust_executable_bit &&
|
|
|
|
(0100 & (ntohl(ce->ce_mode) ^ st->st_mode)))
|
2005-05-06 21:45:01 +08:00
|
|
|
changed |= MODE_CHANGED;
|
2005-05-05 20:38:25 +08:00
|
|
|
break;
|
|
|
|
case S_IFLNK:
|
2007-03-03 05:11:30 +08:00
|
|
|
if (!S_ISLNK(st->st_mode) &&
|
|
|
|
(has_symlinks || !S_ISREG(st->st_mode)))
|
|
|
|
changed |= TYPE_CHANGED;
|
2005-05-05 20:38:25 +08:00
|
|
|
break;
|
2007-04-10 12:20:29 +08:00
|
|
|
case S_IFDIRLNK:
|
|
|
|
if (!S_ISDIR(st->st_mode))
|
|
|
|
changed |= TYPE_CHANGED;
|
|
|
|
else if (ce_compare_gitlink(ce))
|
|
|
|
changed |= DATA_CHANGED;
|
|
|
|
break;
|
2005-05-05 20:38:25 +08:00
|
|
|
default:
|
|
|
|
die("internal error: ce_mode is %o", ntohl(ce->ce_mode));
|
|
|
|
}
|
2005-04-16 01:44:27 +08:00
|
|
|
if (ce->ce_mtime.sec != htonl(st->st_mtime))
|
2005-04-10 00:48:20 +08:00
|
|
|
changed |= MTIME_CHANGED;
|
2005-04-16 01:44:27 +08:00
|
|
|
if (ce->ce_ctime.sec != htonl(st->st_ctime))
|
|
|
|
changed |= CTIME_CHANGED;
|
|
|
|
|
2005-05-23 06:08:15 +08:00
|
|
|
#ifdef USE_NSEC
|
2005-04-16 01:44:27 +08:00
|
|
|
/*
|
|
|
|
* nsec seems unreliable - not all filesystems support it, so
|
|
|
|
* as long as it is in the inode cache you get right nsec
|
|
|
|
* but after it gets flushed, you get zero nsec.
|
|
|
|
*/
|
2005-04-22 00:58:24 +08:00
|
|
|
if (ce->ce_mtime.nsec != htonl(st->st_mtim.tv_nsec))
|
2005-04-16 01:44:27 +08:00
|
|
|
changed |= MTIME_CHANGED;
|
2005-04-22 00:58:24 +08:00
|
|
|
if (ce->ce_ctime.nsec != htonl(st->st_ctim.tv_nsec))
|
2005-04-10 00:48:20 +08:00
|
|
|
changed |= CTIME_CHANGED;
|
2005-04-16 01:44:27 +08:00
|
|
|
#endif
|
|
|
|
|
|
|
|
if (ce->ce_uid != htonl(st->st_uid) ||
|
|
|
|
ce->ce_gid != htonl(st->st_gid))
|
2005-04-10 00:48:20 +08:00
|
|
|
changed |= OWNER_CHANGED;
|
2005-05-23 06:08:15 +08:00
|
|
|
if (ce->ce_ino != htonl(st->st_ino))
|
2005-04-10 00:48:20 +08:00
|
|
|
changed |= INODE_CHANGED;
|
2005-05-23 06:08:15 +08:00
|
|
|
|
|
|
|
#ifdef USE_STDEV
|
|
|
|
/*
|
|
|
|
* st_dev breaks on network filesystems where different
|
|
|
|
* clients will have different views of what "device"
|
|
|
|
* the filesystem is on
|
|
|
|
*/
|
|
|
|
if (ce->ce_dev != htonl(st->st_dev))
|
|
|
|
changed |= INODE_CHANGED;
|
|
|
|
#endif
|
|
|
|
|
2005-04-16 01:44:27 +08:00
|
|
|
if (ce->ce_size != htonl(st->st_size))
|
2005-04-10 00:48:20 +08:00
|
|
|
changed |= DATA_CHANGED;
|
2005-09-20 06:11:15 +08:00
|
|
|
|
2005-12-21 04:12:18 +08:00
|
|
|
return changed;
|
|
|
|
}
|
|
|
|
|
2006-08-16 12:38:07 +08:00
|
|
|
int ce_match_stat(struct cache_entry *ce, struct stat *st, int options)
|
2005-12-21 04:12:18 +08:00
|
|
|
{
|
2006-02-09 13:15:24 +08:00
|
|
|
unsigned int changed;
|
2006-08-16 12:38:07 +08:00
|
|
|
int ignore_valid = options & 01;
|
|
|
|
int assume_racy_is_modified = options & 02;
|
2006-02-09 13:15:24 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* If it's marked as always valid in the index, it's
|
|
|
|
* valid whatever the checked-out copy says.
|
|
|
|
*/
|
|
|
|
if (!ignore_valid && (ce->ce_flags & htons(CE_VALID)))
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
changed = ce_match_stat_basic(ce, st);
|
2005-12-21 04:12:18 +08:00
|
|
|
|
Racy GIT
This fixes the longstanding "Racy GIT" problem, which was pretty
much there from the beginning of time, but was first
demonstrated by Pasky in this message on October 24, 2005:
http://marc.theaimsgroup.com/?l=git&m=113014629716878
If you run the following sequence of commands:
echo frotz >infocom
git update-index --add infocom
echo xyzzy >infocom
so that the second update to file "infocom" does not change
st_mtime, what is recorded as the stat information for the cache
entry "infocom" exactly matches what is on the filesystem
(owner, group, inum, mtime, ctime, mode, length). After this
sequence, we incorrectly think "infocom" file still has string
"frotz" in it, and get really confused. E.g. git-diff-files
would say there is no change, git-update-index --refresh would
not even look at the filesystem to correct the situation.
Some ways of working around this issue were already suggested by
Linus in the same thread on the same day, including waiting
until the next second before returning from update-index if a
cache entry written out has the current timestamp, but that
means we can make at most one commit per second, and given that
the e-mail patch workflow used by Linus needs to process at
least 5 commits per second, it is not an acceptable solution.
Linus notes that git-apply is primarily used to update the index
while processing e-mailed patches, which is true, and
git-apply's up-to-date check is fooled by the same problem but
luckily in the other direction, so it is not really a big issue,
but still it is disturbing.
The function ce_match_stat() is called to bypass the comparison
against filesystem data when the stat data recorded in the cache
entry matches what stat() returns from the filesystem. This
patch tackles the problem by changing it to actually go to the
filesystem data for cache entries that have the same mtime as
the index file itself. This works as long as the index file and
working tree files are on the filesystems that share the same
monotonic clock. Files on network mounted filesystems sometimes
get skewed timestamps compared to "date" output, but as long as
working tree files' timestamps are skewed the same way as the
index file's, this approach still works. The only problematic
files are the ones that have the same timestamp as the index
file's, because two file updates that sandwitch the index file
update must happen within the same second to trigger the
problem.
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-20 16:02:15 +08:00
|
|
|
/*
|
|
|
|
* Within 1 second of this sequence:
|
|
|
|
* echo xyzzy >file && git-update-index --add file
|
|
|
|
* running this command:
|
|
|
|
* echo frotz >file
|
|
|
|
* would give a falsely clean cache entry. The mtime and
|
|
|
|
* length match the cache, and other stat fields do not change.
|
|
|
|
*
|
|
|
|
* We could detect this at update-index time (the cache entry
|
|
|
|
* being registered/updated records the same time as "now")
|
|
|
|
* and delay the return from git-update-index, but that would
|
|
|
|
* effectively mean we can make at most one commit per second,
|
|
|
|
* which is not acceptable. Instead, we check cache entries
|
|
|
|
* whose mtime are the same as the index file timestamp more
|
2006-02-09 13:15:24 +08:00
|
|
|
* carefully than others.
|
Racy GIT
This fixes the longstanding "Racy GIT" problem, which was pretty
much there from the beginning of time, but was first
demonstrated by Pasky in this message on October 24, 2005:
http://marc.theaimsgroup.com/?l=git&m=113014629716878
If you run the following sequence of commands:
echo frotz >infocom
git update-index --add infocom
echo xyzzy >infocom
so that the second update to file "infocom" does not change
st_mtime, what is recorded as the stat information for the cache
entry "infocom" exactly matches what is on the filesystem
(owner, group, inum, mtime, ctime, mode, length). After this
sequence, we incorrectly think "infocom" file still has string
"frotz" in it, and get really confused. E.g. git-diff-files
would say there is no change, git-update-index --refresh would
not even look at the filesystem to correct the situation.
Some ways of working around this issue were already suggested by
Linus in the same thread on the same day, including waiting
until the next second before returning from update-index if a
cache entry written out has the current timestamp, but that
means we can make at most one commit per second, and given that
the e-mail patch workflow used by Linus needs to process at
least 5 commits per second, it is not an acceptable solution.
Linus notes that git-apply is primarily used to update the index
while processing e-mailed patches, which is true, and
git-apply's up-to-date check is fooled by the same problem but
luckily in the other direction, so it is not really a big issue,
but still it is disturbing.
The function ce_match_stat() is called to bypass the comparison
against filesystem data when the stat data recorded in the cache
entry matches what stat() returns from the filesystem. This
patch tackles the problem by changing it to actually go to the
filesystem data for cache entries that have the same mtime as
the index file itself. This works as long as the index file and
working tree files are on the filesystems that share the same
monotonic clock. Files on network mounted filesystems sometimes
get skewed timestamps compared to "date" output, but as long as
working tree files' timestamps are skewed the same way as the
index file's, this approach still works. The only problematic
files are the ones that have the same timestamp as the index
file's, because two file updates that sandwitch the index file
update must happen within the same second to trigger the
problem.
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-20 16:02:15 +08:00
|
|
|
*/
|
|
|
|
if (!changed &&
|
|
|
|
index_file_timestamp &&
|
2006-08-16 12:38:07 +08:00
|
|
|
index_file_timestamp <= ntohl(ce->ce_mtime.sec)) {
|
|
|
|
if (assume_racy_is_modified)
|
|
|
|
changed |= DATA_CHANGED;
|
|
|
|
else
|
|
|
|
changed |= ce_modified_check_fs(ce, st);
|
|
|
|
}
|
2005-09-20 06:11:15 +08:00
|
|
|
|
Racy GIT
This fixes the longstanding "Racy GIT" problem, which was pretty
much there from the beginning of time, but was first
demonstrated by Pasky in this message on October 24, 2005:
http://marc.theaimsgroup.com/?l=git&m=113014629716878
If you run the following sequence of commands:
echo frotz >infocom
git update-index --add infocom
echo xyzzy >infocom
so that the second update to file "infocom" does not change
st_mtime, what is recorded as the stat information for the cache
entry "infocom" exactly matches what is on the filesystem
(owner, group, inum, mtime, ctime, mode, length). After this
sequence, we incorrectly think "infocom" file still has string
"frotz" in it, and get really confused. E.g. git-diff-files
would say there is no change, git-update-index --refresh would
not even look at the filesystem to correct the situation.
Some ways of working around this issue were already suggested by
Linus in the same thread on the same day, including waiting
until the next second before returning from update-index if a
cache entry written out has the current timestamp, but that
means we can make at most one commit per second, and given that
the e-mail patch workflow used by Linus needs to process at
least 5 commits per second, it is not an acceptable solution.
Linus notes that git-apply is primarily used to update the index
while processing e-mailed patches, which is true, and
git-apply's up-to-date check is fooled by the same problem but
luckily in the other direction, so it is not really a big issue,
but still it is disturbing.
The function ce_match_stat() is called to bypass the comparison
against filesystem data when the stat data recorded in the cache
entry matches what stat() returns from the filesystem. This
patch tackles the problem by changing it to actually go to the
filesystem data for cache entries that have the same mtime as
the index file itself. This works as long as the index file and
working tree files are on the filesystems that share the same
monotonic clock. Files on network mounted filesystems sometimes
get skewed timestamps compared to "date" output, but as long as
working tree files' timestamps are skewed the same way as the
index file's, this approach still works. The only problematic
files are the ones that have the same timestamp as the index
file's, because two file updates that sandwitch the index file
update must happen within the same second to trigger the
problem.
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-20 16:02:15 +08:00
|
|
|
return changed;
|
2005-09-20 06:11:15 +08:00
|
|
|
}
|
|
|
|
|
2006-02-09 13:15:24 +08:00
|
|
|
int ce_modified(struct cache_entry *ce, struct stat *st, int really)
|
2005-09-20 06:11:15 +08:00
|
|
|
{
|
Racy GIT
This fixes the longstanding "Racy GIT" problem, which was pretty
much there from the beginning of time, but was first
demonstrated by Pasky in this message on October 24, 2005:
http://marc.theaimsgroup.com/?l=git&m=113014629716878
If you run the following sequence of commands:
echo frotz >infocom
git update-index --add infocom
echo xyzzy >infocom
so that the second update to file "infocom" does not change
st_mtime, what is recorded as the stat information for the cache
entry "infocom" exactly matches what is on the filesystem
(owner, group, inum, mtime, ctime, mode, length). After this
sequence, we incorrectly think "infocom" file still has string
"frotz" in it, and get really confused. E.g. git-diff-files
would say there is no change, git-update-index --refresh would
not even look at the filesystem to correct the situation.
Some ways of working around this issue were already suggested by
Linus in the same thread on the same day, including waiting
until the next second before returning from update-index if a
cache entry written out has the current timestamp, but that
means we can make at most one commit per second, and given that
the e-mail patch workflow used by Linus needs to process at
least 5 commits per second, it is not an acceptable solution.
Linus notes that git-apply is primarily used to update the index
while processing e-mailed patches, which is true, and
git-apply's up-to-date check is fooled by the same problem but
luckily in the other direction, so it is not really a big issue,
but still it is disturbing.
The function ce_match_stat() is called to bypass the comparison
against filesystem data when the stat data recorded in the cache
entry matches what stat() returns from the filesystem. This
patch tackles the problem by changing it to actually go to the
filesystem data for cache entries that have the same mtime as
the index file itself. This works as long as the index file and
working tree files are on the filesystems that share the same
monotonic clock. Files on network mounted filesystems sometimes
get skewed timestamps compared to "date" output, but as long as
working tree files' timestamps are skewed the same way as the
index file's, this approach still works. The only problematic
files are the ones that have the same timestamp as the index
file's, because two file updates that sandwitch the index file
update must happen within the same second to trigger the
problem.
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-20 16:02:15 +08:00
|
|
|
int changed, changed_fs;
|
2006-02-09 13:15:24 +08:00
|
|
|
changed = ce_match_stat(ce, st, really);
|
2005-09-20 06:11:15 +08:00
|
|
|
if (!changed)
|
|
|
|
return 0;
|
|
|
|
/*
|
|
|
|
* If the mode or type has changed, there's no point in trying
|
|
|
|
* to refresh the entry - it's not going to match
|
|
|
|
*/
|
|
|
|
if (changed & (MODE_CHANGED | TYPE_CHANGED))
|
|
|
|
return changed;
|
|
|
|
|
|
|
|
/* Immediately after read-tree or update-index --cacheinfo,
|
|
|
|
* the length field is zero. For other cases the ce_size
|
|
|
|
* should match the SHA1 recorded in the index entry.
|
|
|
|
*/
|
|
|
|
if ((changed & DATA_CHANGED) && ce->ce_size != htonl(0))
|
|
|
|
return changed;
|
|
|
|
|
Racy GIT
This fixes the longstanding "Racy GIT" problem, which was pretty
much there from the beginning of time, but was first
demonstrated by Pasky in this message on October 24, 2005:
http://marc.theaimsgroup.com/?l=git&m=113014629716878
If you run the following sequence of commands:
echo frotz >infocom
git update-index --add infocom
echo xyzzy >infocom
so that the second update to file "infocom" does not change
st_mtime, what is recorded as the stat information for the cache
entry "infocom" exactly matches what is on the filesystem
(owner, group, inum, mtime, ctime, mode, length). After this
sequence, we incorrectly think "infocom" file still has string
"frotz" in it, and get really confused. E.g. git-diff-files
would say there is no change, git-update-index --refresh would
not even look at the filesystem to correct the situation.
Some ways of working around this issue were already suggested by
Linus in the same thread on the same day, including waiting
until the next second before returning from update-index if a
cache entry written out has the current timestamp, but that
means we can make at most one commit per second, and given that
the e-mail patch workflow used by Linus needs to process at
least 5 commits per second, it is not an acceptable solution.
Linus notes that git-apply is primarily used to update the index
while processing e-mailed patches, which is true, and
git-apply's up-to-date check is fooled by the same problem but
luckily in the other direction, so it is not really a big issue,
but still it is disturbing.
The function ce_match_stat() is called to bypass the comparison
against filesystem data when the stat data recorded in the cache
entry matches what stat() returns from the filesystem. This
patch tackles the problem by changing it to actually go to the
filesystem data for cache entries that have the same mtime as
the index file itself. This works as long as the index file and
working tree files are on the filesystems that share the same
monotonic clock. Files on network mounted filesystems sometimes
get skewed timestamps compared to "date" output, but as long as
working tree files' timestamps are skewed the same way as the
index file's, this approach still works. The only problematic
files are the ones that have the same timestamp as the index
file's, because two file updates that sandwitch the index file
update must happen within the same second to trigger the
problem.
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-20 16:02:15 +08:00
|
|
|
changed_fs = ce_modified_check_fs(ce, st);
|
|
|
|
if (changed_fs)
|
|
|
|
return changed | changed_fs;
|
2005-09-20 06:11:15 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2005-05-21 00:09:18 +08:00
|
|
|
int base_name_compare(const char *name1, int len1, int mode1,
|
|
|
|
const char *name2, int len2, int mode2)
|
|
|
|
{
|
|
|
|
unsigned char c1, c2;
|
|
|
|
int len = len1 < len2 ? len1 : len2;
|
|
|
|
int cmp;
|
|
|
|
|
|
|
|
cmp = memcmp(name1, name2, len);
|
|
|
|
if (cmp)
|
|
|
|
return cmp;
|
|
|
|
c1 = name1[len];
|
|
|
|
c2 = name2[len];
|
2007-04-10 12:20:29 +08:00
|
|
|
if (!c1 && (S_ISDIR(mode1) || S_ISDIRLNK(mode1)))
|
2005-05-21 00:09:18 +08:00
|
|
|
c1 = '/';
|
2007-04-10 12:20:29 +08:00
|
|
|
if (!c2 && (S_ISDIR(mode2) || S_ISDIRLNK(mode2)))
|
2005-05-21 00:09:18 +08:00
|
|
|
c2 = '/';
|
|
|
|
return (c1 < c2) ? -1 : (c1 > c2) ? 1 : 0;
|
|
|
|
}
|
|
|
|
|
2005-04-16 13:51:44 +08:00
|
|
|
int cache_name_compare(const char *name1, int flags1, const char *name2, int flags2)
|
2005-04-10 00:26:55 +08:00
|
|
|
{
|
2005-04-16 13:51:44 +08:00
|
|
|
int len1 = flags1 & CE_NAMEMASK;
|
|
|
|
int len2 = flags2 & CE_NAMEMASK;
|
2005-04-10 00:26:55 +08:00
|
|
|
int len = len1 < len2 ? len1 : len2;
|
|
|
|
int cmp;
|
|
|
|
|
|
|
|
cmp = memcmp(name1, name2, len);
|
|
|
|
if (cmp)
|
|
|
|
return cmp;
|
|
|
|
if (len1 < len2)
|
|
|
|
return -1;
|
|
|
|
if (len1 > len2)
|
|
|
|
return 1;
|
2006-02-09 13:15:24 +08:00
|
|
|
|
2006-02-13 15:46:25 +08:00
|
|
|
/* Compare stages */
|
|
|
|
flags1 &= CE_STAGEMASK;
|
|
|
|
flags2 &= CE_STAGEMASK;
|
2006-02-09 13:15:24 +08:00
|
|
|
|
2005-04-16 13:51:44 +08:00
|
|
|
if (flags1 < flags2)
|
|
|
|
return -1;
|
|
|
|
if (flags1 > flags2)
|
|
|
|
return 1;
|
2005-04-10 00:26:55 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
int cache_name_pos(const char *name, int namelen)
|
|
|
|
{
|
|
|
|
int first, last;
|
|
|
|
|
|
|
|
first = 0;
|
|
|
|
last = active_nr;
|
|
|
|
while (last > first) {
|
|
|
|
int next = (last + first) >> 1;
|
|
|
|
struct cache_entry *ce = active_cache[next];
|
2005-06-08 04:35:56 +08:00
|
|
|
int cmp = cache_name_compare(name, namelen, ce->name, ntohs(ce->ce_flags));
|
2005-04-10 00:26:55 +08:00
|
|
|
if (!cmp)
|
2005-04-11 13:06:50 +08:00
|
|
|
return next;
|
2005-04-10 00:26:55 +08:00
|
|
|
if (cmp < 0) {
|
|
|
|
last = next;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
first = next+1;
|
|
|
|
}
|
2005-04-11 13:06:50 +08:00
|
|
|
return -first-1;
|
2005-04-10 00:26:55 +08:00
|
|
|
}
|
|
|
|
|
2005-04-17 03:05:45 +08:00
|
|
|
/* Remove entry, return true if there are more entries to go.. */
|
2005-05-15 10:04:25 +08:00
|
|
|
int remove_cache_entry_at(int pos)
|
2005-04-17 03:05:45 +08:00
|
|
|
{
|
2005-05-07 07:48:43 +08:00
|
|
|
active_cache_changed = 1;
|
2005-04-17 03:05:45 +08:00
|
|
|
active_nr--;
|
|
|
|
if (pos >= active_nr)
|
|
|
|
return 0;
|
|
|
|
memmove(active_cache + pos, active_cache + pos + 1, (active_nr - pos) * sizeof(struct cache_entry *));
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2005-09-21 15:00:47 +08:00
|
|
|
int remove_file_from_cache(const char *path)
|
2005-04-10 03:09:27 +08:00
|
|
|
{
|
|
|
|
int pos = cache_name_pos(path, strlen(path));
|
2005-04-18 00:53:35 +08:00
|
|
|
if (pos < 0)
|
|
|
|
pos = -pos-1;
|
|
|
|
while (pos < active_nr && !strcmp(active_cache[pos]->name, path))
|
2005-05-15 10:04:25 +08:00
|
|
|
remove_cache_entry_at(pos);
|
2005-04-10 03:09:27 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2007-04-02 13:14:40 +08:00
|
|
|
int add_file_to_cache(const char *path, int verbose)
|
2006-07-26 09:52:35 +08:00
|
|
|
{
|
|
|
|
int size, namelen;
|
|
|
|
struct stat st;
|
|
|
|
struct cache_entry *ce;
|
|
|
|
|
|
|
|
if (lstat(path, &st))
|
|
|
|
die("%s: unable to stat (%s)", path, strerror(errno));
|
|
|
|
|
2007-04-10 12:20:29 +08:00
|
|
|
if (!S_ISREG(st.st_mode) && !S_ISLNK(st.st_mode) && !S_ISDIR(st.st_mode))
|
|
|
|
die("%s: can only add regular files, symbolic links or git-directories", path);
|
2006-07-26 09:52:35 +08:00
|
|
|
|
|
|
|
namelen = strlen(path);
|
|
|
|
size = cache_entry_size(namelen);
|
|
|
|
ce = xcalloc(1, size);
|
|
|
|
memcpy(ce->name, path, namelen);
|
|
|
|
ce->ce_flags = htons(namelen);
|
|
|
|
fill_stat_cache_info(ce, &st);
|
|
|
|
|
2007-03-03 05:11:30 +08:00
|
|
|
if (trust_executable_bit && has_symlinks)
|
2007-02-17 14:43:48 +08:00
|
|
|
ce->ce_mode = create_ce_mode(st.st_mode);
|
|
|
|
else {
|
2007-03-03 05:11:30 +08:00
|
|
|
/* If there is an existing entry, pick the mode bits and type
|
|
|
|
* from it, otherwise assume unexecutable regular file.
|
2006-07-26 09:52:35 +08:00
|
|
|
*/
|
2007-02-17 14:43:48 +08:00
|
|
|
struct cache_entry *ent;
|
2006-07-26 09:52:35 +08:00
|
|
|
int pos = cache_name_pos(path, namelen);
|
2007-02-17 14:43:48 +08:00
|
|
|
|
|
|
|
ent = (0 <= pos) ? active_cache[pos] : NULL;
|
|
|
|
ce->ce_mode = ce_mode_from_stat(ent, st.st_mode);
|
2006-07-26 09:52:35 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
if (index_path(ce->sha1, path, &st, 1))
|
|
|
|
die("unable to index file %s", path);
|
2006-12-17 17:09:41 +08:00
|
|
|
if (add_cache_entry(ce, ADD_CACHE_OK_TO_ADD|ADD_CACHE_OK_TO_REPLACE))
|
2006-07-26 09:52:35 +08:00
|
|
|
die("unable to add %s to index",path);
|
|
|
|
if (verbose)
|
|
|
|
printf("add '%s'\n", path);
|
|
|
|
cache_tree_invalidate_path(active_cache_tree, path);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2005-05-15 10:04:25 +08:00
|
|
|
int ce_same_name(struct cache_entry *a, struct cache_entry *b)
|
2005-04-17 03:05:45 +08:00
|
|
|
{
|
|
|
|
int len = ce_namelen(a);
|
|
|
|
return ce_namelen(b) == len && !memcmp(a->name, b->name, len);
|
|
|
|
}
|
|
|
|
|
2005-07-15 07:55:06 +08:00
|
|
|
int ce_path_match(const struct cache_entry *ce, const char **pathspec)
|
|
|
|
{
|
|
|
|
const char *match, *name;
|
|
|
|
int len;
|
|
|
|
|
|
|
|
if (!pathspec)
|
|
|
|
return 1;
|
|
|
|
|
|
|
|
len = ce_namelen(ce);
|
|
|
|
name = ce->name;
|
|
|
|
while ((match = *pathspec++) != NULL) {
|
|
|
|
int matchlen = strlen(match);
|
|
|
|
if (matchlen > len)
|
|
|
|
continue;
|
|
|
|
if (memcmp(name, match, matchlen))
|
|
|
|
continue;
|
|
|
|
if (matchlen && name[matchlen-1] == '/')
|
|
|
|
return 1;
|
|
|
|
if (name[matchlen] == '/' || !name[matchlen])
|
|
|
|
return 1;
|
2005-08-17 11:44:32 +08:00
|
|
|
if (!matchlen)
|
|
|
|
return 1;
|
2005-07-15 07:55:06 +08:00
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2006-05-19 03:07:31 +08:00
|
|
|
/*
|
|
|
|
* We fundamentally don't like some paths: we don't want
|
|
|
|
* dot or dot-dot anywhere, and for obvious reasons don't
|
|
|
|
* want to recurse into ".git" either.
|
|
|
|
*
|
|
|
|
* Also, we don't want double slashes or slashes at the
|
|
|
|
* end that can make pathnames ambiguous.
|
|
|
|
*/
|
|
|
|
static int verify_dotfile(const char *rest)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* The first character was '.', but that
|
|
|
|
* has already been discarded, we now test
|
|
|
|
* the rest.
|
|
|
|
*/
|
|
|
|
switch (*rest) {
|
|
|
|
/* "." is not allowed */
|
|
|
|
case '\0': case '/':
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* ".git" followed by NUL or slash is bad. This
|
|
|
|
* shares the path end test with the ".." case.
|
|
|
|
*/
|
|
|
|
case 'g':
|
|
|
|
if (rest[1] != 'i')
|
|
|
|
break;
|
|
|
|
if (rest[2] != 't')
|
|
|
|
break;
|
|
|
|
rest += 2;
|
|
|
|
/* fallthrough */
|
|
|
|
case '.':
|
|
|
|
if (rest[1] == '\0' || rest[1] == '/')
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
int verify_path(const char *path)
|
|
|
|
{
|
|
|
|
char c;
|
|
|
|
|
|
|
|
goto inside;
|
|
|
|
for (;;) {
|
|
|
|
if (!c)
|
|
|
|
return 1;
|
|
|
|
if (c == '/') {
|
|
|
|
inside:
|
|
|
|
c = *path++;
|
|
|
|
switch (c) {
|
|
|
|
default:
|
|
|
|
continue;
|
|
|
|
case '/': case '\0':
|
|
|
|
break;
|
|
|
|
case '.':
|
|
|
|
if (verify_dotfile(path))
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
c = *path++;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2005-06-19 11:21:34 +08:00
|
|
|
/*
|
|
|
|
* Do we have another file that has the beginning components being a
|
|
|
|
* proper superset of the name we're trying to add?
|
2005-05-08 12:48:12 +08:00
|
|
|
*/
|
2005-06-19 11:21:34 +08:00
|
|
|
static int has_file_name(const struct cache_entry *ce, int pos, int ok_to_replace)
|
2005-05-08 12:48:12 +08:00
|
|
|
{
|
2005-06-19 11:21:34 +08:00
|
|
|
int retval = 0;
|
|
|
|
int len = ce_namelen(ce);
|
2005-06-25 17:25:29 +08:00
|
|
|
int stage = ce_stage(ce);
|
2005-06-19 11:21:34 +08:00
|
|
|
const char *name = ce->name;
|
2005-05-08 12:48:12 +08:00
|
|
|
|
2005-06-19 11:21:34 +08:00
|
|
|
while (pos < active_nr) {
|
|
|
|
struct cache_entry *p = active_cache[pos++];
|
2005-05-08 12:48:12 +08:00
|
|
|
|
2005-06-19 11:21:34 +08:00
|
|
|
if (len >= ce_namelen(p))
|
2005-05-08 12:48:12 +08:00
|
|
|
break;
|
2005-06-19 11:21:34 +08:00
|
|
|
if (memcmp(name, p->name, len))
|
|
|
|
break;
|
2005-06-25 17:25:29 +08:00
|
|
|
if (ce_stage(p) != stage)
|
|
|
|
continue;
|
2005-06-19 11:21:34 +08:00
|
|
|
if (p->name[len] != '/')
|
|
|
|
continue;
|
2007-03-30 16:55:37 +08:00
|
|
|
if (!ce_stage(p) && !p->ce_mode)
|
|
|
|
continue;
|
2005-06-19 11:21:34 +08:00
|
|
|
retval = -1;
|
|
|
|
if (!ok_to_replace)
|
|
|
|
break;
|
|
|
|
remove_cache_entry_at(--pos);
|
2005-05-08 12:48:12 +08:00
|
|
|
}
|
2005-06-19 11:21:34 +08:00
|
|
|
return retval;
|
|
|
|
}
|
2005-05-08 12:48:12 +08:00
|
|
|
|
2005-06-19 11:21:34 +08:00
|
|
|
/*
|
|
|
|
* Do we have another file with a pathname that is a proper
|
|
|
|
* subset of the name we're trying to add?
|
|
|
|
*/
|
|
|
|
static int has_dir_name(const struct cache_entry *ce, int pos, int ok_to_replace)
|
|
|
|
{
|
|
|
|
int retval = 0;
|
2005-06-25 17:25:29 +08:00
|
|
|
int stage = ce_stage(ce);
|
2005-06-19 11:21:34 +08:00
|
|
|
const char *name = ce->name;
|
|
|
|
const char *slash = name + ce_namelen(ce);
|
2005-05-08 12:48:12 +08:00
|
|
|
|
2005-06-19 11:21:34 +08:00
|
|
|
for (;;) {
|
|
|
|
int len;
|
2005-05-08 12:48:12 +08:00
|
|
|
|
2005-06-19 11:21:34 +08:00
|
|
|
for (;;) {
|
|
|
|
if (*--slash == '/')
|
|
|
|
break;
|
|
|
|
if (slash <= ce->name)
|
|
|
|
return retval;
|
|
|
|
}
|
|
|
|
len = slash - name;
|
2005-05-08 12:48:12 +08:00
|
|
|
|
2005-06-25 17:25:29 +08:00
|
|
|
pos = cache_name_pos(name, ntohs(create_ce_flags(len, stage)));
|
2005-06-19 11:21:34 +08:00
|
|
|
if (pos >= 0) {
|
2007-03-30 16:55:37 +08:00
|
|
|
/*
|
|
|
|
* Found one, but not so fast. This could
|
|
|
|
* be a marker that says "I was here, but
|
|
|
|
* I am being removed". Such an entry is
|
|
|
|
* not a part of the resulting tree, and
|
|
|
|
* it is Ok to have a directory at the same
|
|
|
|
* path.
|
|
|
|
*/
|
|
|
|
if (stage || active_cache[pos]->ce_mode) {
|
|
|
|
retval = -1;
|
|
|
|
if (!ok_to_replace)
|
|
|
|
break;
|
|
|
|
remove_cache_entry_at(pos);
|
|
|
|
continue;
|
|
|
|
}
|
2005-06-19 11:21:34 +08:00
|
|
|
}
|
2007-03-30 16:55:37 +08:00
|
|
|
else
|
|
|
|
pos = -pos-1;
|
2005-06-19 11:21:34 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Trivial optimization: if we find an entry that
|
|
|
|
* already matches the sub-directory, then we know
|
2005-06-25 17:25:29 +08:00
|
|
|
* we're ok, and we can exit.
|
2005-06-19 11:21:34 +08:00
|
|
|
*/
|
2005-06-25 17:25:29 +08:00
|
|
|
while (pos < active_nr) {
|
2005-06-19 11:21:34 +08:00
|
|
|
struct cache_entry *p = active_cache[pos];
|
2005-06-25 17:25:29 +08:00
|
|
|
if ((ce_namelen(p) <= len) ||
|
|
|
|
(p->name[len] != '/') ||
|
|
|
|
memcmp(p->name, name, len))
|
|
|
|
break; /* not our subdirectory */
|
2007-03-30 16:55:37 +08:00
|
|
|
if (ce_stage(p) == stage && (stage || p->ce_mode))
|
2005-06-25 17:25:29 +08:00
|
|
|
/* p is at the same stage as our entry, and
|
|
|
|
* is a subdirectory of what we are looking
|
|
|
|
* at, so we cannot have conflicts at our
|
|
|
|
* level or anything shorter.
|
|
|
|
*/
|
|
|
|
return retval;
|
|
|
|
pos++;
|
2005-05-08 12:55:21 +08:00
|
|
|
}
|
2005-05-08 12:48:12 +08:00
|
|
|
}
|
2005-06-19 11:21:34 +08:00
|
|
|
return retval;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* We may be in a situation where we already have path/file and path
|
|
|
|
* is being added, or we already have path and path/file is being
|
|
|
|
* added. Either one would result in a nonsense tree that has path
|
|
|
|
* twice when git-write-tree tries to write it out. Prevent it.
|
|
|
|
*
|
|
|
|
* If ok-to-replace is specified, we remove the conflicting entries
|
|
|
|
* from the cache so the caller should recompute the insert position.
|
|
|
|
* When this happens, we return non-zero.
|
|
|
|
*/
|
|
|
|
static int check_file_directory_conflict(const struct cache_entry *ce, int pos, int ok_to_replace)
|
|
|
|
{
|
2007-03-30 16:55:37 +08:00
|
|
|
int retval;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* When ce is an "I am going away" entry, we allow it to be added
|
|
|
|
*/
|
|
|
|
if (!ce_stage(ce) && !ce->ce_mode)
|
|
|
|
return 0;
|
|
|
|
|
2005-06-19 11:21:34 +08:00
|
|
|
/*
|
|
|
|
* We check if the path is a sub-path of a subsequent pathname
|
|
|
|
* first, since removing those will not change the position
|
2007-03-30 16:55:37 +08:00
|
|
|
* in the array.
|
2005-06-19 11:21:34 +08:00
|
|
|
*/
|
2007-03-30 16:55:37 +08:00
|
|
|
retval = has_file_name(ce, pos, ok_to_replace);
|
|
|
|
|
2005-06-19 11:21:34 +08:00
|
|
|
/*
|
|
|
|
* Then check if the path might have a clashing sub-directory
|
|
|
|
* before it.
|
|
|
|
*/
|
|
|
|
return retval + has_dir_name(ce, pos, ok_to_replace);
|
2005-05-08 12:48:12 +08:00
|
|
|
}
|
|
|
|
|
2005-05-08 12:55:21 +08:00
|
|
|
int add_cache_entry(struct cache_entry *ce, int option)
|
2005-04-10 03:09:27 +08:00
|
|
|
{
|
|
|
|
int pos;
|
2005-05-08 12:55:21 +08:00
|
|
|
int ok_to_add = option & ADD_CACHE_OK_TO_ADD;
|
|
|
|
int ok_to_replace = option & ADD_CACHE_OK_TO_REPLACE;
|
2005-06-25 17:25:29 +08:00
|
|
|
int skip_df_check = option & ADD_CACHE_SKIP_DFCHECK;
|
2006-02-09 13:15:24 +08:00
|
|
|
|
2005-06-08 04:35:56 +08:00
|
|
|
pos = cache_name_pos(ce->name, ntohs(ce->ce_flags));
|
2005-04-10 03:09:27 +08:00
|
|
|
|
2005-10-12 09:45:33 +08:00
|
|
|
/* existing match? Just replace it. */
|
2005-04-11 13:06:50 +08:00
|
|
|
if (pos >= 0) {
|
2005-05-07 07:48:43 +08:00
|
|
|
active_cache_changed = 1;
|
2005-04-11 13:06:50 +08:00
|
|
|
active_cache[pos] = ce;
|
2005-04-10 03:09:27 +08:00
|
|
|
return 0;
|
|
|
|
}
|
2005-04-11 13:06:50 +08:00
|
|
|
pos = -pos-1;
|
2005-04-10 03:09:27 +08:00
|
|
|
|
2005-04-17 03:05:45 +08:00
|
|
|
/*
|
|
|
|
* Inserting a merged entry ("stage 0") into the index
|
|
|
|
* will always replace all non-merged entries..
|
|
|
|
*/
|
|
|
|
if (pos < active_nr && ce_stage(ce) == 0) {
|
2005-05-15 10:04:25 +08:00
|
|
|
while (ce_same_name(active_cache[pos], ce)) {
|
2005-04-17 03:05:45 +08:00
|
|
|
ok_to_add = 1;
|
2005-05-15 10:04:25 +08:00
|
|
|
if (!remove_cache_entry_at(pos))
|
2005-04-17 03:05:45 +08:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2005-04-11 02:32:54 +08:00
|
|
|
if (!ok_to_add)
|
|
|
|
return -1;
|
2006-05-19 03:07:31 +08:00
|
|
|
if (!verify_path(ce->name))
|
|
|
|
return -1;
|
2005-04-11 02:32:54 +08:00
|
|
|
|
2005-10-12 09:45:33 +08:00
|
|
|
if (!skip_df_check &&
|
|
|
|
check_file_directory_conflict(ce, pos, ok_to_replace)) {
|
2005-05-08 12:55:21 +08:00
|
|
|
if (!ok_to_replace)
|
2006-12-17 08:23:02 +08:00
|
|
|
return error("'%s' appears as both a file and as a directory", ce->name);
|
2005-06-08 04:35:56 +08:00
|
|
|
pos = cache_name_pos(ce->name, ntohs(ce->ce_flags));
|
2005-05-08 12:55:21 +08:00
|
|
|
pos = -pos-1;
|
|
|
|
}
|
2005-05-08 12:48:12 +08:00
|
|
|
|
2005-04-10 03:09:27 +08:00
|
|
|
/* Make sure the array is big enough .. */
|
|
|
|
if (active_nr == active_alloc) {
|
|
|
|
active_alloc = alloc_nr(active_alloc);
|
2005-04-27 03:00:58 +08:00
|
|
|
active_cache = xrealloc(active_cache, active_alloc * sizeof(struct cache_entry *));
|
2005-04-10 03:09:27 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Add it in.. */
|
|
|
|
active_nr++;
|
|
|
|
if (active_nr > pos)
|
|
|
|
memmove(active_cache + pos + 1, active_cache + pos, (active_nr - pos - 1) * sizeof(ce));
|
|
|
|
active_cache[pos] = ce;
|
2005-05-07 07:48:43 +08:00
|
|
|
active_cache_changed = 1;
|
2005-04-10 03:09:27 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2006-05-20 00:56:35 +08:00
|
|
|
/*
|
|
|
|
* "refresh" does not calculate a new sha1 file or bring the
|
|
|
|
* cache up-to-date for mode/content changes. But what it
|
|
|
|
* _does_ do is to "re-match" the stat information of a file
|
|
|
|
* with the cache, so that you can refresh the cache for a
|
|
|
|
* file that hasn't been changed but where the stat entry is
|
|
|
|
* out of date.
|
|
|
|
*
|
|
|
|
* For example, you'd want to do this after doing a "git-read-tree",
|
|
|
|
* to link up the stat cache details with the proper files.
|
|
|
|
*/
|
2007-04-02 12:34:34 +08:00
|
|
|
static struct cache_entry *refresh_cache_ent(struct cache_entry *ce, int really, int *err)
|
2006-05-20 00:56:35 +08:00
|
|
|
{
|
|
|
|
struct stat st;
|
|
|
|
struct cache_entry *updated;
|
|
|
|
int changed, size;
|
|
|
|
|
2006-07-26 12:32:18 +08:00
|
|
|
if (lstat(ce->name, &st) < 0) {
|
2007-04-02 12:34:34 +08:00
|
|
|
if (err)
|
|
|
|
*err = errno;
|
2006-07-26 12:32:18 +08:00
|
|
|
return NULL;
|
|
|
|
}
|
2006-05-20 00:56:35 +08:00
|
|
|
|
|
|
|
changed = ce_match_stat(ce, &st, really);
|
|
|
|
if (!changed) {
|
|
|
|
if (really && assume_unchanged &&
|
|
|
|
!(ce->ce_flags & htons(CE_VALID)))
|
|
|
|
; /* mark this one VALID again */
|
|
|
|
else
|
2006-07-26 12:32:18 +08:00
|
|
|
return ce;
|
2006-05-20 00:56:35 +08:00
|
|
|
}
|
|
|
|
|
2006-07-26 12:32:18 +08:00
|
|
|
if (ce_modified(ce, &st, really)) {
|
2007-04-02 12:34:34 +08:00
|
|
|
if (err)
|
|
|
|
*err = EINVAL;
|
2006-07-26 12:32:18 +08:00
|
|
|
return NULL;
|
|
|
|
}
|
2006-05-20 00:56:35 +08:00
|
|
|
|
|
|
|
size = ce_size(ce);
|
|
|
|
updated = xmalloc(size);
|
|
|
|
memcpy(updated, ce, size);
|
|
|
|
fill_stat_cache_info(updated, &st);
|
|
|
|
|
|
|
|
/* In this case, if really is not set, we should leave
|
|
|
|
* CE_VALID bit alone. Otherwise, paths marked with
|
|
|
|
* --no-assume-unchanged (i.e. things to be edited) will
|
|
|
|
* reacquire CE_VALID bit automatically, which is not
|
|
|
|
* really what we want.
|
|
|
|
*/
|
|
|
|
if (!really && assume_unchanged && !(ce->ce_flags & htons(CE_VALID)))
|
|
|
|
updated->ce_flags &= ~htons(CE_VALID);
|
|
|
|
|
|
|
|
return updated;
|
|
|
|
}
|
|
|
|
|
|
|
|
int refresh_cache(unsigned int flags)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
int has_errors = 0;
|
|
|
|
int really = (flags & REFRESH_REALLY) != 0;
|
|
|
|
int allow_unmerged = (flags & REFRESH_UNMERGED) != 0;
|
|
|
|
int quiet = (flags & REFRESH_QUIET) != 0;
|
|
|
|
int not_new = (flags & REFRESH_IGNORE_MISSING) != 0;
|
|
|
|
|
|
|
|
for (i = 0; i < active_nr; i++) {
|
|
|
|
struct cache_entry *ce, *new;
|
2007-04-02 12:34:34 +08:00
|
|
|
int cache_errno = 0;
|
|
|
|
|
2006-05-20 00:56:35 +08:00
|
|
|
ce = active_cache[i];
|
|
|
|
if (ce_stage(ce)) {
|
|
|
|
while ((i < active_nr) &&
|
|
|
|
! strcmp(active_cache[i]->name, ce->name))
|
|
|
|
i++;
|
|
|
|
i--;
|
|
|
|
if (allow_unmerged)
|
|
|
|
continue;
|
|
|
|
printf("%s: needs merge\n", ce->name);
|
|
|
|
has_errors = 1;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
2007-04-02 12:34:34 +08:00
|
|
|
new = refresh_cache_ent(ce, really, &cache_errno);
|
2006-07-26 12:32:18 +08:00
|
|
|
if (new == ce)
|
2006-05-20 00:56:35 +08:00
|
|
|
continue;
|
2006-07-26 12:32:18 +08:00
|
|
|
if (!new) {
|
|
|
|
if (not_new && cache_errno == ENOENT)
|
2006-05-20 00:56:35 +08:00
|
|
|
continue;
|
2006-07-26 12:32:18 +08:00
|
|
|
if (really && cache_errno == EINVAL) {
|
2006-05-20 00:56:35 +08:00
|
|
|
/* If we are doing --really-refresh that
|
|
|
|
* means the index is not valid anymore.
|
|
|
|
*/
|
|
|
|
ce->ce_flags &= ~htons(CE_VALID);
|
|
|
|
active_cache_changed = 1;
|
|
|
|
}
|
|
|
|
if (quiet)
|
|
|
|
continue;
|
|
|
|
printf("%s: needs update\n", ce->name);
|
|
|
|
has_errors = 1;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
active_cache_changed = 1;
|
|
|
|
/* You can NOT just free active_cache[i] here, since it
|
|
|
|
* might not be necessarily malloc()ed but can also come
|
|
|
|
* from mmap(). */
|
|
|
|
active_cache[i] = new;
|
|
|
|
}
|
|
|
|
return has_errors;
|
|
|
|
}
|
|
|
|
|
2007-04-02 12:34:34 +08:00
|
|
|
struct cache_entry *refresh_cache_entry(struct cache_entry *ce, int really)
|
|
|
|
{
|
|
|
|
return refresh_cache_ent(ce, really, NULL);
|
|
|
|
}
|
|
|
|
|
2006-04-25 12:18:58 +08:00
|
|
|
static int verify_hdr(struct cache_header *hdr, unsigned long size)
|
2005-04-08 06:13:13 +08:00
|
|
|
{
|
|
|
|
SHA_CTX c;
|
2006-04-25 12:18:58 +08:00
|
|
|
unsigned char sha1[20];
|
2005-04-08 06:13:13 +08:00
|
|
|
|
2005-04-16 01:44:27 +08:00
|
|
|
if (hdr->hdr_signature != htonl(CACHE_SIGNATURE))
|
2005-04-08 06:13:13 +08:00
|
|
|
return error("bad signature");
|
2005-04-21 03:36:41 +08:00
|
|
|
if (hdr->hdr_version != htonl(2))
|
|
|
|
return error("bad index version");
|
2005-04-08 06:13:13 +08:00
|
|
|
SHA1_Init(&c);
|
2005-04-21 03:36:41 +08:00
|
|
|
SHA1_Update(&c, hdr, size - 20);
|
2005-04-08 06:13:13 +08:00
|
|
|
SHA1_Final(sha1, &c);
|
2006-08-18 02:54:57 +08:00
|
|
|
if (hashcmp(sha1, (unsigned char *)hdr + size - 20))
|
2005-04-21 03:36:41 +08:00
|
|
|
return error("bad index file sha1 signature");
|
2005-04-08 06:13:13 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2006-04-25 12:18:58 +08:00
|
|
|
static int read_index_extension(const char *ext, void *data, unsigned long sz)
|
|
|
|
{
|
|
|
|
switch (CACHE_EXT(ext)) {
|
|
|
|
case CACHE_EXT_TREE:
|
|
|
|
active_cache_tree = cache_tree_read(data, sz);
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
if (*ext < 'A' || 'Z' < *ext)
|
|
|
|
return error("index uses %.4s extension, which we do not understand",
|
|
|
|
ext);
|
|
|
|
fprintf(stderr, "ignoring %.4s extension\n", ext);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
int read_cache(void)
|
2006-07-26 12:32:18 +08:00
|
|
|
{
|
|
|
|
return read_cache_from(get_index_file());
|
|
|
|
}
|
|
|
|
|
|
|
|
/* remember to discard_cache() before reading a different cache! */
|
|
|
|
int read_cache_from(const char *path)
|
2005-04-08 06:13:13 +08:00
|
|
|
{
|
|
|
|
int fd, i;
|
|
|
|
struct stat st;
|
2006-07-26 12:32:18 +08:00
|
|
|
unsigned long offset;
|
2005-04-08 06:13:13 +08:00
|
|
|
struct cache_header *hdr;
|
|
|
|
|
|
|
|
errno = EBUSY;
|
2006-07-26 12:32:18 +08:00
|
|
|
if (cache_mmap)
|
2005-10-02 04:24:27 +08:00
|
|
|
return active_nr;
|
|
|
|
|
2005-04-08 06:13:13 +08:00
|
|
|
errno = ENOENT;
|
Racy GIT
This fixes the longstanding "Racy GIT" problem, which was pretty
much there from the beginning of time, but was first
demonstrated by Pasky in this message on October 24, 2005:
http://marc.theaimsgroup.com/?l=git&m=113014629716878
If you run the following sequence of commands:
echo frotz >infocom
git update-index --add infocom
echo xyzzy >infocom
so that the second update to file "infocom" does not change
st_mtime, what is recorded as the stat information for the cache
entry "infocom" exactly matches what is on the filesystem
(owner, group, inum, mtime, ctime, mode, length). After this
sequence, we incorrectly think "infocom" file still has string
"frotz" in it, and get really confused. E.g. git-diff-files
would say there is no change, git-update-index --refresh would
not even look at the filesystem to correct the situation.
Some ways of working around this issue were already suggested by
Linus in the same thread on the same day, including waiting
until the next second before returning from update-index if a
cache entry written out has the current timestamp, but that
means we can make at most one commit per second, and given that
the e-mail patch workflow used by Linus needs to process at
least 5 commits per second, it is not an acceptable solution.
Linus notes that git-apply is primarily used to update the index
while processing e-mailed patches, which is true, and
git-apply's up-to-date check is fooled by the same problem but
luckily in the other direction, so it is not really a big issue,
but still it is disturbing.
The function ce_match_stat() is called to bypass the comparison
against filesystem data when the stat data recorded in the cache
entry matches what stat() returns from the filesystem. This
patch tackles the problem by changing it to actually go to the
filesystem data for cache entries that have the same mtime as
the index file itself. This works as long as the index file and
working tree files are on the filesystems that share the same
monotonic clock. Files on network mounted filesystems sometimes
get skewed timestamps compared to "date" output, but as long as
working tree files' timestamps are skewed the same way as the
index file's, this approach still works. The only problematic
files are the ones that have the same timestamp as the index
file's, because two file updates that sandwitch the index file
update must happen within the same second to trigger the
problem.
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-20 16:02:15 +08:00
|
|
|
index_file_timestamp = 0;
|
2006-07-26 12:32:18 +08:00
|
|
|
fd = open(path, O_RDONLY);
|
2005-10-02 04:24:27 +08:00
|
|
|
if (fd < 0) {
|
|
|
|
if (errno == ENOENT)
|
|
|
|
return 0;
|
|
|
|
die("index file open failed (%s)", strerror(errno));
|
|
|
|
}
|
2005-04-08 06:13:13 +08:00
|
|
|
|
|
|
|
if (!fstat(fd, &st)) {
|
2007-03-07 09:44:37 +08:00
|
|
|
cache_mmap_size = xsize_t(st.st_size);
|
2005-04-08 06:13:13 +08:00
|
|
|
errno = EINVAL;
|
2006-07-26 12:32:18 +08:00
|
|
|
if (cache_mmap_size >= sizeof(struct cache_header) + 20)
|
2006-12-24 13:47:23 +08:00
|
|
|
cache_mmap = xmmap(NULL, cache_mmap_size, PROT_READ | PROT_WRITE, MAP_PRIVATE, fd, 0);
|
2006-12-26 12:40:58 +08:00
|
|
|
else
|
|
|
|
die("index file smaller than expected");
|
|
|
|
} else
|
|
|
|
die("cannot stat the open index (%s)", strerror(errno));
|
2005-04-08 06:13:13 +08:00
|
|
|
close(fd);
|
|
|
|
|
2006-07-26 12:32:18 +08:00
|
|
|
hdr = cache_mmap;
|
|
|
|
if (verify_hdr(hdr, cache_mmap_size) < 0)
|
2005-04-08 06:13:13 +08:00
|
|
|
goto unmap;
|
|
|
|
|
2005-04-16 01:44:27 +08:00
|
|
|
active_nr = ntohl(hdr->hdr_entries);
|
2005-04-08 06:13:13 +08:00
|
|
|
active_alloc = alloc_nr(active_nr);
|
2006-05-10 00:14:00 +08:00
|
|
|
active_cache = xcalloc(active_alloc, sizeof(struct cache_entry *));
|
2005-04-08 06:13:13 +08:00
|
|
|
|
|
|
|
offset = sizeof(*hdr);
|
2005-04-16 01:44:27 +08:00
|
|
|
for (i = 0; i < active_nr; i++) {
|
2006-07-26 12:32:18 +08:00
|
|
|
struct cache_entry *ce = (struct cache_entry *) ((char *) cache_mmap + offset);
|
2005-04-08 06:13:13 +08:00
|
|
|
offset = offset + ce_size(ce);
|
|
|
|
active_cache[i] = ce;
|
|
|
|
}
|
Racy GIT
This fixes the longstanding "Racy GIT" problem, which was pretty
much there from the beginning of time, but was first
demonstrated by Pasky in this message on October 24, 2005:
http://marc.theaimsgroup.com/?l=git&m=113014629716878
If you run the following sequence of commands:
echo frotz >infocom
git update-index --add infocom
echo xyzzy >infocom
so that the second update to file "infocom" does not change
st_mtime, what is recorded as the stat information for the cache
entry "infocom" exactly matches what is on the filesystem
(owner, group, inum, mtime, ctime, mode, length). After this
sequence, we incorrectly think "infocom" file still has string
"frotz" in it, and get really confused. E.g. git-diff-files
would say there is no change, git-update-index --refresh would
not even look at the filesystem to correct the situation.
Some ways of working around this issue were already suggested by
Linus in the same thread on the same day, including waiting
until the next second before returning from update-index if a
cache entry written out has the current timestamp, but that
means we can make at most one commit per second, and given that
the e-mail patch workflow used by Linus needs to process at
least 5 commits per second, it is not an acceptable solution.
Linus notes that git-apply is primarily used to update the index
while processing e-mailed patches, which is true, and
git-apply's up-to-date check is fooled by the same problem but
luckily in the other direction, so it is not really a big issue,
but still it is disturbing.
The function ce_match_stat() is called to bypass the comparison
against filesystem data when the stat data recorded in the cache
entry matches what stat() returns from the filesystem. This
patch tackles the problem by changing it to actually go to the
filesystem data for cache entries that have the same mtime as
the index file itself. This works as long as the index file and
working tree files are on the filesystems that share the same
monotonic clock. Files on network mounted filesystems sometimes
get skewed timestamps compared to "date" output, but as long as
working tree files' timestamps are skewed the same way as the
index file's, this approach still works. The only problematic
files are the ones that have the same timestamp as the index
file's, because two file updates that sandwitch the index file
update must happen within the same second to trigger the
problem.
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-20 16:02:15 +08:00
|
|
|
index_file_timestamp = st.st_mtime;
|
2006-07-26 12:32:18 +08:00
|
|
|
while (offset <= cache_mmap_size - 20 - 8) {
|
2006-04-25 12:18:58 +08:00
|
|
|
/* After an array of active_nr index entries,
|
|
|
|
* there can be arbitrary number of extended
|
|
|
|
* sections, each of which is prefixed with
|
|
|
|
* extension name (4-byte) and section length
|
|
|
|
* in 4-byte network byte order.
|
|
|
|
*/
|
|
|
|
unsigned long extsize;
|
2006-07-26 12:32:18 +08:00
|
|
|
memcpy(&extsize, (char *) cache_mmap + offset + 4, 4);
|
2006-04-25 12:18:58 +08:00
|
|
|
extsize = ntohl(extsize);
|
2006-07-26 12:32:18 +08:00
|
|
|
if (read_index_extension(((const char *) cache_mmap) + offset,
|
|
|
|
(char *) cache_mmap + offset + 8,
|
2006-06-18 23:18:09 +08:00
|
|
|
extsize) < 0)
|
2006-04-25 12:18:58 +08:00
|
|
|
goto unmap;
|
|
|
|
offset += 8;
|
|
|
|
offset += extsize;
|
|
|
|
}
|
2005-04-08 06:13:13 +08:00
|
|
|
return active_nr;
|
|
|
|
|
|
|
|
unmap:
|
2006-07-26 12:32:18 +08:00
|
|
|
munmap(cache_mmap, cache_mmap_size);
|
2005-04-08 06:13:13 +08:00
|
|
|
errno = EINVAL;
|
2005-10-02 04:24:27 +08:00
|
|
|
die("index file corrupt");
|
2005-04-08 06:13:13 +08:00
|
|
|
}
|
|
|
|
|
2006-11-18 20:07:06 +08:00
|
|
|
int discard_cache(void)
|
Status update on merge-recursive in C
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: Junio C Hamano <junkio@cox.net>
2006-07-09 00:42:41 +08:00
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
|
2006-08-10 22:47:21 +08:00
|
|
|
active_nr = active_cache_changed = 0;
|
|
|
|
index_file_timestamp = 0;
|
|
|
|
cache_tree_free(&active_cache_tree);
|
Status update on merge-recursive in C
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: Junio C Hamano <junkio@cox.net>
2006-07-09 00:42:41 +08:00
|
|
|
if (cache_mmap == NULL)
|
|
|
|
return 0;
|
|
|
|
ret = munmap(cache_mmap, cache_mmap_size);
|
|
|
|
cache_mmap = NULL;
|
|
|
|
cache_mmap_size = 0;
|
|
|
|
|
|
|
|
/* no need to throw away allocated active_cache */
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2005-04-21 03:16:57 +08:00
|
|
|
#define WRITE_BUFFER_SIZE 8192
|
2005-05-18 20:14:09 +08:00
|
|
|
static unsigned char write_buffer[WRITE_BUFFER_SIZE];
|
2005-04-21 03:16:57 +08:00
|
|
|
static unsigned long write_buffer_len;
|
|
|
|
|
2006-08-09 05:47:32 +08:00
|
|
|
static int ce_write_flush(SHA_CTX *context, int fd)
|
|
|
|
{
|
|
|
|
unsigned int buffered = write_buffer_len;
|
|
|
|
if (buffered) {
|
|
|
|
SHA1_Update(context, write_buffer, buffered);
|
2007-01-08 23:58:23 +08:00
|
|
|
if (write_in_full(fd, write_buffer, buffered) != buffered)
|
2006-08-09 05:47:32 +08:00
|
|
|
return -1;
|
|
|
|
write_buffer_len = 0;
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2005-04-21 03:36:41 +08:00
|
|
|
static int ce_write(SHA_CTX *context, int fd, void *data, unsigned int len)
|
2005-04-21 03:16:57 +08:00
|
|
|
{
|
|
|
|
while (len) {
|
|
|
|
unsigned int buffered = write_buffer_len;
|
|
|
|
unsigned int partial = WRITE_BUFFER_SIZE - buffered;
|
|
|
|
if (partial > len)
|
|
|
|
partial = len;
|
|
|
|
memcpy(write_buffer + buffered, data, partial);
|
|
|
|
buffered += partial;
|
|
|
|
if (buffered == WRITE_BUFFER_SIZE) {
|
2006-08-09 05:47:32 +08:00
|
|
|
write_buffer_len = buffered;
|
|
|
|
if (ce_write_flush(context, fd))
|
2005-04-21 03:16:57 +08:00
|
|
|
return -1;
|
|
|
|
buffered = 0;
|
|
|
|
}
|
|
|
|
write_buffer_len = buffered;
|
|
|
|
len -= partial;
|
2006-06-18 23:18:09 +08:00
|
|
|
data = (char *) data + partial;
|
2005-04-21 03:16:57 +08:00
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2006-04-25 12:18:58 +08:00
|
|
|
static int write_index_ext_header(SHA_CTX *context, int fd,
|
2006-05-29 03:08:08 +08:00
|
|
|
unsigned int ext, unsigned int sz)
|
2006-04-25 12:18:58 +08:00
|
|
|
{
|
|
|
|
ext = htonl(ext);
|
|
|
|
sz = htonl(sz);
|
2006-08-15 04:38:14 +08:00
|
|
|
return ((ce_write(context, fd, &ext, 4) < 0) ||
|
|
|
|
(ce_write(context, fd, &sz, 4) < 0)) ? -1 : 0;
|
2006-04-25 12:18:58 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static int ce_flush(SHA_CTX *context, int fd)
|
2005-04-21 03:16:57 +08:00
|
|
|
{
|
|
|
|
unsigned int left = write_buffer_len;
|
2005-04-21 03:36:41 +08:00
|
|
|
|
2005-04-21 03:16:57 +08:00
|
|
|
if (left) {
|
|
|
|
write_buffer_len = 0;
|
2005-04-21 03:36:41 +08:00
|
|
|
SHA1_Update(context, write_buffer, left);
|
2005-04-21 03:16:57 +08:00
|
|
|
}
|
2005-04-21 03:36:41 +08:00
|
|
|
|
2005-09-11 21:27:47 +08:00
|
|
|
/* Flush first if not enough space for SHA1 signature */
|
|
|
|
if (left + 20 > WRITE_BUFFER_SIZE) {
|
2007-01-08 23:58:23 +08:00
|
|
|
if (write_in_full(fd, write_buffer, left) != left)
|
2005-09-11 21:27:47 +08:00
|
|
|
return -1;
|
|
|
|
left = 0;
|
|
|
|
}
|
|
|
|
|
2005-04-21 03:36:41 +08:00
|
|
|
/* Append the SHA1 signature at the end */
|
2006-04-25 12:18:58 +08:00
|
|
|
SHA1_Final(write_buffer + left, context);
|
2005-04-21 03:36:41 +08:00
|
|
|
left += 20;
|
2007-01-08 23:58:23 +08:00
|
|
|
return (write_in_full(fd, write_buffer, left) != left) ? -1 : 0;
|
2005-04-21 03:16:57 +08:00
|
|
|
}
|
|
|
|
|
2005-12-21 04:12:18 +08:00
|
|
|
static void ce_smudge_racily_clean_entry(struct cache_entry *ce)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* The only thing we care about in this function is to smudge the
|
|
|
|
* falsely clean entry due to touch-update-touch race, so we leave
|
|
|
|
* everything else as they are. We are called for entries whose
|
|
|
|
* ce_mtime match the index file mtime.
|
|
|
|
*/
|
|
|
|
struct stat st;
|
|
|
|
|
|
|
|
if (lstat(ce->name, &st) < 0)
|
|
|
|
return;
|
|
|
|
if (ce_match_stat_basic(ce, &st))
|
|
|
|
return;
|
|
|
|
if (ce_modified_check_fs(ce, &st)) {
|
2005-12-21 06:18:47 +08:00
|
|
|
/* This is "racily clean"; smudge it. Note that this
|
|
|
|
* is a tricky code. At first glance, it may appear
|
|
|
|
* that it can break with this sequence:
|
|
|
|
*
|
|
|
|
* $ echo xyzzy >frotz
|
|
|
|
* $ git-update-index --add frotz
|
|
|
|
* $ : >frotz
|
|
|
|
* $ sleep 3
|
|
|
|
* $ echo filfre >nitfol
|
|
|
|
* $ git-update-index --add nitfol
|
|
|
|
*
|
2006-08-05 19:16:02 +08:00
|
|
|
* but it does not. When the second update-index runs,
|
2005-12-21 06:18:47 +08:00
|
|
|
* it notices that the entry "frotz" has the same timestamp
|
|
|
|
* as index, and if we were to smudge it by resetting its
|
|
|
|
* size to zero here, then the object name recorded
|
|
|
|
* in index is the 6-byte file but the cached stat information
|
|
|
|
* becomes zero --- which would then match what we would
|
|
|
|
* obtain from the filesystem next time we stat("frotz").
|
|
|
|
*
|
|
|
|
* However, the second update-index, before calling
|
|
|
|
* this function, notices that the cached size is 6
|
|
|
|
* bytes and what is on the filesystem is an empty
|
|
|
|
* file, and never calls us, so the cached size information
|
|
|
|
* for "frotz" stays 6 which does not match the filesystem.
|
|
|
|
*/
|
2005-12-21 04:12:18 +08:00
|
|
|
ce->ce_size = htonl(0);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2006-04-25 12:18:58 +08:00
|
|
|
int write_cache(int newfd, struct cache_entry **cache, int entries)
|
2005-04-10 03:09:27 +08:00
|
|
|
{
|
|
|
|
SHA_CTX c;
|
|
|
|
struct cache_header hdr;
|
2006-08-16 12:40:43 +08:00
|
|
|
int i, removed;
|
2005-06-10 16:32:37 +08:00
|
|
|
|
|
|
|
for (i = removed = 0; i < entries; i++)
|
|
|
|
if (!cache[i]->ce_mode)
|
|
|
|
removed++;
|
2005-04-10 03:09:27 +08:00
|
|
|
|
2005-04-16 01:44:27 +08:00
|
|
|
hdr.hdr_signature = htonl(CACHE_SIGNATURE);
|
2005-04-21 03:36:41 +08:00
|
|
|
hdr.hdr_version = htonl(2);
|
2005-06-10 16:32:37 +08:00
|
|
|
hdr.hdr_entries = htonl(entries - removed);
|
2005-04-10 03:09:27 +08:00
|
|
|
|
|
|
|
SHA1_Init(&c);
|
2005-04-21 03:36:41 +08:00
|
|
|
if (ce_write(&c, newfd, &hdr, sizeof(hdr)) < 0)
|
2005-04-10 03:09:27 +08:00
|
|
|
return -1;
|
|
|
|
|
|
|
|
for (i = 0; i < entries; i++) {
|
|
|
|
struct cache_entry *ce = cache[i];
|
2005-06-10 06:34:04 +08:00
|
|
|
if (!ce->ce_mode)
|
|
|
|
continue;
|
2006-08-09 05:47:32 +08:00
|
|
|
if (index_file_timestamp &&
|
|
|
|
index_file_timestamp <= ntohl(ce->ce_mtime.sec))
|
2005-12-21 04:12:18 +08:00
|
|
|
ce_smudge_racily_clean_entry(ce);
|
2005-04-21 03:36:41 +08:00
|
|
|
if (ce_write(&c, newfd, ce, ce_size(ce)) < 0)
|
2005-04-10 03:09:27 +08:00
|
|
|
return -1;
|
|
|
|
}
|
2006-04-24 07:52:08 +08:00
|
|
|
|
2006-04-25 12:18:58 +08:00
|
|
|
/* Write extension data here */
|
|
|
|
if (active_cache_tree) {
|
|
|
|
unsigned long sz;
|
|
|
|
void *data = cache_tree_write(active_cache_tree, &sz);
|
|
|
|
if (data &&
|
|
|
|
!write_index_ext_header(&c, newfd, CACHE_EXT_TREE, sz) &&
|
|
|
|
!ce_write(&c, newfd, data, sz))
|
2007-01-12 04:25:16 +08:00
|
|
|
free(data);
|
2006-04-25 12:18:58 +08:00
|
|
|
else {
|
|
|
|
free(data);
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return ce_flush(&c, newfd);
|
2005-04-10 03:09:27 +08:00
|
|
|
}
|