vcsh rename: Renaming a repository fails to rename or re-whitelist the corresponding ".gitignore.d" file

[leycec]

When renaming an existing repository from old_repo to new_repo, the "vcsh rename old_repo new_repo" command currently fails to rename and re-whitelist the corresponding .gitignore file (if any) from ~/.gitignore.d/old_repo to ~/.gitignore.d/new_repo.

Apologies if this issue has already been noted. My Google-fu is supremely lacking.

Side Effects

Unsurprisingly, this has a number of unfortunate side effects. After the repository rename:

• All files previously ignored by that repository will be instead marked as untracked. Which basically means everything (...including the recently misshapen kitchen sink).
• After the user manually renames ~/.gitignore.d/old_repo to ~/.gitignore.d/new_repo, ~/.gitignore.d/new_repo will itself be ignored until the user manually re-whitelists that file (e.g., by changing the line resembling "!/.gitignore.d/old_repo" to read "!/.gitignore.d/new_repo").

Possible Solutions

Automating both the file rename and re-whitelisting appears feasible... but probably non-trivial. Until someone scripts up a robust solution for this, it'd be awesome if the vcsh rename subcommand could at least be revised to:

1. Detect the existence of a ~/.gitignore.d/old_repo file.
2. If such file exists, print a non-fatal warning recommending that such file be manually:
   1. Renamed to ~/.gitignore.d/new_repo.
   2. Edited so as to re-whitelist itself.

In Synopsis

Thanks for the omnipresent effort, Rich and crew. vcsh is simple greatness, and you all are the reason why. Hamsters for all! 🐹

[RichiH]

Please give https://github.com/RichiH/vcsh/tree/fix/rename_gitignore_gitattributes a try. Since the files themselves are not touched by the rename, this should do everything you need.

[leycec]

Awesome. You caught the need to rename the corresponding .gitattributes.d file as well, which I shamefacedly overlooked. For safety, it might be helpful to test whether each target file already exists and respond accordingly: e.g.,

[ -e "$VCSH_BASE/.gitignore.d/$VCSH_REPO_NAME_NEW" ] &&
    fatal "'$VCSH_BASE/.gitignore.d/$VCSH_REPO_NAME_NEW' already exists"
[ -e "$VCSH_BASE/.gitattributes.d/$VCSH_REPO_NAME_NEW" ] &&
    fatal "'$VCSH_BASE/.gitattributes.d/$VCSH_REPO_NAME_NEW' already exists"

Likewise, would it be feasible to print a non-fatal warning recommending that the user manually re-whitelist $VCSH_REPO_NAME_NEW in .gitignore.d/$VCSH_REPO_NAME_NEW as well?

Otherwise, this looks fabulous! Thanks for the fast reply, Rich.

[guyhughes]

@leycec In my PR #162 I did this another way through upgrade() which is called in rename().

[leycec]

Nice! Intuitively, that strikes me as a sensible solution. Rich's would work too, of course; but we'd might as well strike a few pending issues with one blow, right?

Also, I know I'm pedantically hammering this – but it'd be great "...to print a non-fatal warning recommending that the user manually re-whitelist $VCSH_REPO_NAME_NEW in .gitignore.d/$VCSH_REPO_NAME_NEW." I've personally neglected to do that after a rename and then stumbled about in confusion as nothing worked anymore. (Anyone else? Just me? Gre-aaat.)

[guyhughes]

Hmm. @leycec, in master right now upgrade() already does git add -f on
the gitignore and gitattributes files..
https://github.com/RichiH/vcsh/pull/162/files#diff-19d8c2aa1e961494cef417cb18cf3e4cR441

My understanding is that once a file is being tracked by git, the gitignore
will not impact the tracking of that file, i.e. the gitignore only affects
a git add without -f. I don't know anything though. Am I wrong?

[leycec]

@guyhughes Ah! Quite right. I'm all for elegant solutions, and that seems to fit the bill.

Since your pull request already addresses this and any future complaint I could possibly concoct, you know everything. I unreservedly give a thumbs up.

[madduck]

Seems a duplicate of #37

[alerque]

I'm closing this as it does seem to be a duplicate of #37, but I've made a note on #162 to review the two proposed implementations.