Support traversal of git folders below the castle root

[andsens]

As discussed in #93 it can be very useful at times to fiddle with .git repos by using homeshick. To do that homeshick needs to stop skipping files and folders named .git when linking.

However, some things still need to be skipped:

• The .git folder in the root of a castle, since that is a folder managed by git and not the user
• The .git files in submodules of a repo
• The .git folders in submodules of a repo for older git versions (if I remember correctly git switched to just managing all submodules in the .git folder of the root repository, so we need the git version where that changed)

[andsens]

The tests for this addition need to be very thorough since a bug in the handling of this could screw things up in all kinds of ways. To put it differently: The detection of when a .git folder is something that was created by the user and when it was created by git must be 100% accurate.

[andsens]

Hold on, this is actually really simple.

• The root folder won't ever be traversed because it's not in home/
• To exclude .git files only the find command should be changed to find . -mindepth 1 -name .git -a -type f -prune -o -print
• For git versions that still use the .git folder in submodules we simply fall back to the old find command, anything else would just be too complicated

The questions remaining are:

• In what git version where those .git folders replaced with files pointing at the root?
• Does the existence of those .git folders depend on the current git version or the git version the repo was created with?

[squaresurf]

Off the top of my head I think that .git folders for submodules were moved to the parent .git folder in git 1.7.8. I could be wrong though. https://jira.atlassian.com/browse/SRCTREE-837

I will keep searching though.

[squaresurf]

It does seem like it is 1.7.8:

• http://stackoverflow.com/questions/15346296/git-folder-for-submodules
• https://github.com/git/git/blob/master/Documentation/RelNotes/1.7.8.txt

The one thing that I see in the release notes though is that it seems that this behavior only applies to submodules added with 1.7.8 or greater. If I read that correctly that means that a repo created with a version less than 1.7.8 while using a version of git 1.7.8 or greater could indeed have the .git directories within the submodules. Am I reading that incorrectly?

[andsens]

Oh boy, yup I get to the same conclusion. I don't think there's a way to figure out with which version a git submodule was added. As far as I can see the only way to get around this, is to filter out all the submodule .git folder paths.

EDIT: p.s. good job on finding the version :-)

[andsens]

Come to think of it, this might actually be related to another feature I have been thinking of and may make things easier.
gitignored files should not be symlinked. .git files and folders (that is, the ones created by git) are ignored by git. A simple git check-ignore on the path that we are trying to link (like we do in track) would resolve all our problems!

[squaresurf]

Thats a great idea. Do you want that feature to be its own github issue and we'll link from it here? Or should we just implement that tied to this issue?

[andsens]

I created a new issue for it (#95). It's always better to track individual changes like this, so we can reference them in the future, should there be any problems with the feature or extensions to it.

[squaresurf]

I agree that this change is larger than this issue. Thank you for creating issue #95.

[absorber]

If I understand this correctly, this feature will enable homeshick to track git project folders as well? That sounds great.

Personally I have 2 git working dirs in ~/.tmux/plugins/, which will get ignored when I start to homeshick track ~/.tmux/.

So if the main issue seems git's inability to track git working dirs inside git working dirs, then isn't this a solution? - http://stackoverflow.com/questions/4659549/maintain-git-repo-inside-another-git-repo
Especially that part about 'fake submodules' appears to be interesting.