As a former release manager I would like to defend the squashed commits.
It is much easier to handle cherry-picks and other merges for PR-s that
way. Though currect release process is not that merge intensive.
As of forced push, I'd be pragmatic. Do not do that on master, release
or a shared feature branches. And let it be Ok on your lone developed PR
backing branches on your fork.
On 11/18/19 6:10 PM, Tim Boudreau wrote:
I really don't see the point of squashing commits. I know, everybody would
like to look like they write perfect, concise, error-free code the first
time. But nobody does - and that seems to be the primary purpose. If you
want to see the set of changes that implement a feature, it's not that hard
to come up with an incantation of git diff -r that will let you do that -
and that kind of forensics as far less common - not something you should
contort your development process and spend work on to optimize. So it
seems to me, the main point of making commit history pretty is ego. Which
is a silly thing to get excited about.
-Tim
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
For additional commands, e-mail: dev-h...@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
