Bender not updating git dependencies that have already been cloned

[kgreig87]

Description:

I've observed that when using Bender with dependencies pinned to a specific branch, the tool may not update those dependencies if they've already been cloned, even if new commits are pushed to that branch.

To Reproduce:

Set up a my_package with the following dependencies:

package:
  name: my_package
dependencies:
  my_common: { git: "/my.git.repo/common.git", rev: my_branch }

Run any Bender command within the my_package repo for the first time. This causes Bender to clone my_common at the HEAD of my_branch.

Push a new commit to my_branch.

Inside the my_package repo, run bender update -f.

Expected Behavior:
The my_common dependency should be updated to the latest commit on my_branch.

Actual Behavior:
The my_common dependency is not updated. Upon running bender update -f --debug, it appears that already-cloned dependencies are treated as Path dependencies, not Git dependencies. This seems to prevent them from being updated.

Questions:

1. Is this behavior intentional?
2. Would there be any concerns if I propose a PR to introduce a flag that forces Bender to fetch the HEAD of the branch for each Git dependency?

[micprog]

Thank you for pointing this out! Unfortunately, I was not able to reproduce this issue, for me the new commit was fetched properly.

While generally bender keeps git repositories linked as such (check the Bender.lock), if you have a checkout_dir specified in your workspace in your top Bender.yml, bender treats all dependencies as path dependencies after it cloned them. This is to allow for manual manipulation without bender interfering on the next update (bender assumes you want to manipulate things if they are not in the hidden directory), as your changes may likely be overwritten otherwise. Maybe this is interfering with your update?

Normally, I strongly discourage using branch names to reference dependency versions, especially for repositories you are not in control of, as these may be updated and lead to breaking changes in your project.

Of course, if the issue persists and you can implement a bugfix, I would be happy to review it in a PR!