Hi, Ricardo Wurmus <[email protected]> writes:
> Vagrant Cascadian <[email protected]> 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). I think we're just discovering the value of 'git merge' in the context of merging large (many commits) branches. Recording what and when it happened is their purpose, so we should use them in this case, it seems. Using git tags instead would be an ad-hoc (and inelegant, in my opinion) solution. -- Thanks, Maxim
