lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Ernst <r...@iernst.net>
Subject Re: Git Policy/Preference: how to fold in feature branches? squash?
Date Fri, 25 Mar 2016 17:38:38 GMT
On Fri, Mar 25, 2016 at 10:17 AM, Chris Hostetter <hossman_lucene@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.

Mime
View raw message