jacebrowning / gitman

Language-agnostic dependency manager using Git.
https://gitman.readthedocs.io
MIT License
198 stars 32 forks source link

Detect changes in remote repositories when listing dependencies #302

Open SebastianBalle opened 1 year ago

SebastianBalle commented 1 year ago

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

location: .gitman
sources:
  - repo: https://[org]@dev.azure.com/[org]/[project]/_git/[repo]
    name: utils
    rev: main
    type: git
    params:
    sparse_paths:
      -
    links:
      - source: ''
        target: .config
      - source: .pre-commit-config.yaml
        target: .pre-commit-config.yaml

Assume I am making a change directly in the .pre-commit-config.yaml in the root project then I expect git to detect the changes/commited changes as they do for git submodules.

cd .gitman/utils
gitman list --fail-if-dirt  # OK

echo '#' >> .pre-commit-config.yaml
gitman list --fail-if-dirt  # Uncommitted changes

git add .pre-commit-config.yaml
gitman list --fail-if-dirt  # Uncommitted changes

git commit -m"test"
gitman list --fail-if-dirt # OK, but it's not OK - the change has not been pushed to remote repo

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 any git 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.

jacebrowning commented 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?

SebastianBalle commented 1 year ago

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.

jacebrowning commented 1 year ago

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.

SebastianBalle commented 1 year ago

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.