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.