Detect changes in remote repositories when listing dependencies about gitman HOT 4 OPEN

I see what you mean. I think for now it would be valuable to have the --fail-if-unpushed could solve the problem if this could be specified together with the --fail-if-dirty then we can have the alias alias git='f(){ if ! gitman list --fail-if-dirty --fail-if-unpushed > /dev/null; then gitman list --fail-if-dirty --fail-if-unpushed; fi; git "$@"; unset -f f; }; f' as well as have the gitman list --fail-if-dirty --fail-if-unpushed in a pre-commit hook.

I guess it is not possible for git to be aware of changes made introduced by another tool (gitman) so until then the above alias will solve it.

from gitman.

To be clear, are you proposing that --fail-if-dirty should cause gitman to return an error if there are any unpushed changes?

Generally, "dirty" does not refer to unpushed changes so perhaps a new --fail-if-unpushed option is in order?

from gitman.

Yes, I would like gitman to return an error (exit code 1) if changes are found in any dependency repositories. This could be used by other scripts.

At least in our use of git submodules, we work directly in the submodule to test the changes in the context of where they are used. If they are sourced directly with no changes, I guess the functionality of gitman would cover this. When/if we make any changes to a submodule, git will indicate modified: ../../[path-to-submodule] (modified content), which will allow the developer to commit and push the change to the submodule. In an ideal world, git would also recognize changes in gitman dependency repositories.

I would actually prefer to minimize the number of flags, as a single flag could cover both --fail-if-dirty and --fail-if-unpushed (unless there is a specific reason for separating the flags). However, the problem still exists if git does not recognize these changes locally, so we would need to have a custom alias for git (as in previous comment) to ensure we execute the correct gitman command to verify these local changes to any dependency repositories.

Alternatively, we could include gitman list in a pre-commit hook to avoid missing any local changes to the dependency repository. The exit code would be valuable here as well.

from gitman.

My initial thought on why --fail-if-dirty should not care about remote repositories is that it currently operates using the same mechanism install uses to check for changes that will be overwritten. That is to say, if gitman list --fail-if-dirty fails, then gitman install will necessary fail unless the --force option is added.

from gitman.