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
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 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 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 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
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
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
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
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 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
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
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
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
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
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, 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 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 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
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 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
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
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
22 matches
Mail list logo
