From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxxxxxxxx>
Date: Sat, 22 Mar 2008 09:48:41 -0700
This is immaterial on sane filesystems, but if you have a broken (aka
case-insensitive) filesystem, and the objective is to remove the file
'abc' and replace it with the file 'Abc', then we must make sure to do
the removal first.
Otherwise, you'd first update the file 'Abc' - which would just
overwrite the file 'abc' due to the broken case-insensitive filesystem -
and then remove file 'abc' - which would now brokenly remove the just
updated file 'Abc' on that broken filesystem.
By doing removals first, this won't happen.
Signed-off-by: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
---
Ok, this one looks - and is, really - trivial, but it's actually the only
one in the whole series that I'm even remotely nervous about. First off,
it actually does what it does regardless of that "core.ignorecase"
variable, but that wouldn't worry me if it wasn't for the fact that I
don't remember/understand what the heck that "last_symlink" logic was
there for.
I *think* the logic is only for removal, and that splitting up the single
loop to be two loops is totally safe and actually cleans things up, but I
really want somebody to take a look at this.
This patch is important, because without it you can't reliably switch
between branches with case-aliases on a case-insensitive filesystem, and
strictly speaking I should have put it before the previous patch, but I
put it last because of this worry of mine. Patches 1-6 I think are totally
obvious and ready to go at any point. This one I really want Junio to
double-check.
The patch itself is really really trivial. We used to do both removal and
file updates in one phase, we just split it into two. So I don't worry
about the code, I only worry about that "last_symlink" thing.
Anyway, this concludes the series. It's not _complete_ - the
case-independent compare function is a joke and only gets US-ASCII
correct, and there are other cases we will want to fix up. But in the end,
I think this series of seven trivial patches really does make git somewhat
aware of broken filesystems at a very core level.
unpack-trees.c | 9 +++++++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/unpack-trees.c b/unpack-trees.c
index 95d3413..feae846 100644
--- a/unpack-trees.c
+++ b/unpack-trees.c
@@ -79,16 +79,21 @@ static int check_updates(struct unpack_trees_options *o)
for (i = 0; i < index->cache_nr; i++) {
struct cache_entry *ce = index->cache[i];
- if (ce->ce_flags & (CE_UPDATE | CE_REMOVE))
- display_progress(progress, ++cnt);
if (ce->ce_flags & CE_REMOVE) {
+ display_progress(progress, ++cnt);
if (o->update)
unlink_entry(ce->name, last_symlink);
remove_index_entry_at(&o->result, i);
i--;
continue;
}
+ }
+
+ for (i = 0; i < index->cache_nr; i++) {
+ struct cache_entry *ce = index->cache[i];
+
if (ce->ce_flags & CE_UPDATE) {
+ display_progress(progress, ++cnt);
ce->ce_flags &= ~CE_UPDATE;
if (o->update) {
errs |= checkout_entry(ce, &state, NULL);
--
1.5.5.rc0.28.g61a0.dirty
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
