Closed squaresurf closed 10 years ago
Very nice! I'll have a look at it in the weekend.
I was thinking about rewriting your code later on at some point to simply run directly on the output of ls-files
to reduce complexity - it would require the linking loop to have some kind of advanced mkdir -p
that still respects the linking table, but then I started to think about #77 and how that would be implemented in that case.
Your approach is definitely the simplest and the one that is more readily extensible, especially because we could implement the filtering mechanism in get_repo_files
.
I'm glad it worked out. I was definitely thinking about #77 while I was coding this. Which issue(s) would you like to see done next?
Which issue(s) would you like to see done next?
Heh, I like that question. Fixing #96 would definitely be helpful if we decide to implement some changes that break backwards compatibility.
Sweet. I'll work on that next when I get some time. Not sure when that'll be exactly though. No worries if you get to it first.
Besides adding a test for this feature, I also had to update some existing tests slightly.
First I had to make sure that tests that modify their test repo, also commit to that test repo. Otherwise the linking function wouldn't do anything since git ignores files not added to the repo.
Secondly, I had to modify the 'fail when linking file with newline' test to look for symlinks with double quotes since that is how they are returned by
git ls-files
which brings up the point that we could now support filenames with newlines in them.git ls-files
wraps such filenames in quotes like:"subdir/filename_with\nnewline"
That being said I'm not sure of the usefulness of newlines in filenames.