Re: "git-checkout-cache -f -a" failure

>>>>> "PB" == Petr Baudis <pasky@ucw.cz> writes:

PB> What if you have some files not tracked by git in the subdirectory?
PB> Either you need to check for this and deal with it (Cogito's approach
PB> would be to remove the git-tracked files and rename the subdirectory),
PB> or not do it at all.

Let me understand you correctly.  You "rename the subdirectory"
because the cache you want to check out records a non-directory
there.  Is this correct?  When do you "remove the git-tracked
files"?  Do you mean "if a file that is not tracked (in the
user's mind) is there in the filesystem, and the cache to be
checked out has a file there, the file on the filesystem is
removed"?  What happens if an existing non-directory interferes
with a directory to be checked out from the cache?

I think the right thing for the core GIT layer to do, when the
end user is using the Plumbing tools directly and says "really
please" by specifying an '-f', is to make the checkout succeed
by removing conflicting stuff, as my fixed patch does.

If the Porcelain runs checkout-cache on the user's behalf, the
story is a bit different.  Porcelain would have some idea of
what GIT tree the files in the working directory originated from
("the last commit", or "my head before the read-tree -m merge")
before the user started working in it.  When the user wants to
update the work tree to match a cache (which may be quite
different from "the last commit", if it is coming from cg-seek
or result of a merge), the Porcelain knows:

 - the set of non git-tracked (from the point of view from "the
   last commit") files that are in the work tree;

 - among those, the set of files that would be overwritten by
   this checkout.  This includes, but not limited to, the files
   that would otherwise interfere because of file-directory
   conflicts.

And then you can set aside those "to-be-overwritten" files,
remove them from the filesystem, and run your checkout.

The determination of which files to set aside should not be done
based on whether they cause file-directory conflicts.  If the
user has a non-tracked file which happens to be registered as a
tracked file in the cache to be checked out (e.g. after a
three-way merge), that file is as valuable as a non-tracked file
that is in a subdirectory that the new cache happens to have as
a non-directory.  Losing the former is as harmful as losing the
latter.  From what you say above, it sounds like you are saving
the latter but not the former, but my readins of what you wrote
above may be mistaken.

-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html