Keep ".git" file in in --cleanDestinationDir

[g-a-c]

Ignore files specifically called ".git" in order to preserve submodule information for Git post-1.7.8 (which seems to be the point things changed from having an entire “.git” directory inside the submodule to having a “.git” file pointing to a gitdir outside of the submodule)

This should restore what I believe was the intended behaviour of #3202 and fix the issue for pojebunny in #4546

See #3202 and #4546

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. The resources of the Hugo team are limited, and so we are asking for your help. If this is a bug and you can still reproduce this error on the master branch, please reply with all of the information you have about it in order to keep the issue open. If this is a feature request, and you feel that it is still relevant and valuable, please tell us why. This issue will automatically be closed in the near future if no further activity occurs. Thank you for all your contributions.

[g-a-c]

If this is a feature request, and you feel that it is still relevant and valuable, please tell us why. This issue will automatically be closed in the near future if no further activity occurs. Thank you for all your contributions.

I don't currently use Hugo but I believe this PR still adds value for other users attempting to use submodules with recent versions of Git.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. The resources of the Hugo team are limited, and so we are asking for your help. If this is a bug and you can still reproduce this error on the master branch, please reply with all of the information you have about it in order to keep the issue open. If this is a feature request, and you feel that it is still relevant and valuable, please tell us why. This issue will automatically be closed in the near future if no further activity occurs. Thank you for all your contributions.

[Jonathan-Ironman]

Same issue here. The .git file should be preserved imo

[g-a-c]

I don't remember any of the context around why I opened this. However...

• gohugoio/hugo#3210 shows that there was a separate command added called cleanDestinationDirKeepDotFolders which
• This command is not documented, and if I'm reading the current master code correctly it is part of the regular cleanDestinationDir functionality since ~2017 - so I don't know why I ever even opened this...

edit - I see. This refers to a .git file, not a directory, which would not be covered by the existing behaviour so may still be a valid PR.

[Jonathan-Ironman]

Exactly, it leaves the dirs intact but clears .git, .gitignore, etc. I'm having the public folder as a git submodule and it for instance also has a README.md file which would be nice to keep. Custom regex filter settings would be ideal here I suppose, but ignoring dot-files is already a big help.

[bep]

I didn't know .git could be a file -- we can check for that, but we're not making this more complicated than that.

[Jonathan-Ironman]

https://github.com/spf13/fsync/pull/10 This seems related, might it already be possible?

All . files right? There's a bunch of them (i.e. .gitignore, .firebaserc)

[g-a-c]

I didn't know .git could be a file -- we can check for that, but we're not making this more complicated than that.

Honestly, I don't remember all the details of this. But I think it was related to me wanting to pull in a remote theme without committing it in its entirety to my Hugo repo.

That seemed (at the time at least) like a sensible thing to do because it meant updating the theme was just a change of reference, and I think the way I achieved that was by having a theme subdirectory or something similar in my output directory, which was a submodule reference (this somehow turned into a .git file inside the theme subdir, though I don't fully understand/remember why). So when the output directory was being cleared, I actually wanted that submodule reference to remain so that once the output step was finished I could pull the theme from its remote reference into my output directory and then rsync --delete the whole thing up to a webserver.

It was a very, very early exploration into rudimentary CI/CD for me at the time. It may no longer make sense, and I don't use Hugo anymore, which is why I just let the PR expire at the second time of asking instead of being an ass and trying to force a change through that I didn't need anymore.

[luisfelipe3d]

any update?

[DominoPivot]

This would still be pertinent, though the codebase has changed quite a bit since this PR was opened. The code now lives in /commands/hugobuilder.go. I could open my own PR if needed, though I don't have a Go environment ready and never contributed here.

		syncer.DeleteFilter = func(f os.FileInfo) bool {
-			return f.IsDir() && strings.HasPrefix(f.Name(), ".")
+			return strings.HasPrefix(f.Name(), ".")
		}

I ran into this issue when I found an old site of mine whose public folder contained a redundant clone of the same repository but with the gh-pages branch always checked out. This is precisely what a git worktree is for, I probably just didn't know at the time. I ran this command to replace the redundant clone with a worktree:

rm -rf public && git worktree add public gh-pages

This had the effect of replacing the public/.git folder with a single file. I knew --cleanDestinationDir left public/.git alone before so I was surprised when it got deleted now that it was a file instead of a folder. I believe this should be fixed for consistency, though I'm not sure if there are people who rely on the current behavior. Still, I found some workarounds for now:

• git worktree repair public to recreate the .git file
• git worktree lock public to avoid accidental pruning if Hugo deletes the .git file in the future
• copy the .git file to the static folder, and make sure not to run git commands within that folder

[jmooring]

I've read through this thread several times and it no longer seems relevant given current (six years later) hosting methods. We continue to retain dot directories when cleaning the publishDir, though at this point I can't come up with a good reason to do that either.