Andreas Schwab :
> On Dez 25 2019, Eric S. Raymond wrote:
>
> > That's easily fixed by adding a timezone entry to your author-map
> > entry - CET, is it?
>
> The time zone is not constant.
Congratulations, you have broken one of reposurgeon's assumptions.
It is possible to use reposurgeon;d DSL
Joseph Myers :
> reposurgeon results are fully reproducible (by design, the same inputs to
> the same version of reposurgeon should produce the same output as a
> git-fast-import stream,
Designer confirms, and adds that we gave a *very* stringent test suite
to verify this.
Much of it consists o
Richard Earnshaw (lists) :
> Well, personally, I'd rather we didn't throw away data we have in our
> current SVN repo unless it's unpresentable in the final conversion.
I agree with this philosophy. You will have noticed by now, I hope,
that reposurgeon peserves as much as it can, leaving deletion
Maxim Kuvyrkov :
> Removing auto-generated .gitignore files from reposurgeon conversion
> would allow comparison of git trees vs gcc-pretty and gcc-reparent
> beyond r195087. So, while we are evaluating the conversion
> candidates, it is best to disable conversion features that cause
> hard-to-wor
Snapshot gcc-8-20191227 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/8-20191227/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 8 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-8
On Fri, 27 Dec 2019, Andreas Schwab wrote:
> SVN also only has a committer, so the fabricated author should not be
> influenced by the committer.
That issue has been fixed.
--
Joseph S. Myers
j...@polyomino.org.uk
On Dez 25 2019, Eric S. Raymond wrote:
> That's easily fixed by adding a timezone entry to your author-map
> entry - CET, is it?
The time zone is not constant.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now fo
On Dez 25 2019, Joseph Myers wrote:
> On investigation, I think you are referring to the conversion of r269472.
> That was committed for you by Jim Wilson and thus has you as author and
> Jim Wilson as committer and Jim Wilson's timezone entry has been applied.
> So the argument here is that
Email addresses from the ChangeLog files are not validated during
commits, so a number of typos exist in the extracted data. I've
extracted the 'Author:' entry from a prototype conversion and then piped
that through sort and uniq -c. Subsequent analysis shows the following
addresses/names that ar
Hi!
On Fri, Dec 27, 2019 at 12:44:25PM -0500, David Malcolm wrote:
> I'm wondering what the plan is for the git-only branches currently
> hosted on the gcc.gnu.org git server.
Those should be pretty trivial to convert, *if* the chosen conversion
does not change file contents at all (it shouldn't)
On Fri, 27 Dec 2019, Richard Biener wrote:
> Does this allow to keep the URL of the old git mirror and the new
> official fit repo the same or would that cause conflicts with existing
> clones?
The URL of the old mirror feels like it's the right URL to use for the new
conversion. It would cau
On December 27, 2019 6:58:11 PM GMT+01:00, Joseph Myers
wrote:
>On Fri, 27 Dec 2019, David Malcolm wrote:
>
>> What the plan for such branches?
>
>My view is: add all refs (and thus all objects) from the existing git
>mirror to the converted repository, probably under names that are not
>fetche
On Fri, 27 Dec 2019, David Malcolm wrote:
> What the plan for such branches?
My view is: add all refs (and thus all objects) from the existing git
mirror to the converted repository, probably under names that are not
fetched by default (this increases the repository size, after git gc
--aggres
(Sorry if I'm missing a FAQ here, but the discussion about the git
conversion has grown very large)
I'm wondering what the plan is for the git-only branches currently
hosted on the gcc.gnu.org git server.
In particular, I'm actively developing stuff in my "dmalcolm/analyzer"
branch there, and I'v
On Fri, Dec 27, 2019 at 7:23 AM J Decker wrote:
> would you suggest I go? It doesn't look like C standards, unlike
> es-discuss for ecma script, I couldn't find a open forum to discuss such
> things... or even a github group like... https://github.com/tc39/proposals
You can table the proposal at
On Thu, Dec 26, 2019 at 05:32:52PM -0500, Eric S. Raymond wrote:
> Toon Moene :
> > So we are going to base this world wide free software endeavor on a source
> > code system that doesn't keep time by UTC ?
>
> They all *do* keep time by UTC.
(Git stores unix time, instead -- close enough ;-) )
On 25/12/2019 11:02, Roman Zhuykov wrote:
> First of all thanks to everyone who spent time making the conversion
> better and better. Here is my 2c, I have studied a little my colleagues
> trunk history in Maxim's gcc-pretty vs gcc-reposurgeon-5b.
>
> 1) In gcc-pretty timezone info is lost in both
On Fri, Dec 27, 2019 at 03:32:57AM -0800, Andrew Pinski wrote:
> 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.
On Fri, Dec 27, 2019 at 11:21:41AM +, 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 appear
On 27/12/2019 11:35, Joseph Myers wrote:
> On Fri, 27 Dec 2019, Richard Earnshaw (lists) wrote:
>
>> 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 histor
On Fri, 27 Dec 2019, Alexandre Oliva wrote:
> That depends on the used tool. A reproducible one, or at least one that
> aimed at stability across multiple conversions, could make this easier,
> but I guess reposurgeon is not such a tool. Which suggests to me we
> have to be even more reassured o
On Dec 26, 2019, Joseph Myers wrote:
> We should ensure we don't have missing branches in the first place (for
> whatever definition of what branches we should have).
*nod*
> Adding a branch after the fact is a fundamentally different kind of
> operation
That depends on the used tool. A repr
On Fri, 27 Dec 2019, Richard Earnshaw (lists) wrote:
> 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.
To some extent it fits with th
On Fri, Dec 27, 2019 at 3:22 AM Richard Earnshaw (lists)
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 +, Joseph Myers wrote:
> >>> If we don't want merge commits on git master for the cases where p
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 +, 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 reposurge
> On Dec 27, 2019, at 4:32 AM, Joseph Myers wrote:
>
> On Thu, 26 Dec 2019, Joseph Myers wrote:
>
>>> It appears that .gitignore has been added in r1 by reposurgeon and then
>>> deleted at r130805. In SVN repository .gitignore was added in r195087.
>>> I speculate that addition of .gitignore
26 matches
Mail list logo
