Proposal for the transition timetable for the move to GIT

[Segher Boessenkool]

On Fri, Dec 27, 2019 at 11:21:41AM +0000, Richard Earnshaw (lists) wrote:
> On 26/12/2019 18:59, Joseph Myers wrote:
> > On Thu, 26 Dec 2019, Jakub Jelinek wrote:
> >> Yes, I'd prefer the trunk to have no merge commits (in svn I've removed the
> >> svn:mergeinfo property on the trunk when it appeared too).
> > 
> > I've added the unmerge commands for the three commits in question to 
> > gcc.lift.
> 
> I'm not really sure I understand why we don't want merge commits into
> trunk, especially for large changes.  Performing archaeology on a change
> is just so much easier if the development history is just there.
> 
> Without the merge information, if you're tracking down the reason for a
> bug, you get to the merge, and then have to go find the branch where the
> development was done and start the process all over again.  With merge
> information, tools like git blame will show which commit during
> development touched the relevant line last and a major step in analysis
> is vastly simplified.

Archaeology is much simpler still if people do not do merges at all, but
use a rebase (or rebase-like, e.g. quilt) workflow.  That way, there are
no bad changes that have to be undone later, etc.  Ideally everything
comes in as small, well thought out patches.


Segher