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