bdowning@xxxxxxxxx (Brian Downing) writes:
> However, that commit looks like it's solving a different problem
> entirely (supporting changing between two branches where .gitattributes
> exists in both cases) and happens to fix the no .gitattributes -> read
> from index regression at the same time. I don't know enough about the
> guts to tell, but does this also fix the core problem of the regression
> (I assume something about trying to read from the wrong index, given the
> commit that broke it), or does it just happen to work around it?
Actually the commit solves both.
Notice that the second hunk of the patch to unpack-trees passes o->result
to the new git_attr_set_direction() function to tell it to read from the
new index, instead of reading from the wrong one. In addition, by setting
the direction to CHECKOUT, it favors to read the attribute data from the
index over from the work tree.
Note that this is merely a "good enough" approximation and arguing that we
should only read from the in-index attributes during checkout (and read
only from work tree attributes during checkin) is futile. Look at other
thread with Kristian Amlie for details.
diff --git a/unpack-trees.c b/unpack-trees.c
index e547282..661218c 100644
--- a/unpack-trees.c
+++ b/unpack-trees.c
@@ -105,6 +106,7 @@ static int check_updates(struct unpack_trees_options *o)
cnt = 0;
}
+ git_attr_set_direction(GIT_ATTR_CHECKOUT, &o->result);
for (i = 0; i < index->cache_nr; i++) {
struct cache_entry *ce = index->cache[i];
--
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
