Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Detect changes in remote repositories when listing dependencies #302

Open
SebastianBalle opened this issue Mar 6, 2023 · 4 comments
Open

Comments

@SebastianBalle
Copy link

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
Copy link
Owner

jacebrowning commented Mar 6, 2023

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
Copy link
Author

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
Copy link
Owner

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
Copy link
Author

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.

@jacebrowning jacebrowning changed the title Detecting changes in dependency repositories Detect changes in remote repositories with --fail-if-unpushed option Mar 7, 2023
@jacebrowning jacebrowning changed the title Detect changes in remote repositories with --fail-if-unpushed option Detect changes in remote repositories when listing dependencies Mar 7, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants