Vagrant Cascadian <vagr...@debian.org> writes:

Seeing big merges land, and wondering "what is the merge and what is just the usual churn on master" is pretty much a perpetual question for
me...

I feel the same. It was an even bigger problem in the past with core-updates merges where it would be very hard to figure out a "stable" commit for time travel amidst all those commits that lie just somewhere between merges.

I think your proposed solution of tagging things is a low-cost workaround. Using merge commits would also be nice (without necessarily abandoning the rebase workflow to keep history more understandable).

--
Ricardo

Reply via email to