Re: Issues with higher-order stages in dircache
Linus, earlier I wrote [*R1*]: - An explicit update-cache [--add] [--remove] path should be taken as a signal from the user (or Cogito) to tell the dircache layer the merge is done and here is the result. So just delete higher-order stages for the path and record the specified path at stage 0 (or remove it altogether). and I think this commit of yours implements the adding half. commit be7b1f05cea8e5213ffef8f74ebdefed2aacb6fc:1 author Linus Torvalds [EMAIL PROTECTED] 1113678345 -0700 committer Linus Torvalds [EMAIL PROTECTED] 1113678345 -0700 When inserting a index entry of stage 0, remove all old unmerged entries. I am wondering if you have a particular reason not to do the same for the removing half. Without it, currently I do not see a way for the user or Cogito to tell dircache layer that the merge should result in removal. That is, other than first adding a phony entry there (which brings the entry down to stage 0) and then immediately doing a regular update-cache --remove. That is two instead of one reading of 1.6MB index file for the kernel case. Also do you have any comments on this one from the same message? * read-tree - When merging two trees, i.e. read-tree -m A B, shouldn't we collapse identical stage-1/2 into stage-0? [References] *R1* http://marc.theaimsgroup.com/?l=gitm=111366023126466w=2 - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Issues with higher-order stages in dircache
On Sat, 16 Apr 2005, Junio C Hamano wrote: I am wondering if you have a particular reason not to do the same for the removing half. No. Except for me being silly. Please just make it so. Also do you have any comments on this one from the same message? * read-tree - When merging two trees, i.e. read-tree -m A B, shouldn't we collapse identical stage-1/2 into stage-0? How do you actually intend to merge two trees? That sounds like a total special case, and better done with diff-tree. But regardless, since I assume the result is the later tree, why do a read-tree -m A B, since what you really want is read-tree B? The real merge always needs the base tree, and I'd hate to complicate the real merge with some special-case that isn't relevant for that real case. Linus - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
