search

plumed / plumed2

Development version of plumed 2
https://www.plumed.org
GNU Lesser General Public License v3.0
364 stars 289 forks source link

[WIP]Changing style a guide to branch conflicts #1157

Open Iximiel opened 1 week ago

Iximiel commented 1 week ago

1114 will probably cause some headache after being merged, so this is a guide to avoid future merge conflicts

the hashes of this issue will likely change and also the instructions

*I would recommend doing this procedure right before opening a PR, since rebasing will likely become a complex affair after these instructions

or just do a plain rebase into the last upstream/basebranch commit right now if your branch has few commit that can be adjusted likely in a few passages/ few make astyle*

Do NOT do all the v2.9 steps, then v2.10 steps, then the master steps, since v2.10 has already the done them for the changes in v2.9, and same master for v2.10. Only do the procedure with the hashes relevant to your base branch!!!

BEFORE DOING ANYTHING DO A BACKUP OF YOUR BRANCH WITH git branch nameofyourbranch-bk

If you mess something up you can then git reset --hard nameofyourbranch-bk while checked out in nameofyourbranch to reset to the previous version

I assume you have the remote origin pointed at your own repository and upstream to the public plumed2 repository.

Let's go

v2.9

If you are working in a branch from v2.9, use the following hashes

this is the before-v2.9-astyle commit: 4a575f47cf800516a646473afd0704c5fe2f4fe4 this is the v2.9-astyle commit: 9464903282b556e1617e3b76f3e6fcdefe52d486 may change

start with git fetch upstream/v2.9

  1. I would recommend rebasing git rebase 4a575f47cf800516a646473afd0704c5fe2f4fe4, but merging is ok: git merge 4a575f47cf800516a646473afd0704c5fe2f4fe4 this will likely be the most headachy thing in the procedure
  2. git merge --strategy-option=ours 9464903282b556e1617e3b76f3e6fcdefe52d486 this will tell git that the branch has been merged with no problem for future merges, but will likely not update the .astyle.options
  3. git checkout 9464903282b556e1617e3b76f3e6fcdefe52d486 .astyle.options to retrieve the new options
  4. git checkout upstream/v2.9 .git-blame-ignore-revs to retrieve the file to keep the blame cleaner (targeting the upstream to not override other contributions)
  5. make astyle
  6. git commit -am astyled
  7. optional add the hash of the last comment to .git-blame-ignore-revs maybe with a comment
  8. git commit the .git-blame-ignore-revs changes
  9. ready to go, you can merge upstream/v2.9 or prepare the PR to be merged into it

v2.10

If you are working in a branch from v2.10, use the following hashes

this is the before-v2.10-astyle commit: 9464903282b556e1617e3b76f3e6fcdefe52d486 may change this is the v2.10-astyle commit: c88dc98b4de17ff7cab07a24d6c627ffdbc34c0f may change

start with git fetch upstream/v2.10

  1. I would recommend rebasing git rebase 9464903282b556e1617e3b76f3e6fcdefe52d486, but merging is ok: git merge 9464903282b556e1617e3b76f3e6fcdefe52d486 this will likely be the most headachy thing in the procedure
  2. git merge --strategy-option=ours c88dc98b4de17ff7cab07a24d6c627ffdbc34c0f this will tell git that the branch has been merged with no problem for future merges, but will likely not update the .astyle.options
  3. git checkout c88dc98b4de17ff7cab07a24d6c627ffdbc34c0f .astyle.options to retrieve the new options
  4. git checkout upstream/v2.10 .git-blame-ignore-revs to retrieve the file to keep the blame cleaner (targeting the upstream to not override other contributions)
  5. make astyle
  6. git commit -am astyled
  7. optional add the hash of the last comment to .git-blame-ignore-revs maybe with a comment
  8. git commit the .git-blame-ignore-revs changes
  9. ready to go you can merge upstream/v2.10 or prepare the PR to be merged into it

master

If you are working in a branch from master, use the following hashes

this is the before-master-astyle commit: tbd will be updated this is the master-astyle commit: tbd will be updated

start with git fetch upstream/master

  1. I would recommend rebasing git rebase tbd, but merging is ok: git merge tbd this will likely be the most headachy thing in the procedure
  2. git merge --strategy-option=ours tbd this will tell git that the branch has been merged with no problem for future merges, but will likely not update the .astyle.options
  3. git checkout tbd .astyle.options to retrieve the new options
  4. git checkout upstream/master .git-blame-ignore-revs to retrieve the file to keep the blame cleaner (targeting the upstream to not override other contributions)
  5. make astyle
  6. git commit -am astyled
  7. optional add the hash of the last comment to .git-blame-ignore-revs maybe with a comment
  8. git commit the .git-blame-ignore-revs changes
  9. ready to go you can merge upstream/master or prepare the PR to be merged into it