On Mar 9, 1:27 pm, Junio C Hamano <gits...@xxxxxxxxx> wrote: > Dun Peal <dunpea...@xxxxxxxxx> writes: > That does not sound like a real world to me, though. When a fix or tweak > is needed for codepaths introduced by these feature branches after they > are merged to master, the cleanest thing to do is to queue the fix on top > of the branch that needs that fix or tweak, and merge that to master. > > Of course, you can choose to abandon these feature branches that are > potentially buggy and fork a fix branch from the master branch that was > current when the bug happened to be discovered. But that would make the > backporting bugfixes (or feature tweaks for that matter) to anything older > a lot harder. That's a good point if feature branches may eventually get merged into other branches, e.g. release branches. Our case is simpler: a feature branch that branched off master will only get merged back to master, usually in one merge action that ends the branch. Therefore any future fixes or updates to content that got merged like that can properly be committed directly to master. Of course, if we did need to merge the feature independently into other branches, the squashed branch and any future updates to it would have to be manually cherry-picked - an error prone process that forgoes many amenities that Git offers for this procedure. However, since we do not have such a need, might as well optimize for commit graph simplicity. We probably could find ways to deal with a ~50-level-deep commit graph (composed of 1 master and ~49 feature branches), but if we can instead deal with a single-level-deep one (or 2-3 levels when we introduce a couple of long-running branches), why shouldn't we? > > Why would John care that while implementing feature X, Jill committed > > her half-state Y so she can go home, or made and fixed typo Z? In > > fact, why would Jill care a day, let a lone a couple of months, after > > X was completed and merged to master? > > Who is merging half-state to 'master' or merging 'master' back to the > feature branches? I don't think any of the above relates to the topic of > 'merge --squash' anyway... If Jill merged her branch X back to master with no squashing, half- state Y which got committed in X gets merged to master as well. Half-states like Y get committed to feature branches all the time, since those branches are private, never get deployed in production or even built by the continuous integration server; the feature branch is all about developer convenience, and we're only strict about what he merges back into master. Of course, Jill can selectively squash with `rebase -i` X to a more presentable form before merging it back to master. But if she's already squashing, why not use the ultimate, simplest squash offered by `rebase --squash`, as it happens to perfectly fit the purpose of our short-term feature branches? D. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html