This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Proposal for the transition timetable for the move to GIT
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