[ET Trac] [Einstein Toolkit] #1949: provide floating branch to "current release" and links to it

[Einstein Toolkit]

#1949: provide floating branch to "current release" and links to it
--------------------------+-------------------------------------------------
  Reporter:  rhaas        |       Owner:                     
      Type:  enhancement  |      Status:  new                
  Priority:  minor        |   Milestone:                     
 Component:  Other        |     Version:  development version
Resolution:               |    Keywords:  EinsteinToolkit    
--------------------------+-------------------------------------------------

Comment (by hinder):

 There is no "git update" command.  You probably mean "git pull".  Ignoring
 SVN, and the fact that we have multiple components, this would be a bit
 tricky even in a single-git repo setup.

 As far as I understand it, our support for upgrading from one release to
 the next is "wipe out your tree and run GetComponents again", which is
 very bad already, but a complicated problem to get right with multiple
 repositories in multiple version control systems, any of which may have
 local uncommitted or committed changes, or be on different branches to
 master (this is a problem of a component framework, not really something
 we have done wrong).  This has been the case in all the release notes that
 I checked.

 If we reset the branch to point to the new release, then a "git pull" by a
 user on the original branch would, if there were backported commits on
 that branch, attempt to merge the new branch into the old branch.  If
 there were backports, this might lead to conflicts.  Even if there
 weren't, the pulled branch would be a merge, rather than identical to the
 new release, so this is not really what we want.

 "git pull" has never been the right command for upgrading from one release
 to the next.  "pull" means to pull in changes from the remote branch
 tracked by the current branch.  Upgrading to a new release corresponds
 instead, at the moment, to checking out a different branch.  i.e. you
 would do git checkout ET_2016_11.  Assuming no local committed or
 uncommitted changes, this will do the right thing; the code version will
 switch completely to the new release.  If you have local working copy
 changes, these will remain in your tree, unless there are conflicts which
 cannot be merged, in which case you will get conflict markers.  If you
 have local commits, they will disappear from your working copy, since you
 are moving to a branch which doesn't have them, but they will remain on
 your old branch.  This all seems very reasonable.

 If we had a floating release branch, I don't think anything would change.
 The user would "git checkout origin/currentrelease", and I think this
 would just work.

 Since we don't support updating a tree from one release to the next, the
 issue of updating doesn't apply in any case.  The advantage of Roland's
 proposal is that we wouldn't have to update websites each time.

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