Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jgit-dev] Extend DirCacheCheckout to skip conflicts

Christian,

thanks for your confirmation. I am aware that failOnConflict is true in this case. My sole intention was to get confirmation that DirCacheCheckout offers two ways of dealing with conflicts, and both need to be addressed in order to get this bug resolved. 

I don't intend to delete unsaved working files, rather the opposite, this is why I work on the skipConflicts extension. And getting back to the original matter, how could we proceed so that the bug gets fixed and the skipConflicts patch can eventually be applied? I would prefer if someone with a better understanding of DirCacheCheckout than I have could fix the bug.

Best,
Rüdiger



From: Christian Halstrick <christian.halstrick@xxxxxxxxx>
To: R�diger Herrmann <ruediger.herrmann@xxxxxx>
Cc: JGit Developers List <jgit-dev@xxxxxxxxxxx>
Sent: Wednesday, June 15, 2016 9:25 AM
Subject: 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?



Back to the top