On 27 Apr 17:39, Dan McGee wrote: > It likely happened because you did a rebase -i, but since your local > master branch "pointer" hadn't kept up with the actual master branch, > it wasn't based off the current master branch. > > Not sure how to explain it more other than what I said before- look at > the visual and read 'man git-rebase' which is pretty extensive, and/or > find some tutorials on what rebase is and how it works on the > interwebs.
> This is where I think git hosting services confuse the original > intent. Before one click forks, you would clone a project's repo which > automatically sets up the origin remote and the remote tracking branch > master. Just think about the definition of "origin"- unless you have > commit access to a project, you will probably never be pushing to the > origin, in a sense. > The first thing you should do is take a step back so you don't have to > do "origin master" ever again. When I `git pull`, it pulls > origin/master automatically into master. When I `git push`, it > automatically pushes master to origin for me. This little bit in > .git/config does that for me, but you can set it up, it looks like, by > doing `git branch --set-upstream master origin/master`. > > [branch "master"] > remote = origin > merge = refs/heads/master > Looks totally right now. And optdepends are your friend: > > $ pacman -Qi git > ... > Optional Deps : tk: gitk and git gui Thanks for explaining, I've started using the git part where I can and I should've checked the optdepends, thanks for pointing that out.
