Prevent clean files from showing up as untracked #601
Conversation
Looking at the code in porcelain.path_to_tree_path, this looks like there was an attempt at this in 85b5383, however relpath is non-destructive, and has no effect unless the result is assigned to something. If this were assigned when path is relative, then relpath would assume path was at root, and so we must check that the path is absolute before calling relpath. Fixes jelmer#598
alistair-broomhead
force-pushed
the
598-status-shows-all-files-untracked
branch
from
5a577ec
to
d9f3de5
Compare
Codecov Report
@@ Coverage Diff @@
## master #601 +/- ##
==========================================
- Coverage 90.97% 90.94% -0.04%
==========================================
Files 73 73
Lines 18470 18316 -154
Branches 1977 1961 -16
==========================================
- Hits 16803 16657 -146
+ Misses 1265 1260 -5
+ Partials 402 399 -3
Continue to review full report at Codecov.
|
|
Rebased on top of current master to check for conflicts (there were none) |
| :param path: A path | ||
| :return: A path formatted for use in e.g. an index | ||
| """ | ||
| os.path.relpath(path, repopath) | ||
| if os.path.isabs(path): |
There was a problem hiding this comment.
"path" will be relative to os.getcwd(), so I think we should unconditionally call relpath since path_to_tree_path should return the relative path to the repository.
There was a problem hiding this comment.
Sorry it's been a few months so I can't quite remember, but when I was testing this it seemed like in some cases this function receives an absolute path. This was in fact responsible for #598 as it was seeing these clean files from the repo as not being the same as the files from the listing, and so did not think they were tracked. I'd need to look at what's happened in the code since January, but this was definitely a false assumption back then, and so needed testing in the code. It's also possible that the calling code is what's at fault, and that the fix belongs elsewhere. I have to admit I was somewhat surprised to see #600 accepted so quickly but this not, given the comparative levels of complexity and scope,
It looks like there may need to be some communication with @r0mainK from #635 as there are some functional changes here and some ruggedisation there, and it would be good to make sure that both of these are done without losing one or the other.
|
See also #601 |
jelmer
force-pushed
the
master
branch
2 times, most recently
from
f1ae053
to
cd30df4
Compare
Looking at the code in porcelain.path_to_tree_path, this looks like there was an attempt at this in 85b5383, however relpath is non-destructive, and has no effect unless the result is assigned to something. If this were assigned when path is relative, then relpath would assume path was at root, and so we must check that the path is absolute before calling relpath.
Fixes #598