Re: Git no longer reads attributes from the index properly
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Mar 20, 2009, 10:16 UTC
- Message-ID
- <7v4oxojy7m.fsf@gitster.siamese.dyndns.org>
- In-Reply-To
- <20090320084031.GD1037@lavos.net>
bdowning@lavos.net (Brian Downing) writes:
Show 7 quoted lines
> 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];