Only You Can Prevent git Merge Commits | Hacker News Reader

Only You Can Prevent git Merge Commits

viget.com

26 pointscrnixon16 comments

Git tries pretty hard to avoid this now; it won't treat fast-forwards as merge commits, it will just fast-forward you. Apparently this was not always the case.

Anyway, "git pull --rebase" is your friend. (And so is "git push --force". git pull will DTRT on the other end, so this shouldn't mess anyone else up.)

And so is "git push --force".

Wait, what? I thought you were supposed to avoid "push --force" when pushing to a public repo?

It doesn't break git, but it may confuse your contributors.

I'm thinking that he means, if everyone is doing git pull --rebase then a git push --force won't screwup the people you are sharing with.

My manpages still seem to warn against using both commands, but I'm locally running on a version dated 2/09/2009 (I have a cronjob at work that pulls down the latest version of git and compiles it daily).

[edit] Maybe by 'do the right thing' he means that it won't overwrite their local history (i.e. the pull/merge will fail because the histories are different)

All I know is that I "git push --force" all the time, and it has never caused anyone tracking my repositories to complain or stop sending me patches. I assume this means git handles it fine. (I just tested this, and git does handle it fine. It says "forced update", and everything works normally. The reflog stores the old pre-force-push tree still, so you are free to revert and push -f the "old" tree, if you really feel the need to.)

Anyway, "git push --force" has the potential to lose data, but less potential than "rm -rf .". You will destroy your central repository, not anyone's actual work. ("Destroy your central repository" sounds bad, but isn't. The important copy is the one on your disk.)

A clean history is better than never using "push -f" IMHO. The manual authors apparently disagree.

> The manual authors apparently disagree.

Pushing doesn't always mean to a central repository. Since there is no distinction, you could be git pushing while on a branch that is tracking a topic branch in someone else's local (local to them) repo.

Pushing to non-bare repositories is always considered harmful.

Totally with you on git pull --rebase. Thing is great. More skeptical on git push --force, I think it's better to just revert/make new commits to fix your screwups.

please don't "git push --force" unless you know what it's doing, people - you will lose work and people will get really confused. the --force should never be necessary, even when using 'pull --rebase'. the push command normally will refuse to push unless the latest commit on the server is in your history somewhere. this means that if someone pushes since you last pushed or fetched, introducing commits you have not seen yet, and you try to push, it will not let you until you have pulled them down and either rebased your local work on top of it or merged your work with it.

'--force' overrides this check, pushing anyways, effectively losing (possibly multiple) commits on the server. it should only be used if you were forced to change your history somehow (removing files with a password in it, rewinding work in an emergency), it should almost never be used and there should be a really good reason for it. i've used it maybe a dozen times last year of the thousands of pushes i've done.

I liberally rewrite my history; this is why I push --force. I don't view version control as an auditing tool, I view it as a debugging tool. YMMV.

if you are the _only_ person with push access to your repo, then that's fine. i just don't want other people reading this that collaborate with people on repos that multiple devs have push access to thinking that --force is fine to use, because it will lose commit data.

I've read a number of times that you should never rebase commits that other people may have fetched already. Is this a possible danger here, or will git only rebase your strictly-local commits?

It will only rebase your local commits.

That doesn't necessarily help you. If somebody has pulled from you, you'll rebase your supposedly local commits and screw over the person who pulled from you.

Whenever you're rebasing, you should make sure you understand how git works and what the consequences are.

it's funny how some people hate merges and want to do everything with rebasing and fast-forwarding (like this) and others hate ff-ing and think everything should be done with merges to maintain branch history (http://nvie.com/archives/323 thinks the '--no-ff' option should be the default).

personally, i use a combination - i tend to rebase when it's only a couple of commits and i merge when there are dozens of commits off, whichever is easier/cleaner. if there are likely going to be conflicts to resolve, rebase is often a bit more difficult, and people tend to have a harder time understanding rebase conceptually so i tend not to encourage it's use to beginners. however, it's interesting to see how each person subtly differently sees how the world of VCS should be, and how Git makes it relatively easy to have such different workflows.

I've been using git-up (http://github.com/aanand/git-up) for a while now - it takes care of rebasing _all_ of your tracking branches, as well as stashing & unstashhing any local, uncommitted changes you may have lying around.

Reply on news.ycombinator.com