mirrors/jgit - jgit - source @ dussan.org

Christian Halstrick ffa237e7db Fix computation of id in WorkingTreeIterator with autocrlf and smudging JGit failed to do checkouts when the index contained smudged entries and autocrlf was on. In such cases the WorkingTreeIterator calculated the SHA1 sometimes on content which was not correctly filtered. The SHA1 was computed on content which two times went through a lf->crlf conversion. We used to tell the treewalk whether it is a checkin or checkout operation and always use the related filters when reading any content. If on windows and autocrlf is true and we do a checkout operation then we always used a lf->crlf conversion on any text content. That's not correct. Even during a checkout we sometimes need the crlf->lf conversion. E.g. when calculating the content-id for working-tree content we need to use crlf->lf filtering although the overall operation type is checkout. Often this bug does not have effects because we seldom compute the content-id of filesystem content during a checkout. But we do need to know whether a file is dirty or not before we overwrite it during a checkout. And if the index entries are smudged we don't trust the index and compute filesystem-content-sha1's explicitly. This caused EGit not to be able to switch branches anymore on Windows when autocrlf was true. EGit denied the checkout because it thought workingtree files are dirty because content-sha1 are computed on wrongly filtered content. Bug: 493360 Change-Id: I1072a57b4c529ba3aaa50b7b02d2b816bb64a9b8 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>	8 years ago
..
eclipse/jgit	Fix computation of id in WorkingTreeIterator with autocrlf and smudging	8 years ago

Christian Halstrick ffa237e7db Fix computation of id in WorkingTreeIterator with autocrlf and smudging

JGit failed to do checkouts when the index contained smudged entries and
autocrlf was on. In such cases the WorkingTreeIterator calculated the
SHA1 sometimes on content which was not correctly filtered. The SHA1 was
computed on content which two times went through a lf->crlf conversion.

We used to tell the treewalk whether it is a checkin or checkout
operation and always use the related filters when reading any content.
If on windows and autocrlf is true and we do a checkout operation then
we always used a lf->crlf conversion on any text content. That's not
correct. Even during a checkout we sometimes need the crlf->lf
conversion. E.g. when calculating the content-id for working-tree
content we need to use crlf->lf filtering although the overall operation
type is checkout.

Often this bug does not have effects because we seldom compute the
content-id of filesystem content during a checkout. But we do need to
know whether a file is dirty or not before we overwrite it during a
checkout. And if the index entries are smudged we don't trust the index
and compute filesystem-content-sha1's explicitly.

This caused EGit not to be able to switch branches anymore on Windows
when autocrlf was true. EGit denied the checkout because it thought
workingtree files are dirty because content-sha1 are computed on wrongly
filtered content.

Bug: 493360
Change-Id: I1072a57b4c529ba3aaa50b7b02d2b816bb64a9b8
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>

8 years ago

eclipse/jgit

Fix computation of id in WorkingTreeIterator with autocrlf and smudging

8 years ago