> And if I push without first pulling, must it always punish me with a merge commit? Can't I say "oh shit I don't want to do this, go back and git pull"?

This is a source of probably 50% of my "ah, fuck, time to undo..." moments with git, these days. I hate that shit. Muscle-memory gets ahead of me and I commit on a shared remote branch, which would be fine given our workflow except that I didn't pull first. What a pain in the ass.

I have this in my .gitconfig so the pull will fail rather than merge.

    [pull]
        ff = only

If it does fail I can decide whether to merge or rebase.

I guess I have `git pull --rebase` as muscle memory.

I would guess there's an easy way to make git do this automatically for you via config so you never forget, but I just never, ever `git pull`

Or:

> git config --global alias.up '!git fetch && git rebase --autostash FETCH_HEAD'

From:

https://github.com/JKrag/git-up

git config --global pull.rebase true

You probably also want:

git config --global rebase.autostash true

For the sake of your coworkers (and your future self), please don't lie just to make your history look pretty.

I try to make each commit a snapshot of a working repository (compileable or runnable or testable, whatever is the heuristic for working) where the difference between each snapshot can be explained by the commit message. Ideally they are isolated to a single logical "unit" of change (fix, refactor, add, remove). The goal here being to minimize the amount of confusion and work for anyone traveling up and down the tree. I often have to rewrite my local history to make this happen, because the actual changes that I make can happen in a somewhat arbitrary order. How has local history revision bitten you?

Rebasing leads to either having long stretches of non-compiling commits in history or giant non-bisectable commits. E.g. you added a method call on your feature branch, that method was renamed in master while you were working on your feature. If you merge then your commits still compile and I can use automated `git bisect` the way it's intended. If you rebase then your commits don't compile and I can't bisect through commits on your feature branch. If you squash then your whole feature development becomes a single monster commit and I can't bisect through it.

I agree with having as many commits as possible be compilable, but that's not the sole criterion, because there's a tension between that and having granular history: if you squash the whole history of the repo into a single commit then that means 100% of commits are compilable, but it's still a bad move. Conversely, a non-compiling commit in between two compiling commits is not a big problem (you just make sure your git bisect script skips non-compiling commits) - what really matters is keeping the diff between two successive compiling commits as small as possible. IME the best way to achieve that is never rewriting history.

That's a very good point with rebasing. Thanks for explaining.

It is for this reason that I have changed my workflow to always stash first, then pull, then pop the stash and do the merges locally, then push.

And always diff before stash because sometimes it's just random shit I wasn't serious about, so I'll re-checkout that file and then stash the rest.

> And if I push without first pulling

I think I know git well, but you got me confused. I've never heard of pushes causing merges. Surely you are talking about pulls, right?

push causes the error, the resolving pull creates the merge; the correct resolution has been pointed out as git pull --rebase but most people don't realize this.

Maybe somebody who has a habit of using --force when pushing. A major downside of rebase-centric workflows is that it teaches you to ignore the safety rails when pushing, or when deleting branches.

`--force-with-lease` would fix this problem (it needs an alias). Also, `--force` wouldn't cause a merge commit; it would overwrite the remote changes.

The only theory that makes sense is that this person doesn't know how to `pull --rebase`, but the order of `push` vs `pull` wouldn't change the presence of merge commits, so I'm still confused.

I don’t know git well, but I often run into the problem being discussed.

If I pull from origin before making my changes, I don’t have to merge, obviously.

But correct me if I’m wrong: I think that if I don’t pull first, but my changes don’t conflict with any part of what was done by the previous commit(s) I missed, I’ll still have to merge if I touched a file they touched.

This is a common scenario for me. Correct some typos in comments for example, and I get forced to figure out how to merge using vim, which I don’t know how to use at all (being a nano user). I’m sure I could and should switch to at least using nano by default, but I don’t know how merging really works, either.

What I really want to do is undo my commit, pull, and redo my commit. Then I don’t have to figure out git merge.

> I don’t know git well, but I often run into the problem being discussed.

I do understand the problem being discussed; what I don't understand is what it has to do with pushing first. You have the same problem no matter which order you use `git push` vs `git pull`.

> I think that if I don’t pull first, but my changes don’t conflict with any part of what was done by the previous commit(s) I missed, I’ll still have to merge if I touched a file they touched.

Yes, that's true.

> What I really want to do is undo my commit, pull, and redo my commit. Then I don’t have to figure out git merge.

You can do that with `git pull --rebase`, which, as others have mentioned, you can set as the default behavior of `git pull` like this:

https://news.ycombinator.com/item?id=27581416

Ooh, --force-with-lease looks like a nice feature, especially for updating github PRs that aren't yet merged. I still wouldn't want to use it where anybody else has a copy of the changes, since that's where you need a merge commit to avoid breaking somebody else's repo, but that gives me a safer option than a blind --force.

Just remember that --force-with-lease only protects you from overriding commits you have not yet fetched.

Wait, what? I've probably been using Gerrit too long but why do you ever need force in a rebase workflow?

These may be specific to a workflow with git + github, when using git from the command line, but here are the cases I've run into where overriding safeties is needed.

1. After making a PR, there are conflicts when merging into main. In a merge-based workflow, I would merge main into the feature branch, resolve any conflicts, then push. In a rebase-based workflow, I rebase the branch onto main, resolve any conflicts, but now I need to push --force. As some of the other comments have mentioned, this can be improved with --force-with-lease, but still isn't the greatest.

2. After making a PR, there are some typos that need to be fixed. Fix these in an interactive rebase, to edit the same commit that introduced the typos. Also requires either --force or --force-with-lease.

3. When the PR is accepted, the result is rebased on top of main. My local branch still exists, and must be deleted. I would prefer to use `git branch -d` to delete the feature branch, but this rightfully says that the feature branch hasn't been merged in. I instead need to use `git branch -D` to forcefully delete it, introducing a point of human error. (There are some cases where git can delete the branch safely, which I think occurs either when the feature branch has only a single commit, or when the feature branch can be applied on top of main without a rebase, but I haven't exactly determined it.)

#1 and #3 are cases where a safer option cannot be used due to a rebase-workflow. #2 would exist in either case, since even in a merge workflow, rebasing of branches before they are pulled makes sense to do.

> There are some cases where git can delete the branch safely, which I think occurs either when the feature branch has only a single commit, or when the feature branch can be applied on top of main without a rebase, but I haven't exactly determined it.

FWIW: it occurs when the feature branch was based on the tip of master (because no-one else has committed to master since you branched/since you rebased onto master) - in this case rebasing your feature branch onto master is a no-op and the commits that go into master have the same hashes as they had on your feature branch.

I usually use `git pull -r` to rebase upstream changes

Git init inits a git repo.

Git submodule runs commands on submodules.

What is hard about this UX?

And it's not punishing you, its doing what you asked, to pull into a non matching head, how does it know you're not using git in the intended and distributed way?

Btw, just quit the editor without saving, it aborts.

The "intended" way generates a completely spurious merge commit - it doesn't represent a real commit, and rarely do you care about keeping track of merges into a short lived branch which are already tracked on master.

Most people want a single source of truth workflow that corresponds to the old total ordering imposed by svn or p4.

> The "intended" way generates a completely spurious merge commit - it doesn't represent a real commit, and rarely do you care about keeping track of merges into a short lived branch which are already tracked on master.

On the contrary, you want those commits for bisection, which is the main reason to have a VCS history at all.

> Most people want a single source of truth workflow that corresponds to the old total ordering imposed by svn or p4.

People think they want that, but I've never seen a convincing case for why. Bisect works better if you use merge. Blame works better if you use merge. And if you really want to see the history without merges (why?), it's one flag to do that.

So use svn?

I would, but the option is not mine to make.

[misunderstanding removed]

I think they mean the commit message editor, which git will use to open a temp file to save the message to if you don't specify a message in-line with the "-m" flag when committing, including when a merge commit is initiated by a "pull". This happens on the CLI, it's just usually (though doesn't have to be!) a command line editor that it opens. I think vim's a common default.

AFAIK whatever's opened does need to block the CLI, so you can't use a command that opens a GUI editor then returns immediately or git will interpret that as your having closed the file without saving, but otherwise any editor should work, CLI or GUI, and can be assigned in your git config.

In a thread about common sources of confusion, I think it would be more helpful to leave the misunderstanding so others might learn from it. Ie, edit to add "this is a misunderstanding" to the top, not replace it entirely.

Git invokes an editor, for writing commit messages, etc. (it looks in the VISUAL and EDITOR env vars). That could be a GUI text editor, or something running in the CLI (personally, I use emacsclient to open a new buffer in an existing Emacs window)

What they're saying is: if you quit that editor without saving the commit message, git will abort.

You can also quit the CLI editor, e.g. vim.