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: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

> On Aug 2, 2019, at 11:41 AM, Maxim Kuvyrkov <> wrote:
>> On Aug 1, 2019, at 11:43 PM, Jason Merrill <> wrote:
>>> Unfortunately, current mirror does not and could not account for rewrites of SVN commit log messages.  For trunk the histories of diverge in 2008 due to commit message change of r138154.  This is not a single occurrence; I've compared histories only of trunk and gcc-6-branch, and both had commit message change (for gcc-6-branch see r259978).
>>> It's up to the community is to weigh pros and cons of re-using existing GCC mirror as conversion base vs regenerating history from scratch:
>>> Pros of using GCC mirror:
>>> + No need to rebase public git-only branches
>>> + No need to rebase private branches
>>> + No need to rebase current clones, checkouts, work-in-progress trees
>>> Cons of using GCC mirror:
>>> - Poor author / committer IDs (this breaks patch statistics software)
>>> - Several commit messages will not be the current "fixed" version
>>> Thoughts?
>> I'm still inclined to stick with the mirror.  I would expect patch
>> statistics software to be able to be taught about multiple addresses
>> for the same person.
> Patch tracking software breaks on emails like <fxcoudert@138bc75d-0d04-0410-961f-82ee72b054a4> , where 38bc75d-0d04-0410-961f-82ee72b054a4 is not a reasonable domain name.
> For completeness, I'll generate and upload a repo based on current mirror with all branches and tags converted.

Yeah, this didn't worked as well as I hoped.  Current gcc git mirror has wrong history for branches that followed scenario:
1. create $branch from $base at revision N
2. commit WORK on $branch
3. delete $branch
4. create $branch from $base at revision N+M
5. rebase WORK on current $branch

Current mirror connects histories of two versions of $branch, and we get wrong history.  In step (4) instead of plain history of $base we get a commit merging histories of $branch just before deletion and $base at revision N+M.

There are many branches like this, e.g., branches/gccgo.

Maxim Kuvyrkov

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