Issues with higher-order stages in dircache

quoted

quoted

quoted

quoted

"JCH" == Junio C Hamano [off-list ref] writes:

JCH> So what's next?

Here is my current thinking on the impact your higher-order
stage dircache entries would have to the rest of the system and
how to deal with them.

 * read-tree

   - When merging two trees, i.e. "read-tree -m A B", shouldn't
     we collapse identical stage-1/2 into stage-0?

 * update-cache

   - 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).

   - "update-cache --refresh" should just ignore a path that has
     not been merged,  Maybe say "needs merge", just like "needs
     update" [*1*].

   - "update-cache --cacheinfo" should get an extra "stage"
     argument.  Unmerged state is typically produced by running
     "read-tree -m", but the user or Cogito can do it by hand
     with this if he wanted to.

   - I do not think we need a separate "remove the entry for
     this path at this stage" thing.  That is only necessary if
     the user or Cogito is doing things by hand (as opposed to
     "read-tree -m"), which should be a very rare case.  He can
     always do "update-cache --remove" followed by "update-cache
     --cacheinfo" to obtain the desired result if he really
     wanted to.  For that, "update-cache --force-remove" may
     come in handy.

 * show-diff

   - What should we do about unmerged paths?  Showing diffs
     between the combinations (1->2), (1->3), and (2->3) that
     exist may not be a bad idea.  It would not be confusing
     because by definition dircache with higher-order stages is
     a merge temporary directory and the user should not have a
     working file there to begin with.

     I think the current implementation does a very bad thing:
     repeating the same diff as many times as it has
     higher-order stages for the same path.

 * checkout-cache

   - When checkout-cache is run with explicit paths that are
     unmerged, what should we do?  What does that mean in the
     first place?  One use scenario I can think of is that the
     user or Cogito wants the contents at all three stages, in
     order to run a merge tool on them.  From this point of
     view, checking out all the available stages for the path
     makes sense.

     My "cunning plan" is to drop ".1-$file", ".2-$file", and
     ".3-$file" in the working directory.  How does that sound?

   - When checkout-cache -a is run, presumably the user wants to
     check out everything to verify (e.g. build-test) the
     result.  In this case, we should skip unmerged paths, give
     a warning, and check out only the merged ones.


[Footnotes]

*1* Unrelated note.  Who is the intended consumer of this "needs
    update" message?  Should we make it machine readable with
    '-z' flag as well?  Otherwise, shouldn't it go to stderr?
    Currently it goes to stdout.