>>>>> "JCH" == Junio C Hamano <[EMAIL PROTECTED]> 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.
-
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
