git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jonathan Nieder <jrnieder@gmail.com>
To: Nguyen Thai Ngoc Duy <pclouds@gmail.com>
Cc: Git Mailing List <git@vger.kernel.org>,
	Christian Couder <chriscool@tuxfamily.org>
Subject: Re: replaced objects and working directory
Date: Sun, 25 Jul 2010 01:02:07 -0500	[thread overview]
Message-ID: <20100725060207.GA17601@burratino> (raw)
In-Reply-To: <AANLkTi=3=MX8+U4Oq4q_RACyxFYj-HmBYXFBxxQdFf_e@mail.gmail.com>

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

      reply	other threads:[~2010-07-25  6:03 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-25  4:20 replaced objects and working directory Nguyen Thai Ngoc Duy
2010-07-25  6:02 ` Jonathan Nieder [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100725060207.GA17601@burratino \
    --to=jrnieder@gmail.com \
    --cc=chriscool@tuxfamily.org \
    --cc=git@vger.kernel.org \
    --cc=pclouds@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).