Richard Earnshaw (lists) :
> Well a lot of that is a property of the conversion tool. git svn does a
> relatively poor job of anything other than straight history (I believe it
> just ignores the non-linear information.
Yes, svn-git does a *terrible* job on anything other than linear history.
Th
Joseph Myers :
> I think the main thing to make sure of in the conversion regarding that
> issue is that cherry-picks do *not* turn into merge commits
I confirm that this is how it now works.
--
http://www.catb.org/~esr/";>Eric S. Raymond
On 19/11/2019 11:24, Eric S. Raymond wrote:
Richard Earnshaw (lists) :
Well a lot of that is a property of the conversion tool. git svn does a
relatively poor job of anything other than straight history (I believe it
just ignores the non-linear information.
Yes, svn-git does a *terrible* job
Hi,
I am curious to know if you would be interested in acquiring a Visitors list
of Expo SE 2019.
We have 5,000 unique Attendees.
Every Contacts include: Contact Name, Email, Job Title, Phone Number etc.
Share your thoughts or pass this to concern person.
If in
On Mon, Nov 18, 2019 at 4:38 PM Richard Earnshaw (lists) <
richard.earns...@arm.com> wrote:
> On 18/11/2019 20:53, Jason Merrill wrote:
> > On Mon, Nov 18, 2019 at 2:51 PM Segher Boessenkool <
> > seg...@kernel.crashing.org> wrote:
> >
> >> On Mon, Nov 18, 2019 at 07:21:22PM +, Richard Earnsha
On Tue, Nov 19, 2019 at 09:56:50AM -0500, Jason Merrill wrote:
> Yep. I don't think we need to worry about getting optimal one-line
> summaries for ancient commits; something reasonably unique should be plenty.
In that case, how about just "SVN rNN"? And then we don't need the
footer from git
On Tue, 19 Nov 2019 at 16:31, Segher Boessenkool wrote:
>
> On Tue, Nov 19, 2019 at 09:56:50AM -0500, Jason Merrill wrote:
> > Yep. I don't think we need to worry about getting optimal one-line
> > summaries for ancient commits; something reasonably unique should be plenty.
>
> In that case, how ab
On 19/11/2019 16:31, Segher Boessenkool wrote:
On Tue, Nov 19, 2019 at 09:56:50AM -0500, Jason Merrill wrote:
Yep. I don't think we need to worry about getting optimal one-line
summaries for ancient commits; something reasonably unique should be plenty.
In that case, how about just "SVN rN
On Tue, Nov 19, 2019 at 11:31 AM Segher Boessenkool <
seg...@kernel.crashing.org> wrote:
> On Tue, Nov 19, 2019 at 09:56:50AM -0500, Jason Merrill wrote:
> > Yep. I don't think we need to worry about getting optimal one-line
> > summaries for ancient commits; something reasonably unique should be
Hello,
I'm looking into how the unwind mechanism works in order to gather
information to inform how we should eventually handle exceptions in MTE.
I'm currently having a discussion on the llvm-dev list about how HWASAN
handles exceptions, and believe it has relevence.
https://lists.llvm.org/pip
Richard Earnshaw (lists) :
> I was looking at the reposurgeon code last night, and I think I can see what
> the problem *might* be, but I haven't had time to produce a testcase.
>
> Some of our commits have mergeinfo that looks a bit like this:
>
> 202022-202023,202026,202028-202029,202036,202039
Jason Merrill :
> Well, I was thinking of also giving some clue of what the commit was
> about. One possibly cut-off line accomplishes that, a simple revision
> number not so much.
It's conventional under Git to have comments lead with a summary sentence.
I think you're going to find that the va
On 19/11/2019 11:45, Richard Earnshaw (lists) wrote:
> On 19/11/2019 11:24, Eric S. Raymond wrote:
>> Richard Earnshaw (lists) :
>>> Well a lot of that is a property of the conversion tool. git svn does a
>>> relatively poor job of anything other than straight history (I
>>> believe it
>>> just ig
On 19/11/2019 19:32, Eric S. Raymond wrote:
> Richard Earnshaw (lists) :
>> I was looking at the reposurgeon code last night, and I think I can see what
>> the problem *might* be, but I haven't had time to produce a testcase.
>>
>> Some of our commits have mergeinfo that looks a bit like this:
>>
>
On 19/11/2019 19:47, Richard Earnshaw (lists) wrote:
> On 19/11/2019 19:32, Eric S. Raymond wrote:
>> Richard Earnshaw (lists) :
>>> I was looking at the reposurgeon code last night, and I think I can see what
>>> the problem *might* be, but I haven't had time to produce a testcase.
>>>
>>> Some of
Richard Earnshaw (lists) :
> I've been unsuccessful so far in creating a simple reproducer. However,
> r278216 on the gcc 'ranger' branch is an example of what I mean. The
> property list for this is
>
> $ svn propget svn:mergeinfo -r278216
> FILE:///home/rearnsha/tmp/gcc-mirror/branches/ranger
Richard Earnshaw (lists) :
> Nope, that was from running the go version from yesterday. This one, to
> be precise: 1ab3c514c6cd5e1a5d6b68a8224df299751ca637
>
> This pass used to be very fast a couple of weeks back, but something
> went in recently that's caused a major slowdown.
>
> Oh, and I'v
On 19/11/2019 22:14, Eric S. Raymond wrote:
> Richard Earnshaw (lists) :
>> Nope, that was from running the go version from yesterday. This one, to
>> be precise: 1ab3c514c6cd5e1a5d6b68a8224df299751ca637
>>
>> This pass used to be very fast a couple of weeks back, but something
>> went in recentl
On 11/18/19 3:44 PM, Nicholas Krause wrote:
Greetings Richard,
Seems some of these things can either be closed or discussed here:
Add support to a multithread environment to Garbage Collector:
This may not matter as memory is in bulk at the beginning of passes.
I've benchmarked
it and i
On Tue, Nov 19, 2019 at 02:36:21PM -0500, Eric S. Raymond wrote:
> Jason Merrill :
> > Well, I was thinking of also giving some clue of what the commit was
> > about. One possibly cut-off line accomplishes that, a simple revision
> > number not so much.
Sure, but it isn't easy at all to automatic
On Tue, 19 Nov 2019, Segher Boessenkool wrote:
> Most of the time after I type "git log" I type "/\<123456\>". We need
> to keep a way to easily map SVN revision ids to git commits, and
> something a bit more elegant than the ugly git-svn footers would be nice.
Whatever reposurgeon's "write --le
On 11/19/19 6:44 PM, Joseph Myers wrote:
On Tue, 19 Nov 2019, Segher Boessenkool wrote:
Most of the time after I type "git log" I type "/\<123456\>". We need
to keep a way to easily map SVN revision ids to git commits, and
something a bit more elegant than the ugly git-svn footers would be
22 matches
Mail list logo
