
Only You Can Prevent git Merge Commits - crnixon
http://www.viget.com/extend/only-you-can-prevent-git-merge-commits/
======
jrockway
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.)

~~~
tlrobinson
_And so is "git push --force"._

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

~~~
pyre
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)

~~~
jrockway
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.

~~~
pyre
> _The manual authors apparently disagree._

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

~~~
jrockway
Pushing to non-bare repositories is always considered harmful.

------
r00k
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?

~~~
crnixon
It will only rebase your local commits.

~~~
jmtulloss
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.

------
schacon
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.

------
jperras
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.

