replaced objects and working directory

replaced objects and working directory

[Nguyen Thai Ngoc Duy]

Hi,

Should worktree (or the index) be aware of replaced objects? It seems
a bit odd to do "git checkout HEAD^" then "git status" reports
modification. Maybe "git status" and similar operations should also
check worktree version against the replaced version, in addition to
the original version?

$ git init
$ echo 1 > 1
$ git add 1
$ SHA1=`git hash-object 1`
$ git ci -m 1
$ echo 2 >> 1
$ git add 1
$ git ci -m 2
$ SHA2=`git hash-object 1`
$ git replace $SHA1 $SHA2
$ git st
# On branch master
nothing to commit (working directory clean)
$ git co HEAD^
$ git st
# Not currently on any branch.
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified:   1
#
no changes added to commit (use "git add" and/or "git commit -a")
$ git di
diff --git a/1 b/1
index d00491f..1191247 100644
-- 
Duy

Re: replaced objects and working directory

[Jonathan Nieder]

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