3 ms·

Ok so let me post an opinion from the other side. I think that histories that represent actual history in git are actually not useful at all. Let's look at an e

by jenius 13y ago

Ok so let me post an opinion from the other side. I think that histories that represent actual history in git are actually not useful at all. Let's look at an example. I make a commit that introduces a bug and contains a typo. Someone else points out the bug, so I fix the bug. Then someone else points out the typo so I fix the typo, one small commit for each fix. While this is indeed an accurate depiction of history, having three commits (one broken, and two silly short one character/line changes) in your commit history instead of one commit is not in any way useful here. For anyone reviewing a pull request or doing anything else that involved looking through the history (that's what history is for, right?), this is a waste of time, and unnecessarily sloppy. Or if you need to cherry-pick or bisect, for example, you now have three commits that represent one change, rather than one commit for one change. Let's say someone makes a pull request to one of my projects for a change they made that ends up having 5 commits fixing things they did wrong initially, that could be 1 or 2 commits. There is zero chance I'm going to say "Ah well, I guess that's an accurate representation of history! Let's merge it!" I'm going to tell them to squash and rebase their commits to clean it up, then force push. And to be honest, I think anyone who didn't do this would be doing it wrong, promoting a messy history in their project. Generally, this whole debate within git is referred to as whether you should "hide the sausage" or not. Further discussion can be found here, with lots of arguments I didn't touch on at all in this comment: http://sethrobertson.github.io/GitBestPractices/#sausage http://sethrobertson.github.io/GitBestPractices/#sausage

sergiosgc 13y ago
In the precise case of the bug and typo, you should probably use git commit --amend. Anyhow, generically, while your changes are local, rewrite history to your hearts content. Have it tell a development story that makes sense. The real important part is: you can rewrite history only while it is private. When you push the commits, never ever rewrite history. Namely, rebasing is not a replacement for merging.
- kmowery 13y ago
  git commit --amend is rewriting history, just not very much of it. If you --amend after pushing, you run into the exact same problems mentioned before.
  - sergiosgc 13y ago
    Yes, of course. I failed to mention that.
snth 13y ago
Haha, I think you meant "hide the sausage making".
- benrhughes 13y ago
  ROFL, yes - "hide the sausage" has quite a different meaning. Though you could argue that rebasing is, um, hiding the sausage with history.
ender7 13y ago
Once you push a change to a public repo, you should not change it. It sucks that it's broken, but that's your fault; you should either roll back your change or submit a second change that fixes it. However, you shouldn't rebase your second change onto your first one. There be dragons. If you want to have a perfect public repo history, you can revert your change, fix it in private, then push the modified version to the public repo.
- dbaupp 13y ago
  "Once you push to a shared branch in public repo" rebasing and force pushing feature branches is OK (how else does one maintain a clean history after code-review?).
pierrebai 13y ago
Every times I hear these sort of justification my little rage meter goes up a notch. These arguments are all based on unverified and unncessary optimizations. * How many times have you read a project history commit by commit? How much time the occasional typo-commit took you to read? The probalbe answer, if measure would be negligible. Yet you're ready to spend time rewiting history. Which can cause real and known time wate as people have to rebase remerge, and sometimes cause all the problem that have been outlined. * The whole point of bisect is using a logarithmic search into history. The rare typo-fix commit won't affect its runtime. Again, this is wasting time for no measurable effect. * Stop the micro-fixing commit already in the first place! But what really annoys me is that all these are the symptoms of a deeper disease: mis-managed repos. This first thing to do if you have the legendary 50GB log show up in your repo is not to rewrite history. The first thing to do is to make an urgent note to review your repo management processes. How did that file get in there in the first place? Are you pulling directly in your main repo!? The correct practice is to always pull into a staging repo and only merge into main if clean. How do you know it's clean? Easy: use the double-staging repo trick: pull into a staging repo make sure everything is shape (human manual process) then pull into another clean-from-main staging repo and diff the history. If the diff is not empty, you know something is wrong. Only when diff are clean do you pull from that staging repo into main. (BTW, that double staging is only necessary if you allow yourself to do cleanup in the staging repos. If you always insist on clean pull, then all the cleaning up is done elsewhere. This is not always possible / easy /efficient to do on busy repo. And on your private working repo, do as you please, as long as the pull then comes off clean.) (Also, I recommend doing the same on your private working repo. I always find it easier to have clean copy of the main repo, one staging repo where my own cersion of clean-up history is kept and the real dirty-work repo yet a third repo. The fact that I prefer to work with mercurial which works best by cloning rather than branching pretty much enforce this discipline. It promotes happy collaborations since you never pull into your work repo and you never push from it.)
- nathanvanfleet 13y ago
  The more I read about this stuff the more I realize there are a lot of ways to manage things that fall entirely outside of the actual software that does the management. We're going into the muddy waters of "best practices" but it's interesting to read about different implementations.

by jenius 13y ago

sergiosgc 13y ago

In the precise case of the bug and typo, you should probably use git commit --amend. Anyhow, generically, while your changes are local, rewrite history to your hearts content. Have it tell a development story that makes sense. The real important part is: you can rewrite history only while it is private. When you push the commits, never ever rewrite history. Namely, rebasing is not a replacement for merging.

kmowery 13y ago
git commit --amend is rewriting history, just not very much of it. If you --amend after pushing, you run into the exact same problems mentioned before.
- sergiosgc 13y ago
  Yes, of course. I failed to mention that.

snth 13y ago

Haha, I think you meant "hide the sausage making".

benrhughes 13y ago
ROFL, yes - "hide the sausage" has quite a different meaning. Though you could argue that rebasing is, um, hiding the sausage with history.

ender7 13y ago

Once you push a change to a public repo, you should not change it. It sucks that it's broken, but that's your fault; you should either roll back your change or submit a second change that fixes it. However, you shouldn't rebase your second change onto your first one. There be dragons. If you want to have a perfect public repo history, you can revert your change, fix it in private, then push the modified version to the public repo.

dbaupp 13y ago
"Once you push to a shared branch in public repo" rebasing and force pushing feature branches is OK (how else does one maintain a clean history after code-review?).

pierrebai 13y ago

Every times I hear these sort of justification my little rage meter goes up a notch. These arguments are all based on unverified and unncessary optimizations. * How many times have you read a project history commit by commit? How much time the occasional typo-commit took you to read? The probalbe answer, if measure would be negligible. Yet you're ready to spend time rewiting history. Which can cause real and known time wate as people have to rebase remerge, and sometimes cause all the problem that have been outlined. * The whole point of bisect is using a logarithmic search into history. The rare typo-fix commit won't affect its runtime. Again, this is wasting time for no measurable effect. * Stop the micro-fixing commit already in the first place! But what really annoys me is that all these are the symptoms of a deeper disease: mis-managed repos. This first thing to do if you have the legendary 50GB log show up in your repo is not to rewrite history. The first thing to do is to make an urgent note to review your repo management processes. How did that file get in there in the first place? Are you pulling directly in your main repo!? The correct practice is to always pull into a staging repo and only merge into main if clean. How do you know it's clean? Easy: use the double-staging repo trick: pull into a staging repo make sure everything is shape (human manual process) then pull into another clean-from-main staging repo and diff the history. If the diff is not empty, you know something is wrong. Only when diff are clean do you pull from that staging repo into main. (BTW, that double staging is only necessary if you allow yourself to do cleanup in the staging repos. If you always insist on clean pull, then all the cleaning up is done elsewhere. This is not always possible / easy /efficient to do on busy repo. And on your private working repo, do as you please, as long as the pull then comes off clean.) (Also, I recommend doing the same on your private working repo. I always find it easier to have clean copy of the main repo, one staging repo where my own cersion of clean-up history is kept and the real dirty-work repo yet a third repo. The fact that I prefer to work with mercurial which works best by cloning rather than branching pretty much enforce this discipline. It promotes happy collaborations since you never pull into your work repo and you never push from it.)

nathanvanfleet 13y ago
The more I read about this stuff the more I realize there are a lot of ways to manage things that fall entirely outside of the actual software that does the management. We're going into the muddy waters of "best practices" but it's interesting to read about different implementations.