"The new default in Git 2.x is ‘simple’. It means that when doing a git push without specifying a branch, only your current branch will be pushed to the one git pull would normally get your code from."
Hello? Why wasn't it called "current" instead of "simple"?
Why are these unintuitively named options so frequent in git?
Unfortunately, "current" was already taken with a different meaning. There are subtle differences between the different modes.
"current" means: push the current branch into a remote branch with the same name, no matter what.
"upstream" means: push the current branch into the upstream branch, that is the remote branch from which you pull the current branch.
"simple" means: push the current branch into the remote branch from which you are pulling, but only if they have the same name. This is supposed to be "more safe" for beginners than the "upstream" mode.
"Tracking means that a local branch has its upstream set to a remote branch."
edit two: second question. does 'simple' mean the same as 'upstream' as long as the upstream branch (the one you are tracking from) has the same name as your local branch? I believe so but thought I'd double check.
I have been using git for 4 years. I like it a lot more than svn. I never rebase. I still don't understand some of the things, like why they call it upstream, 'the branch you are pulling from', and tracking, when to me they all seem to mean the same thing.
Still pretty common if you contribute to repos which you don't have commit privileges to. Workflow is:
1. Clone library's master branch, begin using software.
2. Discover problem and commit a fix.
3. Use the Github webui to create a fork of the original repo.
4. git remote rename origin upstream
5. git remote add origin https://github.com/me/awesome-library
6. git push origin master:my-bug-fix
7. Use Github webui to create a pull request from your
my-bug-fix branch into the upstream master.
Having both remotes is necessary, though, when the thing you forked is being actively developed. If there's a review period of a few days, you may need to rebase from the upstream—you want to be doing this from the command line, not bumbling around in the Github webui trying to manage it there.
If it were called your "intuitive" name ("current", meaning "this is the current default"), then it would, extremely unintuitively, require renaming if it ever stopped being the default. You would be sacrificing future coherence for the sake of some very mild "intuitive sense" during the present.
Complaining about git's standard porcelain is a popular sport, but so often the people who play it don't give proposals that make more sense than the status quo.
> Complaining about git's standard porcelain is a popular sport, but so often the people who play it don't give proposals that make more sense than the status quo.
This is a classic case where the git behavior seems not just unintuitive, but far more complicated than necessary. Why do multiple modes even exist? If I were starting, I'd consider saying that "git push" with no other arguments is the same as what "current" (or even "simple") do now, but you could specify any number of branches or branch wildcards with an argument (including "*"). That is, like ls(1).
I could definitely be missing some important class of use cases, but this feels so much simpler than even having modes, let alone modes that have complex semantics, and still lets the default (very common) case work and supports pushing a manually-specified set of branches, too.
push.default
Defines the action git push should take if no refspec is given on
the command line, no refspec is configured in the remote, and no
refspec is implied by any of the options given on the command line.
Possible values are:
· nothing - do not push anything.
· matching - push all matching branches. All branches having the
same name in both ends are considered to be matching. This is
the default.
· upstream - push the current branch to its upstream branch.
· tracking - deprecated synonym for upstream.
· current - push the current branch to a branch of the same
name.
(yes, my version of git on this machine is out of date)
Emphasis on: "if no refspec is given on the command line, no refspec is configured in the remote, and no refspec is implied by any of the options given on the command line"
These modes define what happens if you give no options to git-push. If these modes didn't exist, then you would instead be complaining that a plain old `git push` with no arguments didn't "do what you clearly meant" (where "clearly meant" changes from user to user... particularly since different users have different workflows, some centralized, some not.)
If git-push worked as you suggest, then you would just be complaining that you had to escape your asterisks characters to prevent the shell from expanding them (remember that glob expansion is not something that ls provides...), instead of using a far simpler --all.
You want a legitimate complaint about git-push? Try: "git-add allows either --all or -A, but git-push only allows --all."
His proposal seems to be "call whatever happens to be the default 'current'". This of course gets you into a non-intuitive "The king is dead, long live the king" sort of situation.
You are assuming one specific reading, when there are at least two valid ones. The way I read the comment was basically to say, "Geez, what git calls 'simple' ('push the current branch into the remote branch from which you are pulling, but only if they have the same name. This is supposed to be "more safe" for beginners than the "upstream" mode.') sounds like it would be better-named as 'current'. Isn't this obvious to everyone, including the git developers? Why are these unintuitively named options so frequent in git?"
That said, I disagree with the sentiment, since there is already a 'current' mode to which the 'current' name seems to apply at least equally well.
I understand that blumentopf meant that "current" should mean "push the current branch", just like "simple" is documented to do. He didn't know that there are actually _two_ behaviors that "push the current branch", and one of them is named "current" whereas the other, new one, is named "simple" ...
A friend of mine said he contacted the people in charge and suggested some ways out of the counter-intuitiveness. He said they just didn't get it - if each feature works as specified, what's the problem?
We were burnt by this before -- someone did a "git push -f" thinking it would force push only their current branch. It ended up pushing everything including their master which was out of date, thus wiping out a whole bunch of newer commits. Luckily it was also easy to restore due to git's distributed nature.
It's not unreasonable to force push a branch. Anytime you've rebased but already pushed you would need to do so. I've worked on an open source project where every commit was required to pass all the tests, so if you submitted a PR that had any commit fail CI, you would have to alter history and force push.
I also just like pushing to a branch on Github, even if I might rebase later. Circle CI is triggered through Github, so it's nice to have that triggered for me. Our staging servers (production data, your branch's code) are deployed from Github branches as well. Plus looking at diffs on Github is really helpful for me to spot errors—I'm not sure if it's the context switch away from my text editor, Github's diff UI, or what, but it works for me.
> Anytime you've rebased but already pushed you would need to do so.
And that's also unreasonable. Pushed history should be treated as immutable. If you broke the build, push a revert commit, fix the issue, and resubmit. And then fix your tooling to recognize rollbacks.
I tend to treat the history of the master branch as immutable. Working with a remote branch that needs to stay up-to-date with master has, in my experience, required rebasing and force-pushing the branch.
In this case, the person probably thought he or she was pushing "feature-wip" or something similar after cleaning up that branch's history. Not necessarily unreasonable. If master is out of date then
git push -f
throws away any remote commits (under old behavior).
That's only if you have ssh access to the server. I don't think there's a way of seeing the reflog of a remote? I.e. if you're using github and the branch only lives there, can you undo an overwrite?
The 'server' in this case is a remote repository which has some commits you don't have. If you force push to this repository, these commits will be lost for you - only the person who pushed these or someone with access to the server can restore them.
I think every large team using Git has experienced the Git Force Push Master clusterfuck at least once. It's usually right after this that a mandatory gitconfig gets passed around.
If `git config receive.denyNonFastforwards true` is configured on the remote repository then this is prevented. This is the default on modern versions of Git.
I'm really pleased by this change. In my early days of git usage the asymmetry of git pull and git push confused me on several occasions, and I'm glad to see that git is willing to make breaking changes towards a cleaner interface.
As someone in still in early days of git usage (< 1 yr), I've found it quite confusing that pull doesn't pull every matching branch. I'm now sufficiently familiar with git to understand why, but it's sure been frustrating.
Could you please explain it? Because I don't get it. Git's (current) behavior seems exactly backwards to me. It seems to me that what you want is for push to default to the current branch, but pull to default to all branches. i.e. I want push to mean "push what I'm currently working on" and pull to mean "sync my repo's state to be as close as possible to the remote repo's state".
I think what you want in a pull is really just "git fetch", which will update all remote branches. In case you haven't realized this separation, try "git branch -av" to see that your local branch names are distinct from all the "remotes/*" branches. Also, if you have more than one remote repository location, not just origin, then "git remote update" will fetch them all.
Pull is basically the combination of fetch and merge into your local branch. Since there's always a chance for merging to fail and require fixup, it would be dangerous for pull to try all your local branches at once.
Ah, that makes sense, thanks. I guess I'm having a hard time getting out of the SVN mindset. I keep forgetting that there may not be any such thing as the remote repo, I can have different branches tracking different remote repos.
I always use "fetch" instead of "pull" for this reason--I want to update all my remote branches first, and then consider merging with local branches.
It seems that a lot of new git users default to "pull" and I'm not sure why. There must be some really popular tutorial out there that starts with pull.
"git pull" is the closest equivalent to what people are used to from many other source control systems where there is no concept of a local copy of remote branches.
Offtopic: I didn't know about `git branch -v`. Not something I needed enough to go looking for it, but nifty and good to know! Always learning more Git tricks :)
You can use the remote tracking branches if you don't want to make local commits and want them to be automatically updated by fetch. I.e.,
git checkout origin/interesting-branch
Git will warn you that you're in "detached HEAD" state. When you are making local changes or want to return to where you were, you don't want "git fetch" to have side-effects. Note that you can update local branches without switching to them:
git push . origin/branch-name:branch-name
will fast-forward you local 'branch-name' to match 'origin/branch-name'. It's basically the equivalent of
I like this change as well. My early days of git conditioned me to always add the remote and branch when pushing (ie git push origin master) as I did not like the implicit magic behind a bare "git push".
`git push origin master` will only push your master branch to origin. `git push` will push every branch that is tracking a branch on origin; so if you had commits on develop for example, they would also go up provided it was tracking the develop branch on origin.
Git v2 changes what `git push` does by default: only the current working branch will get pushed to origin.
>`git push` will push every branch that is tracking a branch on origin;
or rather, every branch that has the same name as a branch on currently tracked remote. I.e. if you're on branch X that tracks remote A, and both you and the remote have branches called Y and Z, even if Y and Z are marked to track B they will be pushed.
It's worth following Junio Hamano's Git Blame blog[1] to keep up with changes in git of this ilk. This particular item is old news in that regard, and a very welcome change at that.
This is amazing. Every person I have introduced to git is constantly confused by the 'rejected' error message returned when a local branch that is not their current working branch is out of sync with the remote, and they just want to push their current working branch.
I'd still be somewhat weary of doing a targetless force push. For example one may get used to the command and cause damage from a system with an older git.
Same here. It's easier to just always be explicit and avoid any possible weirdness. I think it's a personality trait thing, though... some people are ok with a certain level of "magic" in the form of implicit behavior, and some people like things to be very explicit.
Put me in the camp of people who generally prefer explicit over implicit. shrug
I've gotten in that habit as well, but then, I'm a neat freak when it comes to git, always using `git add -p` and filtering out any unrelated changes into different commits. I'm often dismayed how sloppy other programmers are with git :)
Commit messages like "Ugh, I really need to commit more often. Did X, Y, Z, and maybe some other stuff." make me cringe. Those people need this change the most!
I'm the same way. People look at me like I'm a pedant because I tell them to do another revision of their patch to fix whitespace errors or typos in their commit messages.
It also annoys me when people create a new commit to fix CR feedback instead of amending their non-public commit.
I like having `push.default=upstream` because it's like `simple`, just a little more powerful. With `upstream`, the branch you push to doesn't _need_ to have the same name as the branch you push from. With `simple`, it _does._
This is a great change. I had to learn to add the branch after a couple of bad experiences with bad git pushes. git push <repo> always seemed like it should just push the current branch.
This change of the default makes sense, and I kind of wonder why it wasn't the default in the first place. Kudos to making Git even better and easier for new people to get started.
That's not a direct quote, but consider that git subcommands are split into 'plumbing' and 'porcelain' and take a look at this chapter of the git book: http://git-scm.com/book/ch9-1.html
Hello? Why wasn't it called "current" instead of "simple"?
Why are these unintuitively named options so frequent in git?