Hi All - just a reminder for posterity.
We've been doing some branch maintenance, which means:
* Release_2_8_3_Branch has become Release_2_9_Branch.
* develop has been renamed Pre_29_develop
* A new develop branch has been forked from Release_2_9_Branch.
The following will fix up your local repository to reflect these changes.
Read on further for help about dealing with problems due to unmerged branches:
# rename your local Release_2_8_3_Branch to Release_2_9_Branch
git branch -m Release_2_8_3_Branch Release_2_9_Branch
# update its tracking branch ref
git branch -u origin/Release_2_9_Branch Release_2_9_Branch
# and the same for develop
git branch -m develop Pre_29_develop
git branch -u origin/Pre_29_develop develop
Unmerged Changes.
You WILL HAVE PROBLEMS if you try to push unmerged changes on local branches which were based on either the old Release_2_8_3_Branch or develop branches.
1. Branches tracking Release_2_8_3_Branch
These are straightforward. Simply change your merge strategy so you are pulling and pushing to your local Release_2_9_Branch.
2. Branches forked off Release_2_8_3_Branch.
Again, straightforward. Just use Release_2_9_Branch in any git merge operations (EGit users will have to make sure they change their default merge operations here too).
3. Anything forked from develop
git rebase is your friend. Pre_29_develop has essentially the same content as the current develop, but its history diverged, making merging impossible without a large number of conflicts. Let me know how you get on.. I've got lots of these too!
Jim.
ahem - develop is now Pre_R29_develop
j.
···
On 27/04/2015 16:42, Jim Procter wrote:
Hi All - just a reminder for posterity.
We've been doing some branch maintenance, which means:
* Release_2_8_3_Branch has become Release_2_9_Branch.
* develop has been renamed Pre_29_develop
* A new develop branch has been forked from Release_2_9_Branch.
The following will fix up your local repository to reflect these changes.
Read on further for help about dealing with problems due to unmerged
branches:
# rename your local Release_2_8_3_Branch to Release_2_9_Branch
git branch -m Release_2_8_3_Branch Release_2_9_Branch
# update its tracking branch ref
git branch -u origin/Release_2_9_Branch Release_2_9_Branch
# and the same for develop
git branch -m develop Pre_29_develop
git branch -u origin/Pre_29_develop develop
Unmerged Changes.
You WILL HAVE PROBLEMS if you try to push unmerged changes on local
branches which were based on either the old Release_2_8_3_Branch or
develop branches.
1. Branches tracking Release_2_8_3_Branch
These are straightforward. Simply change your merge strategy so you are
pulling and pushing to your local Release_2_9_Branch.
2. Branches forked off Release_2_8_3_Branch.
Again, straightforward. Just use Release_2_9_Branch in any git merge
operations (EGit users will have to make sure they change their default
merge operations here too).
3. Anything forked from develop
git rebase is your friend. Pre_29_develop has essentially the same
content as the current develop, but its history diverged, making merging
impossible without a large number of conflicts. Let me know how you get
on.. I've got lots of these too!
Jim.
_______________________________________________
Jalview-dev mailing list
Jalview-dev@jalview.org
http://www.compbio.dundee.ac.uk/mailman/listinfo/jalview-dev
This'll teach me to actually test my own advice before giving it.
The following worked for me (args for -m [branch to be renamed] <new branch name>):
git branch -m develop Pre_R29_develop
git fetch origin Pre_R29_develop # on OSX will also fetch all the other branches
git branch -u origin/Pre_R29_develop Pre_R29_develop
git checkout develop # checks out the new develop branch
···
On 27/04/2015 16:44, James Procter wrote:
ahem - develop is now Pre_R29_develop
j.
On 27/04/2015 16:42, Jim Procter wrote:
Hi All - just a reminder for posterity.
We've been doing some branch maintenance, which means:
* Release_2_8_3_Branch has become Release_2_9_Branch.
* develop has been renamed Pre_29_develop
* A new develop branch has been forked from Release_2_9_Branch.
The following will fix up your local repository to reflect these changes.
Read on further for help about dealing with problems due to unmerged
branches:
# rename your local Release_2_8_3_Branch to Release_2_9_Branch
git branch -m Release_2_8_3_Branch Release_2_9_Branch
# update its tracking branch ref
git branch -u origin/Release_2_9_Branch Release_2_9_Branch
# and the same for develop
git branch -m develop Pre_29_develop
git branch -u origin/Pre_29_develop develop
Unmerged Changes.
You WILL HAVE PROBLEMS if you try to push unmerged changes on local
branches which were based on either the old Release_2_8_3_Branch or
develop branches.
1. Branches tracking Release_2_8_3_Branch
These are straightforward. Simply change your merge strategy so you are
pulling and pushing to your local Release_2_9_Branch.
2. Branches forked off Release_2_8_3_Branch.
Again, straightforward. Just use Release_2_9_Branch in any git merge
operations (EGit users will have to make sure they change their default
merge operations here too).
3. Anything forked from develop
git rebase is your friend. Pre_29_develop has essentially the same
content as the current develop, but its history diverged, making merging
impossible without a large number of conflicts. Let me know how you get
on.. I've got lots of these too!
Jim.
_______________________________________________
Jalview-dev mailing list
Jalview-dev@jalview.org
http://www.compbio.dundee.ac.uk/mailman/listinfo/jalview-dev
_______________________________________________
Jalview-dev mailing list
Jalview-dev@jalview.org
http://www.compbio.dundee.ac.uk/mailman/listinfo/jalview-dev