path=. confusion

[jcbhmr]

Just realized that this could have a potential conflict with the documented usage to use path: ., since a .git directory will likely already exist at ./.

Originally posted by @spenserblack in #70 (comment)

we could use:

• GIT_DIR is the location of the .git folder. If this isn’t specified, Git walks up the directory tree until it gets to ~ or /, looking for a .git directory at every step.
• GIT_WORK_TREE is the location of the root of the working directory for a non-bare repository. If --git-dir or GIT_DIR is specified but none of --work-tree, GIT_WORK_TREE or core.worktree is specified, the current working directory is regarded as the top level of your working tree.
  from https://git-scm.com/book/en/v2/Git-Internals-Environment-Variables

and basically do

export GIT_DIR=../wiki.git
export GIT_WORK_TREE="$INPUT_PATH"
gh repo clone "$GITHUB_REPOSITORY" "$GIT_DIR" -- --bare
git config --unset core.bare
git reset

?? 🤔

[jcbhmr]

There's a working version of a github wiki action that uses this technique: https://github.com/Andrew-Chen-Wang/github-wiki-action/tree/jcbhmr

ref Andrew-Chen-Wang/github-wiki-action#30

[spenserblack]

I'm thinking the solution to this is really simple, actually. When path is . (or something that resolve to .), just push the main repository's history to the wiki. The whole point of pulling down the wiki's commits is to preserve its history. When the main repository is the wiki, that's not really necessary.

This can be even further simplified, but I'll put that in a separate issue.

[jcbhmr]

Good point! Would this work with an ignore: input though? 🤔 #49

[spenserblack]

Since nobody has actually expressed a need for #49, I think it's not that high priority. As a potential bug, this takes priority IMO.

But I believe we can find an implementation of #49 that wouldn't conflict with this 🙂