This is the mail archive of the
mailing list for the GCC project.
Re: Proposal for the transition timetable for the move to GIT
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: gcc at gcc dot gnu dot org,Joseph Myers <jsm at polyomino dot org dot uk>,Maxim Kuvyrkov <maxim dot kuvyrkov at linaro dot org>
- Cc: GCC Development <gcc at gcc dot gnu dot org>,Alexandre Oliva <oliva at gnu dot org>,"Eric S. Raymond" <esr at thyrsus dot com>,Jeff Law <law at redhat dot com>,Segher Boessenkool <segher at kernel dot crashing dot org>,Mark Wielaard <mark at klomp dot org>,"Richard Earnshaw (lists)" <Richard dot Earnshaw at arm dot com>,Jakub Jelinek <jakub at redhat dot com>
- Date: Thu, 26 Dec 2019 21:31:12 +0100
- Subject: Re: Proposal for the transition timetable for the move to GIT
- References: <20191216133632.GC3152@gate.crashing.org> <20191216135451.GA3142@thyrsus.com> <20191216140514.GD3152@gate.crashing.org> <alpine.DEB.email@example.com> <20191216153649.GE3152@gate.crashing.org> <firstname.lastname@example.org> <email@example.com> <20191225120747.GA96669@thyrsus.com> <firstname.lastname@example.org> <alpine.DEB.email@example.com> <20191226111633.GJ10088@tucnak> <5DCEA32B-3E36-4400-B931-9F4E2A8F3FA5@linaro.org> <alpine.DEB.firstname.lastname@example.org>
On December 26, 2019 5:58:22 PM GMT+01:00, Joseph Myers <email@example.com> 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
>https://gitlab.com/esr/reposurgeon/issues/219 anyway with a reduced
>for this oddity.
>> Reposurgeon uses $firstname.lastname@example.org 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 gcc.gnu.org,
>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 <email@example.com>
>> 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
><firstname.lastname@example.org>" (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).