Nguyen Thai Ngoc Duy wrote:
> Should worktree (or the index) be aware of replaced objects?
The following is only about replaced blobs (replaced trees are
harder to deal with, I think).
Two uses to keep in mind:
1. "git checkout", "git diff", and so on to explore the
tweaked history (as you mentioned).
2. "git write-tree" as used by filter-branch to set the
new history in stone.
1) Currently read-tree does not do anything special with replaced
blobs; it is up to checkout-index to get the substituted blob object
and write a different file to disk. Unfortunately when update-index
tries to read it back, that means it looks like the file has changed.
> Maybe "git status" and similar operations should also
> check worktree version against the replaced version, in addition to
> the original version?
It might be simpler to check against only the replaced version, like
this:
| diff --git i/read-cache.c w/read-cache.c
| index f1f789b..0f031da 100644
| --- i/read-cache.c
| +++ w/read-cache.c
| @@ -93,7 +93,7 @@ static int ce_compare_data(struct cache_entry *ce, struct stat *st)
| if (fd >= 0) {
| unsigned char sha1[20];
| if (!index_fd(sha1, fd, st, 0, OBJ_BLOB, ce->name))
| - match = hashcmp(sha1, ce->sha1);
| + match = hashcmp(sha1, lookup_replace_object(ce->sha1));
| /* index_fd() closed the file descriptor already */
| }
| return match;
| @@ -134,7 +134,7 @@ static int ce_compare_gitlink(struct cache_entry *ce)
| */
| if (resolve_gitlink_ref(ce->name, "HEAD", sha1) < 0)
| return 0;
| - return hashcmp(sha1, ce->sha1);
| + return hashcmp(sha1, lookup_replace_object(ce->sha1));
| }
|
| static int ce_modified_check_fs(struct cache_entry *ce, struct stat *st)
| @@ -232,7 +232,7 @@ static int ce_match_stat_basic(struct cache_entry *ce, struct stat *st)
|
| /* Racily smudged entry? */
| if (!ce->ce_size) {
| - if (!is_empty_blob_sha1(ce->sha1))
| + if (!is_empty_blob_sha1(lookup_replace_object(ce->sha1)))
| changed |= DATA_CHANGED;
| }
|
The main downside is that if you remove and re-add an index entry,
this is no longer a no-op. But I think that getting "update-index
--refresh" to be content should be enough to make exploring the
alternate objects bearable.
2) write-tree trusts the index as far as blobs go and rewrites all
the trees itself. Probably it should dereference replace refs for
replaced blobs, which would make the "rewriting everything" behavior
more consistent.
| diff --git i/cache-tree.c w/cache-tree.c
| index d917437..43d5030 100644
| --- i/cache-tree.c
| +++ w/cache-tree.c
| @@ -324,7 +324,7 @@ static int update_one(struct cache_tree *it,
| mode = S_IFDIR;
| }
| else {
| - sha1 = ce->sha1;
| + sha1 = lookup_replace_object(ce->sha1);
| mode = ce->ce_mode;
| entlen = pathlen - baselen;
| }
I once had plans for these two tasks and time ran out.
http://thread.gmane.org/gmane.comp.version-control.git/139204/focus=139222
Hope that helps,
Jonathan
--
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