Re: Proposal for the transition timetable for the move to GIT

[Andrew Pinski <pinskia@gmail.com>]

On Fri, Dec 27, 2019 at 3:22 AM Richard Earnshaw (lists)
<Richard.Earnshaw@arm.com> wrote:
>
> On 26/12/2019 18:59, Joseph Myers wrote:
> > On Thu, 26 Dec 2019, Jakub Jelinek wrote:
> >
> >> On Thu, Dec 26, 2019 at 04:58:22PM +0000, Joseph Myers wrote:
> >>> If we don't want merge commits on git master for the cases where people
> >>> put merge properties on trunk in the past, we can use a reposurgeon
> >>> "unmerge" command in gcc.lift to stop the few commits in question from
> >>> being merge commits (while keeping all other merges as-is).  (The merges
> >>> of trunk into other branches that copied merge properties from trunk into
> >>> those branches will still be handled correctly, with exactly two parents
> >>> rather than regaining the extra parents corresponding to the merges into
> >>> trunk that Bernd noted in an earlier version of the conversion, because
> >>> the processing that avoids redundant merge parents takes place well before
> >>> any unmerge commands are executed - so at the time of that processing,
> >>> reposurgeon knows that those other branches are in fact in the ancestry of
> >>> trunk, even if we remove that information in the final git repository.)
> >>
> >> 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.

The one branch merge which would have helped me track down why a
testcase was added is the tree-ssa branch merge.  If we had the commit
for the merge to have the merge info, it would have been easier for me
to track down that.  Note this testcase failed with a new patch I am
working on and I decided in the end, the testcase is bogus and not
even testing what it was testing for anyways.  There is a few other
instances like that which would have been helpful.

Thanks,
Andrew Pinski

>
> R.