Skip to content
This repository has been archived by the owner on Oct 11, 2021. It is now read-only.

Question on workflow #1

Open
v-erena opened this issue Aug 2, 2019 · 1 comment
Open

Question on workflow #1

v-erena opened this issue Aug 2, 2019 · 1 comment

Comments

@v-erena
Copy link

v-erena commented Aug 2, 2019

Trying to avoid to re-invent the wheel, I remembered this tool git-dependencies :)
I was trying out git submodules, which is not nice. git subtrees look better, but still seem quite complex. git subrepo, https://github.com/ingydotnet/git-subrepo, looks promising.
The major benefit of git-dependencies lies in the explicit, easy-to-maintain dependencies.yml.
But how is your workflow when working on code?

  1. fresh clone of container project
  2. installing git-dependencies (if not already done)
  3. git dependencies init

  4. work on container code: commit and push
  5. work on dependency code: keep track of changes with git dependencies and then cd to the repo and do all git related stuff there.
    If I want to switch a branch of a dependency, I reconfigure that in yml.
    Do I understand that correctly?
@nmandery
Copy link
Contributor

nmandery commented Aug 5, 2019

Hi!

Your understanding is correct. The main idea of git-dependencies was to have a tool which allows to check out a driectory hierachy multiple repositories on a defined state with as little messing around with git as possible. One main feature during the creation of git-dependencies was to be able to reference a branch X of a dependency of the container project and simply build on the asumption that branch X will always have the matching code for the container project. This is quite helpful when you are in control of both projects - then there is not need anymore to track the exact referenced commit of the the dependency in the main repository, like a git submodule would require.

The drawback is of course that the developer has more responsibility to track & commit changes in the single repositories as each of those is a completely seperate repository itself. This gives more freedom for some projects by is certainly not optimal for every project.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants