[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jgit-dev] Extend DirCacheCheckout to skip conflicts
|
On Tue, Jun 14, 2016 at 7:15 PM, R�diger Herrmann
<ruediger.herrmann@xxxxxx> wrote:
> My understanding, in this case, is that a CheckoutConflictException should
> only be thrown if setFailOnConflict() was set to true. Otherwise, the local
> file f should be overridden like it is the case in other conflict
> situations. Or am I missing something here?
yes, you are right. But in the test case you wrote failOnConflict is
set to true because true is the default value for failOnConflict. If
you look for references of setFailOnConflict you see that in the
majority of cases we use setFailOnConflict(true).
setFailOnConflict(false) leads to a behavior where jgit is allowed to
delete potentially unsaved files from the users working tree. I think
also native git takes a lot of care not to do this unless it is
explicitly requested by the user. If the user calls "git clean " or
"git reset --hard " then I expect native git to be allowed to
delete/overwrite unsaved content from the filesystem. But when I do
"git checkout ..." then git should be careful that I don't loose
unsaved content. See
https://git-scm.com/docs/git-read-tree#_two_tree_merge and search
where "clean" is false to see what we are allowed to do with dirty
files e.g. during a checkout.
Maybe in your case you know exactly that you are allowed to delete
unsaved content and then failOnConflict(true) is ok for you. And then
DircacheCheckout should delete the file or the folder hierarchy
silently. Imagine you have a workingtree folder src/ with a lot of
sources and now you checkout a branch where there is a file "src". Do
you really want to delete the whole src folder with all the files in
it?
