Had to rebase alpha.... be careful with pushes and merges....

[joshStillerman]

Timo pointed out that the last push from Gabriele did ended up re-creating all of the changes since he last synced his local copy.

It came out in the history as a commit which changed three files followed by a merge that changed 128 files.

I pulled it all to my computer and then: git rebase the-hash-before-this then git push -f

SO: You will need to pull or rebase before proceeding

-Josh

[GabrieleManduchi]

Hmmm....the exact sequence I did was (Andrea witnessed)

1) committed the changes affecting three files 2) pulled alpha - no conflicts reported 3) pushed alpha - three files modified reported

Where is the wrong action??

                                         Gabriele

On 30/10/2015 21:50, Josh Stillerman wrote:

Timo pointed out that the last push from Gabriele did ended up re-creating all of the changes since he last synced his local copy.

It came out in the history as a commit which changed three files followed by a merge that changed 128 files.

I pulled it all to my computer and then: git rebase the-hash-before-this then git push -f

SO: You will need to pull or rebase before proceeding

-Josh

— Reply to this email directly or view it on GitHub https://github.com/MDSplus/mdsplus/issues/186.

Gabriele Manduchi

Istituto Gas Ionizzati del CNR Consorzio RFX - Associazione EURATOM/ENEA sulla Fusione Corso Stati Uniti 4, 35127 Padova - Italy ph +39-049-829-5039/-5000 fax +39-049-8700718 mailto:gabriele.manduchi@igi.cnr.it, http://www.igi.cnr.it

[MDSplusBuilder]

Hi Gabriele,

Very good question! I saw the merge on github as well and it indeed was messed up. The commit for the changes you made was fine but the merge said it involved a large number of commits and a large number of files modified. I believe what happens is that you are working on a local checkout of alpha which has fallen very much behind the alpha branch on github. You apply a commit to your local branch and then pull alpha which brings in all the new commits since the last time you pulled alpha to your local copy. Then when you push it changes the alpha head to consist of what was in your local copy which is the old head + your commit + all the commits on github's alpha since your old head where what you want is your commit on top of the latest alpha. I believe the way to accomplish this is by using the git pull --rebase when you try to update your local alpha after having done a commit on it locally. This updates alpha and sticks your local commits on the head. Reading the man pages on git pull is mentions that there is a way to make this the default behavior but warns against that as this apparently can cause other problems.

Ciao, Tom

On 11/2/2015 2:51 AM, GabrieleManduchi wrote:

Hmmm....the exact sequence I did was (Andrea witnessed)

1) committed the changes affecting three files 2) pulled alpha - no conflicts reported 3) pushed alpha - three files modified reported

Where is the wrong action??

Gabriele

On 30/10/2015 21:50, Josh Stillerman wrote:

Timo pointed out that the last push from Gabriele did ended up re-creating all of the changes since he last synced his local copy.

It came out in the history as a commit which changed three files followed by a merge that changed 128 files.

I pulled it all to my computer and then: git rebase the-hash-before-this then git push -f

SO: You will need to pull or rebase before proceeding

-Josh

— Reply to this email directly or view it on GitHub https://github.com/MDSplus/mdsplus/issues/186.

Gabriele Manduchi

Istituto Gas Ionizzati del CNR Consorzio RFX - Associazione EURATOM/ENEA sulla Fusione Corso Stati Uniti 4, 35127 Padova - Italy ph +39-049-829-5039/-5000 fax +39-049-8700718 mailto:gabriele.manduchi@igi.cnr.it, http://www.igi.cnr.it

— Reply to this email directly or view it on GitHub https://github.com/MDSplus/mdsplus/issues/186#issuecomment-152945083.

[zack-vii]

This is why I recommend to rebase the local branch the head of alpha before creating a pull request. Once created it can be merged easily. Also, when starting a project its branch should be generated ideally from the current head of alpha.

git checkout my_project_branch git rebase MDSplus/alpha git push -f

and then initiate the pull request

[zack-vii]

@GabrieleManduchi: I just realised something, When you say you pulled alpha, is that MDSplus/alpha or your private one. As your private one in most likely not up to date. If you are working on your personal fork you can update your version by

git remote update

but I am not sure what happens is your alpha get detached from MDSplus/alpha. For that reason I deleted my personal version of alpha and linked alpha to MDSplus/alpha.

echo "ref: refs/remotes/MDSplus/alpha">.git/refs/heads/alpha

MDSplus/alpha is then the branch I am forking from to start my personal projects e.g.: "my_project_branch" This way you will not lose track of changes in the main alpha (MDSplus/alpha). Even if you were working on MDSplus/alpha, your merge would not necessary raise a conflict as I could be merged. But since it was detached from the original (lack of rebase) it basically first reverted all changes and then applied them again with most likely new hashes. This is what messes up the history which later on would make the hunt for bugs impossible.

[alkhwarizmi]

Hi all,

I have a question that is somewhat related to this topic.

I have 2 branches locally alpha and alpha-labview-interface both of them are tracking alkhwarizmi:MDSplus/alpha and alkhwarizmi:MDSplus/alpha-labview-interface.

Is alkhwarizmi:MDSplus/alpha "tracking" MDSplus:origin/alpha or is it a snapshot of when I did the fork?

Sincerely,

[MDSplusBuilder]

Hi,

Unfortunately i have no experience with the use of git forks so not sure how the merge/rebase commands work across two different repositories. I don't know if forked repositories track the original so you can git checkout alpha and git pull on your fork and get your alpha updated from the original. Normally when I work on the MDSplus repository I checkout alpha into another branch, make modifications and commits to the branch and then before issuing a pull request I do:

1) git checkout alpha 2) git pull 3) git checkout mybranch 4) git rebase alpha (this moves the commits on mybranch to the top of the current alpha branch and reports if there are any conflicts). 5) git push origin mybranch 6) create a pull request on github

So I'm not sure how this scenario works when you are working on a fork of the mdsplus. There are others in the MDSplus group that know a lot about git than I do so perhaps they can add a better explanation.

Normally you should only create a pull request unless it is ready to be merged into the mdsplus releases. Pull request are tested automatically but the test coverage is quite limited and does not include tests of the labview interface. If you want someone to test something before you issue a pull request you can just point them to your branch in your fork copy and they can check that branch out of github and test it.

Hope this helps, tom

On 9/24/2016 9:46 AM, AlKhwarizmi wrote:

Hi all,

I have a question that is somewhat related to this topic.

I have 2 branches locally alpha and alpha-labview-interface both of them are tracking alkhwarizmi:MDSplus/alpha and alkhwarizmi:MDSplus/alpha-labview-interface.

Is alkhwarizmi:origin/alpha "tracking" MDSplus:origin/alpha or is it a snapshot of when I did the fork?

Sincerely,

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/MDSplus/mdsplus/issues/186#issuecomment-249365730, or mute the thread https://github.com/notifications/unsubscribe-auth/AI44gbsaFijA_9DZhLx8p5Gu_Cdm2MK_ks5qtSm8gaJpZM4GZTjj.