On Mon, Feb 20, 2012 at 9:36 PM, Nguyen Thai Ngoc Duy <pclouds@xxxxxxxxx> wrote:
> On Mon, Feb 20, 2012 at 03:09:57PM +0100, Thomas Rast wrote:
>> > Interestingly, on my git.git repo, I had an empty cache. Running "git
>> > read-tree HEAD" filled it (according to test-dump-cache-tree). It seems
>> > that running "git checkout" empties the cache. So perhaps git could do
>> > better about keeping the cache valid over time.
>>
>> test_expect_failure 'checkout gives cache-tree' '
>> git checkout HEAD^ &&
>> test_shallow_cache_tree
>> '
>>
>> ;-)
>
> Quick and dirty that passes that test.
I'm aware that Jeff's tackling at lower level, which retains
cache-tree for many more cases. But this patch seems simple and safe
to me, and in my experience this case happens quite often (or maybe I
tend to keep my index clean). Junio, any chance this patch may get in?
> -- 8< --
> diff --git a/builtin/checkout.c b/builtin/checkout.c
> index 5bf96ba..c06287a 100644
> --- a/builtin/checkout.c
> +++ b/builtin/checkout.c
> @@ -319,6 +319,10 @@ static void show_local_changes(struct object *head, struct diff_options *opts)
> die(_("diff_setup_done failed"));
> add_pending_object(&rev, head, NULL);
> run_diff_index(&rev, 0);
> + if (!DIFF_OPT_TST(&rev.diffopt, HAS_CHANGES)) {
> + struct tree *tree = parse_tree_indirect(head->sha1);
> + prime_cache_tree(&active_cache_tree, tree);
> + }
> }
>
> static void describe_detached_head(const char *msg, struct commit *commit)
> @@ -493,13 +497,13 @@ static int merge_working_tree(struct checkout_opts *opts,
> }
> }
>
> + if (!opts->force && !opts->quiet)
> + show_local_changes(&new->commit->object, &opts->diff_options);
> +
> if (write_cache(newfd, active_cache, active_nr) ||
> commit_locked_index(lock_file))
> die(_("unable to write new index file"));
>
> - if (!opts->force && !opts->quiet)
> - show_local_changes(&new->commit->object, &opts->diff_options);
> -
> return 0;
> }
>
> -- 8< --
> --
> Duy
--
Duy
--
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