[ET Trac] [Einstein Toolkit] #248: Enhance GetComponents functionality when dealing with git branches

Einstein Toolkit trac-noreply at einsteintoolkit.org
Thu Feb 3 13:57:09 CST 2011


#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.

-- 
Ticket URL: <https://trac.einsteintoolkit.org/ticket/248#comment:15>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit


More information about the Trac mailing list