#248: Enhance GetComponents functionality when dealing with git branches ----------------------------+----------------------------------------------- Reporter: bmundim | Owner: eric9 Type: enhancement | Status: accepted Priority: minor | Milestone: Component: GetComponents | Version: Resolution: | Keywords: git branches ----------------------------+-----------------------------------------------
Comment (by bmundim):
Replying to [comment:14 eric9]:
It seems that the general wisdom is that one should not set up local
branches unless you are actually planning to working on that branch.
That seems good to me.
The problem is that the local branches will fall behind and become
stale, which I believe is what Ian was saying.
Isn't that up to the user? I think it is the user responsibility to either merger to master their branches with the new features or keep the several different branches up to dated with the changes committed to the master branch. This can be easily done by cherrypicking the commit number.
This means that if we created local branches to track each remote
branch, when users run {{{GetComponents --update}}} I would have to essentially do the following
{{{ for $branch in `git branch` { `git checkout $branch`; `git pull --rebase $branch`; } }}}
This is certainly a possibility, but it involves a lot of extra work and
could possibly lead to conflicts.
Conflicts will be unavoidable even for the master branch, if some sort of management or policy is not enforced, and that is valid for any revision control tool. So I am not sure what you suggest above will make things worse. However I prefer to have a $git_list instead of executing git branch, so the user is more control of the branches they want to track (and update).
Therefore I would suggest simply setting up remote-tracking branches for
the branches that the user requests, like I said in my last post.
oh, ok. Disregard my comments above then. We both agree on this issue.