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 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
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 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 "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
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 reply "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
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 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 reply Arlen <arlen.ng gmx.com> writes:
On Tue, Jun 18, 2013 at 2:41 PM, Walter Bright
<newshound2 digitalmars.com>wrote:


 I often struggle with understanding how github works.


github or git?  In any case, have you tried setting up a local and a remote
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
Jun 18 2013
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