On Thu, 2020-01-09 at 12:30 +, Joseph Myers wrote:
> On Wed, 8 Jan 2020, Jeff Law wrote:
>
> > Is there any chance we could get one more trunk snapshot before the
> > conversion starts -- even if that means firing up the snapshot process
> > Friday? It'd be quite useful for the ongoing
On Fri, Jan 10, 2020 at 12:38:10PM +0100, Richard Biener wrote:
> Just to chime in I also just want to get it done (well, I can handle
> SVN as well :P).
I will never have to learn it! I'm so happy!
> I trust Joseph, too, but then from my POV anything not worse than the current
> mirror works
On Fri, Jan 10, 2020 at 09:49:41AM +, Richard Earnshaw (lists) wrote:
> On 10/01/2020 07:33, Maxim Kuvyrkov wrote:
> >>On Jan 9, 2020, at 5:38 AM, Segher Boessenkool
> >> wrote:
> >>Where and when and by who was it decided to use this conversion?
> >
> >Joseph, please point to message on gcc@
On Thu, Jan 09, 2020 at 12:12:49PM +, Richard Earnshaw (lists) wrote:
> On 09/01/2020 02:38, Segher Boessenkool wrote:
> >Where and when and by who was it decided to use this conversion?
> >
> >Will it at least be *tested* first?
>
> Tested for what?
Acceptance test, of course, the only test
On Thu, 9 Jan 2020, Joseph Myers wrote:
>> Is there any chance we could get one more trunk snapshot before the
>> conversion starts -- even if that means firing up the snapshot process
>> Friday? It'd be quite useful for the ongoing Fedora build testing.
> I could run a snapshot manually. I was
On Fri, 10 Jan 2020, Maxim Kuvyrkov wrote:
> I was wrong re. r182541, I didn't notice that it is the first commit on
> branch. This renders the analysis in favor of reposurgeon conversion,
> not svn-git.
Kudos for that statement, Maxim.
And thanks a bunch for all the work you have been doing,
> On Jan 10, 2020, at 6:15 PM, Joseph Myers wrote:
>
> On Fri, 10 Jan 2020, Maxim Kuvyrkov wrote:
>
>> To me this looks like cherry-picks of r182541 and r182547 from
>> redhat/gcc-4_7-branch into redhat/gcc-4_8-branch.
>
> r182541 is the first commit on /branches/redhat/gcc-4_7-branch after
Bernd Schmidt :
> I was on the fence for a long time, since I felt that the rewritten
> reposurgeon was still somewhat unproven.
And that was a fair criticism for a short while, until the first compare-all
verification on the GCC history came back clean.
The most difficult point in the whole
On Thu, 9 Jan 2020, Joseph Myers wrote:
> On Wed, 8 Jan 2020, Jeff Law wrote:
>
> > Is there any chance we could get one more trunk snapshot before the
> > conversion starts -- even if that means firing up the snapshot process
> > Friday? It'd be quite useful for the ongoing Fedora build
On Fri, 10 Jan 2020, Maxim Kuvyrkov wrote:
> To me this looks like cherry-picks of r182541 and r182547 from
> redhat/gcc-4_7-branch into redhat/gcc-4_8-branch.
r182541 is the first commit on /branches/redhat/gcc-4_7-branch after it
was created as a copy of trunk. I.e., merging and
> On Jan 10, 2020, at 10:33 AM, Maxim Kuvyrkov
> wrote:
>
>> On Jan 9, 2020, at 5:38 AM, Segher Boessenkool
>> wrote:
>>
>> On Wed, Jan 08, 2020 at 11:34:32PM +, Joseph Myers wrote:
>>> As noted on overseers, once Saturday's DATESTAMP update has run at 00:16
>>> UTC on Saturday, I
On 1/10/20 1:53 PM, Nathan Sidwell wrote:
On 1/10/20 6:38 AM, Richard Biener wrote:
So I don't see any clear dissent and most folks just want to get this
done.
Just to chime in I also just want to get it done (well, I can handle
SVN as well :P).
I trust Joseph, too, but then from my POV
On 1/10/20 8:33 AM, Maxim Kuvyrkov wrote:
Joseph, please point to message on gcc@ mailing list that expresses consensus
of GCC community to use reposurgeon conversion. Otherwise, it is not
appropriate to substitute one's opinion for community consensus.
I was on the fence for a long time,
On Fri, 10 Jan 2020, Iain Sandoe wrote:
> One minor nit (and accepted that this might be too late).
Hooks can always be changed after the conversion is live.
> mail commit messages like this:
> [gcc-reposurgeon-8(refs/users/jsm28/heads/test-branch)] Test git hooks
> interaction with Bugzilla.
>
On 1/10/20 6:38 AM, Richard Biener wrote:
So I don't see any clear dissent and most folks just want to get this
done.
Just to chime in I also just want to get it done (well, I can handle
SVN as well :P).
I trust Joseph, too, but then from my POV anything not worse than the current
mirror
Richard Biener wrote:
On Fri, Jan 10, 2020 at 10:49 AM Richard Earnshaw (lists)
wrote:
On 10/01/2020 07:33, Maxim Kuvyrkov wrote:
On Jan 9, 2020, at 5:38 AM, Segher Boessenkool
wrote:
On Wed, Jan 08, 2020 at 11:34:32PM +, Joseph Myers wrote:
As noted on overseers, once Saturday's
On Fri, Jan 10, 2020 at 10:49 AM Richard Earnshaw (lists)
wrote:
>
> On 10/01/2020 07:33, Maxim Kuvyrkov wrote:
> >> On Jan 9, 2020, at 5:38 AM, Segher Boessenkool
> >> wrote:
> >>
> >> On Wed, Jan 08, 2020 at 11:34:32PM +, Joseph Myers wrote:
> >>> As noted on overseers, once Saturday's
On 10/01/2020 07:33, Maxim Kuvyrkov wrote:
On Jan 9, 2020, at 5:38 AM, Segher Boessenkool
wrote:
On Wed, Jan 08, 2020 at 11:34:32PM +, Joseph Myers wrote:
As noted on overseers, once Saturday's DATESTAMP update has run at 00:16
UTC on Saturday, I intend to add a README.MOVED_TO_GIT file
> On Jan 9, 2020, at 5:38 AM, Segher Boessenkool
> wrote:
>
> On Wed, Jan 08, 2020 at 11:34:32PM +, Joseph Myers wrote:
>> As noted on overseers, once Saturday's DATESTAMP update has run at 00:16
>> UTC on Saturday, I intend to add a README.MOVED_TO_GIT file on SVN trunk
>> and change the
Richard Earnshaw (lists) :
> I want to also take this opportunity to thank Maxim for the work he has
> done. Having that fallback option has meant that we could press harder for
> a timely solution and has also driven several significant improvements to
> the overall result. I do not think we
On Wed, 8 Jan 2020, Jeff Law wrote:
> Is there any chance we could get one more trunk snapshot before the
> conversion starts -- even if that means firing up the snapshot process
> Friday? It'd be quite useful for the ongoing Fedora build testing.
I could run a snapshot manually. I was
On 09/01/2020 02:38, Segher Boessenkool wrote:
On Wed, Jan 08, 2020 at 11:34:32PM +, Joseph Myers wrote:
As noted on overseers, once Saturday's DATESTAMP update has run at 00:16
UTC on Saturday, I intend to add a README.MOVED_TO_GIT file on SVN trunk
and change the SVN hooks to make SVN
On Wed, 2020-01-08 at 23:34 +, Joseph Myers wrote:
>
> As noted on overseers, once Saturday's DATESTAMP update has run at 00:16
> UTC on Saturday, I intend to add a README.MOVED_TO_GIT file on SVN trunk
> and change the SVN hooks to make SVN readonly, then disable gccadmin's
> cron jobs
On Wed, Jan 08, 2020 at 11:34:32PM +, Joseph Myers wrote:
> As noted on overseers, once Saturday's DATESTAMP update has run at 00:16
> UTC on Saturday, I intend to add a README.MOVED_TO_GIT file on SVN trunk
> and change the SVN hooks to make SVN readonly, then disable gccadmin's
> cron
On Wed, 8 Jan 2020, Eric S. Raymond wrote:
> They use your feedback to find places where their comment-processing
> scripts could be improved; we've used it learn what additional
> oddities in ChangeLogs we need to be able to handle automatically.
I've used comparisons of authors in the two
Maxim Kuvyrkov :
> Once gcc-reparent conversion is regenerated, I'll do another round of
> comparisons between it and whatever the latest reposurgeon version is.
Thanks, Maxim. Those comparisons have been very helpful to Joseph and
Richard and to the reposurgeon devteam as well.
They use your
> On Dec 30, 2019, at 7:08 PM, Richard Earnshaw (lists)
> wrote:
>
> On 30/12/2019 15:49, Maxim Kuvyrkov wrote:
>>> On Dec 30, 2019, at 6:31 PM, Richard Earnshaw (lists)
>>> wrote:
>>>
>>> On 30/12/2019 13:00, Maxim Kuvyrkov wrote:
> On Dec 30, 2019, at 1:24 AM, Richard Earnshaw (lists)
On 02/01/2020 02:58, Alexandre Oliva wrote:
> On Dec 30, 2019, "Richard Earnshaw (lists)" wrote:
>
>> Right, (and wrong). You have to understand how the release branches and
>> tags are represented in CVS to understand why the SVN conversion is done
>> this way.
>
> I'm curious and ignorant,
On Dec 30, 2019, "Richard Earnshaw (lists)" wrote:
> Right, (and wrong). You have to understand how the release branches and
> tags are represented in CVS to understand why the SVN conversion is done
> this way.
I'm curious and ignorant, is the convoluted representation that Maxim
described
On Tue, Dec 31, 2019 at 01:42:55PM +, Joseph Myers wrote:
> As the remaining changes being made to the reposurgeon conversion are of
> the form "tidy things up where reposurgeon is already making a reasonable
> conservative choice but minor improvements are still possible", I think
> it's
On 31/12/2019 13:42, Joseph Myers wrote:
> On Mon, 16 Dec 2019, Jeff Law wrote:
>
>>> Joseph Myers has made his choice. He has said repeatedly that he
>>> wants to follow through with the reposurgeon conversion, and he's
>>> putting his effort behind that by writing tests and even contributing
On Mon, 16 Dec 2019, Jeff Law wrote:
> > Joseph Myers has made his choice. He has said repeatedly that he
> > wants to follow through with the reposurgeon conversion, and he's
> > putting his effort behind that by writing tests and even contributing
> > code to reposurgeon.
> >
> > We'll get
On Mon, Dec 30, 2019 at 06:23:16PM -0600, Segher Boessenkool wrote:
> > To me, that indicates that using a conversion tool that is conservative in
> > its heuristics, and then selectively applying improvements to the extent
> > they can be done safely with manual review in a reasonable time, is
Joseph Myers :
> To me, that indicates that using a conversion tool that is conservative in
> its heuristics, and then selectively applying improvements to the extent
> they can be done safely with manual review in a reasonable time, is better
> than applying a conversion tool with more
On Mon, Dec 30, 2019 at 10:58:05PM +, Joseph Myers wrote:
> > If you guys want to ever finish, you'll need to drop the quest for
> > perfection, because this leads to a) much more work, and b) worse quality
> > in the end.
>
> To me, that indicates that using a conversion tool that is
On Mon, 30 Dec 2019, Segher Boessenkool wrote:
> To make it not be super much work, I'd do the second option: better
> heuristics. Those in Maxim's conversion have been great since over half
> a year, you could borrow some, or peek for inspiration?
Actually, comparing authors between the two
On Mon, Dec 30, 2019 at 03:36:42PM +, Richard Earnshaw (lists) wrote:
> On 29/12/2019 23:13, Segher Boessenkool wrote:
> > On Sun, Dec 29, 2019 at 11:00:08PM +, Joseph Myers wrote:
> >> fixups in bugdb.py - and that way benefit both from reposurgeon making
> >> choices that are as
On 30/12/2019 15:49, Maxim Kuvyrkov wrote:
>> On Dec 30, 2019, at 6:31 PM, Richard Earnshaw (lists)
>> wrote:
>>
>> On 30/12/2019 13:00, Maxim Kuvyrkov wrote:
On Dec 30, 2019, at 1:24 AM, Richard Earnshaw (lists)
wrote:
On 29/12/2019 18:30, Maxim Kuvyrkov wrote:
> Below
> On Dec 30, 2019, at 6:31 PM, Richard Earnshaw (lists)
> wrote:
>
> On 30/12/2019 13:00, Maxim Kuvyrkov wrote:
>>> On Dec 30, 2019, at 1:24 AM, Richard Earnshaw (lists)
>>> wrote:
>>>
>>> On 29/12/2019 18:30, Maxim Kuvyrkov wrote:
Below are several more issues I found in reposurgeon-6a
On 29/12/2019 23:13, Segher Boessenkool wrote:
> On Sun, Dec 29, 2019 at 11:00:08PM +, Joseph Myers wrote:
>> fixups in bugdb.py - and that way benefit both from reposurgeon making
>> choices that are as conservatively safe as possible, which seems a
>> desirable property for problem cases
On 30/12/2019 13:00, Maxim Kuvyrkov wrote:
>> On Dec 30, 2019, at 1:24 AM, Richard Earnshaw (lists)
>> wrote:
>>
>> On 29/12/2019 18:30, Maxim Kuvyrkov wrote:
>>> Below are several more issues I found in reposurgeon-6a conversion
>>> comparing it against gcc-reparent conversion.
>>>
>>> I am
> On Dec 30, 2019, at 1:24 AM, Richard Earnshaw (lists)
> wrote:
>
> On 29/12/2019 18:30, Maxim Kuvyrkov wrote:
>> Below are several more issues I found in reposurgeon-6a conversion comparing
>> it against gcc-reparent conversion.
>>
>> I am sure, these and whatever other problems I may find
> On Dec 30, 2019, at 3:18 AM, Joseph Myers wrote:
>
> On Sun, 29 Dec 2019, Richard Earnshaw (lists) wrote:
>
>> gcc-reparent is better, but many (most?) of the release tags are shown
>> as merge commits with a fake parent back to the gcc-3 branch point,
>> which is certainly not what happened
Le 30/12/2019 à 01:18, Joseph Myers a écrit :
Do "git log egcs_1_1_2_prerelease_2" in gcc-reparent, for example. The
history ends up containing two different versions of SVN r5 and of many
other commits.
When trying to migrate Blender from svn to git, we actually tried
git-svn first, and it
Le 29/12/2019 à 18:30, Ian Lance Taylor via gcc a écrit :
On Sun, Dec 29, 2019 at 5:49 AM Julien '_FrnchFrgg_' RIVAUD
wrote:
Which brings me to something I find strange in your policy: to me,
merges from trunk to branches should be rare if not nonexistent. And you
are deciding to banish
On Sun, 29 Dec 2019, Richard Earnshaw (lists) wrote:
> gcc-reparent is better, but many (most?) of the release tags are shown
> as merge commits with a fake parent back to the gcc-3 branch point,
> which is certainly not what happened when the tagging was done at that
> time.
And looking at the
On Sun, 2019-12-29 at 22:30 +0100, Thomas Koenig wrote:
> Am 29.12.19 um 14:26 schrieb Segher Boessenkool:
> > We cannot waste a year on a social experiment. We can slowly and carefully
> > adopt new procedures, certainly. But anything drastic isn't advisable imo.
> >
> > Also, many GCC
On Sun, Dec 29, 2019 at 11:00:08PM +, Joseph Myers wrote:
> fixups in bugdb.py - and that way benefit both from reposurgeon making
> choices that are as conservatively safe as possible, which seems a
> desirable property for problem cases that haven't been manually reviewed,
Problem cases
On Sun, 29 Dec 2019, Eric S. Raymond wrote:
> Joseph Myers :
> > The case you mention is one where there was a merge to a branch not from
> > its immediate parent but from an indirect parent. I don't think it would
> > be hard to support detecting such merges in reposurgeon.
>
> We're working
Joseph Myers :
> The case you mention is one where there was a merge to a branch not from
> its immediate parent but from an indirect parent. I don't think it would
> be hard to support detecting such merges in reposurgeon.
We're working on it.
> This is an example where the originally added
On Sun, 29 Dec 2019, Mark Wielaard wrote:
> Maybe we should have a separate historical git repo which contains
> everything that we were able to salvage and that people could git
> remote add if they are really, really interested.
I'm not convinced that's very different from having one repo with
On 29/12/2019 18:30, Maxim Kuvyrkov wrote:
> Below are several more issues I found in reposurgeon-6a conversion comparing
> it against gcc-reparent conversion.
>
> I am sure, these and whatever other problems I may find in the reposurgeon
> conversion can be fixed in time. However, I don't see
Am 29.12.19 um 14:26 schrieb Segher Boessenkool:
We cannot waste a year on a social experiment. We can slowly and carefully
adopt new procedures, certainly. But anything drastic isn't advisable imo.
Also, many GCC developers aren't familiar with Git at all. It takes time
to learn it, and to
On Sun, 29 Dec 2019, Maxim Kuvyrkov wrote:
> With the "Missed merges" problem (see below) I don't see how reposurgeon
> conversion can be considered "ready".
It aims to be conservatively safe regarding merges, erring on the side of
not adding incorrect merges if in doubt. Because of the
Below are several more issues I found in reposurgeon-6a conversion comparing it
against gcc-reparent conversion.
I am sure, these and whatever other problems I may find in the reposurgeon
conversion can be fixed in time. However, I don't see why should bother. My
conversion has been
On Sun, Dec 29, 2019 at 5:49 AM Julien '_FrnchFrgg_' RIVAUD
wrote:
>
> Which brings me to something I find strange in your policy: to me,
> merges from trunk to branches should be rare if not nonexistent. And you
> are deciding to banish merges the other way around.
Out of curiosity, why do you
Hi,
On Wed, 2019-12-25 at 06:10 -0600, Segher Boessenkool wrote:
> git-svn did not miss any branches. Finding branches is not done by
> git-svn at all, for this. These branches were skipped because they
> have nothing to do with GCC, have no history in common (they are not
> descendants of
Le 29/12/2019 à 17:32, Richard Earnshaw a écrit :
We agreed that for changes in our current workflow practices we'd defer
that until *after* we'd switched to git; so this is getting off topic.
On the other hand, we do need to sort out what we do with existing merge
history, as that forms part
On 29/12/2019 12:15, Segher Boessenkool wrote:
> On Sun, Dec 29, 2019 at 12:02:51PM +0100, Richard Biener wrote:
>> For bisecting trunk a merge would be a single commit, right? So I could see
>> value in preserving a patch series where individual steps might introduce
>> temporary issues as a
On Sun, Dec 29, 2019 at 02:48:31PM +0100, Julien '_FrnchFrgg_' RIVAUD wrote:
> >Merges aren't scary. Merges are inconvenient.
>
> No they are not. You are unaccustomed to them, which is different.
Lol. Okay, end of discussion. You are assuming all the wrong things.
Segher
Le 29/12/2019 à 14:31, Segher Boessenkool a écrit :
On Sun, Dec 29, 2019 at 12:46:50PM +0100, Julien '_FrnchFrgg_' RIVAUD wrote:
At worst, no commit is testable in the
branch except the last, and git will say that the bug was introduced in
the branch, which is not worse that what you'd get
Le 29/12/2019 à 14:26, Segher Boessenkool a écrit :
Hi!
On Sun, Dec 29, 2019 at 12:42:07PM +0100, Julien '_FrnchFrgg_' RIVAUD wrote:
I'm not arguing that you should go that route, it seems a bit extreme to
me. But outright refusing merges on the basis they are painful is (if
you can accept the
On Sun, Dec 29, 2019 at 12:46:50PM +0100, Julien '_FrnchFrgg_' RIVAUD wrote:
> At worst, no commit is testable in the
> branch except the last, and git will say that the bug was introduced in
> the branch, which is not worse that what you'd get without a merge commit.
We normally require every
Hi!
On Sun, Dec 29, 2019 at 12:42:07PM +0100, Julien '_FrnchFrgg_' RIVAUD wrote:
> I'm not arguing that you should go that route, it seems a bit extreme to
> me. But outright refusing merges on the basis they are painful is (if
> you can accept the strong word) ludicrous.
They are painful for
On Sun, Dec 29, 2019 at 12:02:51PM +0100, Richard Biener wrote:
> For bisecting trunk a merge would be a single commit, right? So I could see
> value in preserving a patch series where individual steps might introduce
> temporary issues as a branch merge (after rebasing) so the series is visible
Le 29/12/2019 à 12:02, Richard Biener a écrit :
On December 29, 2019 11:41:00 AM GMT+01:00, Segher Boessenkool
wrote:
On Sun, Dec 29, 2019 at 02:40:45AM +0100, Julien FrnchFrgg Rivaud
wrote:
Oh, I'm not talking about historical merges. I'm saying we
shouldn't do
future merges, where we
Le 29/12/2019 à 11:41, Segher Boessenkool a écrit :
On Sun, Dec 29, 2019 at 02:40:45AM +0100, Julien FrnchFrgg Rivaud wrote:
Oh, I'm not talking about historical merges. I'm saying we shouldn't do
future merges, where we can help that. It disagrees with our documented
"submitting patches"
On December 29, 2019 11:41:00 AM GMT+01:00, Segher Boessenkool
wrote:
>On Sun, Dec 29, 2019 at 02:40:45AM +0100, Julien FrnchFrgg Rivaud
>wrote:
>> >Oh, I'm not talking about historical merges. I'm saying we
>shouldn't do
>> >future merges, where we can help that. It disagrees with our
On Sun, Dec 29, 2019 at 02:40:45AM +0100, Julien FrnchFrgg Rivaud wrote:
> >Oh, I'm not talking about historical merges. I'm saying we shouldn't do
> >future merges, where we can help that. It disagrees with our documented
> >"submitting patches" protocol.
>
> I don't see how that can be
Le 28/12/2019 à 21:28, Segher Boessenkool a écrit :
On Sat, Dec 28, 2019 at 05:11:47PM +, Richard Earnshaw (lists) wrote >> I
disagree. The review comments will show up as additional commits on
the branch and can be tracked back to such events. Once history gets
flattened into a major
On Sat, Dec 28, 2019 at 05:11:47PM +, Richard Earnshaw (lists) wrote:
> On 28/12/2019 12:19, Segher Boessenkool wrote:
> > Branch merges do not mesh well with our commit policies, fwiw:
> > everything should normally be posted for public review on the mailing
> > lists. This does not really
On 28/12/2019 12:19, Segher Boessenkool wrote:
> Branch merges do not mesh well with our commit policies, fwiw:
> everything should normally be posted for public review on the mailing
> lists. This does not really work for commits that have been set in
> stone months before.
>
I disagree. The
On Fri, Dec 27, 2019 at 11:35:21AM +, 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
On Fri, 27 Dec 2019, Eric S. Raymond wrote:
> > Merge info is not one of those cases.
>
> Sometimes. Some Subversion mergeinfo operations map to Git's
> branch-centric merging. Many do not, corresponding to cherry-picks
> that cannot be expressed in a Git history.
And in the case of merge
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
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
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
>
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
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
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
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
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
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
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
> 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
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 at r1 is expected, but it's
> > deletion at r130805 is
On Thu, 26 Dec 2019, Jakub Jelinek wrote:
> Is there some easy way (e.g. file in the conversion scripts) to correct
> spelling and other mistakes in the commit authors?
I've added author fixups to bugdb.py, so you can add any number of fixes
(e.g. based on authors that look suspicious in "git
Alexandre Oliva :
> I don't see that it does (help). Incremental conversion of a missed
> branch should include the very same parent links that the conversion of
> the entire repo would, just linking to the proper commits in the adopted
> conversion. git-svn can do that incrementally, after the
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
>the
>> branch to trunk, which is both
On Thu, 26 Dec 2019, Alexandre Oliva wrote:
> I don't see that it does (help). Incremental conversion of a missed
> branch should include the very same parent links that the conversion of
> the entire repo would, just linking to the proper commits in the adopted
> conversion. git-svn can do
On Dec 26, 2019, "Eric S. Raymond" wrote:
> Alexandre Oliva :
>> On Dec 25, 2019, "Eric S. Raymond" wrote:
>>
>> > Reposurgeon has a reparent command. If you have determined that a
>> > branch is detached or has an incorrect attachment point, patching the
>> > metadata of the root node to fix
Alexandre Oliva :
> On Dec 25, 2019, "Eric S. Raymond" wrote:
>
> > Reposurgeon has a reparent command. If you have determined that a
> > branch is detached or has an incorrect attachment point, patching the
> > metadata of the root node to fix that is very easy.
>
> Thanks, I see how that can
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 reposurgeon
> > "unmerge" command in gcc.lift to stop
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 reposurgeon
> "unmerge" command in gcc.lift to stop the few commits in question from
> being merge
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 the
> branch to trunk, which is both good and bad. The good part is that we
> get more visibility into how
> On Dec 26, 2019, at 2:16 PM, Jakub Jelinek wrote:
>
> On Thu, Dec 26, 2019 at 11:04:29AM +, Joseph Myers wrote:
> Is there some easy way (e.g. file in the conversion scripts) to correct
> spelling and other mistakes in the commit authors?
> E.g. there are misspelled surnames, etc. (e.g.
On Thu, 26 Dec 2019, Jakub Jelinek wrote:
> Is there some easy way (e.g. file in the conversion scripts) to correct
> spelling and other mistakes in the commit authors?
These can be corrected via reposurgeon commands in gcc.lift (see the
existing "// attribution =A set
jwakely@gmail.com"
On Thu, Dec 26, 2019 at 11:04:29AM +, Joseph Myers wrote:
Is there some easy way (e.g. file in the conversion scripts) to correct
spelling and other mistakes in the commit authors?
E.g. there are misspelled surnames, etc. (e.g. looking at my name, I see
Jakub Jakub Jelinek (1):
Jakub Jeilnek
On Thu, 26 Dec 2019, Alexandre Oliva wrote:
> Could make it a requirement that at least the commits associated with
> head branches and published tags compare equal in both conversions, or
> that differences are known, understood and accepted, before we switch
> over to either one? Going over
1 - 100 of 195 matches
Mail list logo
