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