This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

On December 26, 2019 5:58:22 PM GMT+01:00, Joseph Myers <> wrote:
>On Thu, 26 Dec 2019, Maxim Kuvyrkov wrote:
>> Reposurgeon creates merge entries on trunk when changes from a branch
>> are merged into trunk.  This brings entire development history from
>> branch to trunk, which is both good and bad.  The good part is that
>> get more visibility into how the code evolved.  The bad part is that
>> get many "noisy" commits from merged branch (e.g., "Merge in trunk" 
>> every few revisions) and that our SVN branches are work-in-progress 
>> quality, not ready for review/commit quality.  It's common for files
>> be re-written in large chunks on branches.
>Seeing "noisy" or possibly confusing commits in "git log" output for 
>master is simply a consequence of the possibly confusing defaults for
>git log behaves (showing all commits in the ancestry in reverse
>date order).  I often find "git log --first-parent" output less
>when dealing with any git repository making heavy use of branches (but 
>there are other options as well to control how it shows such
>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 

We've never wanted merge properties on trunk, even deleted them from time to time. And I don't think we want any merge commits to appear in git for this reason
(non-official branches might be fine). 


>"unmerge" command in gcc.lift to stop the few commits in question from 
>being merge commits (while keeping all other merges as-is).  (The
>of trunk into other branches that copied merge properties from trunk
>those branches will still be handled correctly, with exactly two
>rather than regaining the extra parents corresponding to the merges
>trunk that Bernd noted in an earlier version of the conversion, because
>the processing that avoids redundant merge parents takes place well
>any unmerge commands are executed - so at the time of that processing, 
>reposurgeon knows that those other branches are in fact in the ancestry
>trunk, even if we remove that information in the final git repository.)
>> Also, reposurgeon's commit logs don't have information on SVN path
>> which the change came, so there is no easy way to determine that a
>> commit is from a merged branch, not an original trunk commit. 
>I think it's idiomatic in git for a branch commit not to say "this is a
>commit on X branch", i.e. this is a general property of branchy git 
>histories (and unmerge is the solution if we don't want a branchy
>of master, or use of smarter git tools for viewing the history that
>may well make more use of when dealing with repositories with that kind
>> It appears that .gitignore has been added in r1 by reposurgeon and
>> deleted at r130805.  In SVN repository .gitignore was added in
>> I speculate that addition of .gitignore at r1 is expected, but it's 
>> deletion at r130805 is highly suspicious.
>I suspect this is one of the known issues related to
>.gitignore files.  Since such files are not really part of the GCC 
>history, and the .gitignore files checked into SVN are properly
>as far as I can see, I don't think it's a particularly important issue
>the GCC conversion (since auto-generated .gitignore files are only 
>nice-to-have, not required).  I've filed 
> anyway with a reduced
>for this oddity.
>> Reposurgeon uses $ for committer email addresses even
>> when it correctly detects author name from ChangeLog.
>I think that's logically accurate (and certainly harmless) as a 
>description of commits made to a central repository on, 
>although using committer = author would also be OK.
>> == Bad summary line ==
>> While looking around r138087, below caught my eye.  Is the contents
>> summary line as expected?
>> commit cc2726884d56995c514d8171cc4a03657851657e
>> Author: Chris Fairles <>
>> Date:   Wed Jul 23 14:49:00 2008 +0000
>>     acinclude.m4 ([GLIBCXX_CHECK_CLOCK_GETTIME]): Define
>Yes.  This seems to be Richard's script working exactly as intended, by
>extracting the first bit of the ChangeLog entry *after* the date/author
>header as a better description than "2008-07-23 Chris Fairles 
><>" (i.e. it certainly gives more distinctive 
>information about the commit and is more useful than having a
>line as the summary line).  I don't think it's a bad summary line (but 
>Richard's script supports hardcoding new summary lines for individual 
>commits where desired).

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]