From: David Turner <dturner@twopensource.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Jeff King <peff@peff.net>, Elijah Newren <newren@gmail.com>,
git mailing list <git@vger.kernel.org>
Subject: Re: git reset for index restoration?
Date: Thu, 22 May 2014 19:02:26 -0400 [thread overview]
Message-ID: <1400799746.18134.48.camel@stross> (raw)
In-Reply-To: <xmqqwqddla63.fsf@gitster.dls.corp.google.com>
On Thu, 2014-05-22 at 15:29 -0700, Junio C Hamano wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
> > But at least my understanding has been that "git commit" (no partial
> > commit, write the whole index as a commit) which uses the "git
> > write-tree" machinery knows which subtree has what tree object name
> > and populates the cache-tree fully.
>
> Here is what I tried just now.
>
> $ rm .git/index
> $ git read-tree HEAD HEAD
>
> Note that a single-tree read-tree will populate the cache-tree and
> that is why I am forcing "switch branches" 2-way read-tree here,
> which I know will discard the cache-tree fully.
>
> $ ls -l .git/index
> -rw-r----- 1 jch eng 249440 May 22 15:20 .git/index
> $ git checkout HEAD^0
> $ ls -l .git/index
> -rw-r----- 1 jch eng 249440 May 22 15:21 .git/index
>
> Still the same size, without cache-tree.
>
> $ git write-tree
> 57361c4add61b638dad1c1c2542edf877f515c48
> $ ls -l .git/index
> -rw-r----- 1 jch eng 254383 May 22 15:21 .git/index
>
> The size differences come from the recomputation of the cache tree.
> The result is the same if we replace "git write-tree" with a
> whole-index commit, e.g.
>
> $ git commit --allow-empty -m foo
>
> and test-dump-cache-tree seem to see a fully populated cache-tree
> after these steps.
I get the same results as you with git write-tree. But I do not get the
same results from a whole-index git commit (I tried your exact
command-line). That is, when I do git commit with no cache-tree in
place, it does not create one.
To expand: even if git commit did work for me the way it seems to work
for you, I still believe that the cache-tree behavior would be
suboptimal, because every time a user switches branches, they lose their
cache-tree, and thus all of their git status commands are slow until
their first commit. But I am willing to believe that my workflow is
atypical, and that most people commit enough soon after switching
branches.
next prev parent reply other threads:[~2014-05-22 23:02 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-22 16:22 git reset for index restoration? David Turner
2014-05-22 16:46 ` Jeff King
2014-05-22 18:08 ` David Turner
2014-05-22 18:23 ` Jeff King
2014-05-22 19:26 ` David Turner
2014-05-22 16:46 ` Elijah Newren
2014-05-22 18:17 ` David Turner
2014-05-22 18:39 ` Jeff King
2014-05-22 19:07 ` David Turner
2014-05-22 19:09 ` Jeff King
2014-05-22 19:30 ` Jeff King
2014-05-22 21:34 ` Junio C Hamano
2014-05-22 21:53 ` David Turner
2014-05-22 21:58 ` Junio C Hamano
2014-05-22 22:01 ` David Turner
2014-05-22 22:12 ` Junio C Hamano
2014-05-22 22:18 ` Junio C Hamano
2014-05-22 23:33 ` Duy Nguyen
2014-05-22 23:37 ` David Turner
2014-05-22 22:29 ` Junio C Hamano
2014-05-22 23:02 ` David Turner [this message]
2014-05-22 23:14 ` Junio C Hamano
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=1400799746.18134.48.camel@stross \
--to=dturner@twopensource.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=newren@gmail.com \
--cc=peff@peff.net \
/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).