RFA: untracked cache vs git reset --hard

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi all,

I have a problem and would like to solicit advice how to fix it.

The untracked cache has made a real difference on rather large
repositories with tons of directories, and it is really, really useful.

But. One innocuous `git reset --hard` will just blow it away.

How? reset_index() calls unpack_trees() which in turn tries to populate a
new index and then discards the old one:

	https://github.com/git/git/blob/v2.12.2/unpack-trees.c#L1293

That discard_index() unfortunately also blows away each and every index
extension that had been read carefully before.

All users of `git reset --hard` (including `git stash`) suffer this.

In fact, it looks as if *any* caller of unpack_trees() would suffer the
same problem: git-am, git-checkout, git-commit, git-merge, etc

Now, I could imagine that maybe we could just "move"
o->dst_index.untracked to o->result.untracked, and that the machinery then
would do the right thing.

However, I am far from an expert in this area, so I would appreciate all
the helpful advice I could get.

Thoughts?

Thanks,
Johannes



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]