user/sven/git.git/read-cache.c, branch v1.8.0.2

read-cache.c: mark a private file-scope symbol as static

2012-09-16T05:58:21Z

Signed-off-by: Junio C Hamano

Merge branch 'jk/maint-null-in-trees'

2012-08-27T18:54:28Z

We do not want a link to 0{40} object stored anywhere in our objects. * jk/maint-null-in-trees: fsck: detect null sha1 in tree entries do not write null sha1s to on-disk index diff: do not use null sha1 as a sentinel value

Merge branch 'nd/index-errno'

2012-08-22T18:51:42Z

Assignments to errno before calling system functions that used to matter in the old code were left behind after the code structure changed sufficiently to make them useless. * nd/index-errno: read_index_from: remove bogus errno assignments

read_index_from: remove bogus errno assignments

2012-08-06T17:01:21Z

These assignments comes from the very first commit e83c516 (Initial revision of "git", the information manager from hell - 2005-04-07). Back then we did not die() when errors happened so correct errno was required. Since 5d1a5c0 ([PATCH] Better error reporting for "git status" - 2005-10-01), read_index_from() learned to die rather than just return -1 and these assignments became irrelevant. Remove them. While at it, move die_errno() next to xmmap() call because it's the mmap's error code that we care about. Otherwise if close(fd); fails, it could overwrite mmap's errno. Signed-off-by: Nguyễn Thái Ngọc Duy Signed-off-by: Junio C Hamano

do not write null sha1s to on-disk index

2012-07-29T22:13:36Z

We should never need to write the null sha1 into an index entry (short of the 1 in 2^160 chance that somebody actually has content that hashes to it). If we attempt to do so, it is much more likely that it is a bug, since we use the null sha1 as a sentinel value to mean "not valid". The presence of null sha1s in the index (which can come from, among other things, "update-index --cacheinfo", or by reading a corrupted tree) can cause problems for later readers, because they cannot distinguish the literal null sha1 from its use a sentinel value. For example, "git diff-files" on such an entry would make it appear as if it is stat-dirty, and until recently, the diff code assumed such an entry meant that we should be diffing a working tree file rather than a blob. Ideally, we would stop such entries from entering even our in-core index. However, we do sometimes legitimately add entries with null sha1s in order to represent these sentinel situations; simply forbidding them in add_index_entry breaks a lot of the existing code. However, we can at least make sure that our in-core sentinel representation never makes it to disk. To be thorough, we will test an attempt to add both a blob and a submodule entry. In the former case, we might run into problems anyway because we will be missing the blob object. But in the latter case, we do not enforce connectivity across gitlink entries, making this our only point of enforcement. The current implementation does not care which type of entry we are seeing, but testing both cases helps future-proof the test suite in case that changes. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

Merge branch 'tg/ce-namelen-field'

2012-07-24T03:55:21Z

Split lower bits of ce_flags field and creates a new ce_namelen field in the in-core index structure. * tg/ce-namelen-field: Strip namelen out of ce_flags into a ce_namelen field

Merge branch 'tg/maint-cache-name-compare'

2012-07-16T04:40:18Z

Even though the index can record pathnames longer than 1<<12 bytes, in some places we were not comparing them in full, potentially replacing index entries instead of adding. * tg/maint-cache-name-compare: cache_name_compare(): do not truncate while comparing paths

Strip namelen out of ce_flags into a ce_namelen field

2012-07-11T16:42:45Z

Strip the name length from the ce_flags field and move it into its own ce_namelen field in struct cache_entry. This will both give us a tiny bit of a performance enhancement when working with long pathnames and is a refactoring for more readability of the code. It enhances readability, by making it more clear what is a flag, and where the length is stored and make it clear which functions use stages in comparisions and which only use the length. It also makes CE_NAMEMASK private, so that users don't mistakenly write the name length in the flags. Signed-off-by: Thomas Gummerer Signed-off-by: Junio C Hamano

Merge branch 'tg/maint-cache-name-compare' into tg/ce-namelen-field

2012-07-11T16:40:25Z

* tg/maint-cache-name-compare: cache_name_compare(): do not truncate while comparing paths

cache_name_compare(): do not truncate while comparing paths

2012-07-11T16:25:56Z

We failed to use ce_namelen() equivalent and instead only compared up to the CE_NAMEMASK bytes by mistake. Adding an overlong path that shares the same common prefix as an existing entry in the index did not add a new entry, but instead replaced the existing one, as the result. Signed-off-by: Junio C Hamano