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

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!

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.