|
|
|
|
/*
|
|
|
|
|
* GIT - The information manager from hell
|
|
|
|
|
*
|
|
|
|
|
* Copyright (C) Linus Torvalds, 2005
|
|
|
|
|
*/
|
|
|
|
|
#define NO_THE_INDEX_COMPATIBILITY_MACROS
|
|
|
|
|
#include "cache.h"
|
|
|
|
|
#include "cache-tree.h"
|
|
|
|
|
#include "refs.h"
|
|
|
|
|
#include "dir.h"
|
|
|
|
|
#include "tree.h"
|
|
|
|
|
#include "commit.h"
|
|
|
|
|
#include "diff.h"
|
|
|
|
|
#include "diffcore.h"
|
|
|
|
|
#include "revision.h"
|
|
|
|
|
#include "blob.h"
|
|
|
|
|
|
|
|
|
|
/* 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" */
|
|
|
|
|
|
|
|
|
|
struct index_state the_index;
|
|
|
|
|
|
|
|
|
|
static void set_index_entry(struct index_state *istate, int nr, struct cache_entry *ce)
|
|
|
|
|
{
|
|
|
|
|
istate->cache[nr] = ce;
|
|
|
|
|
add_name_hash(istate, ce);
|
|
|
|
|
}
|
|
|
|
|
|
Create pathname-based hash-table lookup into index
This creates a hash index of every single file added to the index.
Right now that hash index isn't actually used for much: I implemented a
"cache_name_exists()" function that uses it to efficiently look up a
filename in the index without having to do the O(logn) binary search,
but quite frankly, that's not why this patch is interesting.
No, the whole and only reason to create the hash of the filenames in the
index is that by modifying the hash function, you can fairly easily do
things like making it always hash equivalent names into the same bucket.
That, in turn, means that suddenly questions like "does this name exist
in the index under an _equivalent_ name?" becomes much much cheaper.
Guiding principles behind this patch:
- it shouldn't be too costly. In fact, my primary goal here was to
actually speed up "git commit" with a fully populated kernel tree, by
being faster at checking whether a file already existed in the index. I
did succeed, but only barely:
Best before:
[torvalds@woody linux]$ time git commit > /dev/null
real 0m0.255s
user 0m0.168s
sys 0m0.088s
Best after:
[torvalds@woody linux]$ time ~/git/git commit > /dev/null
real 0m0.233s
user 0m0.144s
sys 0m0.088s
so some things are actually faster (~8%).
Caveat: that's really the best case. Other things are invariably going
to be slightly slower, since we populate that index cache, and quite
frankly, few things really use it to look things up.
That said, the cost is really quite small. The worst case is probably
doing a "git ls-files", which will do very little except puopulate the
index, and never actually looks anything up in it, just lists it.
Before:
[torvalds@woody linux]$ time git ls-files > /dev/null
real 0m0.016s
user 0m0.016s
sys 0m0.000s
After:
[torvalds@woody linux]$ time ~/git/git ls-files > /dev/null
real 0m0.021s
user 0m0.012s
sys 0m0.008s
and while the thing has really gotten relatively much slower, we're
still talking about something almost unmeasurable (eg 5ms). And that
really should be pretty much the worst case.
So we lose 5ms on one "benchmark", but win 22ms on another. Pick your
poison - this patch has the advantage that it will _likely_ speed up
the cases that are complex and expensive more than it slows down the
cases that are already so fast that nobody cares. But if you look at
relative speedups/slowdowns, it doesn't look so good.
- It should be simple and clean
The code may be a bit subtle (the reasons I do hash removal the way I
do etc), but it re-uses the existing hash.c files, so it really is
fairly small and straightforward apart from a few odd details.
Now, this patch on its own doesn't really do much, but I think it's worth
looking at, if only because if done correctly, the name hashing really can
make an improvement to the whole issue of "do we have a filename that
looks like this in the index already". And at least it gets real testing
by being used even by default (ie there is a real use-case for it even
without any insane filesystems).
NOTE NOTE NOTE! The current hash is a joke. I'm ashamed of it, I'm just
not ashamed of it enough to really care. I took all the numbers out of my
nether regions - I'm sure it's good enough that it works in practice, but
the whole point was that you can make a really much fancier hash that
hashes characters not directly, but by their upper-case value or something
like that, and thus you get a case-insensitive hash, while still keeping
the name and the index itself totally case sensitive.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
17 years ago
|
|
|
static void replace_index_entry(struct index_state *istate, int nr, struct cache_entry *ce)
|
|
|
|
|
{
|
|
|
|
|
struct cache_entry *old = istate->cache[nr];
|
|
|
|
|
|
|
|
|
|
remove_name_hash(old);
|
Fix name re-hashing semantics
We handled the case of removing and re-inserting cache entries badly,
which is something that merging commonly needs to do (removing the
different stages, and then re-inserting one of them as the merged
state).
We even had a rather ugly special case for this failure case, where
replace_index_entry() basically turned itself into a no-op if the new
and the old entries were the same, exactly because the hash routines
didn't handle it on their own.
So what this patch does is to not just have the UNHASHED bit, but a
HASHED bit too, and when you insert an entry into the name hash, that
involves:
- clear the UNHASHED bit, because now it's valid again for lookup
(which is really all that UNHASHED meant)
- if we're being lazy, we're done here (but we still want to clear the
UNHASHED bit regardless of lazy mode, since we can become unlazy
later, and so we need the UNHASHED bit to always be set correctly,
even if we never actually insert the entry into the hash list)
- if it was already hashed, we just leave it on the list
- otherwise mark it HASHED and insert it into the list
this all means that unhashing and rehashing a name all just works
automatically. Obviously, you cannot change the name of an entry (that
would be a serious bug), but nothing can validly do that anyway (you'd
have to allocate a new struct cache_entry anyway since the name length
could change), so that's not a new limitation.
The code actually gets simpler in many ways, although the lazy hashing
does mean that there are a few odd cases (ie something can be marked
unhashed even though it was never on the hash in the first place, and
isn't actually marked hashed!).
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
17 years ago
|
|
|
set_index_entry(istate, nr, ce);
|
Create pathname-based hash-table lookup into index
This creates a hash index of every single file added to the index.
Right now that hash index isn't actually used for much: I implemented a
"cache_name_exists()" function that uses it to efficiently look up a
filename in the index without having to do the O(logn) binary search,
but quite frankly, that's not why this patch is interesting.
No, the whole and only reason to create the hash of the filenames in the
index is that by modifying the hash function, you can fairly easily do
things like making it always hash equivalent names into the same bucket.
That, in turn, means that suddenly questions like "does this name exist
in the index under an _equivalent_ name?" becomes much much cheaper.
Guiding principles behind this patch:
- it shouldn't be too costly. In fact, my primary goal here was to
actually speed up "git commit" with a fully populated kernel tree, by
being faster at checking whether a file already existed in the index. I
did succeed, but only barely:
Best before:
[torvalds@woody linux]$ time git commit > /dev/null
real 0m0.255s
user 0m0.168s
sys 0m0.088s
Best after:
[torvalds@woody linux]$ time ~/git/git commit > /dev/null
real 0m0.233s
user 0m0.144s
sys 0m0.088s
so some things are actually faster (~8%).
Caveat: that's really the best case. Other things are invariably going
to be slightly slower, since we populate that index cache, and quite
frankly, few things really use it to look things up.
That said, the cost is really quite small. The worst case is probably
doing a "git ls-files", which will do very little except puopulate the
index, and never actually looks anything up in it, just lists it.
Before:
[torvalds@woody linux]$ time git ls-files > /dev/null
real 0m0.016s
user 0m0.016s
sys 0m0.000s
After:
[torvalds@woody linux]$ time ~/git/git ls-files > /dev/null
real 0m0.021s
user 0m0.012s
sys 0m0.008s
and while the thing has really gotten relatively much slower, we're
still talking about something almost unmeasurable (eg 5ms). And that
really should be pretty much the worst case.
So we lose 5ms on one "benchmark", but win 22ms on another. Pick your
poison - this patch has the advantage that it will _likely_ speed up
the cases that are complex and expensive more than it slows down the
cases that are already so fast that nobody cares. But if you look at
relative speedups/slowdowns, it doesn't look so good.
- It should be simple and clean
The code may be a bit subtle (the reasons I do hash removal the way I
do etc), but it re-uses the existing hash.c files, so it really is
fairly small and straightforward apart from a few odd details.
Now, this patch on its own doesn't really do much, but I think it's worth
looking at, if only because if done correctly, the name hashing really can
make an improvement to the whole issue of "do we have a filename that
looks like this in the index already". And at least it gets real testing
by being used even by default (ie there is a real use-case for it even
without any insane filesystems).
NOTE NOTE NOTE! The current hash is a joke. I'm ashamed of it, I'm just
not ashamed of it enough to really care. I took all the numbers out of my
nether regions - I'm sure it's good enough that it works in practice, but
the whole point was that you can make a really much fancier hash that
hashes characters not directly, but by their upper-case value or something
like that, and thus you get a case-insensitive hash, while still keeping
the name and the index itself totally case sensitive.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
17 years ago
|
|
|
istate->cache_changed = 1;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void rename_index_entry_at(struct index_state *istate, int nr, const char *new_name)
|
|
|
|
|
{
|
|
|
|
|
struct cache_entry *old = istate->cache[nr], *new;
|
|
|
|
|
int namelen = strlen(new_name);
|
|
|
|
|
|
|
|
|
|
new = xmalloc(cache_entry_size(namelen));
|
|
|
|
|
copy_cache_entry(new, old);
|
|
|
|
|
new->ce_flags &= ~(CE_STATE_MASK | CE_NAMEMASK);
|
|
|
|
|
new->ce_flags |= (namelen >= CE_NAMEMASK ? CE_NAMEMASK : namelen);
|
|
|
|
|
memcpy(new->name, new_name, namelen + 1);
|
|
|
|
|
|
|
|
|
|
cache_tree_invalidate_path(istate->cache_tree, old->name);
|
|
|
|
|
remove_index_entry_at(istate, nr);
|
|
|
|
|
add_index_entry(istate, new, ADD_CACHE_OK_TO_ADD|ADD_CACHE_OK_TO_REPLACE);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* 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)
|
|
|
|
|
{
|
make USE_NSEC work as expected
Since the filesystem ext4 is now defined as stable in Linux v2.6.28,
and ext4 supports nanonsecond resolution timestamps natively, it is
time to make USE_NSEC work as expected.
This will make racy git situations less likely to happen. For 'git
checkout' this means it will be less likely that we have to open, read
the contents of the file into RAM, and check if file is really
modified or not. The result sould be a litle less used CPU time, less
pagefaults and a litle faster program, at least for 'git checkout'.
Since the number of possible racy git situations would increase when
disks gets faster, this patch would be more and more helpfull as times
go by. For a fast Solid State Disk, this patch should be helpfull.
Note that, when file operations starts to take less than 1 nanosecond,
one would again start to get more racy git situations.
For more info on racy git, see Documentation/technical/racy-git.txt
For more info on ext4, see http://kernelnewbies.org/Ext4
Signed-off-by: Kjetil Barvik <barvik@broadpark.no>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
16 years ago
|
|
|
ce->ce_ctime.sec = (unsigned int)st->st_ctime;
|
|
|
|
|
ce->ce_mtime.sec = (unsigned int)st->st_mtime;
|
|
|
|
|
ce->ce_ctime.nsec = ST_CTIME_NSEC(*st);
|
|
|
|
|
ce->ce_mtime.nsec = ST_MTIME_NSEC(*st);
|
|
|
|
|
ce->ce_dev = st->st_dev;
|
|
|
|
|
ce->ce_ino = st->st_ino;
|
|
|
|
|
ce->ce_uid = st->st_uid;
|
|
|
|
|
ce->ce_gid = st->st_gid;
|
|
|
|
|
ce->ce_size = st->st_size;
|
|
|
|
|
|
|
|
|
|
if (assume_unchanged)
|
|
|
|
|
ce->ce_flags |= CE_VALID;
|
|
|
|
|
|
|
|
|
|
if (S_ISREG(st->st_mode))
|
|
|
|
|
ce_mark_uptodate(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>
19 years ago
|
|
|
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];
|
|
|
|
|
if (!index_fd(sha1, fd, st, 0, OBJ_BLOB, ce->name))
|
|
|
|
|
match = hashcmp(sha1, ce->sha1);
|
|
|
|
|
/* 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>
19 years ago
|
|
|
}
|
|
|
|
|
return match;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
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>
19 years ago
|
|
|
{
|
|
|
|
|
int match = -1;
|
|
|
|
|
void *buffer;
|
|
|
|
|
unsigned long size;
|
|
|
|
|
enum object_type type;
|
|
|
|
|
struct strbuf sb = STRBUF_INIT;
|
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>
19 years ago
|
|
|
|
|
|
|
|
if (strbuf_readlink(&sb, ce->name, 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>
19 years ago
|
|
|
return -1;
|
|
|
|
|
|
|
|
|
|
buffer = read_sha1_file(ce->sha1, &type, &size);
|
|
|
|
|
if (buffer) {
|
|
|
|
|
if (size == sb.len)
|
|
|
|
|
match = memcmp(buffer, sb.buf, size);
|
|
|
|
|
free(buffer);
|
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>
19 years ago
|
|
|
}
|
|
|
|
|
strbuf_release(&sb);
|
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>
19 years ago
|
|
|
return match;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int ce_compare_gitlink(struct cache_entry *ce)
|
|
|
|
|
{
|
|
|
|
|
unsigned char sha1[20];
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* We don't actually require that the .git directory
|
|
|
|
|
* under GITLINK 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>
19 years ago
|
|
|
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:
|
|
|
|
|
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>
19 years ago
|
|
|
return DATA_CHANGED;
|
|
|
|
|
break;
|
|
|
|
|
case S_IFDIR:
|
|
|
|
|
if (S_ISGITLINK(ce->ce_mode))
|
|
|
|
|
return ce_compare_gitlink(ce) ? DATA_CHANGED : 0;
|
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>
19 years ago
|
|
|
default:
|
|
|
|
|
return TYPE_CHANGED;
|
|
|
|
|
}
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
rm: loosen safety valve for empty files
If a file is different between the working tree copy, the index, and the
HEAD, then we do not allow it to be deleted without --force.
However, this is overly tight in the face of "git add --intent-to-add":
$ git add --intent-to-add file
$ : oops, I don't actually want to stage that yet
$ git rm --cached file
error: 'empty' has staged content different from both the
file and the HEAD (use -f to force removal)
$ git rm -f --cached file
Unfortunately, there is currently no way to distinguish between an empty
file that has been added and an "intent to add" file. The ideal behavior
would be to disallow the former while allowing the latter.
This patch loosens the safety valve to allow the deletion only if we are
deleting the cached entry and the cached content is empty. This covers
the intent-to-add situation, and assumes there is little harm in not
protecting users who have legitimately added an empty file. In many
cases, the file will still be empty, in which case the safety valve does
not trigger anyway (since the content remains untouched in the working
tree). Otherwise, we do remove the fact that no content was staged, but
given that the content is by definition empty, it is not terribly
difficult for a user to recreate it.
However, we still document the desired behavior in the form of two
tests. One checks the correct removal of an intent-to-add file. The other
checks that we still disallow removal of empty files, but is marked as
expect_failure to indicate this compromise. If the intent-to-add feature
is ever extended to differentiate between normal empty files and
intent-to-add files, then the safety valve can be re-tightened.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
16 years ago
|
|
|
int is_empty_blob_sha1(const unsigned char *sha1)
|
|
|
|
|
{
|
|
|
|
|
static const unsigned char empty_blob_sha1[20] = {
|
|
|
|
|
0xe6,0x9d,0xe2,0x9b,0xb2,0xd1,0xd6,0x43,0x4b,0x8b,
|
|
|
|
|
0x29,0xae,0x77,0x5a,0xd8,0xc2,0xe4,0x8c,0x53,0x91
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
return !hashcmp(sha1, empty_blob_sha1);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int ce_match_stat_basic(struct cache_entry *ce, struct stat *st)
|
|
|
|
|
{
|
|
|
|
|
unsigned int changed = 0;
|
|
|
|
|
|
|
|
|
|
if (ce->ce_flags & CE_REMOVE)
|
|
|
|
|
return MODE_CHANGED | DATA_CHANGED | TYPE_CHANGED;
|
|
|
|
|
|
|
|
|
|
switch (ce->ce_mode & S_IFMT) {
|
|
|
|
|
case S_IFREG:
|
|
|
|
|
changed |= !S_ISREG(st->st_mode) ? TYPE_CHANGED : 0;
|
|
|
|
|
/* We consider only the owner x bit to be relevant for
|
|
|
|
|
* "mode changes"
|
|
|
|
|
*/
|
|
|
|
|
if (trust_executable_bit &&
|
|
|
|
|
(0100 & (ce->ce_mode ^ st->st_mode)))
|
|
|
|
|
changed |= MODE_CHANGED;
|
|
|
|
|
break;
|
|
|
|
|
case S_IFLNK:
|
|
|
|
|
if (!S_ISLNK(st->st_mode) &&
|
|
|
|
|
(has_symlinks || !S_ISREG(st->st_mode)))
|
|
|
|
|
changed |= TYPE_CHANGED;
|
|
|
|
|
break;
|
|
|
|
|
case S_IFGITLINK:
|
|
|
|
|
/* We ignore most of the st_xxx fields for gitlinks */
|
|
|
|
|
if (!S_ISDIR(st->st_mode))
|
|
|
|
|
changed |= TYPE_CHANGED;
|
|
|
|
|
else if (ce_compare_gitlink(ce))
|
|
|
|
|
changed |= DATA_CHANGED;
|
|
|
|
|
return changed;
|
|
|
|
|
default:
|
|
|
|
|
die("internal error: ce_mode is %o", ce->ce_mode);
|
|
|
|
|
}
|
make USE_NSEC work as expected
Since the filesystem ext4 is now defined as stable in Linux v2.6.28,
and ext4 supports nanonsecond resolution timestamps natively, it is
time to make USE_NSEC work as expected.
This will make racy git situations less likely to happen. For 'git
checkout' this means it will be less likely that we have to open, read
the contents of the file into RAM, and check if file is really
modified or not. The result sould be a litle less used CPU time, less
pagefaults and a litle faster program, at least for 'git checkout'.
Since the number of possible racy git situations would increase when
disks gets faster, this patch would be more and more helpfull as times
go by. For a fast Solid State Disk, this patch should be helpfull.
Note that, when file operations starts to take less than 1 nanosecond,
one would again start to get more racy git situations.
For more info on racy git, see Documentation/technical/racy-git.txt
For more info on ext4, see http://kernelnewbies.org/Ext4
Signed-off-by: Kjetil Barvik <barvik@broadpark.no>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
16 years ago
|
|
|
if (ce->ce_mtime.sec != (unsigned int)st->st_mtime)
|
|
|
|
|
changed |= MTIME_CHANGED;
|
make USE_NSEC work as expected
Since the filesystem ext4 is now defined as stable in Linux v2.6.28,
and ext4 supports nanonsecond resolution timestamps natively, it is
time to make USE_NSEC work as expected.
This will make racy git situations less likely to happen. For 'git
checkout' this means it will be less likely that we have to open, read
the contents of the file into RAM, and check if file is really
modified or not. The result sould be a litle less used CPU time, less
pagefaults and a litle faster program, at least for 'git checkout'.
Since the number of possible racy git situations would increase when
disks gets faster, this patch would be more and more helpfull as times
go by. For a fast Solid State Disk, this patch should be helpfull.
Note that, when file operations starts to take less than 1 nanosecond,
one would again start to get more racy git situations.
For more info on racy git, see Documentation/technical/racy-git.txt
For more info on ext4, see http://kernelnewbies.org/Ext4
Signed-off-by: Kjetil Barvik <barvik@broadpark.no>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
16 years ago
|
|
|
if (trust_ctime && ce->ce_ctime.sec != (unsigned int)st->st_ctime)
|
|
|
|
|
changed |= CTIME_CHANGED;
|
|
|
|
|
|
make USE_NSEC work as expected
Since the filesystem ext4 is now defined as stable in Linux v2.6.28,
and ext4 supports nanonsecond resolution timestamps natively, it is
time to make USE_NSEC work as expected.
This will make racy git situations less likely to happen. For 'git
checkout' this means it will be less likely that we have to open, read
the contents of the file into RAM, and check if file is really
modified or not. The result sould be a litle less used CPU time, less
pagefaults and a litle faster program, at least for 'git checkout'.
Since the number of possible racy git situations would increase when
disks gets faster, this patch would be more and more helpfull as times
go by. For a fast Solid State Disk, this patch should be helpfull.
Note that, when file operations starts to take less than 1 nanosecond,
one would again start to get more racy git situations.
For more info on racy git, see Documentation/technical/racy-git.txt
For more info on ext4, see http://kernelnewbies.org/Ext4
Signed-off-by: Kjetil Barvik <barvik@broadpark.no>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
16 years ago
|
|
|
#ifdef USE_NSEC
|
|
|
|
|
if (ce->ce_mtime.nsec != ST_MTIME_NSEC(*st))
|
make USE_NSEC work as expected
Since the filesystem ext4 is now defined as stable in Linux v2.6.28,
and ext4 supports nanonsecond resolution timestamps natively, it is
time to make USE_NSEC work as expected.
This will make racy git situations less likely to happen. For 'git
checkout' this means it will be less likely that we have to open, read
the contents of the file into RAM, and check if file is really
modified or not. The result sould be a litle less used CPU time, less
pagefaults and a litle faster program, at least for 'git checkout'.
Since the number of possible racy git situations would increase when
disks gets faster, this patch would be more and more helpfull as times
go by. For a fast Solid State Disk, this patch should be helpfull.
Note that, when file operations starts to take less than 1 nanosecond,
one would again start to get more racy git situations.
For more info on racy git, see Documentation/technical/racy-git.txt
For more info on ext4, see http://kernelnewbies.org/Ext4
Signed-off-by: Kjetil Barvik <barvik@broadpark.no>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
16 years ago
|
|
|
changed |= MTIME_CHANGED;
|
|
|
|
|
if (trust_ctime && ce->ce_ctime.nsec != ST_CTIME_NSEC(*st))
|
make USE_NSEC work as expected
Since the filesystem ext4 is now defined as stable in Linux v2.6.28,
and ext4 supports nanonsecond resolution timestamps natively, it is
time to make USE_NSEC work as expected.
This will make racy git situations less likely to happen. For 'git
checkout' this means it will be less likely that we have to open, read
the contents of the file into RAM, and check if file is really
modified or not. The result sould be a litle less used CPU time, less
pagefaults and a litle faster program, at least for 'git checkout'.
Since the number of possible racy git situations would increase when
disks gets faster, this patch would be more and more helpfull as times
go by. For a fast Solid State Disk, this patch should be helpfull.
Note that, when file operations starts to take less than 1 nanosecond,
one would again start to get more racy git situations.
For more info on racy git, see Documentation/technical/racy-git.txt
For more info on ext4, see http://kernelnewbies.org/Ext4
Signed-off-by: Kjetil Barvik <barvik@broadpark.no>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
16 years ago
|
|
|
changed |= CTIME_CHANGED;
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
if (ce->ce_uid != (unsigned int) st->st_uid ||
|
|
|
|
|
ce->ce_gid != (unsigned int) st->st_gid)
|
|
|
|
|
changed |= OWNER_CHANGED;
|
|
|
|
|
if (ce->ce_ino != (unsigned int) st->st_ino)
|
|
|
|
|
changed |= INODE_CHANGED;
|
|
|
|
|
|
|
|
|
|
#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 != (unsigned int) st->st_dev)
|
|
|
|
|
changed |= INODE_CHANGED;
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
if (ce->ce_size != (unsigned int) st->st_size)
|
|
|
|
|
changed |= DATA_CHANGED;
|
|
|
|
|
|
|
|
|
|
/* Racily smudged entry? */
|
|
|
|
|
if (!ce->ce_size) {
|
|
|
|
|
if (!is_empty_blob_sha1(ce->sha1))
|
|
|
|
|
changed |= DATA_CHANGED;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return changed;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int is_racy_timestamp(const struct index_state *istate, struct cache_entry *ce)
|
|
|
|
|
{
|
|
|
|
|
return (!S_ISGITLINK(ce->ce_mode) &&
|
make USE_NSEC work as expected
Since the filesystem ext4 is now defined as stable in Linux v2.6.28,
and ext4 supports nanonsecond resolution timestamps natively, it is
time to make USE_NSEC work as expected.
This will make racy git situations less likely to happen. For 'git
checkout' this means it will be less likely that we have to open, read
the contents of the file into RAM, and check if file is really
modified or not. The result sould be a litle less used CPU time, less
pagefaults and a litle faster program, at least for 'git checkout'.
Since the number of possible racy git situations would increase when
disks gets faster, this patch would be more and more helpfull as times
go by. For a fast Solid State Disk, this patch should be helpfull.
Note that, when file operations starts to take less than 1 nanosecond,
one would again start to get more racy git situations.
For more info on racy git, see Documentation/technical/racy-git.txt
For more info on ext4, see http://kernelnewbies.org/Ext4
Signed-off-by: Kjetil Barvik <barvik@broadpark.no>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
16 years ago
|
|
|
istate->timestamp.sec &&
|
|
|
|
|
#ifdef USE_NSEC
|
|
|
|
|
/* nanosecond timestamped files can also be racy! */
|
|
|
|
|
(istate->timestamp.sec < ce->ce_mtime.sec ||
|
|
|
|
|
(istate->timestamp.sec == ce->ce_mtime.sec &&
|
|
|
|
|
istate->timestamp.nsec <= ce->ce_mtime.nsec))
|
|
|
|
|
#else
|
|
|
|
|
istate->timestamp.sec <= ce->ce_mtime.sec
|
|
|
|
|
#endif
|
|
|
|
|
);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
int ie_match_stat(const struct index_state *istate,
|
|
|
|
|
struct cache_entry *ce, struct stat *st,
|
|
|
|
|
unsigned int options)
|
|
|
|
|
{
|
|
|
|
|
unsigned int changed;
|
|
|
|
|
int ignore_valid = options & CE_MATCH_IGNORE_VALID;
|
|
|
|
|
int assume_racy_is_modified = options & CE_MATCH_RACY_IS_DIRTY;
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* 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 & CE_VALID))
|
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Intent-to-add entries have not been added, so the index entry
|
|
|
|
|
* by definition never matches what is in the work tree until it
|
|
|
|
|
* actually gets added.
|
|
|
|
|
*/
|
|
|
|
|
if (ce->ce_flags & CE_INTENT_TO_ADD)
|
|
|
|
|
return DATA_CHANGED | TYPE_CHANGED | MODE_CHANGED;
|
|
|
|
|
|
|
|
|
|
changed = ce_match_stat_basic(ce, st);
|
|
|
|
|
|
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>
19 years ago
|
|
|
/*
|
|
|
|
|
* 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
|
|
|
|
|
* 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>
19 years ago
|
|
|
*/
|
|
|
|
|
if (!changed && is_racy_timestamp(istate, ce)) {
|
|
|
|
|
if (assume_racy_is_modified)
|
|
|
|
|
changed |= DATA_CHANGED;
|
|
|
|
|
else
|
|
|
|
|
changed |= ce_modified_check_fs(ce, st);
|
|
|
|
|
}
|
|
|
|
|
|
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>
19 years ago
|
|
|
return changed;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
int ie_modified(const struct index_state *istate,
|
|
|
|
|
struct cache_entry *ce, struct stat *st, unsigned int options)
|
|
|
|
|
{
|
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>
19 years ago
|
|
|
int changed, changed_fs;
|
|
|
|
|
|
|
|
|
|
changed = ie_match_stat(istate, ce, st, options);
|
|
|
|
|
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, as we have never even read the
|
|
|
|
|
* lstat(2) information once, and we cannot trust DATA_CHANGED
|
|
|
|
|
* returned by ie_match_stat() which in turn was returned by
|
|
|
|
|
* ce_match_stat_basic() to signal that the filesize of the
|
|
|
|
|
* blob changed. We have to actually go to the filesystem to
|
|
|
|
|
* see if the contents match, and if so, should answer "unchanged".
|
|
|
|
|
*
|
|
|
|
|
* The logic does not apply to gitlinks, as ce_match_stat_basic()
|
|
|
|
|
* already has checked the actual HEAD from the filesystem in the
|
|
|
|
|
* subproject. If ie_match_stat() already said it is different,
|
|
|
|
|
* then we know it is.
|
|
|
|
|
*/
|
|
|
|
|
if ((changed & DATA_CHANGED) &&
|
|
|
|
|
(S_ISGITLINK(ce->ce_mode) || ce->ce_size != 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>
19 years ago
|
|
|
changed_fs = ce_modified_check_fs(ce, st);
|
|
|
|
|
if (changed_fs)
|
|
|
|
|
return changed | changed_fs;
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
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];
|
Fix thinko in subproject entry sorting
This fixes a total thinko in my original series: subprojects do *not* sort
like directories, because the index is sorted purely by full pathname, and
since a subproject shows up in the index as a normal NUL-terminated
string, it never has the issues with sorting with the '/' at the end.
So if you have a subproject "proj" and a file "proj.c", the subproject
sorts alphabetically before the file in the index (and must thus also sort
that way in a tree object, since trees sort as the index).
In contrast, it you have two files "proj/file" and "proj.c", the "proj.c"
will sort alphabetically before "proj/file" in the index. The index
itself, of course, does not actually contain an entry "proj/", but in the
*tree* that gets written out, the tree entry "proj" will sort after the
file entry "proj.c", which is the only real magic sorting rule.
In other words: the magic sorting rule only affects tree entries, and
*only* affects tree entries that point to other trees (ie are of the type
S_IFDIR).
Anyway, that thinko just means that we should remove the special case to
make S_ISDIRLNK entries sort like S_ISDIR entries. They don't. They sort
like normal files.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
18 years ago
|
|
|
if (!c1 && S_ISDIR(mode1))
|
|
|
|
|
c1 = '/';
|
Fix thinko in subproject entry sorting
This fixes a total thinko in my original series: subprojects do *not* sort
like directories, because the index is sorted purely by full pathname, and
since a subproject shows up in the index as a normal NUL-terminated
string, it never has the issues with sorting with the '/' at the end.
So if you have a subproject "proj" and a file "proj.c", the subproject
sorts alphabetically before the file in the index (and must thus also sort
that way in a tree object, since trees sort as the index).
In contrast, it you have two files "proj/file" and "proj.c", the "proj.c"
will sort alphabetically before "proj/file" in the index. The index
itself, of course, does not actually contain an entry "proj/", but in the
*tree* that gets written out, the tree entry "proj" will sort after the
file entry "proj.c", which is the only real magic sorting rule.
In other words: the magic sorting rule only affects tree entries, and
*only* affects tree entries that point to other trees (ie are of the type
S_IFDIR).
Anyway, that thinko just means that we should remove the special case to
make S_ISDIRLNK entries sort like S_ISDIR entries. They don't. They sort
like normal files.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
18 years ago
|
|
|
if (!c2 && S_ISDIR(mode2))
|
|
|
|
|
c2 = '/';
|
|
|
|
|
return (c1 < c2) ? -1 : (c1 > c2) ? 1 : 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* df_name_compare() is identical to base_name_compare(), except it
|
|
|
|
|
* compares conflicting directory/file entries as equal. Note that
|
|
|
|
|
* while a directory name compares as equal to a regular file, they
|
|
|
|
|
* then individually compare _differently_ to a filename that has
|
|
|
|
|
* a dot after the basename (because '\0' < '.' < '/').
|
|
|
|
|
*
|
|
|
|
|
* This is used by routines that want to traverse the git namespace
|
|
|
|
|
* but then handle conflicting entries together when possible.
|
|
|
|
|
*/
|
|
|
|
|
int df_name_compare(const char *name1, int len1, int mode1,
|
|
|
|
|
const char *name2, int len2, int mode2)
|
|
|
|
|
{
|
|
|
|
|
int len = len1 < len2 ? len1 : len2, cmp;
|
|
|
|
|
unsigned char c1, c2;
|
|
|
|
|
|
|
|
|
|
cmp = memcmp(name1, name2, len);
|
|
|
|
|
if (cmp)
|
|
|
|
|
return cmp;
|
|
|
|
|
/* Directories and files compare equal (same length, same name) */
|
|
|
|
|
if (len1 == len2)
|
|
|
|
|
return 0;
|
|
|
|
|
c1 = name1[len];
|
|
|
|
|
if (!c1 && S_ISDIR(mode1))
|
|
|
|
|
c1 = '/';
|
|
|
|
|
c2 = name2[len];
|
|
|
|
|
if (!c2 && S_ISDIR(mode2))
|
|
|
|
|
c2 = '/';
|
|
|
|
|
if (c1 == '/' && !c2)
|
|
|
|
|
return 0;
|
|
|
|
|
if (c2 == '/' && !c1)
|
|
|
|
|
return 0;
|
|
|
|
|
return c1 - c2;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
int cache_name_compare(const char *name1, int flags1, const char *name2, int flags2)
|
|
|
|
|
{
|
|
|
|
|
int len1 = flags1 & CE_NAMEMASK;
|
|
|
|
|
int len2 = flags2 & CE_NAMEMASK;
|
|
|
|
|
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;
|
|
|
|
|
|
|
|
|
|
/* Compare stages */
|
|
|
|
|
flags1 &= CE_STAGEMASK;
|
|
|
|
|
flags2 &= CE_STAGEMASK;
|
|
|
|
|
|
|
|
|
|
if (flags1 < flags2)
|
|
|
|
|
return -1;
|
|
|
|
|
if (flags1 > flags2)
|
|
|
|
|
return 1;
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
int index_name_pos(const struct index_state *istate, const char *name, int namelen)
|
|
|
|
|
{
|
|
|
|
|
int first, last;
|
|
|
|
|
|
|
|
|
|
first = 0;
|
|
|
|
|
last = istate->cache_nr;
|
|
|
|
|
while (last > first) {
|
|
|
|
|
int next = (last + first) >> 1;
|
|
|
|
|
struct cache_entry *ce = istate->cache[next];
|
|
|
|
|
int cmp = cache_name_compare(name, namelen, ce->name, ce->ce_flags);
|
|
|
|
|
if (!cmp)
|
|
|
|
|
return next;
|
|
|
|
|
if (cmp < 0) {
|
|
|
|
|
last = next;
|
|
|
|
|
continue;
|
|
|
|
|
}
|
|
|
|
|
first = next+1;
|
|
|
|
|
}
|
|
|
|
|
return -first-1;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Remove entry, return true if there are more entries to go.. */
|
|
|
|
|
int remove_index_entry_at(struct index_state *istate, int pos)
|
|
|
|
|
{
|
Create pathname-based hash-table lookup into index
This creates a hash index of every single file added to the index.
Right now that hash index isn't actually used for much: I implemented a
"cache_name_exists()" function that uses it to efficiently look up a
filename in the index without having to do the O(logn) binary search,
but quite frankly, that's not why this patch is interesting.
No, the whole and only reason to create the hash of the filenames in the
index is that by modifying the hash function, you can fairly easily do
things like making it always hash equivalent names into the same bucket.
That, in turn, means that suddenly questions like "does this name exist
in the index under an _equivalent_ name?" becomes much much cheaper.
Guiding principles behind this patch:
- it shouldn't be too costly. In fact, my primary goal here was to
actually speed up "git commit" with a fully populated kernel tree, by
being faster at checking whether a file already existed in the index. I
did succeed, but only barely:
Best before:
[torvalds@woody linux]$ time git commit > /dev/null
real 0m0.255s
user 0m0.168s
sys 0m0.088s
Best after:
[torvalds@woody linux]$ time ~/git/git commit > /dev/null
real 0m0.233s
user 0m0.144s
sys 0m0.088s
so some things are actually faster (~8%).
Caveat: that's really the best case. Other things are invariably going
to be slightly slower, since we populate that index cache, and quite
frankly, few things really use it to look things up.
That said, the cost is really quite small. The worst case is probably
doing a "git ls-files", which will do very little except puopulate the
index, and never actually looks anything up in it, just lists it.
Before:
[torvalds@woody linux]$ time git ls-files > /dev/null
real 0m0.016s
user 0m0.016s
sys 0m0.000s
After:
[torvalds@woody linux]$ time ~/git/git ls-files > /dev/null
real 0m0.021s
user 0m0.012s
sys 0m0.008s
and while the thing has really gotten relatively much slower, we're
still talking about something almost unmeasurable (eg 5ms). And that
really should be pretty much the worst case.
So we lose 5ms on one "benchmark", but win 22ms on another. Pick your
poison - this patch has the advantage that it will _likely_ speed up
the cases that are complex and expensive more than it slows down the
cases that are already so fast that nobody cares. But if you look at
relative speedups/slowdowns, it doesn't look so good.
- It should be simple and clean
The code may be a bit subtle (the reasons I do hash removal the way I
do etc), but it re-uses the existing hash.c files, so it really is
fairly small and straightforward apart from a few odd details.
Now, this patch on its own doesn't really do much, but I think it's worth
looking at, if only because if done correctly, the name hashing really can
make an improvement to the whole issue of "do we have a filename that
looks like this in the index already". And at least it gets real testing
by being used even by default (ie there is a real use-case for it even
without any insane filesystems).
NOTE NOTE NOTE! The current hash is a joke. I'm ashamed of it, I'm just
not ashamed of it enough to really care. I took all the numbers out of my
nether regions - I'm sure it's good enough that it works in practice, but
the whole point was that you can make a really much fancier hash that
hashes characters not directly, but by their upper-case value or something
like that, and thus you get a case-insensitive hash, while still keeping
the name and the index itself totally case sensitive.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
17 years ago
|
|
|
struct cache_entry *ce = istate->cache[pos];
|
|
|
|
|
|
|
|
|
|
remove_name_hash(ce);
|
|
|
|
|
istate->cache_changed = 1;
|
|
|
|
|
istate->cache_nr--;
|
|
|
|
|
if (pos >= istate->cache_nr)
|
|
|
|
|
return 0;
|
|
|
|
|
memmove(istate->cache + pos,
|
|
|
|
|
istate->cache + pos + 1,
|
|
|
|
|
(istate->cache_nr - pos) * sizeof(struct cache_entry *));
|
|
|
|
|
return 1;
|
|
|
|
|
}
|
|
|
|
|
|
check_updates(): effective removal of cache entries marked CE_REMOVE
Below is oprofile output from GIT command 'git chekcout -q my-v2.6.25'
(move from tag v2.6.27 to tag v2.6.25 of the Linux kernel):
CPU: Core 2, speed 1999.95 MHz (estimated)
Counted CPU_CLK_UNHALTED events (Clock cycles when not halted) with a unit
mask of 0x00 (Unhalted core cycles) count 20000
Counted INST_RETIRED_ANY_P events (number of instructions retired) with a
unit mask of 0x00 (No unit mask) count 20000
CPU_CLK_UNHALT...|INST_RETIRED:2...|
samples| %| samples| %|
------------------------------------
409247 100.000 342878 100.000 git
CPU_CLK_UNHALT...|INST_RETIRED:2...|
samples| %| samples| %|
------------------------------------
260476 63.6476 257843 75.1996 libz.so.1.2.3
100876 24.6492 64378 18.7758 kernel-2.6.28.4_2.vmlinux
30850 7.5382 7874 2.2964 libc-2.9.so
14775 3.6103 8390 2.4469 git
2020 0.4936 4325 1.2614 libcrypto.so.0.9.8
191 0.0467 32 0.0093 libpthread-2.9.so
58 0.0142 36 0.0105 ld-2.9.so
1 2.4e-04 0 0 libldap-2.3.so.0.2.31
Detail list of the top 20 function entries (libz counted in one blob):
CPU_CLK_UNHALTED INST_RETIRED_ANY_P
samples % samples % image name symbol name
260476 63.6862 257843 75.2725 libz.so.1.2.3 /lib/libz.so.1.2.3
16587 4.0555 3636 1.0615 libc-2.9.so memcpy
7710 1.8851 277 0.0809 libc-2.9.so memmove
3679 0.8995 1108 0.3235 kernel-2.6.28.4_2.vmlinux d_validate
3546 0.8670 2607 0.7611 kernel-2.6.28.4_2.vmlinux __getblk
3174 0.7760 1813 0.5293 libc-2.9.so _int_malloc
2396 0.5858 3681 1.0746 kernel-2.6.28.4_2.vmlinux copy_to_user
2270 0.5550 2528 0.7380 kernel-2.6.28.4_2.vmlinux __link_path_walk
2205 0.5391 1797 0.5246 kernel-2.6.28.4_2.vmlinux ext4_mark_iloc_dirty
2103 0.5142 1203 0.3512 kernel-2.6.28.4_2.vmlinux find_first_zero_bit
2077 0.5078 997 0.2911 kernel-2.6.28.4_2.vmlinux do_get_write_access
2070 0.5061 514 0.1501 git cache_name_compare
2043 0.4995 1501 0.4382 kernel-2.6.28.4_2.vmlinux rcu_irq_exit
2022 0.4944 1732 0.5056 kernel-2.6.28.4_2.vmlinux __ext4_get_inode_loc
2020 0.4939 4325 1.2626 libcrypto.so.0.9.8 /usr/lib/libcrypto.so.0.9.8
1965 0.4804 1384 0.4040 git patch_delta
1708 0.4176 984 0.2873 kernel-2.6.28.4_2.vmlinux rcu_sched_grace_period
1682 0.4112 727 0.2122 kernel-2.6.28.4_2.vmlinux sysfs_slab_alias
1659 0.4056 290 0.0847 git find_pack_entry_one
1480 0.3619 1307 0.3816 kernel-2.6.28.4_2.vmlinux ext4_writepage_trans_blocks
Notice the memmove line, where the CPU did 7710 / 277 = 27.8 cycles
per instruction, and compared to the total cycles spent inside the
source code of GIT for this command, all the memmove() calls
translates to (7710 * 100) / 14775 = 52.2% of this.
Retesting with a GIT program compiled for gcov usage, I found out that
the memmove() calls came from remove_index_entry_at() in read-cache.c,
where we have:
memmove(istate->cache + pos,
istate->cache + pos + 1,
(istate->cache_nr - pos) * sizeof(struct cache_entry *));
remove_index_entry_at() is called 4902 times from check_updates() in
unpack-trees.c, and each time called we move each cache_entry pointers
(from the removed one) one step to the left.
Since we have 28828 entries in the cache this time, and if we on
average move half of them each time, we in total move approximately
4902 * 0.5 * 28828 * 4 = 282 629 712 bytes, or twice this amount if
each pointer is 8 bytes (64 bit).
OK, is seems that the function check_updates() is called 28 times, so
the estimated guess above had been more correct if check_updates() had
been called only once, but the point is: we get lots of bytes moved.
To fix this, and use an O(N) algorithm instead, where N is the number
of cache_entries, we delete/remove all entries in one loop through all
entries.
From a retest, the new remove_marked_cache_entries() from the patch
below, ended up with the following output line from oprofile:
46 0.0105 15 0.0041 git remove_marked_cache_entries
If we can trust the numbers from oprofile in this case, we saved
approximately ((7710 - 46) * 20000) / (2 * 1000 * 1000 * 1000) = 0.077
seconds CPU time with this fix for this particular test. And notice
that now the CPU did only 46 / 15 = 3.1 cycles/instruction.
Signed-off-by: Kjetil Barvik <barvik@broadpark.no>
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
16 years ago
|
|
|
/*
|
|
|
|
|
* Remove all cache ententries marked for removal, that is where
|
|
|
|
|
* CE_REMOVE is set in ce_flags. This is much more effective than
|
|
|
|
|
* calling remove_index_entry_at() for each entry to be removed.
|
|
|
|
|
*/
|
|
|
|
|
void remove_marked_cache_entries(struct index_state *istate)
|
|
|
|
|
{
|
|
|
|
|
struct cache_entry **ce_array = istate->cache;
|
|
|
|
|
unsigned int i, j;
|
|
|
|
|
|
|
|
|
|
for (i = j = 0; i < istate->cache_nr; i++) {
|
|
|
|
|
if (ce_array[i]->ce_flags & CE_REMOVE)
|
|
|
|
|
remove_name_hash(ce_array[i]);
|
|
|
|
|
else
|
|
|
|
|
ce_array[j++] = ce_array[i];
|
|
|
|
|
}
|
|
|
|
|
istate->cache_changed = 1;
|
|
|
|
|
istate->cache_nr = j;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
int remove_file_from_index(struct index_state *istate, const char *path)
|
|
|
|
|
{
|
|
|
|
|
int pos = index_name_pos(istate, path, strlen(path));
|
|
|
|
|
if (pos < 0)
|
|
|
|
|
pos = -pos-1;
|
|
|
|
|
cache_tree_invalidate_path(istate->cache_tree, path);
|
|
|
|
|
while (pos < istate->cache_nr && !strcmp(istate->cache[pos]->name, path))
|
|
|
|
|
remove_index_entry_at(istate, pos);
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int compare_name(struct cache_entry *ce, const char *path, int namelen)
|
|
|
|
|
{
|
|
|
|
|
return namelen != ce_namelen(ce) || memcmp(path, ce->name, namelen);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int index_name_pos_also_unmerged(struct index_state *istate,
|
|
|
|
|
const char *path, int namelen)
|
|
|
|
|
{
|
|
|
|
|
int pos = index_name_pos(istate, path, namelen);
|
|
|
|
|
struct cache_entry *ce;
|
|
|
|
|
|
|
|
|
|
if (pos >= 0)
|
|
|
|
|
return pos;
|
|
|
|
|
|
|
|
|
|
/* maybe unmerged? */
|
|
|
|
|
pos = -1 - pos;
|
|
|
|
|
if (pos >= istate->cache_nr ||
|
|
|
|
|
compare_name((ce = istate->cache[pos]), path, namelen))
|
|
|
|
|
return -1;
|
|
|
|
|
|
|
|
|
|
/* order of preference: stage 2, 1, 3 */
|
|
|
|
|
if (ce_stage(ce) == 1 && pos + 1 < istate->cache_nr &&
|
|
|
|
|
ce_stage((ce = istate->cache[pos + 1])) == 2 &&
|
|
|
|
|
!compare_name(ce, path, namelen))
|
|
|
|
|
pos++;
|
|
|
|
|
return pos;
|
|
|
|
|
}
|
|
|
|
|
|
Make git-add behave more sensibly in a case-insensitive environment
This expands on the previous patch, and allows "git add" to sanely handle
a filename that has changed case, keeping the case in the index constant,
and avoiding aliases.
In particular, if you have an index entry called "File", but the
checked-out tree is case-corrupted and has an entry called "file"
instead, doing a
git add .
(or naming "file" explicitly) will automatically notice that we have an
alias, and will replace the name "file" with the existing index
capitalization (ie "File").
However, if we actually have *both* a file called "File" and one called
"file", and they don't have the same lstat() information (ie we're on a
case-sensitive filesystem but have the "core.ignorecase" flag set), we
will error out if we try to add them both.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
17 years ago
|
|
|
static int different_name(struct cache_entry *ce, struct cache_entry *alias)
|
|
|
|
|
{
|
|
|
|
|
int len = ce_namelen(ce);
|
|
|
|
|
return ce_namelen(alias) != len || memcmp(ce->name, alias->name, len);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* If we add a filename that aliases in the cache, we will use the
|
|
|
|
|
* name that we already have - but we don't want to update the same
|
|
|
|
|
* alias twice, because that implies that there were actually two
|
|
|
|
|
* different files with aliasing names!
|
|
|
|
|
*
|
|
|
|
|
* So we use the CE_ADDED flag to verify that the alias was an old
|
|
|
|
|
* one before we accept it as
|
|
|
|
|
*/
|
|
|
|
|
static struct cache_entry *create_alias_ce(struct cache_entry *ce, struct cache_entry *alias)
|
|
|
|
|
{
|
|
|
|
|
int len;
|
|
|
|
|
struct cache_entry *new;
|
|
|
|
|
|
|
|
|
|
if (alias->ce_flags & CE_ADDED)
|
|
|
|
|
die("Will not add file alias '%s' ('%s' already exists in index)", ce->name, alias->name);
|
|
|
|
|
|
|
|
|
|
/* Ok, create the new entry using the name of the existing alias */
|
|
|
|
|
len = ce_namelen(alias);
|
|
|
|
|
new = xcalloc(1, cache_entry_size(len));
|
|
|
|
|
memcpy(new->name, alias->name, len);
|
|
|
|
|
copy_cache_entry(new, ce);
|
|
|
|
|
free(ce);
|
|
|
|
|
return new;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void record_intent_to_add(struct cache_entry *ce)
|
|
|
|
|
{
|
|
|
|
|
unsigned char sha1[20];
|
|
|
|
|
if (write_sha1_file("", 0, blob_type, sha1))
|
|
|
|
|
die("cannot create an empty blob in the object database");
|
|
|
|
|
hashcpy(ce->sha1, sha1);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
int add_to_index(struct index_state *istate, const char *path, struct stat *st, int flags)
|
|
|
|
|
{
|
|
|
|
|
int size, namelen, was_same;
|
|
|
|
|
mode_t st_mode = st->st_mode;
|
|
|
|
|
struct cache_entry *ce, *alias;
|
git-add: make the entry stat-clean after re-adding the same contents
Earlier in commit 0781b8a9b2fe760fc4ed519a3a26e4b9bd6ccffe
(add_file_to_index: skip rehashing if the cached stat already
matches), add_file_to_index() were taught not to re-add the path
if it already matches the index.
The change meant well, but was not executed quite right. It
used ie_modified() to see if the file on the work tree is really
different from the index, and skipped adding the contents if the
function says "not modified".
This was wrong. There are three possible comparison results
between the index and the file in the work tree:
- with lstat(2) we _know_ they are different. E.g. if the
length or the owner in the cached stat information is
different from the length we just obtained from lstat(2), we
can tell the file is modified without looking at the actual
contents.
- with lstat(2) we _know_ they are the same. The same length,
the same owner, the same everything (but this has a twist, as
described below).
- we cannot tell from lstat(2) information alone and need to go
to the filesystem to actually compare.
The last case arises from what we call 'racy git' situation,
that can be caused with this sequence:
$ echo hello >file
$ git add file
$ echo aeiou >file ;# the same length
If the second "echo" is done within the same filesystem
timestamp granularity as the first "echo", then the timestamp
recorded by "git add" and the timestamp we get from lstat(2)
will be the same, and we can mistakenly say the file is not
modified. The path is called 'racily clean'. We need to
reliably detect racily clean paths are in fact modified.
To solve this problem, when we write out the index, we mark the
index entry that has the same timestamp as the index file itself
(that is the time from the point of view of the filesystem) to
tell any later code that does the lstat(2) comparison not to
trust the cached stat info, and ie_modified() then actually goes
to the filesystem to compare the contents for such a path.
That's all good, but it should not be used for this "git add"
optimization, as the goal of "git add" is to actually update the
path in the index and make it stat-clean. With the false
optimization, we did _not_ cause any data loss (after all, what
we failed to do was only to update the cached stat information),
but it made the following sequence leave the file stat dirty:
$ echo hello >file
$ git add file
$ echo hello >file ;# the same contents
$ git add file
The solution is not to use ie_modified() which goes to the
filesystem to see if it is really clean, but instead use
ie_match_stat() with "assume racily clean paths are dirty"
option, to force re-adding of such a path.
There was another problem with "git add -u". The codepath
shares the same issue when adding the paths that are found to be
modified, but in addition, it asked "git diff-files" machinery
run_diff_files() function (which is "git diff-files") to list
the paths that are modified. But "git diff-files" machinery
uses the same ie_modified() call so that it does not report
racily clean _and_ actually clean paths as modified, which is
not what we want.
The patch allows the callers of run_diff_files() to pass the
same "assume racily clean paths are dirty" option, and makes
"git-add -u" codepath to use that option, to discover and re-add
racily clean _and_ actually clean paths.
We could further optimize on top of this patch to differentiate
the case where the path really needs re-adding (i.e. the content
of the racily clean entry was indeed different) and the case
where only the cached stat information needs to be refreshed
(i.e. the racily clean entry was actually clean), but I do not
think it is worth it.
This patch applies to maint and all the way up.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
17 years ago
|
|
|
unsigned ce_option = CE_MATCH_IGNORE_VALID|CE_MATCH_RACY_IS_DIRTY;
|
|
|
|
|
int verbose = flags & (ADD_CACHE_VERBOSE | ADD_CACHE_PRETEND);
|
|
|
|
|
int pretend = flags & ADD_CACHE_PRETEND;
|
|
|
|
|
int intent_only = flags & ADD_CACHE_INTENT;
|
|
|
|
|
int add_option = (ADD_CACHE_OK_TO_ADD|ADD_CACHE_OK_TO_REPLACE|
|
|
|
|
|
(intent_only ? ADD_CACHE_NEW_ONLY : 0));
|
|
|
|
|
|
|
|
|
|
if (!S_ISREG(st_mode) && !S_ISLNK(st_mode) && !S_ISDIR(st_mode))
|
|
|
|
|
return error("%s: can only add regular files, symbolic links or git-directories", path);
|
|
|
|
|
|
|
|
|
|
namelen = strlen(path);
|
|
|
|
|
if (S_ISDIR(st_mode)) {
|
|
|
|
|
while (namelen && path[namelen-1] == '/')
|
|
|
|
|
namelen--;
|
|
|
|
|
}
|
|
|
|
|
size = cache_entry_size(namelen);
|
|
|
|
|
ce = xcalloc(1, size);
|
|
|
|
|
memcpy(ce->name, path, namelen);
|
|
|
|
|
ce->ce_flags = namelen;
|
|
|
|
|
if (!intent_only)
|
|
|
|
|
fill_stat_cache_info(ce, st);
|
|
|
|
|
else
|
|
|
|
|
ce->ce_flags |= CE_INTENT_TO_ADD;
|
|
|
|
|
|
|
|
|
|
if (trust_executable_bit && has_symlinks)
|
|
|
|
|
ce->ce_mode = create_ce_mode(st_mode);
|
|
|
|
|
else {
|
|
|
|
|
/* If there is an existing entry, pick the mode bits and type
|
|
|
|
|
* from it, otherwise assume unexecutable regular file.
|
|
|
|
|
*/
|
|
|
|
|
struct cache_entry *ent;
|
|
|
|
|
int pos = index_name_pos_also_unmerged(istate, path, namelen);
|
|
|
|
|
|
|
|
|
|
ent = (0 <= pos) ? istate->cache[pos] : NULL;
|
|
|
|
|
ce->ce_mode = ce_mode_from_stat(ent, st_mode);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
alias = index_name_exists(istate, ce->name, ce_namelen(ce), ignore_case);
|
|
|
|
|
if (alias && !ce_stage(alias) && !ie_match_stat(istate, alias, st, ce_option)) {
|
|
|
|
|
/* Nothing changed, really */
|
|
|
|
|
free(ce);
|
|
|
|
|
ce_mark_uptodate(alias);
|
Make git-add behave more sensibly in a case-insensitive environment
This expands on the previous patch, and allows "git add" to sanely handle
a filename that has changed case, keeping the case in the index constant,
and avoiding aliases.
In particular, if you have an index entry called "File", but the
checked-out tree is case-corrupted and has an entry called "file"
instead, doing a
git add .
(or naming "file" explicitly) will automatically notice that we have an
alias, and will replace the name "file" with the existing index
capitalization (ie "File").
However, if we actually have *both* a file called "File" and one called
"file", and they don't have the same lstat() information (ie we're on a
case-sensitive filesystem but have the "core.ignorecase" flag set), we
will error out if we try to add them both.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
17 years ago
|
|
|
alias->ce_flags |= CE_ADDED;
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
if (!intent_only) {
|
|
|
|
|
if (index_path(ce->sha1, path, st, 1))
|
|
|
|
|
return error("unable to index file %s", path);
|
|
|
|
|
} else
|
|
|
|
|
record_intent_to_add(ce);
|
|
|
|
|
|
Make git-add behave more sensibly in a case-insensitive environment
This expands on the previous patch, and allows "git add" to sanely handle
a filename that has changed case, keeping the case in the index constant,
and avoiding aliases.
In particular, if you have an index entry called "File", but the
checked-out tree is case-corrupted and has an entry called "file"
instead, doing a
git add .
(or naming "file" explicitly) will automatically notice that we have an
alias, and will replace the name "file" with the existing index
capitalization (ie "File").
However, if we actually have *both* a file called "File" and one called
"file", and they don't have the same lstat() information (ie we're on a
case-sensitive filesystem but have the "core.ignorecase" flag set), we
will error out if we try to add them both.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
17 years ago
|
|
|
if (ignore_case && alias && different_name(ce, alias))
|
|
|
|
|
ce = create_alias_ce(ce, alias);
|
|
|
|
|
ce->ce_flags |= CE_ADDED;
|
|
|
|
|
|
|
|
|
|
/* It was suspected to be racily clean, but it turns out to be Ok */
|
|
|
|
|
was_same = (alias &&
|
|
|
|
|
!ce_stage(alias) &&
|
|
|
|
|
!hashcmp(alias->sha1, ce->sha1) &&
|
|
|
|
|
ce->ce_mode == alias->ce_mode);
|
|
|
|
|
|
|
|
|
|
if (pretend)
|
|
|
|
|
;
|
|
|
|
|
else if (add_index_entry(istate, ce, add_option))
|
|
|
|
|
return error("unable to add %s to index",path);
|
|
|
|
|
if (verbose && !was_same)
|
|
|
|
|
printf("add '%s'\n", path);
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
int add_file_to_index(struct index_state *istate, const char *path, int flags)
|
|
|
|
|
{
|
|
|
|
|
struct stat st;
|
|
|
|
|
if (lstat(path, &st))
|
|
|
|
|
die("%s: unable to stat (%s)", path, strerror(errno));
|
|
|
|
|
return add_to_index(istate, path, &st, flags);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
struct cache_entry *make_cache_entry(unsigned int mode,
|
|
|
|
|
const unsigned char *sha1, const char *path, int stage,
|
|
|
|
|
int refresh)
|
|
|
|
|
{
|
|
|
|
|
int size, len;
|
|
|
|
|
struct cache_entry *ce;
|
|
|
|
|
|
|
|
|
|
if (!verify_path(path)) {
|
|
|
|
|
error("Invalid path '%s'", path);
|
|
|
|
|
return NULL;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
len = strlen(path);
|
|
|
|
|
size = cache_entry_size(len);
|
|
|
|
|
ce = xcalloc(1, size);
|
|
|
|
|
|
|
|
|
|
hashcpy(ce->sha1, sha1);
|
|
|
|
|
memcpy(ce->name, path, len);
|
|
|
|
|
ce->ce_flags = create_ce_flags(len, stage);
|
|
|
|
|
ce->ce_mode = create_ce_mode(mode);
|
|
|
|
|
|
|
|
|
|
if (refresh)
|
|
|
|
|
return refresh_cache_entry(ce, 0);
|
|
|
|
|
|
|
|
|
|
return ce;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
int ce_same_name(struct cache_entry *a, struct cache_entry *b)
|
|
|
|
|
{
|
|
|
|
|
int len = ce_namelen(a);
|
|
|
|
|
return ce_namelen(b) == len && !memcmp(a->name, b->name, len);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
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;
|
|
|
|
|
if (!matchlen)
|
|
|
|
|
return 1;
|
|
|
|
|
}
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* 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++;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Do we have another file that has the beginning components being a
|
|
|
|
|
* proper superset of the name we're trying to add?
|
|
|
|
|
*/
|
|
|
|
|
static int has_file_name(struct index_state *istate,
|
|
|
|
|
const struct cache_entry *ce, int pos, int ok_to_replace)
|
|
|
|
|
{
|
|
|
|
|
int retval = 0;
|
|
|
|
|
int len = ce_namelen(ce);
|
|
|
|
|
int stage = ce_stage(ce);
|
|
|
|
|
const char *name = ce->name;
|
|
|
|
|
|
|
|
|
|
while (pos < istate->cache_nr) {
|
|
|
|
|
struct cache_entry *p = istate->cache[pos++];
|
|
|
|
|
|
|
|
|
|
if (len >= ce_namelen(p))
|
|
|
|
|
break;
|
|
|
|
|
if (memcmp(name, p->name, len))
|
|
|
|
|
break;
|
|
|
|
|
if (ce_stage(p) != stage)
|
|
|
|
|
continue;
|
|
|
|
|
if (p->name[len] != '/')
|
|
|
|
|
continue;
|
|
|
|
|
if (p->ce_flags & CE_REMOVE)
|
|
|
|
|
continue;
|
|
|
|
|
retval = -1;
|
|
|
|
|
if (!ok_to_replace)
|
|
|
|
|
break;
|
|
|
|
|
remove_index_entry_at(istate, --pos);
|
|
|
|
|
}
|
|
|
|
|
return retval;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* 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(struct index_state *istate,
|
|
|
|
|
const struct cache_entry *ce, int pos, int ok_to_replace)
|
|
|
|
|
{
|
|
|
|
|
int retval = 0;
|
|
|
|
|
int stage = ce_stage(ce);
|
|
|
|
|
const char *name = ce->name;
|
|
|
|
|
const char *slash = name + ce_namelen(ce);
|
|
|
|
|
|
|
|
|
|
for (;;) {
|
|
|
|
|
int len;
|
|
|
|
|
|
|
|
|
|
for (;;) {
|
|
|
|
|
if (*--slash == '/')
|
|
|
|
|
break;
|
|
|
|
|
if (slash <= ce->name)
|
|
|
|
|
return retval;
|
|
|
|
|
}
|
|
|
|
|
len = slash - name;
|
|
|
|
|
|
|
|
|
|
pos = index_name_pos(istate, name, create_ce_flags(len, stage));
|
|
|
|
|
if (pos >= 0) {
|
|
|
|
|
/*
|
|
|
|
|
* 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 (!(istate->cache[pos]->ce_flags & CE_REMOVE)) {
|
|
|
|
|
retval = -1;
|
|
|
|
|
if (!ok_to_replace)
|
|
|
|
|
break;
|
|
|
|
|
remove_index_entry_at(istate, pos);
|
|
|
|
|
continue;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
else
|
|
|
|
|
pos = -pos-1;
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Trivial optimization: if we find an entry that
|
|
|
|
|
* already matches the sub-directory, then we know
|
|
|
|
|
* we're ok, and we can exit.
|
|
|
|
|
*/
|
|
|
|
|
while (pos < istate->cache_nr) {
|
|
|
|
|
struct cache_entry *p = istate->cache[pos];
|
|
|
|
|
if ((ce_namelen(p) <= len) ||
|
|
|
|
|
(p->name[len] != '/') ||
|
|
|
|
|
memcmp(p->name, name, len))
|
|
|
|
|
break; /* not our subdirectory */
|
|
|
|
|
if (ce_stage(p) == stage && !(p->ce_flags & CE_REMOVE))
|
|
|
|
|
/*
|
|
|
|
|
* 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++;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
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(struct index_state *istate,
|
|
|
|
|
const struct cache_entry *ce,
|
|
|
|
|
int pos, int ok_to_replace)
|
|
|
|
|
{
|
|
|
|
|
int retval;
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* When ce is an "I am going away" entry, we allow it to be added
|
|
|
|
|
*/
|
|
|
|
|
if (ce->ce_flags & CE_REMOVE)
|
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* We check if the path is a sub-path of a subsequent pathname
|
|
|
|
|
* first, since removing those will not change the position
|
|
|
|
|
* in the array.
|
|
|
|
|
*/
|
|
|
|
|
retval = has_file_name(istate, ce, pos, ok_to_replace);
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Then check if the path might have a clashing sub-directory
|
|
|
|
|
* before it.
|
|
|
|
|
*/
|
|
|
|
|
return retval + has_dir_name(istate, ce, pos, ok_to_replace);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int add_index_entry_with_check(struct index_state *istate, struct cache_entry *ce, int option)
|
|
|
|
|
{
|
|
|
|
|
int pos;
|
|
|
|
|
int ok_to_add = option & ADD_CACHE_OK_TO_ADD;
|
|
|
|
|
int ok_to_replace = option & ADD_CACHE_OK_TO_REPLACE;
|
|
|
|
|
int skip_df_check = option & ADD_CACHE_SKIP_DFCHECK;
|
|
|
|
|
int new_only = option & ADD_CACHE_NEW_ONLY;
|
|
|
|
|
|
|
|
|
|
cache_tree_invalidate_path(istate->cache_tree, ce->name);
|
|
|
|
|
pos = index_name_pos(istate, ce->name, ce->ce_flags);
|
|
|
|
|
|
|
|
|
|
/* existing match? Just replace it. */
|
|
|
|
|
if (pos >= 0) {
|
|
|
|
|
if (!new_only)
|
|
|
|
|
replace_index_entry(istate, pos, ce);
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
pos = -pos-1;
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Inserting a merged entry ("stage 0") into the index
|
|
|
|
|
* will always replace all non-merged entries..
|
|
|
|
|
*/
|
|
|
|
|
if (pos < istate->cache_nr && ce_stage(ce) == 0) {
|
|
|
|
|
while (ce_same_name(istate->cache[pos], ce)) {
|
|
|
|
|
ok_to_add = 1;
|
|
|
|
|
if (!remove_index_entry_at(istate, pos))
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (!ok_to_add)
|
|
|
|
|
return -1;
|
|
|
|
|
if (!verify_path(ce->name))
|
|
|
|
|
return error("Invalid path '%s'", ce->name);
|
|
|
|
|
|
|
|
|
|
if (!skip_df_check &&
|
|
|
|
|
check_file_directory_conflict(istate, ce, pos, ok_to_replace)) {
|
|
|
|
|
if (!ok_to_replace)
|
|
|
|
|
return error("'%s' appears as both a file and as a directory",
|
|
|
|
|
ce->name);
|
|
|
|
|
pos = index_name_pos(istate, ce->name, ce->ce_flags);
|
|
|
|
|
pos = -pos-1;
|
|
|
|
|
}
|
|
|
|
|
return pos + 1;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
int add_index_entry(struct index_state *istate, struct cache_entry *ce, int option)
|
|
|
|
|
{
|
|
|
|
|
int pos;
|
|
|
|
|
|
|
|
|
|
if (option & ADD_CACHE_JUST_APPEND)
|
|
|
|
|
pos = istate->cache_nr;
|
|
|
|
|
else {
|
|
|
|
|
int ret;
|
|
|
|
|
ret = add_index_entry_with_check(istate, ce, option);
|
|
|
|
|
if (ret <= 0)
|
|
|
|
|
return ret;
|
|
|
|
|
pos = ret - 1;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Make sure the array is big enough .. */
|
|
|
|
|
if (istate->cache_nr == istate->cache_alloc) {
|
|
|
|
|
istate->cache_alloc = alloc_nr(istate->cache_alloc);
|
|
|
|
|
istate->cache = xrealloc(istate->cache,
|
|
|
|
|
istate->cache_alloc * sizeof(struct cache_entry *));
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Add it in.. */
|
|
|
|
|
istate->cache_nr++;
|
|
|
|
|
if (istate->cache_nr > pos + 1)
|
|
|
|
|
memmove(istate->cache + pos + 1,
|
|
|
|
|
istate->cache + pos,
|
|
|
|
|
(istate->cache_nr - pos - 1) * sizeof(ce));
|
Create pathname-based hash-table lookup into index
This creates a hash index of every single file added to the index.
Right now that hash index isn't actually used for much: I implemented a
"cache_name_exists()" function that uses it to efficiently look up a
filename in the index without having to do the O(logn) binary search,
but quite frankly, that's not why this patch is interesting.
No, the whole and only reason to create the hash of the filenames in the
index is that by modifying the hash function, you can fairly easily do
things like making it always hash equivalent names into the same bucket.
That, in turn, means that suddenly questions like "does this name exist
in the index under an _equivalent_ name?" becomes much much cheaper.
Guiding principles behind this patch:
- it shouldn't be too costly. In fact, my primary goal here was to
actually speed up "git commit" with a fully populated kernel tree, by
being faster at checking whether a file already existed in the index. I
did succeed, but only barely:
Best before:
[torvalds@woody linux]$ time git commit > /dev/null
real 0m0.255s
user 0m0.168s
sys 0m0.088s
Best after:
[torvalds@woody linux]$ time ~/git/git commit > /dev/null
real 0m0.233s
user 0m0.144s
sys 0m0.088s
so some things are actually faster (~8%).
Caveat: that's really the best case. Other things are invariably going
to be slightly slower, since we populate that index cache, and quite
frankly, few things really use it to look things up.
That said, the cost is really quite small. The worst case is probably
doing a "git ls-files", which will do very little except puopulate the
index, and never actually looks anything up in it, just lists it.
Before:
[torvalds@woody linux]$ time git ls-files > /dev/null
real 0m0.016s
user 0m0.016s
sys 0m0.000s
After:
[torvalds@woody linux]$ time ~/git/git ls-files > /dev/null
real 0m0.021s
user 0m0.012s
sys 0m0.008s
and while the thing has really gotten relatively much slower, we're
still talking about something almost unmeasurable (eg 5ms). And that
really should be pretty much the worst case.
So we lose 5ms on one "benchmark", but win 22ms on another. Pick your
poison - this patch has the advantage that it will _likely_ speed up
the cases that are complex and expensive more than it slows down the
cases that are already so fast that nobody cares. But if you look at
relative speedups/slowdowns, it doesn't look so good.
- It should be simple and clean
The code may be a bit subtle (the reasons I do hash removal the way I
do etc), but it re-uses the existing hash.c files, so it really is
fairly small and straightforward apart from a few odd details.
Now, this patch on its own doesn't really do much, but I think it's worth
looking at, if only because if done correctly, the name hashing really can
make an improvement to the whole issue of "do we have a filename that
looks like this in the index already". And at least it gets real testing
by being used even by default (ie there is a real use-case for it even
without any insane filesystems).
NOTE NOTE NOTE! The current hash is a joke. I'm ashamed of it, I'm just
not ashamed of it enough to really care. I took all the numbers out of my
nether regions - I'm sure it's good enough that it works in practice, but
the whole point was that you can make a really much fancier hash that
hashes characters not directly, but by their upper-case value or something
like that, and thus you get a case-insensitive hash, while still keeping
the name and the index itself totally case sensitive.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
17 years ago
|
|
|
set_index_entry(istate, pos, ce);
|
|
|
|
|
istate->cache_changed = 1;
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* "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.
|
|
|
|
|
*/
|
|
|
|
|
static struct cache_entry *refresh_cache_ent(struct index_state *istate,
|
|
|
|
|
struct cache_entry *ce,
|
|
|
|
|
unsigned int options, int *err)
|
|
|
|
|
{
|
|
|
|
|
struct stat st;
|
|
|
|
|
struct cache_entry *updated;
|
|
|
|
|
int changed, size;
|
|
|
|
|
int ignore_valid = options & CE_MATCH_IGNORE_VALID;
|
|
|
|
|
|
|
|
|
|
if (ce_uptodate(ce))
|
|
|
|
|
return ce;
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* CE_VALID means the user promised us that the change to
|
|
|
|
|
* the work tree does not matter and told us not to worry.
|
|
|
|
|
*/
|
|
|
|
|
if (!ignore_valid && (ce->ce_flags & CE_VALID)) {
|
|
|
|
|
ce_mark_uptodate(ce);
|
|
|
|
|
return ce;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (lstat(ce->name, &st) < 0) {
|
|
|
|
|
if (err)
|
|
|
|
|
*err = errno;
|
|
|
|
|
return NULL;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
changed = ie_match_stat(istate, ce, &st, options);
|
|
|
|
|
if (!changed) {
|
|
|
|
|
/*
|
|
|
|
|
* The path is unchanged. If we were told to ignore
|
|
|
|
|
* valid bit, then we did the actual stat check and
|
|
|
|
|
* found that the entry is unmodified. If the entry
|
|
|
|
|
* is not marked VALID, this is the place to mark it
|
|
|
|
|
* valid again, under "assume unchanged" mode.
|
|
|
|
|
*/
|
|
|
|
|
if (ignore_valid && assume_unchanged &&
|
|
|
|
|
!(ce->ce_flags & CE_VALID))
|
|
|
|
|
; /* mark this one VALID again */
|
|
|
|
|
else {
|
|
|
|
|
/*
|
|
|
|
|
* We do not mark the index itself "modified"
|
|
|
|
|
* because CE_UPTODATE flag is in-core only;
|
|
|
|
|
* we are not going to write this change out.
|
|
|
|
|
*/
|
|
|
|
|
ce_mark_uptodate(ce);
|
|
|
|
|
return ce;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (ie_modified(istate, ce, &st, options)) {
|
|
|
|
|
if (err)
|
|
|
|
|
*err = EINVAL;
|
|
|
|
|
return NULL;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
size = ce_size(ce);
|
|
|
|
|
updated = xmalloc(size);
|
|
|
|
|
memcpy(updated, ce, size);
|
|
|
|
|
fill_stat_cache_info(updated, &st);
|
|
|
|
|
/*
|
|
|
|
|
* If ignore_valid 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 (!ignore_valid && assume_unchanged &&
|
|
|
|
|
!(ce->ce_flags & CE_VALID))
|
|
|
|
|
updated->ce_flags &= ~CE_VALID;
|
|
|
|
|
|
|
|
|
|
return updated;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
int refresh_index(struct index_state *istate, unsigned int flags, const char **pathspec, char *seen)
|
|
|
|
|
{
|
|
|
|
|
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;
|
|
|
|
|
int ignore_submodules = (flags & REFRESH_IGNORE_SUBMODULES) != 0;
|
|
|
|
|
unsigned int options = really ? CE_MATCH_IGNORE_VALID : 0;
|
|
|
|
|
const char *needs_update_message;
|
|
|
|
|
|
|
|
|
|
needs_update_message = ((flags & REFRESH_SAY_CHANGED)
|
|
|
|
|
? "locally modified" : "needs update");
|
|
|
|
|
for (i = 0; i < istate->cache_nr; i++) {
|
|
|
|
|
struct cache_entry *ce, *new;
|
|
|
|
|
int cache_errno = 0;
|
|
|
|
|
|
|
|
|
|
ce = istate->cache[i];
|
|
|
|
|
if (ignore_submodules && S_ISGITLINK(ce->ce_mode))
|
|
|
|
|
continue;
|
|
|
|
|
|
|
|
|
|
if (ce_stage(ce)) {
|
|
|
|
|
while ((i < istate->cache_nr) &&
|
|
|
|
|
! strcmp(istate->cache[i]->name, ce->name))
|
|
|
|
|
i++;
|
|
|
|
|
i--;
|
|
|
|
|
if (allow_unmerged)
|
|
|
|
|
continue;
|
|
|
|
|
printf("%s: needs merge\n", ce->name);
|
|
|
|
|
has_errors = 1;
|
|
|
|
|
continue;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (pathspec && !match_pathspec(pathspec, ce->name, strlen(ce->name), 0, seen))
|
|
|
|
|
continue;
|
|
|
|
|
|
|
|
|
|
new = refresh_cache_ent(istate, ce, options, &cache_errno);
|
|
|
|
|
if (new == ce)
|
|
|
|
|
continue;
|
|
|
|
|
if (!new) {
|
|
|
|
|
if (not_new && cache_errno == ENOENT)
|
|
|
|
|
continue;
|
|
|
|
|
if (really && cache_errno == EINVAL) {
|
|
|
|
|
/* If we are doing --really-refresh that
|
|
|
|
|
* means the index is not valid anymore.
|
|
|
|
|
*/
|
|
|
|
|
ce->ce_flags &= ~CE_VALID;
|
|
|
|
|
istate->cache_changed = 1;
|
|
|
|
|
}
|
|
|
|
|
if (quiet)
|
|
|
|
|
continue;
|
|
|
|
|
printf("%s: %s\n", ce->name, needs_update_message);
|
|
|
|
|
has_errors = 1;
|
|
|
|
|
continue;
|
|
|
|
|
}
|
Create pathname-based hash-table lookup into index
This creates a hash index of every single file added to the index.
Right now that hash index isn't actually used for much: I implemented a
"cache_name_exists()" function that uses it to efficiently look up a
filename in the index without having to do the O(logn) binary search,
but quite frankly, that's not why this patch is interesting.
No, the whole and only reason to create the hash of the filenames in the
index is that by modifying the hash function, you can fairly easily do
things like making it always hash equivalent names into the same bucket.
That, in turn, means that suddenly questions like "does this name exist
in the index under an _equivalent_ name?" becomes much much cheaper.
Guiding principles behind this patch:
- it shouldn't be too costly. In fact, my primary goal here was to
actually speed up "git commit" with a fully populated kernel tree, by
being faster at checking whether a file already existed in the index. I
did succeed, but only barely:
Best before:
[torvalds@woody linux]$ time git commit > /dev/null
real 0m0.255s
user 0m0.168s
sys 0m0.088s
Best after:
[torvalds@woody linux]$ time ~/git/git commit > /dev/null
real 0m0.233s
user 0m0.144s
sys 0m0.088s
so some things are actually faster (~8%).
Caveat: that's really the best case. Other things are invariably going
to be slightly slower, since we populate that index cache, and quite
frankly, few things really use it to look things up.
That said, the cost is really quite small. The worst case is probably
doing a "git ls-files", which will do very little except puopulate the
index, and never actually looks anything up in it, just lists it.
Before:
[torvalds@woody linux]$ time git ls-files > /dev/null
real 0m0.016s
user 0m0.016s
sys 0m0.000s
After:
[torvalds@woody linux]$ time ~/git/git ls-files > /dev/null
real 0m0.021s
user 0m0.012s
sys 0m0.008s
and while the thing has really gotten relatively much slower, we're
still talking about something almost unmeasurable (eg 5ms). And that
really should be pretty much the worst case.
So we lose 5ms on one "benchmark", but win 22ms on another. Pick your
poison - this patch has the advantage that it will _likely_ speed up
the cases that are complex and expensive more than it slows down the
cases that are already so fast that nobody cares. But if you look at
relative speedups/slowdowns, it doesn't look so good.
- It should be simple and clean
The code may be a bit subtle (the reasons I do hash removal the way I
do etc), but it re-uses the existing hash.c files, so it really is
fairly small and straightforward apart from a few odd details.
Now, this patch on its own doesn't really do much, but I think it's worth
looking at, if only because if done correctly, the name hashing really can
make an improvement to the whole issue of "do we have a filename that
looks like this in the index already". And at least it gets real testing
by being used even by default (ie there is a real use-case for it even
without any insane filesystems).
NOTE NOTE NOTE! The current hash is a joke. I'm ashamed of it, I'm just
not ashamed of it enough to really care. I took all the numbers out of my
nether regions - I'm sure it's good enough that it works in practice, but
the whole point was that you can make a really much fancier hash that
hashes characters not directly, but by their upper-case value or something
like that, and thus you get a case-insensitive hash, while still keeping
the name and the index itself totally case sensitive.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
17 years ago
|
|
|
|
|
|
|
|
replace_index_entry(istate, i, new);
|
|
|
|
|
}
|
|
|
|
|
return has_errors;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
struct cache_entry *refresh_cache_entry(struct cache_entry *ce, int really)
|
|
|
|
|
{
|
|
|
|
|
return refresh_cache_ent(&the_index, ce, really, NULL);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int verify_hdr(struct cache_header *hdr, unsigned long size)
|
|
|
|
|
{
|
|
|
|
|
git_SHA_CTX c;
|
|
|
|
|
unsigned char sha1[20];
|
|
|
|
|
|
|
|
|
|
if (hdr->hdr_signature != htonl(CACHE_SIGNATURE))
|
|
|
|
|
return error("bad signature");
|
|
|
|
|
if (hdr->hdr_version != htonl(2) && hdr->hdr_version != htonl(3))
|
|
|
|
|
return error("bad index version");
|
|
|
|
|
git_SHA1_Init(&c);
|
|
|
|
|
git_SHA1_Update(&c, hdr, size - 20);
|
|
|
|
|
git_SHA1_Final(sha1, &c);
|
|
|
|
|
if (hashcmp(sha1, (unsigned char *)hdr + size - 20))
|
|
|
|
|
return error("bad index file sha1 signature");
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int read_index_extension(struct index_state *istate,
|
|
|
|
|
const char *ext, void *data, unsigned long sz)
|
|
|
|
|
{
|
|
|
|
|
switch (CACHE_EXT(ext)) {
|
|
|
|
|
case CACHE_EXT_TREE:
|
|
|
|
|
istate->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_index(struct index_state *istate)
|
|
|
|
|
{
|
|
|
|
|
return read_index_from(istate, get_index_file());
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void convert_from_disk(struct ondisk_cache_entry *ondisk, struct cache_entry *ce)
|
|
|
|
|
{
|
|
|
|
|
size_t len;
|
|
|
|
|
const char *name;
|
|
|
|
|
|
make USE_NSEC work as expected
Since the filesystem ext4 is now defined as stable in Linux v2.6.28,
and ext4 supports nanonsecond resolution timestamps natively, it is
time to make USE_NSEC work as expected.
This will make racy git situations less likely to happen. For 'git
checkout' this means it will be less likely that we have to open, read
the contents of the file into RAM, and check if file is really
modified or not. The result sould be a litle less used CPU time, less
pagefaults and a litle faster program, at least for 'git checkout'.
Since the number of possible racy git situations would increase when
disks gets faster, this patch would be more and more helpfull as times
go by. For a fast Solid State Disk, this patch should be helpfull.
Note that, when file operations starts to take less than 1 nanosecond,
one would again start to get more racy git situations.
For more info on racy git, see Documentation/technical/racy-git.txt
For more info on ext4, see http://kernelnewbies.org/Ext4
Signed-off-by: Kjetil Barvik <barvik@broadpark.no>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
16 years ago
|
|
|
ce->ce_ctime.sec = ntohl(ondisk->ctime.sec);
|
|
|
|
|
ce->ce_mtime.sec = ntohl(ondisk->mtime.sec);
|
|
|
|
|
ce->ce_ctime.nsec = ntohl(ondisk->ctime.nsec);
|
|
|
|
|
ce->ce_mtime.nsec = ntohl(ondisk->mtime.nsec);
|
|
|
|
|
ce->ce_dev = ntohl(ondisk->dev);
|
|
|
|
|
ce->ce_ino = ntohl(ondisk->ino);
|
|
|
|
|
ce->ce_mode = ntohl(ondisk->mode);
|
|
|
|
|
ce->ce_uid = ntohl(ondisk->uid);
|
|
|
|
|
ce->ce_gid = ntohl(ondisk->gid);
|
|
|
|
|
ce->ce_size = ntohl(ondisk->size);
|
|
|
|
|
/* On-disk flags are just 16 bits */
|
|
|
|
|
ce->ce_flags = ntohs(ondisk->flags);
|
|
|
|
|
|
|
|
|
|
hashcpy(ce->sha1, ondisk->sha1);
|
|
|
|
|
|
|
|
|
|
len = ce->ce_flags & CE_NAMEMASK;
|
|
|
|
|
|
|
|
|
|
if (ce->ce_flags & CE_EXTENDED) {
|
|
|
|
|
struct ondisk_cache_entry_extended *ondisk2;
|
|
|
|
|
int extended_flags;
|
|
|
|
|
ondisk2 = (struct ondisk_cache_entry_extended *)ondisk;
|
|
|
|
|
extended_flags = ntohs(ondisk2->flags2) << 16;
|
|
|
|
|
/* We do not yet understand any bit out of CE_EXTENDED_FLAGS */
|
|
|
|
|
if (extended_flags & ~CE_EXTENDED_FLAGS)
|
|
|
|
|
die("Unknown index entry format %08x", extended_flags);
|
|
|
|
|
ce->ce_flags |= extended_flags;
|
|
|
|
|
name = ondisk2->name;
|
|
|
|
|
}
|
|
|
|
|
else
|
|
|
|
|
name = ondisk->name;
|
|
|
|
|
|
|
|
|
|
if (len == CE_NAMEMASK)
|
|
|
|
|
len = strlen(name);
|
|
|
|
|
/*
|
|
|
|
|
* NEEDSWORK: If the original index is crafted, this copy could
|
|
|
|
|
* go unchecked.
|
|
|
|
|
*/
|
|
|
|
|
memcpy(ce->name, name, len + 1);
|
|
|
|
|
}
|
|
|
|
|
|
Create pathname-based hash-table lookup into index
This creates a hash index of every single file added to the index.
Right now that hash index isn't actually used for much: I implemented a
"cache_name_exists()" function that uses it to efficiently look up a
filename in the index without having to do the O(logn) binary search,
but quite frankly, that's not why this patch is interesting.
No, the whole and only reason to create the hash of the filenames in the
index is that by modifying the hash function, you can fairly easily do
things like making it always hash equivalent names into the same bucket.
That, in turn, means that suddenly questions like "does this name exist
in the index under an _equivalent_ name?" becomes much much cheaper.
Guiding principles behind this patch:
- it shouldn't be too costly. In fact, my primary goal here was to
actually speed up "git commit" with a fully populated kernel tree, by
being faster at checking whether a file already existed in the index. I
did succeed, but only barely:
Best before:
[torvalds@woody linux]$ time git commit > /dev/null
real 0m0.255s
user 0m0.168s
sys 0m0.088s
Best after:
[torvalds@woody linux]$ time ~/git/git commit > /dev/null
real 0m0.233s
user 0m0.144s
sys 0m0.088s
so some things are actually faster (~8%).
Caveat: that's really the best case. Other things are invariably going
to be slightly slower, since we populate that index cache, and quite
frankly, few things really use it to look things up.
That said, the cost is really quite small. The worst case is probably
doing a "git ls-files", which will do very little except puopulate the
index, and never actually looks anything up in it, just lists it.
Before:
[torvalds@woody linux]$ time git ls-files > /dev/null
real 0m0.016s
user 0m0.016s
sys 0m0.000s
After:
[torvalds@woody linux]$ time ~/git/git ls-files > /dev/null
real 0m0.021s
user 0m0.012s
sys 0m0.008s
and while the thing has really gotten relatively much slower, we're
still talking about something almost unmeasurable (eg 5ms). And that
really should be pretty much the worst case.
So we lose 5ms on one "benchmark", but win 22ms on another. Pick your
poison - this patch has the advantage that it will _likely_ speed up
the cases that are complex and expensive more than it slows down the
cases that are already so fast that nobody cares. But if you look at
relative speedups/slowdowns, it doesn't look so good.
- It should be simple and clean
The code may be a bit subtle (the reasons I do hash removal the way I
do etc), but it re-uses the existing hash.c files, so it really is
fairly small and straightforward apart from a few odd details.
Now, this patch on its own doesn't really do much, but I think it's worth
looking at, if only because if done correctly, the name hashing really can
make an improvement to the whole issue of "do we have a filename that
looks like this in the index already". And at least it gets real testing
by being used even by default (ie there is a real use-case for it even
without any insane filesystems).
NOTE NOTE NOTE! The current hash is a joke. I'm ashamed of it, I'm just
not ashamed of it enough to really care. I took all the numbers out of my
nether regions - I'm sure it's good enough that it works in practice, but
the whole point was that you can make a really much fancier hash that
hashes characters not directly, but by their upper-case value or something
like that, and thus you get a case-insensitive hash, while still keeping
the name and the index itself totally case sensitive.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
17 years ago
|
|
|
static inline size_t estimate_cache_size(size_t ondisk_size, unsigned int entries)
|
|
|
|
|
{
|
|
|
|
|
long per_entry;
|
|
|
|
|
|
|
|
|
|
per_entry = sizeof(struct cache_entry) - sizeof(struct ondisk_cache_entry);
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Alignment can cause differences. This should be "alignof", but
|
|
|
|
|
* since that's a gcc'ism, just use the size of a pointer.
|
|
|
|
|
*/
|
|
|
|
|
per_entry += sizeof(void *);
|
|
|
|
|
return ondisk_size + entries*per_entry;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* remember to discard_cache() before reading a different cache! */
|
|
|
|
|
int read_index_from(struct index_state *istate, const char *path)
|
|
|
|
|
{
|
|
|
|
|
int fd, i;
|
|
|
|
|
struct stat st;
|
|
|
|
|
unsigned long src_offset, dst_offset;
|
|
|
|
|
struct cache_header *hdr;
|
|
|
|
|
void *mmap;
|
|
|
|
|
size_t mmap_size;
|
|
|
|
|
|
|
|
|
|
errno = EBUSY;
|
unpack_trees(): protect the handcrafted in-core index from read_cache()
unpack_trees() rebuilds the in-core index from scratch by allocating a new
structure and finishing it off by copying the built one to the final
index.
The resulting in-core index is Ok for most use, but read_cache() does not
recognize it as such. The function is meant to be no-op if you already
have loaded the index, until you call discard_cache().
This change the way read_cache() detects an already initialized in-core
index, by introducing an extra bit, and marks the handcrafted in-core
index as initialized, to avoid this problem.
A better fix in the longer term would be to change the read_cache() API so
that it will always discard and re-read from the on-disk index to avoid
confusion. But there are higher level API that have relied on the current
semantics, and they and their users all need to get converted, which is
outside the scope of 'maint' track.
An example of such a higher level API is write_cache_as_tree(), which is
used by git-write-tree as well as later Porcelains like git-merge, revert
and cherry-pick. In the longer term, we should remove read_cache() from
there and add one to cmd_write_tree(); other callers expect that the
in-core index they prepared is what gets written as a tree so no other
change is necessary for this particular codepath.
The original version of this patch marked the index by pointing an
otherwise wasted malloc'ed memory with o->result.alloc, but this version
uses Linus's idea to use a new "initialized" bit, which is conceptually
much cleaner.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
17 years ago
|
|
|
if (istate->initialized)
|
|
|
|
|
return istate->cache_nr;
|
|
|
|
|
|
|
|
|
|
errno = ENOENT;
|
make USE_NSEC work as expected
Since the filesystem ext4 is now defined as stable in Linux v2.6.28,
and ext4 supports nanonsecond resolution timestamps natively, it is
time to make USE_NSEC work as expected.
This will make racy git situations less likely to happen. For 'git
checkout' this means it will be less likely that we have to open, read
the contents of the file into RAM, and check if file is really
modified or not. The result sould be a litle less used CPU time, less
pagefaults and a litle faster program, at least for 'git checkout'.
Since the number of possible racy git situations would increase when
disks gets faster, this patch would be more and more helpfull as times
go by. For a fast Solid State Disk, this patch should be helpfull.
Note that, when file operations starts to take less than 1 nanosecond,
one would again start to get more racy git situations.
For more info on racy git, see Documentation/technical/racy-git.txt
For more info on ext4, see http://kernelnewbies.org/Ext4
Signed-off-by: Kjetil Barvik <barvik@broadpark.no>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
16 years ago
|
|
|
istate->timestamp.sec = 0;
|
|
|
|
|
istate->timestamp.nsec = 0;
|
|
|
|
|
fd = open(path, O_RDONLY);
|
|
|
|
|
if (fd < 0) {
|
|
|
|
|
if (errno == ENOENT)
|
|
|
|
|
return 0;
|
|
|
|
|
die("index file open failed (%s)", strerror(errno));
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (fstat(fd, &st))
|
|
|
|
|
die("cannot stat the open index (%s)", strerror(errno));
|
|
|
|
|
|
|
|
|
|
errno = EINVAL;
|
|
|
|
|
mmap_size = xsize_t(st.st_size);
|
|
|
|
|
if (mmap_size < sizeof(struct cache_header) + 20)
|
|
|
|
|
die("index file smaller than expected");
|
|
|
|
|
|
|
|
|
|
mmap = xmmap(NULL, mmap_size, PROT_READ | PROT_WRITE, MAP_PRIVATE, fd, 0);
|
|
|
|
|
close(fd);
|
|
|
|
|
if (mmap == MAP_FAILED)
|
|
|
|
|
die("unable to map index file");
|
|
|
|
|
|
|
|
|
|
hdr = mmap;
|
|
|
|
|
if (verify_hdr(hdr, mmap_size) < 0)
|
|
|
|
|
goto unmap;
|
|
|
|
|
|
|
|
|
|
istate->cache_nr = ntohl(hdr->hdr_entries);
|
|
|
|
|
istate->cache_alloc = alloc_nr(istate->cache_nr);
|
|
|
|
|
istate->cache = xcalloc(istate->cache_alloc, sizeof(struct cache_entry *));
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* The disk format is actually larger than the in-memory format,
|
|
|
|
|
* due to space for nsec etc, so even though the in-memory one
|
|
|
|
|
* has room for a few more flags, we can allocate using the same
|
|
|
|
|
* index size
|
|
|
|
|
*/
|
Create pathname-based hash-table lookup into index
This creates a hash index of every single file added to the index.
Right now that hash index isn't actually used for much: I implemented a
"cache_name_exists()" function that uses it to efficiently look up a
filename in the index without having to do the O(logn) binary search,
but quite frankly, that's not why this patch is interesting.
No, the whole and only reason to create the hash of the filenames in the
index is that by modifying the hash function, you can fairly easily do
things like making it always hash equivalent names into the same bucket.
That, in turn, means that suddenly questions like "does this name exist
in the index under an _equivalent_ name?" becomes much much cheaper.
Guiding principles behind this patch:
- it shouldn't be too costly. In fact, my primary goal here was to
actually speed up "git commit" with a fully populated kernel tree, by
being faster at checking whether a file already existed in the index. I
did succeed, but only barely:
Best before:
[torvalds@woody linux]$ time git commit > /dev/null
real 0m0.255s
user 0m0.168s
sys 0m0.088s
Best after:
[torvalds@woody linux]$ time ~/git/git commit > /dev/null
real 0m0.233s
user 0m0.144s
sys 0m0.088s
so some things are actually faster (~8%).
Caveat: that's really the best case. Other things are invariably going
to be slightly slower, since we populate that index cache, and quite
frankly, few things really use it to look things up.
That said, the cost is really quite small. The worst case is probably
doing a "git ls-files", which will do very little except puopulate the
index, and never actually looks anything up in it, just lists it.
Before:
[torvalds@woody linux]$ time git ls-files > /dev/null
real 0m0.016s
user 0m0.016s
sys 0m0.000s
After:
[torvalds@woody linux]$ time ~/git/git ls-files > /dev/null
real 0m0.021s
user 0m0.012s
sys 0m0.008s
and while the thing has really gotten relatively much slower, we're
still talking about something almost unmeasurable (eg 5ms). And that
really should be pretty much the worst case.
So we lose 5ms on one "benchmark", but win 22ms on another. Pick your
poison - this patch has the advantage that it will _likely_ speed up
the cases that are complex and expensive more than it slows down the
cases that are already so fast that nobody cares. But if you look at
relative speedups/slowdowns, it doesn't look so good.
- It should be simple and clean
The code may be a bit subtle (the reasons I do hash removal the way I
do etc), but it re-uses the existing hash.c files, so it really is
fairly small and straightforward apart from a few odd details.
Now, this patch on its own doesn't really do much, but I think it's worth
looking at, if only because if done correctly, the name hashing really can
make an improvement to the whole issue of "do we have a filename that
looks like this in the index already". And at least it gets real testing
by being used even by default (ie there is a real use-case for it even
without any insane filesystems).
NOTE NOTE NOTE! The current hash is a joke. I'm ashamed of it, I'm just
not ashamed of it enough to really care. I took all the numbers out of my
nether regions - I'm sure it's good enough that it works in practice, but
the whole point was that you can make a really much fancier hash that
hashes characters not directly, but by their upper-case value or something
like that, and thus you get a case-insensitive hash, while still keeping
the name and the index itself totally case sensitive.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
17 years ago
|
|
|
istate->alloc = xmalloc(estimate_cache_size(mmap_size, istate->cache_nr));
|
unpack_trees(): protect the handcrafted in-core index from read_cache()
unpack_trees() rebuilds the in-core index from scratch by allocating a new
structure and finishing it off by copying the built one to the final
index.
The resulting in-core index is Ok for most use, but read_cache() does not
recognize it as such. The function is meant to be no-op if you already
have loaded the index, until you call discard_cache().
This change the way read_cache() detects an already initialized in-core
index, by introducing an extra bit, and marks the handcrafted in-core
index as initialized, to avoid this problem.
A better fix in the longer term would be to change the read_cache() API so
that it will always discard and re-read from the on-disk index to avoid
confusion. But there are higher level API that have relied on the current
semantics, and they and their users all need to get converted, which is
outside the scope of 'maint' track.
An example of such a higher level API is write_cache_as_tree(), which is
used by git-write-tree as well as later Porcelains like git-merge, revert
and cherry-pick. In the longer term, we should remove read_cache() from
there and add one to cmd_write_tree(); other callers expect that the
in-core index they prepared is what gets written as a tree so no other
change is necessary for this particular codepath.
The original version of this patch marked the index by pointing an
otherwise wasted malloc'ed memory with o->result.alloc, but this version
uses Linus's idea to use a new "initialized" bit, which is conceptually
much cleaner.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
17 years ago
|
|
|
istate->initialized = 1;
|
|
|
|
|
|
|
|
|
|
src_offset = sizeof(*hdr);
|
|
|
|
|
dst_offset = 0;
|
|
|
|
|
for (i = 0; i < istate->cache_nr; i++) {
|
|
|
|
|
struct ondisk_cache_entry *disk_ce;
|
|
|
|
|
struct cache_entry *ce;
|
|
|
|
|
|
|
|
|
|
disk_ce = (struct ondisk_cache_entry *)((char *)mmap + src_offset);
|
|
|
|
|
ce = (struct cache_entry *)((char *)istate->alloc + dst_offset);
|
|
|
|
|
convert_from_disk(disk_ce, ce);
|
Create pathname-based hash-table lookup into index
This creates a hash index of every single file added to the index.
Right now that hash index isn't actually used for much: I implemented a
"cache_name_exists()" function that uses it to efficiently look up a
filename in the index without having to do the O(logn) binary search,
but quite frankly, that's not why this patch is interesting.
No, the whole and only reason to create the hash of the filenames in the
index is that by modifying the hash function, you can fairly easily do
things like making it always hash equivalent names into the same bucket.
That, in turn, means that suddenly questions like "does this name exist
in the index under an _equivalent_ name?" becomes much much cheaper.
Guiding principles behind this patch:
- it shouldn't be too costly. In fact, my primary goal here was to
actually speed up "git commit" with a fully populated kernel tree, by
being faster at checking whether a file already existed in the index. I
did succeed, but only barely:
Best before:
[torvalds@woody linux]$ time git commit > /dev/null
real 0m0.255s
user 0m0.168s
sys 0m0.088s
Best after:
[torvalds@woody linux]$ time ~/git/git commit > /dev/null
real 0m0.233s
user 0m0.144s
sys 0m0.088s
so some things are actually faster (~8%).
Caveat: that's really the best case. Other things are invariably going
to be slightly slower, since we populate that index cache, and quite
frankly, few things really use it to look things up.
That said, the cost is really quite small. The worst case is probably
doing a "git ls-files", which will do very little except puopulate the
index, and never actually looks anything up in it, just lists it.
Before:
[torvalds@woody linux]$ time git ls-files > /dev/null
real 0m0.016s
user 0m0.016s
sys 0m0.000s
After:
[torvalds@woody linux]$ time ~/git/git ls-files > /dev/null
real 0m0.021s
user 0m0.012s
sys 0m0.008s
and while the thing has really gotten relatively much slower, we're
still talking about something almost unmeasurable (eg 5ms). And that
really should be pretty much the worst case.
So we lose 5ms on one "benchmark", but win 22ms on another. Pick your
poison - this patch has the advantage that it will _likely_ speed up
the cases that are complex and expensive more than it slows down the
cases that are already so fast that nobody cares. But if you look at
relative speedups/slowdowns, it doesn't look so good.
- It should be simple and clean
The code may be a bit subtle (the reasons I do hash removal the way I
do etc), but it re-uses the existing hash.c files, so it really is
fairly small and straightforward apart from a few odd details.
Now, this patch on its own doesn't really do much, but I think it's worth
looking at, if only because if done correctly, the name hashing really can
make an improvement to the whole issue of "do we have a filename that
looks like this in the index already". And at least it gets real testing
by being used even by default (ie there is a real use-case for it even
without any insane filesystems).
NOTE NOTE NOTE! The current hash is a joke. I'm ashamed of it, I'm just
not ashamed of it enough to really care. I took all the numbers out of my
nether regions - I'm sure it's good enough that it works in practice, but
the whole point was that you can make a really much fancier hash that
hashes characters not directly, but by their upper-case value or something
like that, and thus you get a case-insensitive hash, while still keeping
the name and the index itself totally case sensitive.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
17 years ago
|
|
|
set_index_entry(istate, i, ce);
|
|
|
|
|
|
|
|
|
|
src_offset += ondisk_ce_size(ce);
|
|
|
|
|
dst_offset += ce_size(ce);
|
|
|
|
|
}
|
make USE_NSEC work as expected
Since the filesystem ext4 is now defined as stable in Linux v2.6.28,
and ext4 supports nanonsecond resolution timestamps natively, it is
time to make USE_NSEC work as expected.
This will make racy git situations less likely to happen. For 'git
checkout' this means it will be less likely that we have to open, read
the contents of the file into RAM, and check if file is really
modified or not. The result sould be a litle less used CPU time, less
pagefaults and a litle faster program, at least for 'git checkout'.
Since the number of possible racy git situations would increase when
disks gets faster, this patch would be more and more helpfull as times
go by. For a fast Solid State Disk, this patch should be helpfull.
Note that, when file operations starts to take less than 1 nanosecond,
one would again start to get more racy git situations.
For more info on racy git, see Documentation/technical/racy-git.txt
For more info on ext4, see http://kernelnewbies.org/Ext4
Signed-off-by: Kjetil Barvik <barvik@broadpark.no>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
16 years ago
|
|
|
istate->timestamp.sec = st.st_mtime;
|
|
|
|
|
istate->timestamp.nsec = ST_MTIME_NSEC(st);
|
make USE_NSEC work as expected
Since the filesystem ext4 is now defined as stable in Linux v2.6.28,
and ext4 supports nanonsecond resolution timestamps natively, it is
time to make USE_NSEC work as expected.
This will make racy git situations less likely to happen. For 'git
checkout' this means it will be less likely that we have to open, read
the contents of the file into RAM, and check if file is really
modified or not. The result sould be a litle less used CPU time, less
pagefaults and a litle faster program, at least for 'git checkout'.
Since the number of possible racy git situations would increase when
disks gets faster, this patch would be more and more helpfull as times
go by. For a fast Solid State Disk, this patch should be helpfull.
Note that, when file operations starts to take less than 1 nanosecond,
one would again start to get more racy git situations.
For more info on racy git, see Documentation/technical/racy-git.txt
For more info on ext4, see http://kernelnewbies.org/Ext4
Signed-off-by: Kjetil Barvik <barvik@broadpark.no>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
16 years ago
|
|
|
|
|
|
|
|
while (src_offset <= mmap_size - 20 - 8) {
|
|
|
|
|
/* 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;
|
|
|
|
|
memcpy(&extsize, (char *)mmap + src_offset + 4, 4);
|
|
|
|
|
extsize = ntohl(extsize);
|
|
|
|
|
if (read_index_extension(istate,
|
|
|
|
|
(const char *) mmap + src_offset,
|
|
|
|
|
(char *) mmap + src_offset + 8,
|
|
|
|
|
extsize) < 0)
|
|
|
|
|
goto unmap;
|
|
|
|
|
src_offset += 8;
|
|
|
|
|
src_offset += extsize;
|
|
|
|
|
}
|
|
|
|
|
munmap(mmap, mmap_size);
|
|
|
|
|
return istate->cache_nr;
|
|
|
|
|
|
|
|
|
|
unmap:
|
|
|
|
|
munmap(mmap, mmap_size);
|
|
|
|
|
errno = EINVAL;
|
|
|
|
|
die("index file corrupt");
|
|
|
|
|
}
|
|
|
|
|
|
checkout: Fix "initial checkout" detection
Earlier commit 5521883 (checkout: do not lose staged removal, 2008-09-07)
tightened the rule to prevent switching branches from losing local
changes, so that staged removal of paths can be protected, while
attempting to keep a loophole to still allow a special case of switching
out of an un-checked-out state.
However, the loophole was made a bit too tight, and did not allow
switching from one branch (in an un-checked-out state) to check out
another branch.
The change to builtin-checkout.c in this commit loosens it to allow this,
by not insisting the original commit and the new commit to be the same.
It also introduces a new function, is_index_unborn (and an associated
macro, is_cache_unborn), to check if the repository is truly in an
un-checked-out state more reliably, by making sure that $GIT_INDEX_FILE
did not exist when populating the in-core index structure. A few places
the earlier commit 5521883 added the check for the initial checkout
condition are updated to use this function.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
16 years ago
|
|
|
int is_index_unborn(struct index_state *istate)
|
|
|
|
|
{
|
make USE_NSEC work as expected
Since the filesystem ext4 is now defined as stable in Linux v2.6.28,
and ext4 supports nanonsecond resolution timestamps natively, it is
time to make USE_NSEC work as expected.
This will make racy git situations less likely to happen. For 'git
checkout' this means it will be less likely that we have to open, read
the contents of the file into RAM, and check if file is really
modified or not. The result sould be a litle less used CPU time, less
pagefaults and a litle faster program, at least for 'git checkout'.
Since the number of possible racy git situations would increase when
disks gets faster, this patch would be more and more helpfull as times
go by. For a fast Solid State Disk, this patch should be helpfull.
Note that, when file operations starts to take less than 1 nanosecond,
one would again start to get more racy git situations.
For more info on racy git, see Documentation/technical/racy-git.txt
For more info on ext4, see http://kernelnewbies.org/Ext4
Signed-off-by: Kjetil Barvik <barvik@broadpark.no>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
16 years ago
|
|
|
return (!istate->cache_nr && !istate->alloc && !istate->timestamp.sec);
|
checkout: Fix "initial checkout" detection
Earlier commit 5521883 (checkout: do not lose staged removal, 2008-09-07)
tightened the rule to prevent switching branches from losing local
changes, so that staged removal of paths can be protected, while
attempting to keep a loophole to still allow a special case of switching
out of an un-checked-out state.
However, the loophole was made a bit too tight, and did not allow
switching from one branch (in an un-checked-out state) to check out
another branch.
The change to builtin-checkout.c in this commit loosens it to allow this,
by not insisting the original commit and the new commit to be the same.
It also introduces a new function, is_index_unborn (and an associated
macro, is_cache_unborn), to check if the repository is truly in an
un-checked-out state more reliably, by making sure that $GIT_INDEX_FILE
did not exist when populating the in-core index structure. A few places
the earlier commit 5521883 added the check for the initial checkout
condition are updated to use this function.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
16 years ago
|
|
|
}
|
|
|
|
|
|
|
|
|
|
int discard_index(struct index_state *istate)
|
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>
19 years ago
|
|
|
{
|
|
|
|
|
istate->cache_nr = 0;
|
|
|
|
|
istate->cache_changed = 0;
|
make USE_NSEC work as expected
Since the filesystem ext4 is now defined as stable in Linux v2.6.28,
and ext4 supports nanonsecond resolution timestamps natively, it is
time to make USE_NSEC work as expected.
This will make racy git situations less likely to happen. For 'git
checkout' this means it will be less likely that we have to open, read
the contents of the file into RAM, and check if file is really
modified or not. The result sould be a litle less used CPU time, less
pagefaults and a litle faster program, at least for 'git checkout'.
Since the number of possible racy git situations would increase when
disks gets faster, this patch would be more and more helpfull as times
go by. For a fast Solid State Disk, this patch should be helpfull.
Note that, when file operations starts to take less than 1 nanosecond,
one would again start to get more racy git situations.
For more info on racy git, see Documentation/technical/racy-git.txt
For more info on ext4, see http://kernelnewbies.org/Ext4
Signed-off-by: Kjetil Barvik <barvik@broadpark.no>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
16 years ago
|
|
|
istate->timestamp.sec = 0;
|
|
|
|
|
istate->timestamp.nsec = 0;
|
|
|
|
|
istate->name_hash_initialized = 0;
|
Create pathname-based hash-table lookup into index
This creates a hash index of every single file added to the index.
Right now that hash index isn't actually used for much: I implemented a
"cache_name_exists()" function that uses it to efficiently look up a
filename in the index without having to do the O(logn) binary search,
but quite frankly, that's not why this patch is interesting.
No, the whole and only reason to create the hash of the filenames in the
index is that by modifying the hash function, you can fairly easily do
things like making it always hash equivalent names into the same bucket.
That, in turn, means that suddenly questions like "does this name exist
in the index under an _equivalent_ name?" becomes much much cheaper.
Guiding principles behind this patch:
- it shouldn't be too costly. In fact, my primary goal here was to
actually speed up "git commit" with a fully populated kernel tree, by
being faster at checking whether a file already existed in the index. I
did succeed, but only barely:
Best before:
[torvalds@woody linux]$ time git commit > /dev/null
real 0m0.255s
user 0m0.168s
sys 0m0.088s
Best after:
[torvalds@woody linux]$ time ~/git/git commit > /dev/null
real 0m0.233s
user 0m0.144s
sys 0m0.088s
so some things are actually faster (~8%).
Caveat: that's really the best case. Other things are invariably going
to be slightly slower, since we populate that index cache, and quite
frankly, few things really use it to look things up.
That said, the cost is really quite small. The worst case is probably
doing a "git ls-files", which will do very little except puopulate the
index, and never actually looks anything up in it, just lists it.
Before:
[torvalds@woody linux]$ time git ls-files > /dev/null
real 0m0.016s
user 0m0.016s
sys 0m0.000s
After:
[torvalds@woody linux]$ time ~/git/git ls-files > /dev/null
real 0m0.021s
user 0m0.012s
sys 0m0.008s
and while the thing has really gotten relatively much slower, we're
still talking about something almost unmeasurable (eg 5ms). And that
really should be pretty much the worst case.
So we lose 5ms on one "benchmark", but win 22ms on another. Pick your
poison - this patch has the advantage that it will _likely_ speed up
the cases that are complex and expensive more than it slows down the
cases that are already so fast that nobody cares. But if you look at
relative speedups/slowdowns, it doesn't look so good.
- It should be simple and clean
The code may be a bit subtle (the reasons I do hash removal the way I
do etc), but it re-uses the existing hash.c files, so it really is
fairly small and straightforward apart from a few odd details.
Now, this patch on its own doesn't really do much, but I think it's worth
looking at, if only because if done correctly, the name hashing really can
make an improvement to the whole issue of "do we have a filename that
looks like this in the index already". And at least it gets real testing
by being used even by default (ie there is a real use-case for it even
without any insane filesystems).
NOTE NOTE NOTE! The current hash is a joke. I'm ashamed of it, I'm just
not ashamed of it enough to really care. I took all the numbers out of my
nether regions - I'm sure it's good enough that it works in practice, but
the whole point was that you can make a really much fancier hash that
hashes characters not directly, but by their upper-case value or something
like that, and thus you get a case-insensitive hash, while still keeping
the name and the index itself totally case sensitive.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
17 years ago
|
|
|
free_hash(&istate->name_hash);
|
|
|
|
|
cache_tree_free(&(istate->cache_tree));
|
|
|
|
|
free(istate->alloc);
|
|
|
|
|
istate->alloc = NULL;
|
unpack_trees(): protect the handcrafted in-core index from read_cache()
unpack_trees() rebuilds the in-core index from scratch by allocating a new
structure and finishing it off by copying the built one to the final
index.
The resulting in-core index is Ok for most use, but read_cache() does not
recognize it as such. The function is meant to be no-op if you already
have loaded the index, until you call discard_cache().
This change the way read_cache() detects an already initialized in-core
index, by introducing an extra bit, and marks the handcrafted in-core
index as initialized, to avoid this problem.
A better fix in the longer term would be to change the read_cache() API so
that it will always discard and re-read from the on-disk index to avoid
confusion. But there are higher level API that have relied on the current
semantics, and they and their users all need to get converted, which is
outside the scope of 'maint' track.
An example of such a higher level API is write_cache_as_tree(), which is
used by git-write-tree as well as later Porcelains like git-merge, revert
and cherry-pick. In the longer term, we should remove read_cache() from
there and add one to cmd_write_tree(); other callers expect that the
in-core index they prepared is what gets written as a tree so no other
change is necessary for this particular codepath.
The original version of this patch marked the index by pointing an
otherwise wasted malloc'ed memory with o->result.alloc, but this version
uses Linus's idea to use a new "initialized" bit, which is conceptually
much cleaner.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
17 years ago
|
|
|
istate->initialized = 0;
|
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>
19 years ago
|
|
|
|
|
|
|
|
/* no need to throw away allocated active_cache */
|
|
|
|
|
return 0;
|
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>
19 years ago
|
|
|
}
|
|
|
|
|
|
|
|
|
|
int unmerged_index(const struct index_state *istate)
|
|
|
|
|
{
|
|
|
|
|
int i;
|
|
|
|
|
for (i = 0; i < istate->cache_nr; i++) {
|
|
|
|
|
if (ce_stage(istate->cache[i]))
|
|
|
|
|
return 1;
|
|
|
|
|
}
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
#define WRITE_BUFFER_SIZE 8192
|
|
|
|
|
static unsigned char write_buffer[WRITE_BUFFER_SIZE];
|
|
|
|
|
static unsigned long write_buffer_len;
|
|
|
|
|
|
|
|
|
|
static int ce_write_flush(git_SHA_CTX *context, int fd)
|
|
|
|
|
{
|
|
|
|
|
unsigned int buffered = write_buffer_len;
|
|
|
|
|
if (buffered) {
|
|
|
|
|
git_SHA1_Update(context, write_buffer, buffered);
|
|
|
|
|
if (write_in_full(fd, write_buffer, buffered) != buffered)
|
|
|
|
|
return -1;
|
|
|
|
|
write_buffer_len = 0;
|
|
|
|
|
}
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int ce_write(git_SHA_CTX *context, int fd, void *data, unsigned int len)
|
|
|
|
|
{
|
|
|
|
|
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) {
|
|
|
|
|
write_buffer_len = buffered;
|
|
|
|
|
if (ce_write_flush(context, fd))
|
|
|
|
|
return -1;
|
|
|
|
|
buffered = 0;
|
|
|
|
|
}
|
|
|
|
|
write_buffer_len = buffered;
|
|
|
|
|
len -= partial;
|
|
|
|
|
data = (char *) data + partial;
|
|
|
|
|
}
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int write_index_ext_header(git_SHA_CTX *context, int fd,
|
|
|
|
|
unsigned int ext, unsigned int sz)
|
|
|
|
|
{
|
|
|
|
|
ext = htonl(ext);
|
|
|
|
|
sz = htonl(sz);
|
|
|
|
|
return ((ce_write(context, fd, &ext, 4) < 0) ||
|
|
|
|
|
(ce_write(context, fd, &sz, 4) < 0)) ? -1 : 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int ce_flush(git_SHA_CTX *context, int fd)
|
|
|
|
|
{
|
|
|
|
|
unsigned int left = write_buffer_len;
|
|
|
|
|
|
|
|
|
|
if (left) {
|
|
|
|
|
write_buffer_len = 0;
|
|
|
|
|
git_SHA1_Update(context, write_buffer, left);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Flush first if not enough space for SHA1 signature */
|
|
|
|
|
if (left + 20 > WRITE_BUFFER_SIZE) {
|
|
|
|
|
if (write_in_full(fd, write_buffer, left) != left)
|
|
|
|
|
return -1;
|
|
|
|
|
left = 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Append the SHA1 signature at the end */
|
|
|
|
|
git_SHA1_Final(write_buffer + left, context);
|
|
|
|
|
left += 20;
|
|
|
|
|
return (write_in_full(fd, write_buffer, left) != left) ? -1 : 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
*
|
|
|
|
|
* Note that this actually does not do much for gitlinks, for
|
|
|
|
|
* which ce_match_stat_basic() always goes to the actual
|
|
|
|
|
* contents. The caller checks with is_racy_timestamp() which
|
|
|
|
|
* always says "no" for gitlinks, so we are not called for them ;-)
|
|
|
|
|
*/
|
|
|
|
|
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)) {
|
|
|
|
|
/* 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
|
|
|
|
|
*
|
|
|
|
|
* but it does not. When the second update-index runs,
|
|
|
|
|
* 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.
|
|
|
|
|
*/
|
|
|
|
|
ce->ce_size = 0;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int ce_write_entry(git_SHA_CTX *c, int fd, struct cache_entry *ce)
|
|
|
|
|
{
|
|
|
|
|
int size = ondisk_ce_size(ce);
|
|
|
|
|
struct ondisk_cache_entry *ondisk = xcalloc(1, size);
|
|
|
|
|
char *name;
|
|
|
|
|
|
make USE_NSEC work as expected
Since the filesystem ext4 is now defined as stable in Linux v2.6.28,
and ext4 supports nanonsecond resolution timestamps natively, it is
time to make USE_NSEC work as expected.
This will make racy git situations less likely to happen. For 'git
checkout' this means it will be less likely that we have to open, read
the contents of the file into RAM, and check if file is really
modified or not. The result sould be a litle less used CPU time, less
pagefaults and a litle faster program, at least for 'git checkout'.
Since the number of possible racy git situations would increase when
disks gets faster, this patch would be more and more helpfull as times
go by. For a fast Solid State Disk, this patch should be helpfull.
Note that, when file operations starts to take less than 1 nanosecond,
one would again start to get more racy git situations.
For more info on racy git, see Documentation/technical/racy-git.txt
For more info on ext4, see http://kernelnewbies.org/Ext4
Signed-off-by: Kjetil Barvik <barvik@broadpark.no>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
16 years ago
|
|
|
ondisk->ctime.sec = htonl(ce->ce_ctime.sec);
|
|
|
|
|
ondisk->mtime.sec = htonl(ce->ce_mtime.sec);
|
|
|
|
|
ondisk->ctime.nsec = htonl(ce->ce_ctime.nsec);
|
|
|
|
|
ondisk->mtime.nsec = htonl(ce->ce_mtime.nsec);
|
|
|
|
|
ondisk->dev = htonl(ce->ce_dev);
|
|
|
|
|
ondisk->ino = htonl(ce->ce_ino);
|
|
|
|
|
ondisk->mode = htonl(ce->ce_mode);
|
|
|
|
|
ondisk->uid = htonl(ce->ce_uid);
|
|
|
|
|
ondisk->gid = htonl(ce->ce_gid);
|
|
|
|
|
ondisk->size = htonl(ce->ce_size);
|
|
|
|
|
hashcpy(ondisk->sha1, ce->sha1);
|
|
|
|
|
ondisk->flags = htons(ce->ce_flags);
|
|
|
|
|
if (ce->ce_flags & CE_EXTENDED) {
|
|
|
|
|
struct ondisk_cache_entry_extended *ondisk2;
|
|
|
|
|
ondisk2 = (struct ondisk_cache_entry_extended *)ondisk;
|
|
|
|
|
ondisk2->flags2 = htons((ce->ce_flags & CE_EXTENDED_FLAGS) >> 16);
|
|
|
|
|
name = ondisk2->name;
|
|
|
|
|
}
|
|
|
|
|
else
|
|
|
|
|
name = ondisk->name;
|
|
|
|
|
memcpy(name, ce->name, ce_namelen(ce));
|
|
|
|
|
|
|
|
|
|
return ce_write(c, fd, ondisk, size);
|
|
|
|
|
}
|
|
|
|
|
|
write_index(): update index_state->timestamp after flushing to disk
Since this timestamp is used to check for racy-clean files, it is
important to keep it uptodate.
For the 'git checkout' command without the '-q' option, this make a
huge difference. Before, each and every file which was updated, was
racy-clean after the call to unpack_trees() and write_index() but
before the GIT process ended.
And because of the call to show_local_changes() in builtin-checkout.c,
we ended up reading those files back into memory, doing a SHA1 to
check if the files was really different from the index. And, of
course, no file was different.
With this fix, 'git checkout' without the '-q' option should now be
almost as fast as with the '-q' option, but not quite, as we still do
some few lstat(2) calls more without the '-q' option.
Below is some average numbers for 10 checkout's to v2.6.27 and 10 to
v2.6.25 of the Linux kernel, to show the difference:
before (git version 1.6.2.rc1.256.g58a87):
7.860 user 2.427 sys 19.465 real 52.8% CPU faults: 0 major 95331 minor
after:
6.184 user 2.160 sys 17.619 real 47.4% CPU faults: 0 major 38994 minor
Signed-off-by: Kjetil Barvik <barvik@broadpark.no>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
16 years ago
|
|
|
int write_index(struct index_state *istate, int newfd)
|
|
|
|
|
{
|
|
|
|
|
git_SHA_CTX c;
|
|
|
|
|
struct cache_header hdr;
|
|
|
|
|
int i, err, removed, extended;
|
|
|
|
|
struct cache_entry **cache = istate->cache;
|
|
|
|
|
int entries = istate->cache_nr;
|
write_index(): update index_state->timestamp after flushing to disk
Since this timestamp is used to check for racy-clean files, it is
important to keep it uptodate.
For the 'git checkout' command without the '-q' option, this make a
huge difference. Before, each and every file which was updated, was
racy-clean after the call to unpack_trees() and write_index() but
before the GIT process ended.
And because of the call to show_local_changes() in builtin-checkout.c,
we ended up reading those files back into memory, doing a SHA1 to
check if the files was really different from the index. And, of
course, no file was different.
With this fix, 'git checkout' without the '-q' option should now be
almost as fast as with the '-q' option, but not quite, as we still do
some few lstat(2) calls more without the '-q' option.
Below is some average numbers for 10 checkout's to v2.6.27 and 10 to
v2.6.25 of the Linux kernel, to show the difference:
before (git version 1.6.2.rc1.256.g58a87):
7.860 user 2.427 sys 19.465 real 52.8% CPU faults: 0 major 95331 minor
after:
6.184 user 2.160 sys 17.619 real 47.4% CPU faults: 0 major 38994 minor
Signed-off-by: Kjetil Barvik <barvik@broadpark.no>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
16 years ago
|
|
|
struct stat st;
|
|
|
|
|
|
|
|
|
|
for (i = removed = extended = 0; i < entries; i++) {
|
|
|
|
|
if (cache[i]->ce_flags & CE_REMOVE)
|
|
|
|
|
removed++;
|
|
|
|
|
|
|
|
|
|
/* reduce extended entries if possible */
|
|
|
|
|
cache[i]->ce_flags &= ~CE_EXTENDED;
|
|
|
|
|
if (cache[i]->ce_flags & CE_EXTENDED_FLAGS) {
|
|
|
|
|
extended++;
|
|
|
|
|
cache[i]->ce_flags |= CE_EXTENDED;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
hdr.hdr_signature = htonl(CACHE_SIGNATURE);
|
|
|
|
|
/* for extended format, increase version so older git won't try to read it */
|
|
|
|
|
hdr.hdr_version = htonl(extended ? 3 : 2);
|
|
|
|
|
hdr.hdr_entries = htonl(entries - removed);
|
|
|
|
|
|
|
|
|
|
git_SHA1_Init(&c);
|
|
|
|
|
if (ce_write(&c, newfd, &hdr, sizeof(hdr)) < 0)
|
|
|
|
|
return -1;
|
|
|
|
|
|
|
|
|
|
for (i = 0; i < entries; i++) {
|
|
|
|
|
struct cache_entry *ce = cache[i];
|
|
|
|
|
if (ce->ce_flags & CE_REMOVE)
|
|
|
|
|
continue;
|
|
|
|
|
if (!ce_uptodate(ce) && is_racy_timestamp(istate, ce))
|
|
|
|
|
ce_smudge_racily_clean_entry(ce);
|
|
|
|
|
if (ce_write_entry(&c, newfd, ce) < 0)
|
|
|
|
|
return -1;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Write extension data here */
|
|
|
|
|
if (istate->cache_tree) {
|
|
|
|
|
struct strbuf sb = STRBUF_INIT;
|
|
|
|
|
|
|
|
|
|
cache_tree_write(&sb, istate->cache_tree);
|
|
|
|
|
err = write_index_ext_header(&c, newfd, CACHE_EXT_TREE, sb.len) < 0
|
|
|
|
|
|| ce_write(&c, newfd, sb.buf, sb.len) < 0;
|
|
|
|
|
strbuf_release(&sb);
|
|
|
|
|
if (err)
|
|
|
|
|
return -1;
|
|
|
|
|
}
|
write_index(): update index_state->timestamp after flushing to disk
Since this timestamp is used to check for racy-clean files, it is
important to keep it uptodate.
For the 'git checkout' command without the '-q' option, this make a
huge difference. Before, each and every file which was updated, was
racy-clean after the call to unpack_trees() and write_index() but
before the GIT process ended.
And because of the call to show_local_changes() in builtin-checkout.c,
we ended up reading those files back into memory, doing a SHA1 to
check if the files was really different from the index. And, of
course, no file was different.
With this fix, 'git checkout' without the '-q' option should now be
almost as fast as with the '-q' option, but not quite, as we still do
some few lstat(2) calls more without the '-q' option.
Below is some average numbers for 10 checkout's to v2.6.27 and 10 to
v2.6.25 of the Linux kernel, to show the difference:
before (git version 1.6.2.rc1.256.g58a87):
7.860 user 2.427 sys 19.465 real 52.8% CPU faults: 0 major 95331 minor
after:
6.184 user 2.160 sys 17.619 real 47.4% CPU faults: 0 major 38994 minor
Signed-off-by: Kjetil Barvik <barvik@broadpark.no>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
16 years ago
|
|
|
|
|
|
|
|
if (ce_flush(&c, newfd) || fstat(newfd, &st))
|
|
|
|
|
return -1;
|
|
|
|
|
istate->timestamp.sec = (unsigned int)st.st_mtime;
|
|
|
|
|
istate->timestamp.nsec = ST_MTIME_NSEC(st);
|
write_index(): update index_state->timestamp after flushing to disk
Since this timestamp is used to check for racy-clean files, it is
important to keep it uptodate.
For the 'git checkout' command without the '-q' option, this make a
huge difference. Before, each and every file which was updated, was
racy-clean after the call to unpack_trees() and write_index() but
before the GIT process ended.
And because of the call to show_local_changes() in builtin-checkout.c,
we ended up reading those files back into memory, doing a SHA1 to
check if the files was really different from the index. And, of
course, no file was different.
With this fix, 'git checkout' without the '-q' option should now be
almost as fast as with the '-q' option, but not quite, as we still do
some few lstat(2) calls more without the '-q' option.
Below is some average numbers for 10 checkout's to v2.6.27 and 10 to
v2.6.25 of the Linux kernel, to show the difference:
before (git version 1.6.2.rc1.256.g58a87):
7.860 user 2.427 sys 19.465 real 52.8% CPU faults: 0 major 95331 minor
after:
6.184 user 2.160 sys 17.619 real 47.4% CPU faults: 0 major 38994 minor
Signed-off-by: Kjetil Barvik <barvik@broadpark.no>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
16 years ago
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Read the index file that is potentially unmerged into given
|
|
|
|
|
* index_state, dropping any unmerged entries. Returns true if
|
|
|
|
|
* the index is unmerged. Callers who want to refuse to work
|
|
|
|
|
* from an unmerged state can call this and check its return value,
|
|
|
|
|
* instead of calling read_cache().
|
|
|
|
|
*/
|
|
|
|
|
int read_index_unmerged(struct index_state *istate)
|
|
|
|
|
{
|
|
|
|
|
int i;
|
|
|
|
|
int unmerged = 0;
|
|
|
|
|
|
|
|
|
|
read_index(istate);
|
|
|
|
|
for (i = 0; i < istate->cache_nr; i++) {
|
|
|
|
|
struct cache_entry *ce = istate->cache[i];
|
|
|
|
|
struct cache_entry *new_ce;
|
|
|
|
|
int size, len;
|
|
|
|
|
|
|
|
|
|
if (!ce_stage(ce))
|
|
|
|
|
continue;
|
|
|
|
|
unmerged = 1;
|
|
|
|
|
len = strlen(ce->name);
|
|
|
|
|
size = cache_entry_size(len);
|
|
|
|
|
new_ce = xcalloc(1, size);
|
|
|
|
|
hashcpy(new_ce->sha1, ce->sha1);
|
|
|
|
|
memcpy(new_ce->name, ce->name, len);
|
|
|
|
|
new_ce->ce_flags = create_ce_flags(len, 0);
|
|
|
|
|
new_ce->ce_mode = ce->ce_mode;
|
|
|
|
|
if (add_index_entry(istate, new_ce, 0))
|
|
|
|
|
return error("%s: cannot drop to stage #0",
|
|
|
|
|
ce->name);
|
|
|
|
|
i = index_name_pos(istate, new_ce->name, len);
|
|
|
|
|
}
|
|
|
|
|
return unmerged;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
struct update_callback_data
|
|
|
|
|
{
|
|
|
|
|
int flags;
|
|
|
|
|
int add_errors;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
static void update_callback(struct diff_queue_struct *q,
|
|
|
|
|
struct diff_options *opt, void *cbdata)
|
|
|
|
|
{
|
|
|
|
|
int i;
|
|
|
|
|
struct update_callback_data *data = cbdata;
|
|
|
|
|
|
|
|
|
|
for (i = 0; i < q->nr; i++) {
|
|
|
|
|
struct diff_filepair *p = q->queue[i];
|
|
|
|
|
const char *path = p->one->path;
|
|
|
|
|
switch (p->status) {
|
|
|
|
|
default:
|
|
|
|
|
die("unexpected diff status %c", p->status);
|
|
|
|
|
case DIFF_STATUS_UNMERGED:
|
|
|
|
|
/*
|
|
|
|
|
* ADD_CACHE_IGNORE_REMOVAL is unset if "git
|
|
|
|
|
* add -u" is calling us, In such a case, a
|
|
|
|
|
* missing work tree file needs to be removed
|
|
|
|
|
* if there is an unmerged entry at stage #2,
|
|
|
|
|
* but such a diff record is followed by
|
|
|
|
|
* another with DIFF_STATUS_DELETED (and if
|
|
|
|
|
* there is no stage #2, we won't see DELETED
|
|
|
|
|
* nor MODIFIED). We can simply continue
|
|
|
|
|
* either way.
|
|
|
|
|
*/
|
|
|
|
|
if (!(data->flags & ADD_CACHE_IGNORE_REMOVAL))
|
|
|
|
|
continue;
|
|
|
|
|
/*
|
|
|
|
|
* Otherwise, it is "git add path" is asking
|
|
|
|
|
* to explicitly add it; we fall through. A
|
|
|
|
|
* missing work tree file is an error and is
|
|
|
|
|
* caught by add_file_to_index() in such a
|
|
|
|
|
* case.
|
|
|
|
|
*/
|
|
|
|
|
case DIFF_STATUS_MODIFIED:
|
|
|
|
|
case DIFF_STATUS_TYPE_CHANGED:
|
|
|
|
|
if (add_file_to_index(&the_index, path, data->flags)) {
|
|
|
|
|
if (!(data->flags & ADD_CACHE_IGNORE_ERRORS))
|
|
|
|
|
die("updating files failed");
|
|
|
|
|
data->add_errors++;
|
|
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
case DIFF_STATUS_DELETED:
|
|
|
|
|
if (data->flags & ADD_CACHE_IGNORE_REMOVAL)
|
|
|
|
|
break;
|
|
|
|
|
if (!(data->flags & ADD_CACHE_PRETEND))
|
|
|
|
|
remove_file_from_index(&the_index, path);
|
|
|
|
|
if (data->flags & (ADD_CACHE_PRETEND|ADD_CACHE_VERBOSE))
|
|
|
|
|
printf("remove '%s'\n", path);
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
int add_files_to_cache(const char *prefix, const char **pathspec, int flags)
|
|
|
|
|
{
|
|
|
|
|
struct update_callback_data data;
|
|
|
|
|
struct rev_info rev;
|
|
|
|
|
init_revisions(&rev, prefix);
|
|
|
|
|
setup_revisions(0, NULL, &rev, NULL);
|
|
|
|
|
rev.prune_data = pathspec;
|
|
|
|
|
rev.diffopt.output_format = DIFF_FORMAT_CALLBACK;
|
|
|
|
|
rev.diffopt.format_callback = update_callback;
|
|
|
|
|
data.flags = flags;
|
|
|
|
|
data.add_errors = 0;
|
|
|
|
|
rev.diffopt.format_callback_data = &data;
|
|
|
|
|
run_diff_files(&rev, DIFF_RACY_IS_MODIFIED);
|
|
|
|
|
return !!data.add_errors;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Returns 1 if the path is an "other" path with respect to
|
|
|
|
|
* the index; that is, the path is not mentioned in the index at all,
|
|
|
|
|
* either as a file, a directory with some files in the index,
|
|
|
|
|
* or as an unmerged entry.
|
|
|
|
|
*
|
|
|
|
|
* We helpfully remove a trailing "/" from directories so that
|
|
|
|
|
* the output of read_directory can be used as-is.
|
|
|
|
|
*/
|
|
|
|
|
int index_name_is_other(const struct index_state *istate, const char *name,
|
|
|
|
|
int namelen)
|
|
|
|
|
{
|
|
|
|
|
int pos;
|
|
|
|
|
if (namelen && name[namelen - 1] == '/')
|
|
|
|
|
namelen--;
|
|
|
|
|
pos = index_name_pos(istate, name, namelen);
|
|
|
|
|
if (0 <= pos)
|
|
|
|
|
return 0; /* exact match */
|
|
|
|
|
pos = -pos - 1;
|
|
|
|
|
if (pos < istate->cache_nr) {
|
|
|
|
|
struct cache_entry *ce = istate->cache[pos];
|
|
|
|
|
if (ce_namelen(ce) == namelen &&
|
|
|
|
|
!memcmp(ce->name, name, namelen))
|
|
|
|
|
return 0; /* Yup, this one exists unmerged */
|
|
|
|
|
}
|
|
|
|
|
return 1;
|
|
|
|
|
}
|
