Open SebastianBalle opened 1 year ago
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?
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.
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.
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.
I would like Gitman to be able to detect changes/committed changes in dependency repositories as changes are often implemented directly within the project for testing when using the dependency repository as a submodule.
I have an example of
gitman.yaml
Assume I am making a change directly in the
.pre-commit-config.yaml
in the root project then I expectgit
to detect the changes/commited changes as they do for git submodules.If I run
git status
from the root I also don't see any changes. I would like to have an indication from Gitman that the dependency repository is in state "Your branch is ahead of 'origin/main' by X commit".One way to mitigate this would be to configure a git alias
alias git='f(){ if ! gitman list --fail-if-dirt > /dev/null; then gitman list --fail-if-dirt; fi; git "$@"; unset -f f; }; f'
to make sure this command is executed before anygit
commands. However, this will not capture the committed changes. This command also returns exit code 0 even though ´gitman` returns an error. I would expect exit code 1.If this is not resolved I am affraid that users will forget that they made any changes to a dependency project and suddenly a lot of changes might be missed and forgotten.