Only You Can Prevent git Merge Commits
1–10 of 17 posts
Re: Only You Can Prevent git Merge Commits
#2Git 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.)
Re: Only You Can Prevent git Merge Commits
#3I'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?
Re: Only You Can Prevent git Merge Commits
#4I'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.
Re: Only You Can Prevent git Merge Commits
#5Git 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?
Re: Only You Can Prevent git Merge Commits
#6Git 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.
Re: Only You Can Prevent git Merge Commits
#7Git 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?
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)
Re: Only You Can Prevent git Merge Commits
#8Earlier quoted context omitted.
And so is "git push --force". Wait, what? I thought you were supposed to avoid "push --force" when pushing to a public repo?
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 l…
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.
Re: Only You Can Prevent git Merge Commits
#9Earlier quoted context omitted.
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 l…
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 fe…
> 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.
Re: Only You Can Prevent git Merge Commits
#10Earlier quoted context omitted.
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 fe…
> 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.
Pushing to non-bare repositories is always considered harmful.