cristibalan / braid

Simple tool to help track vendor branches in a Git repository.
http://cristibalan.github.io/braid
MIT License
457 stars 57 forks source link

Avoid the use of remotes except during braid operations #47

Closed realityforge closed 7 years ago

realityforge commented 7 years ago

Currently braid adds remotes for every upstream repository in the downstream repository. You end up with remotes looking something like the following

$ git remote -v
master/braid/vendor/docs/way_of_stock   /Users/peter/.braid/cache/https___github.com_stocksoftware_way_of_stock.git (fetch)
master/braid/vendor/docs/way_of_stock   /Users/peter/.braid/cache/https___github.com_stocksoftware_way_of_stock.git (push)
master/braid/vendor/plugins/dbt /Users/peter/.braid/cache/https___github.com_realityforge_dbt.git (fetch)
master/braid/vendor/plugins/dbt /Users/peter/.braid/cache/https___github.com_realityforge_dbt.git (push)
master/braid/vendor/plugins/domgen  /Users/peter/.braid/cache/https___github.com_realityforge_domgen.git (fetch)
master/braid/vendor/plugins/domgen  /Users/peter/.braid/cache/https___github.com_realityforge_domgen.git (push)
master/braid/vendor/plugins/rptman  /Users/peter/.braid/cache/https___github.com_realityforge_rptman.git (push)
master/braid/vendor/plugins/rptman  /Users/peter/.braid/cache/https___github.com_realityforge_rptman.git (fetch)
master/braid/vendor/tools/buildr_plus   /Users/peter/.braid/cache/https___github.com_realityforge_buildr_plus.git (push)
master/braid/vendor/tools/buildr_plus   /Users/peter/.braid/cache/https___github.com_realityforge_buildr_plus.git (fetch)
master/braid/vendor/tools/dbt   /Users/peter/.braid/cache/https___github.com_realityforge_dbt.git (push)
master/braid/vendor/tools/dbt   /Users/peter/.braid/cache/https___github.com_realityforge_dbt.git (fetch)
master/braid/vendor/tools/domgen    /Users/peter/.braid/cache/https___github.com_realityforge_domgen.git (push)
master/braid/vendor/tools/domgen    /Users/peter/.braid/cache/https___github.com_realityforge_domgen.git (fetch)
master/braid/vendor/tools/kinjen    /Users/peter/.braid/cache/https___github.com_realityforge_kinjen.git (push)
master/braid/vendor/tools/kinjen    /Users/peter/.braid/cache/https___github.com_realityforge_kinjen.git (fetch)
master/braid/vendor/tools/redfish   /Users/peter/.braid/cache/https___github.com_realityforge_redfish.git (fetch)
master/braid/vendor/tools/redfish   /Users/peter/.braid/cache/https___github.com_realityforge_redfish.git (push)
master/braid/vendor/tools/rptman    /Users/peter/.braid/cache/https___github.com_realityforge_rptman.git (fetch)
master/braid/vendor/tools/rptman    /Users/peter/.braid/cache/https___github.com_realityforge_rptman.git (push)
...

Regular users who interact with the downstream repository find this difficult to work with, particularly when the number of braided directories gets high and/or they are already working with different remotes themselves. It also gets very complex if the braided repositories have tags as they pollute the downstream repository and users who do things such as git push --tags end up with behaviour they really do not expect.

An alternative would be to not add the remotes explicitly and instead interact with the cache via local urls. Another alternative would be to add and then remove remotes as part of the braid process. Either option would improve the user experience at the expense of a more complex braid codebase.

realityforge commented 7 years ago

It should also be noted that avoiding the use of remotes also has the advantage that if users modify the .braids file to move the location of the repository, currently this will leave the remote pointing at an incorrect cache and thus it will not work. Users tend to have to remember to remove the remote and allow braid to recreate it ... which they don't always do which can cause confusion.