On Fri, Mar 25, 2016 at 10:17 AM, Chris Hostetter <hossman_luc...@fucit.org> wrote:
> Ultimately that seems like history that should *not* be on the master > branch .. preserved, sure -- great even that it's in git and easily > browsable/comparable (unlike reivewing the evolution of patch files > attached to jira) but i don't see how every tiny commit made to the > feature branch over several months as designs evolved/changed and files > were added/removed is relevant to the master branch. > For me, I find it useful just to be able to identify the difference between a merge commit into the branch (ie syncing the branch up with master), vs another commit in the branch. This distinction can be useful eg when I see some odd looking code, and I want to identify if it was intentional, or possibly a mistake in merge resolution. It's not a perfect rule, it is gives me guidance on the probability of the reason for the suspicious code. I also think having large changes broken up is useful, even when not viewing with first parent. But it's a judgement call. If I have a tiny commit, and I tweak it maybe from a review comment, then I will usually squash. If I have a large commit I am working on, I try to make each commit make sense on its own, and I don't usually make lots of tiny commits. Again, that is just my style, so for me, keeping that history is useful. If you feel more comfortable squashing into one commit, go for it. I was only trying to explain why I thought it *can* be useful.
