ok, makes sense. Then I'll provide a patch. The test case which you
CheckoutConflictException. But what's your expectation if
src/ and the branch to checkout contains a file src. Should we really
On Wed, Jun 15, 2016 at 6:26 PM, R�diger Herrmann
<
ruediger.herrmann@xxxxxx> wrote:
> 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?
>
>
