I´m mostly thinking in a "tell fetch-file that github.com/mine/scripts.git is already cloned to ~/devstuff/scripts/ fashion" - to then "skip the clone and use my provided folder instead of cloning into CACHE_DIR"
what shines combined with a push-subcommand when doing "active development" in the downstream repo - since it can shove the fix you made back into the upstream so you can commit and release it there
("push" may then also have a --with-commit option that 1) makes a commit in the local upstream 2) updates downstreams `.git-remote-files` commit-key)
on --no-commit idk... while i very much like the idea of it being able to auto-commit, default-enabled might be a little overreaching but not 100% certain on this... - maybe your `--commit <commit>` could become `--ref <ref>` instead to free up --(no-)commit? (ref might even be more git-nomenclature correct ;))
Yeah, I wasn't sure about the commit flag either! I opted to add the feature using a `--commit` flag with no arguments, and the default remaining to not commit, much like `fetch` itself.
Then, I made the automatic commit messages reflect a style that looked like git's standard automatic commit messages, with summaries for larger commits. Though upon reflection, maybe a list of file changes or updates would be more in-line with git's style.
what shines combined with a push-subcommand when doing "active development" in the downstream repo - since it can shove the fix you made back into the upstream so you can commit and release it there
("push" may then also have a --with-commit option that 1) makes a commit in the local upstream 2) updates downstreams `.git-remote-files` commit-key)
on --no-commit idk... while i very much like the idea of it being able to auto-commit, default-enabled might be a little overreaching but not 100% certain on this... - maybe your `--commit <commit>` could become `--ref <ref>` instead to free up --(no-)commit? (ref might even be more git-nomenclature correct ;))
readme: no thanks, just on a throwaway anyhow ;)