Closed wyqydsyq closed 4 years ago
I have been giving this a lot of thought and I have done something like this in the past using entrypoint's and a file in the root of the repo an entrypoint can read a commit hash from, check if the commit is in the history of that other repo, and if not git fetch
then git checkout
that commit in the other repo.
While this strictly did solve the issue it is not a robust solution as what you really want to target is the content of a commit, not the commit itself. If for example you rebase or merge that commit into another branch you can get a wildly different commit hash. I believe there would be a similar issue if you used git tags as I believe they are simply pointers to a commit hash. So if the hash changed because I merged to master, I may have that change but the hash is not in the history of master branch because it came from dev branch for example. This should not incur an automated checkout but due to the hash mismatch, would.
While I am open to this as a feature, it has been nice that dab does not require modification inside a repo at all to use any of its existing features. Combined with the hash/tag issues only really working for one branch, leading to a solution that only works in special cases, I would be more inclined to maybe put this in the wiki as an example for instance rather than make it a native feature.
We could add this into some of the dab specific utilities to make implementing this kind of thing easy, something like adding app/bin/commit-in-git-history
that can be used something like this from any entrypoint:
if ! commit-in-git-history "$1"; then
inform "$DAB_CURRENT_REPO current branch does not have required commit $1, switching to it directly"
git fetch
git checkout "$1"
fi
Would such a utility suffice for your use case? Unless anyone can think of a different approach that avoids the issues raised above.
Closing due to inactivity
Feature Request
Inter-repository dependency pinning
It seems DAB does not provide any way to actually control inter-repository dependencies.
For example, say I'm working on a branch in a front-end UI repo, which also depends on my API repo being checked out at a specific commit (not the latest master, let's say a specific branch or tag).
Someone trying to check out my UI branch needs to be made explicitly aware that they need to check out a particular commit in the API repo, otherwise the UI will break when trying to run against the incorrect API.
Monorepo-based solutions I've used in the past provided a means to support this by way of the monorepo commits specifying a particular commit for each subproject, so someone could check out my PR from the monorepo and it'd automatically know to check out the correct compatible commits for all the subrepositories