www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Today's github tip - fixing local master

reply Walter Bright <newshound2 digitalmars.com> writes:
I often struggle with understanding how github works. A problem I was having 
often is that I have 3 repositories to deal with:

    1. the main one on github (upstream)
    2. my github fork of the main one (origin)
    3. my local git repository

and (2) and (3) got out of sync with (1), causing all my pull requests to go 
bonkers. What I needed was a "fix (2) and (3) so their masters are identical to 
(1)'s master." Various attempts at fixing it all failed in one way or another, 
often with mysterious messages, and cost me a lot of time.

yebblies (Daniel Murphy) provided the solution, which is nicely generic:

   git checkout master
   git fetch upstream master
   git reset --hard FETCH_HEAD
   git push origin master -f

So there it is if anyone else has this problem.
Jun 18 2013
next sibling parent reply David <d dav1d.de> writes:
Am 18.06.2013 21:41, schrieb Walter Bright:
 I often struggle with understanding how github works. A problem I was
 having often is that I have 3 repositories to deal with:
 
    1. the main one on github (upstream)
    2. my github fork of the main one (origin)
    3. my local git repository
 
 and (2) and (3) got out of sync with (1), causing all my pull requests
 to go bonkers. What I needed was a "fix (2) and (3) so their masters are
 identical to (1)'s master." Various attempts at fixing it all failed in
 one way or another, often with mysterious messages, and cost me a lot of
 time.
 
 yebblies (Daniel Murphy) provided the solution, which is nicely generic:
 
   git checkout master
   git fetch upstream master
   git reset --hard FETCH_HEAD
   git push origin master -f
 
 So there it is if anyone else has this problem.

This should not be generalized! this resets everything you have done on master to upstream! Anything is gone, if you actually end up resetting the wrong branch, take a look into "git reflog", which allows you to revert the hard-reset
Jun 18 2013
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 6/18/2013 1:47 PM, David wrote:
 This should not be generalized!
 this resets everything you have done on master to upstream!

Which is what I wanted to do.
 Anything is
 gone, if you actually end up resetting the wrong branch, take a look
 into "git reflog", which allows you to revert the hard-reset

I didn't know about that one.
Jun 18 2013
prev sibling parent "qznc" <qznc web.de> writes:
On Tuesday, 18 June 2013 at 20:47:50 UTC, David wrote:
 Am 18.06.2013 21:41, schrieb Walter Bright:
 I often struggle with understanding how github works. A 
 problem I was
 having often is that I have 3 repositories to deal with:
 
    1. the main one on github (upstream)
    2. my github fork of the main one (origin)
    3. my local git repository
 
 and (2) and (3) got out of sync with (1), causing all my pull 
 requests
 to go bonkers. What I needed was a "fix (2) and (3) so their 
 masters are
 identical to (1)'s master." Various attempts at fixing it all 
 failed in
 one way or another, often with mysterious messages, and cost 
 me a lot of
 time.
 
 yebblies (Daniel Murphy) provided the solution, which is 
 nicely generic:
 
   git checkout master
   git fetch upstream master
   git reset --hard FETCH_HEAD
   git push origin master -f
 
 So there it is if anyone else has this problem.

This should not be generalized! this resets everything you have done on master to upstream! Anything is gone, if you actually end up resetting the wrong branch, take a look into "git reflog", which allows you to revert the hard-reset

My advice would be to use more branches. Never commit to a master branch, only merge. Thus all your changes stay available on their branch and dealing with repo conflicts on master does not risk to discard (or hide wrt reflog) any commits.
Jun 19 2013
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-06-18 21:41, Walter Bright wrote:

 git checkout master
 git fetch upstream master
 git reset --hard FETCH_HEAD
 git push origin master -f

 So there it is if anyone else has this problem.

I don't know what you are doing with your git repositories but you shouldn't have to do a push force (push -f). That's only needed if you changed the history, which "git reset" will do. Instead just sync all: 1. sync local with origin: git checkout master git pull git push origin master 2. sync upstream with master git checkout master git fetch upstream git merge upstream/master git push upstream master 3. sync upstream with origin git push origin master If you have changed the history in any of the repository the above won't work. I also recommend doing all your work in a special branch (not master) or topic branches. -- /Jacob Carlborg
Jun 18 2013
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 6/18/2013 1:52 PM, Jacob Carlborg wrote:
 On 2013-06-18 21:41, Walter Bright wrote:

 git checkout master
 git fetch upstream master
 git reset --hard FETCH_HEAD
 git push origin master -f

 So there it is if anyone else has this problem.

I don't know what you are doing with your git repositories but you shouldn't have to do a push force (push -f). That's only needed if you changed the history, which "git reset" will do. Instead just sync all: 1. sync local with origin: git checkout master git pull git push origin master

That didn't work.
 2. sync upstream with master

 git checkout master
 git fetch upstream
 git merge upstream/master
 git push upstream master

I didn't try that one.
 3. sync upstream with origin

 git push origin master

That didn't work, either.
 If you have changed the history in any of the repository the above won't work.

Hence my problems with it.
 I also recommend doing all your work in a special branch (not master) or topic
 branches.

I do do all the work in not-master branches. But I make mistakes, and often forget to change branches first. Most of my problems with git revolve around trying to undo mistakes.
Jun 18 2013
prev sibling next sibling parent reply "David Nadlinger" <code klickverbot.at> writes:
On Tuesday, 18 June 2013 at 20:52:59 UTC, Jacob Carlborg wrote:
 If you have changed the history in any of the repository the 
 above won't work.

This is exactly the point. Walter had pushed commits to WalterBright/dmd at GitHub that didn't make it to D-Programming-Language/dmd. And, completely unrelated, also managed to configure his local clone such that "git fetch upstream" fetched the branches to "origin/*" instead of "upstream/*", which is why any of the previous attempts to help failed. David
Jun 18 2013
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-06-18 23:04, David Nadlinger wrote:

 This is exactly the point. Walter had pushed commits to WalterBright/dmd
 at GitHub that didn't make it to D-Programming-Language/dmd.

Then he should have pushed them to upstream as well.
 And, completely unrelated, also managed to configure his local clone
 such that "git fetch upstream" fetched the branches to "origin/*"
 instead of "upstream/*", which is why any of the previous attempts to
 help failed.

If he managed to that I can understand he ran into problem. -- /Jacob Carlborg
Jun 18 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/18/2013 2:10 PM, Jacob Carlborg wrote:
 On 2013-06-18 23:04, David Nadlinger wrote:

 This is exactly the point. Walter had pushed commits to WalterBright/dmd
 at GitHub that didn't make it to D-Programming-Language/dmd.

Then he should have pushed them to upstream as well.

No, the procedure is never push to upstream, do P.R.'s.
Jun 18 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-06-19 00:35, Walter Bright wrote:

 No, the procedure is never push to upstream, do P.R.'s.

Then wait for someone to merge the pull request. I don't understand what you did and what you actually tried to do. -- /Jacob Carlborg
Jun 19 2013
parent reply "Daniel Murphy" <yebblies nospamgmail.com> writes:
"Jacob Carlborg" <doob me.com> wrote in message 
news:kps11e$2jl2$1 digitalmars.com...
 On 2013-06-19 00:35, Walter Bright wrote:

 No, the procedure is never push to upstream, do P.R.'s.

Then wait for someone to merge the pull request. I don't understand what you did and what you actually tried to do.

Obviously. Walter accidentally committed to master, then pulled from upstream creating a bunch of merge commits. All the branches he made after this point then contained these extra garbage commits. It didn't help that he pushed this mess to origin/master too. Hard resetting master is the correct solution to this specific problem.
Jun 19 2013
parent reply "Daniel Murphy" <yebblies nospamgmail.com> writes:
"Dicebot" <public dicebot.lv> wrote in message 
news:hvntmeabdeljjxfedixi forum.dlang.org...
 On Wednesday, 19 June 2013 at 12:12:27 UTC, Daniel Murphy wrote:
 Obviously.  Walter accidentally committed to master, then pulled from
 upstream creating a bunch of merge commits.  All the branches he made 
 after
 this point then contained these extra garbage commits.  It didn't help 
 that
 he pushed this mess to origin/master too.  Hard resetting master is the
 correct solution to this specific problem.

Coorect solution would have been to stop immediately when commit to master was made and delete this commit.

So, you're saying it would be better to not screw things up in the first place? Helpful.
Jun 19 2013
parent "Daniel Murphy" <yebblies nospamgmail.com> writes:
"Dicebot" <public dicebot.lv> wrote in message 
news:agstqqkfhxzjvdquxtqs forum.dlang.org...
 On Thursday, 20 June 2013 at 00:28:46 UTC, Daniel Murphy wrote:
 So, you're saying it would be better to not screw things up in the first
 place?  Helpful.

No, I am saying it is better to fix issues when they appear, not stockpile them and then recommend deperate "reset everything" solution (which may cause more harm than issue itself!) to others.

Nobody is recommending 'stockpiling' errors. That is just what accidentally happened in Walter's specific case.
Jun 20 2013
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-06-18 23:04, David Nadlinger wrote:

 This is exactly the point.

My point is that he shouldn't have changed the history in the first place. He also shouldn't encourage other people to do that. That's the problem if you just type in some commands and don't know that they actually do. -- /Jacob Carlborg
Jun 18 2013
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
On Wednesday, 19 June 2013 at 10:26:55 UTC, Jacob Carlborg wrote:
 On 2013-06-19 00:35, Walter Bright wrote:

 No, the procedure is never push to upstream, do P.R.'s.

Then wait for someone to merge the pull request. I don't understand what you did and what you actually tried to do.

This. I am afraid wrong lesson was learned here. It is a dangerous signal that such working copy setup existed at all, not knowing how to fix it is a relatively minor problem.
Jun 19 2013
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
On Wednesday, 19 June 2013 at 12:12:27 UTC, Daniel Murphy wrote:
 Obviously.  Walter accidentally committed to master, then 
 pulled from
 upstream creating a bunch of merge commits.  All the branches 
 he made after
 this point then contained these extra garbage commits.  It 
 didn't help that
 he pushed this mess to origin/master too.  Hard resetting 
 master is the
 correct solution to this specific problem.

Coorect solution would have been to stop immediately when commit to master was made and delete this commit.
Jun 19 2013
prev sibling parent "Dicebot" <public dicebot.lv> writes:
On Thursday, 20 June 2013 at 00:28:46 UTC, Daniel Murphy wrote:
 So, you're saying it would be better to not screw things up in 
 the first
 place?  Helpful.

No, I am saying it is better to fix issues when they appear, not stockpile them and then recommend deperate "reset everything" solution (which may cause more harm than issue itself!) to others.
Jun 20 2013
prev sibling next sibling parent David <d dav1d.de> writes:
Kinda related,

I can recommend #d and #git on freenode for git help ;)
Jun 18 2013
prev sibling next sibling parent "Daniel Murphy" <yebblies nospamgmail.com> writes:
"Walter Bright" <newshound2 digitalmars.com> wrote in message 
news:kpqd65$qs7$1 digitalmars.com...
I often struggle with understanding how github works. A problem I was 
having often is that I have 3 repositories to deal with:

    1. the main one on github (upstream)
    2. my github fork of the main one (origin)
    3. my local git repository

 and (2) and (3) got out of sync with (1), causing all my pull requests to 
 go bonkers. What I needed was a "fix (2) and (3) so their masters are 
 identical to (1)'s master." Various attempts at fixing it all failed in 
 one way or another, often with mysterious messages, and cost me a lot of 
 time.

 yebblies (Daniel Murphy) provided the solution, which is nicely generic:

   git checkout master
   git fetch upstream master
   git reset --hard FETCH_HEAD
   git push origin master -f

 So there it is if anyone else has this problem.

As others have noted, this will completely discard any commits in master, and should be used with caution. It is comparable to removing a virus by manually replacing system files. It is probably possible to prevent git from accepting commits to master, but I have never been able to get it to work. Maybe something like this: https://gist.github.com/Simbul/1781656
Jun 18 2013
prev sibling next sibling parent Arlen <arlen.ng gmx.com> writes:
--0023547c8a91399b2a04df7a2aa3
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Jun 18, 2013 at 2:41 PM, Walter Bright
<newshound2 digitalmars.com>wrote:

 I often struggle with understanding how github works.

on your local system to try out the commands without the fear of ruining your working repo? You can set up a local and remote on your local computer, and push and pull from them in the same way you do with your local repo and github. Example: mkdir test cd test git init local_repo cd local_repo ... add files, commit, etc. cd ../test git clone --bare local_repo/ remote_repo cd ../local_repo git remote add origin ../remote_repo ... add more changes and commit git push origin master Note, to be able to push, that repo needs to be bare. You can also add a dummy linux user to your local system to play the role of a contributor. Using this kind of setup really helped me understand git better. Alren --0023547c8a91399b2a04df7a2aa3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T= ue, Jun 18, 2013 at 2:41 PM, Walter Bright <span dir=3D"ltr">&lt;<a href=3D= "mailto:newshound2 digitalmars.com" target=3D"_blank">newshound2 digitalmar= s.com</a>&gt;</span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-= left:1px solid rgb(204,204,204);padding-left:1ex">I often struggle with und= erstanding how github works. <br> <br> <br> </blockquote></div><br></div><div class=3D"gmail_extra">github or git?=A0 I= n any case, have you tried setting up a local and a remote on your local sy= stem to try out the commands without the fear of ruining your working repo?= =A0 You can set up a local and remote on your local computer, and push and = pull from them in the same way you do with your local repo and github.=A0 E= xample:<br> <br></div><div class=3D"gmail_extra">mkdir test<br></div><div class=3D"gmai= l_extra">cd test<br></div><div class=3D"gmail_extra"><br></div><div class= =3D"gmail_extra">git init local_repo<br></div><div class=3D"gmail_extra">cd= local_repo<br> </div><div class=3D"gmail_extra">... add files, commit, etc.<br><br>cd ../t= est<br>git clone --bare local_repo/ remote_repo<br><br></div><div class=3D"= gmail_extra">cd ../local_repo<br></div><div class=3D"gmail_extra">git remot= e add origin ../remote_repo<br> </div><div class=3D"gmail_extra">... add more changes and commit<br></div><= div class=3D"gmail_extra">git push origin master<br><br></div><div class=3D= "gmail_extra">Note, to be able to push, that repo needs to be bare.=A0 You = can also add a dummy linux user to your local system to play the role of a = contributor.<br> <br></div><div class=3D"gmail_extra">Using this kind of setup really helped= me understand git better.<br><br></div><div class=3D"gmail_extra">Alren<br=
</div></div>

--0023547c8a91399b2a04df7a2aa3--
Jun 18 2013
prev sibling next sibling parent "eles" <eles eles.com> writes:
On Wednesday, 19 June 2013 at 04:21:47 UTC, Arlen wrote:
 On Tue, Jun 18, 2013 at 2:41 PM, Walter Bright
 <newshound2 digitalmars.com>wrote:

I am not a hardcore github user, but from time to time I do make some contributions. To this date, the best approach that I found is explained here: http://stackoverflow.com/a/5269443/1284631 and here: http://kurogo.org/guide/github.html Is a method to contribute to some repository through a fork (remote) and a local repo clone (of the fork). Some more advanced git/github gurus could explain that better than the provided text.
Jun 19 2013
prev sibling next sibling parent "Tyler Jameson Little" <beatgammit gmail.com> writes:
On Tuesday, 18 June 2013 at 19:41:57 UTC, Walter Bright wrote:
 I often struggle with understanding how github works. A problem 
 I was having often is that I have 3 repositories to deal with:

    1. the main one on github (upstream)
    2. my github fork of the main one (origin)
    3. my local git repository

 and (2) and (3) got out of sync with (1), causing all my pull 
 requests to go bonkers. What I needed was a "fix (2) and (3) so 
 their masters are identical to (1)'s master." Various attempts 
 at fixing it all failed in one way or another, often with 
 mysterious messages, and cost me a lot of time.

 yebblies (Daniel Murphy) provided the solution, which is nicely 
 generic:

   git checkout master
   git fetch upstream master
   git reset --hard FETCH_HEAD
   git push origin master -f

 So there it is if anyone else has this problem.

This saved me yesterday! My coworker decided to do a rebase on master, then he made a mistake, push --force'd and in the mean-time I accidentally git pull'd (we're a small team, I knew he was rebasing, but still). We guard merges into master, so it's normally not a problem. Thanks for this! Probably saved us a quite a few WTFs!
Jun 20 2013
prev sibling parent Martin Nowak <code dawg.eu> writes:
On 06/18/2013 09:41 PM, Walter Bright wrote:> I often struggle with 
understanding how github works. A problem I was
 having often is that I have 3 repositories to deal with:

IMHO it's much easier to understand git from bottom up. Git is based on a very simple object model. It only knows 4 types Blob, Tree, Commit and Tag. http://git-scm.com/book/en/Git-Internals-Git-Objects With that you can think of any constellation in terms of commit diagrams like these http://git-scm.com/book/ch3-6.html. And the last bit is to understand what git commands actually do. This is the problematic part of git. Some commands do basic operations others do more complicated stuff. The later usually have gotchas one needs to be aware of. I personally found that using explicit and more verbose commands was helpful to learn git faster.
     1. the main one on github (upstream)
     2. my github fork of the main one (origin)
     3. my local git repository

 and (2) and (3) got out of sync with (1), causing all my pull requests
 to go bonkers. What I needed was a "fix (2) and (3) so their masters are
 identical to (1)'s master." Various attempts at fixing it all failed in
 one way or another, often with mysterious messages, and cost me a lot of
 time.

I never use my remote master branch (origin). What do you need it for?
 yebblies (Daniel Murphy) provided the solution, which is nicely generic:

    git checkout master
    git fetch upstream master
    git reset --hard FETCH_HEAD
    git push origin master -f

 So there it is if anyone else has this problem.

I also tend to prefer the explicit fetch and rebase or reset over pull because what git pull does depends on your .gitconfig.
Jun 23 2013