Given structure as in forking workflow (sorry - cannot post image), let's enumerate them for clarity as:
V, B, G (Violet, Blue, Green), and L, R (Local, Remote). Analogously, D for developer.
Green developer (GD) has cloned remote blue repository (RB) into RG and RG into LG (local GD workstation).
Two questions come to my mind.
First concerns overview with, for example gitg/gitk.
Sometimes, it is required to "peek into" other developer's repository. Let's say that we, VD, want to look into RG owned by GD. There are two options: either create new clone of RG on our workstation, or add new remote to our LV (git remote add RG test_rg). Assume that we need to see both repositories LV and RG, and we follow second choice. However there is slight inconvenience with this: if repository is big and/or convoluted - fetch might be quite long, and overview difficult - which is why VD, removes remote repository (git remote delete test_rg), to have clear vision of own RV/LV. Is there better alternative, as adding/removing RG as it takes some time to fetch each time (git does not cache remote refs)? I'm thinking about something like having both 'origin' and 'upstream' and 'other_origin' but be able to toggle visibility of last one.Second question might probably relate to "publish-branch", mentioned by Felipe Contreras in blog post.
Following this workflow, VD obviously wants to have most current master branch from RB locally in LV. However, this leads to situation where his RV is left behind, with older master, unless we push new master to RV after pulling changes from RG or ssh to RV server and pull from there. While this is not required, VD might think this a) is good at least for better data security (backup). However, other take on this matter is b) to actually remove all branches from RV that are duplicated in RB, to preserve clear repository overview. Besides two above choices, are there any other concerns one should think of, regarding whether to update RV to reflect RB?
