`git branch new-branch-name` means create a new branch. Great, but it doesn't check out the branch, which you want like 99.9% of the time. If you want to do that, you use `git checkout -b new-branch-name`. Yes, a third separate use for git checkout.
Why not (e.g.) `git branch -c new-branch-name` with a config option to make `-c` the default if you want it?
If you rebase and push, it tells you to do a `git pull` to "fix" it, when in every workflow I've ever done, you want to add a `-f` and push away, just be aware that you are intentionally overwriting the remote branch.
I do agree with the second example. Pulling and merging with remote after a rebase makes a terrible mess!
You can fix this by doing `git config --global push.default current`.
git checkout -b test
git push
But in this situation, we actually push with "git push -u origin branchname".
After deleting the "test" branch, I recreated it with "git branch test", switched to it and tried a push, and I got the same error message.
I've almost never had this problem; nearly all branches I've come across usually "know all by themselves" where their remote is. I suspect they inherit it from a global or repository-level setting that might be missing from your setup. Have you tried executing that "--set-upstream" it suggests? Maybe that sets it for the whole repo, or have you had to repeat it for each branch (like the "-u" parameter for the push seems to imply)?
Or maybe, even if you have the remote set correctly on the repo level, branches just somehow don't "inherit" that...? Idunno, maybe some magic setting missing. Aha, one further possibility: If you set the remote on the "master" (or "main") branch, maybe branches branched off from that (and others branched off from those, etc) "inherit" the remote setting?
Finally: Creating a git repo by cloning in stead of from scratch (git clone in stead of git init) automagically sets the remote for the master branch of the newly cloned repo to the master of the repo it was cloned from. Maybe, if this is how it works, that's why it's always worked for me: I've worked mainly with cloned repositories, and my branches are almost always -- albeit sometimes indirectly -- branched, ultimately, from "master".
Anyway, I think somewhere among all that there should be something that fixes your problem once and for all (i.e. for all future branches once it's correctly set for a repo). I'm sure your problem isn't standard behaviour. HTH!
git push origin HEAD
It sounds like you are unaware of
git switch branch
git switch -c new-branch git switch --create new-branchHeh, and I'll do you one better: it's unstaged changes, so it won't put the file back to the HEAD version 100% of the time >:-)
Regardless, what's so bad about deleting the repo and pulling from remote if you can't figure out why you hosed it? It's not like it costs you anything to do `rm ... && git clone ...`. And it's not like this happens daily either.
In the rare case that someone hoses remote, yes you'll have to do some weird git-fu to get everyone working again, but it's really hard to hose remote if you stick to the pull -> commit -> push -> merge pattern, which is what 99% of users are doing anyways. I've used git for 9 years and I've never had to spend longer than an hour troubleshooting git based BS. And if you'll remember, 9 years ago git wasn't the clear winner, it had competition via SVN and Mercurial. Both of them are practically irrelevant at this point so however bad git's UI was, it's clearly better than anything else that existed before.
If it were a human problem, how could alternatives like Mercurial and Darcs get consistent amounts of praise for their intuitive workflows?
> 9 years ago git wasn't the clear winner, it had competition via SVN and Mercurial. Both of them are practically irrelevant at this point so however bad git's UI was, it's clearly better than anything else that existed before.
SVN isn't distributed; it mostly tried to replace CVS, which it managed to do very successfully.
As for DVCS, the fact that system X became more popular than system Y doesn't mean that every aspect of X is better than Y. Many would say git succeeded despite its awful interface. As far as I can tell, the main feature of git was its speed; that made it usable for huge projects like Linux and Xorg, and this endorsement from high-profile projects gave git the edge for DVCS hosting sites like Gitorious. Then GitHub came along, and grew into such a behemoth that git became the de facto standard.
See also: WorseIsBetter
Because maybe mercurial's real problems wouldn't show up until people started using it at scale.
This is a classic problem that happens time and again.
Windows vs. Mac back in 2005:
"Windows having malware is a human problem"
"If it were a human problem, how could alternatives like Mac get consistent amounts of praise for their lack of malware?"
Turns out it's just because Mac didn't have a big enough market share. As soon as it did, Apple could no longer claim that Macs can't get malware because they can and do.
Similarly, if you scaled up the number of Mercurial users by several orders of magnitude so that it was now "mainstream", I'm sure some of its lesser known pain points and/or counter intuitive behaviors would start floating up to the top 10 HN stories. But since hardly anyone uses Mercurial vs. Git, that doesn't happen. Just because a minority of users praise something (<insert lesser known language>, <insert lesser known DB>, <insert lesser known VCS>, etc.) doesn't mean if you scaled up the userbase one or more magnitudes it would continue getting that level of praise from all users.
I actually tried both git and mercurial almost a decade ago having had only experience with subversion, and found git to be much easier to understand and use. I don't recall what those pain points were, and am sure I couldn't describe them correctly if I did remember, but because of that I do expect such things to start popping up if more people used it.
Typically Git was a bit faster for most operations on Linux. Mercurial was a bit faster for other operations. Especially on Windows. And both were much faster than the rest.
Bitbucket and GitHub started around the same time. GitHub just executed better.
That doesn't mean that Git couldn't have a much better UI for this problem than it does. And while I agree that Git seems to have mostly won over SVN and Hg, it doesn't follow that it's because of its UI. (For example, I think that a lot of Git's success actually comes from the UI of GitHub, not Git itself, but I don't have evidence to back it up.)
Take a look at the Research section at the bottom of https://gitless.com/ for work that's been done on how to accomplish the same operations with a simpler conceptual model.
Well, actually, a lot of people work in large repos, so this can be a pain.
Which of course brings up another failing of the git UI: the difficulty of removing old history from the repo. Last I checked, you pretty much have to use a 3rd party tool for this.
It helps a lot to set:
git config --global merge.conflictstyle diff3
then you can see the before as well as the 2 changes you are trying to resolve.
git mergetool
git checkout --ours/theirs && git add .Why is this tone deaf? It’s a development tool for programmers and the internal structure is conceptionally pretty straightforward. Understanding your tools is pretty much prerequisite. You don’t have to have written a compiler to use one, but you do have to have a model of what it does. Git is no different.
But git saved me an immeasurable amount of hours in return. I was asked what I worked on some specific week back in may -- git saved me. I had to look up what performance my program had before a specific change -- git saved me. I had to try stuff out without messing up my codebase -- git saved me.
True, I invested quite a few hours and I still do, but I think the investment pays itself off. I'll never ever do a project without git.
Between the tone deaf responses here about "using a GUI client is the problem," to the tone deaf responses of "you just have to learn it's internal architecture," it should be obvious what the problem is. The problem is not just being able to undo a mistake (though that's certainly one of the problems). Git is an incredibly user-hostile experience, and someone needs to fix or replace it. Can we just say it out loud and stop pretending that the problem is the literally thousands of users who have problems using it?