[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