Revision b3f01ff29f7131e959bcfdfd004744d74d5fa319 authored by Junio C Hamano on 01 March 2012, 02:14:16 UTC, committed by Junio C Hamano on 01 March 2012, 20:00:01 UTC
The plumbing "diff" commands look at the working tree files without refreshing the index themselves for performance reasons (the calling script is expected to do that upfront just once, before calling one or more of them). In the early days of git, they showed the "diff --git" header before they actually ask the xdiff machinery to produce patches, and ended up showing only these headers if the real contents are the same and the difference they noticed was only because the stat info cached in the index did not match that of the working tree. It was too late for the implementation to take the header that it already emitted back. But 3e97c7c (No diff -b/-w output for all-whitespace changes, 2009-11-19) introduced necessary logic to keep the meta-information headers in a strbuf and delay their output until the xdiff machinery noticed actual changes. This was primarily in order to generate patches that ignore whitespaces. When operating under "-w" mode, we wouldn't know if the header is needed until we actually look at the resulting patch, so it was a sensible thing to do, but we did not realize that the same reasoning applies to stat-dirty paths. Later, 296c6bb (diff: fix "git show -C -C" output when renaming a binary file, 2010-05-26) generalized this machinery and added must_show_header toggle. This is turned on when the header must be shown even when there is no patch to be produced, e.g. only the mode was changed, or the path was renamed, without changing the contents. However, when it did so, it still kept the special case for the "-w" mode, which meant that the plumbing would keep showing these phantom changes. This corrects this historical inconsistency by allowing the plumbing to omit paths that are only stat-dirty from its output in the same way as it handles whitespace only changes under "-w" option. The change in the behaviour can be seen in the updated test. Signed-off-by: Junio C Hamano <gitster@pobox.com>
1 parent 5597e84
hash.h
#ifndef HASH_H
#define HASH_H
/*
* These are some simple generic hash table helper functions.
* Not necessarily suitable for all users, but good for things
* where you want to just keep track of a list of things, and
* have a good hash to use on them.
*
* It keeps the hash table at roughly 50-75% free, so the memory
* cost of the hash table itself is roughly
*
* 3 * 2*sizeof(void *) * nr_of_objects
*
* bytes.
*
* FIXME: on 64-bit architectures, we waste memory. It would be
* good to have just 32-bit pointers, requiring a special allocator
* for hashed entries or something.
*/
struct hash_table_entry {
unsigned int hash;
void *ptr;
};
struct hash_table {
unsigned int size, nr;
struct hash_table_entry *array;
};
extern void *lookup_hash(unsigned int hash, const struct hash_table *table);
extern void **insert_hash(unsigned int hash, void *ptr, struct hash_table *table);
extern int for_each_hash(const struct hash_table *table, int (*fn)(void *));
extern void free_hash(struct hash_table *table);
static inline void init_hash(struct hash_table *table)
{
table->size = 0;
table->nr = 0;
table->array = NULL;
}
#endif
![swh spinner](/static/img/swh-spinner.gif)
Computing file changes ...