"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

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

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.

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.

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

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.

"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.

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.

"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.

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.