(As a downstream user and very infrequent committer) +1 for a move to
GitHub. I'm indifferent about git, but pull requests significantly reduce
the effort of contributing small patches. I've found I'm much more likely
to submit a patch to a project if it is on GitHub.
On Tue, May 31, 2016 at 1:31
2016-06-01 20:07 GMT+02:00 Anton Korobeynikov via llvm-dev <
llvm-...@lists.llvm.org>:
> >> Regarding the issue of git sub-modules and keeping Clang/LLVM in sync,
> perhaps we should just put Clang and LLVM into a single git repository and
> add a CMake option to disable compilation of Clang (the
I think we should start two other threads: one about git tooling on Windows
and one about infrastructure problems migrating to git.
I'm confident we can solve both problems relatively easily.
Cheers,
Renato
On 1 Jun 2016 10:09 p.m., "Aaron Ballman" wrote:
> On Wed, Jun 1, 2016 at 3:25 PM, James
It gets so tricky! It's hard for the unwinder to tell the difference between a
real valid stack unwind and random data giving lots of "frames".
It sounds like the problem that needs fixing is to figure out why the assembly
unwind is wrong for frame 0. What do you get for
disass -a
image sh
On Wed, Jun 1, 2016 at 3:25 PM, James Y Knight wrote:
> IMO, if we're switching to git, we should just be clear up front that all
> committers will be expected to switch to git as well -- or at least, if they
> want to use something else (e.g. mercurial's git bridge/etc), that it's
> their own pro
> Even though git 1.7 or something deals with submodules better - I
> don't personally like them at all. I'd rather have a convenience
> script or something which pulls and clones the sources. Not everyone
> needs all the sources and then there's the question of all the
> subprojects and build.. et
On 1 June 2016 at 10:19, Tim Northover wrote:
> On 1 June 2016 at 10:12, Dan Liew via cfe-dev wrote:
>> the directories for each submodule will stay empty. Thus it isn't
>> necessary to pull down all the sources when using git submodules.
>> This would need support from the build system though. I
+1
We use git exclusively within QC, so this looks like simplification to us.
There was mention early in the thread of continuing to enforce linear history;
that’s important to our internal integration machinery. We do currently use
the git-svn-id as a key for some of our internal processes
On 2016-06-01 13:17, Bruce Hoult via cfe-dev wrote:
I'm not sure why this isn't automatic with the
master repo commit checkout, but in any case it's not difficult.
Because there can be local changes that are not committed in the
submodule. That can cause issues when switching to a different c
On 2016-05-31 22:45, Mehdi Amini via llvm-dev wrote:
On May 31, 2016, at 1:31 PM, Renato Golin
wrote:
On 31 May 2016 at 21:28, Mehdi Amini wrote:
Ideally, I'd prefer the cross-repository to be handled with an extra
layer, in a way similar as described in:
https://gerrit-review.googlesource.
With submodules, the current hash of each submodule is recorded in each
master commit. If you check out a different master repository commit then
you run 'git submodule update' and it checks out the corresponding commit
in each submodule. I'm not sure why this isn't automatic with the master
repo c
IMO, if we're switching to git, we should just be clear up front that all
committers will be expected to switch to git as well -- or at least, if
they want to use something else (e.g. mercurial's git bridge/etc), that
it's their own problem.
It is truly NOT that big an imposition to require the us
+1 from me. Our company has very restrictive firewalls and the proxy setup
doesn't work with SVN and http. We have to use special machines in a DMZ
when we push changes to SVN.
To mitigate this we are able to use the individual git repos but that poses
problems for regression testing when we attem
On 1 June 2016 at 21:21, Mehdi Amini wrote:
> I'm not sure how to be robust against that other than putting all the
> projects in the same repo and asking developers to build them all before push.
I'm strongly against a single repo with all in, or asking to build
LLDB when the commit is in Compi
> On Jun 1, 2016, at 1:07 PM, Manuel Jacob wrote:
>
> On 2016-05-31 22:45, Mehdi Amini via llvm-dev wrote:
>>> On May 31, 2016, at 1:31 PM, Renato Golin wrote:
On 31 May 2016 at 21:28, Mehdi Amini wrote:
Ideally, I'd prefer the cross-repository to be handled with an extra
laye
On Wed, Jun 1, 2016 at 1:07 PM, Manuel Jacob via llvm-dev <
llvm-...@lists.llvm.org> wrote:
> On 2016-05-31 22:45, Mehdi Amini via llvm-dev wrote:
>
>> On May 31, 2016, at 1:31 PM, Renato Golin
>>> wrote:
>>>
>>> On 31 May 2016 at 21:28, Mehdi Amini wrote:
>>>
Ideally, I'd prefer the cross-
On 1 June 2016 at 20:31, Aaron Ballman wrote:
> Our main repo is in SVN; I would say we don't know what most people
> are using (aside from "svn for write access because it's the only
> option").
If the LLVM Meetings are any indication, and they are at least related
to the most active developers,
On Wed, Jun 1, 2016 at 3:10 PM, Renato Golin wrote:
> On 1 June 2016 at 19:36, Aaron Ballman wrote:
>> Despite people's reservations of a git-only repository?
>
> Hi Aaron, not at all!
>
> I was especially vague on my first email to make sure SVN folks would
> be shoved on the side, but John had
On Wed, Jun 1, 2016 at 11:18 AM, Renato Golin via llvm-dev <
llvm-...@lists.llvm.org> wrote:
> On 1 June 2016 at 17:02, John Criswell wrote:
> > Do you have a set of volunteers lined up to do such a migration? Getting
> > people willing to do the migration will obviously be key, and that was
> th
> On Jun 1, 2016, at 11:36 AM, Aaron Ballman via llvm-dev
> wrote:
>
> On Wed, Jun 1, 2016 at 2:18 PM, Renato Golin via llvm-dev
> wrote:
>> On 1 June 2016 at 17:02, John Criswell wrote:
>>> Do you have a set of volunteers lined up to do such a migration? Getting
>>> people willing to do the
On 1 June 2016 at 19:55, Mehdi Amini wrote:
> 12.2: mirror git to svn :)
either that or use GitHub's SVN interface, which is RW.
--renato
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
On 1 June 2016 at 19:36, Aaron Ballman wrote:
> Despite people's reservations of a git-only repository?
Hi Aaron, not at all!
I was especially vague on my first email to make sure SVN folks would
be shoved on the side, but John had asked for a full plan *in the case
we move*, and I was just comp
On 1 June 2016 at 19:31, Mehdi Amini wrote:
> If you move to git-only without the rest of the infrastructure/scripts, we're
> losing the convenience we have today with svn, and the "user experience" will
> not be so great. We may face resistance to this change.
> I advocate to first set it up ti
> On Jun 1, 2016, at 11:51 AM, Matthias Braun wrote:
>
> So here's a straw-man proposal for a github migration:
>
> 1. Register an official github project with the llvm foundation.
> 2. Setup another (read-only) mirror of llvm.org/git at this github project
> 3. Make sure we have ala llvm-proje
So here's a straw-man proposal for a github migration:
1. Register an official github project with the llvm foundation.
2. Setup another (read-only) mirror of llvm.org/git at this github project
3. Make sure we have ala llvm-project-submodules setup in the official account.
(Optional or necessary
On Wed, Jun 1, 2016 at 2:18 PM, Renato Golin via llvm-dev
wrote:
> On 1 June 2016 at 17:02, John Criswell wrote:
>> Do you have a set of volunteers lined up to do such a migration? Getting
>> people willing to do the migration will obviously be key, and that was the
>> one thing I didn't see in t
> On Jun 1, 2016, at 11:18 AM, Renato Golin via llvm-dev
> wrote:
>
> On 1 June 2016 at 17:02, John Criswell wrote:
>> Do you have a set of volunteers lined up to do such a migration? Getting
>> people willing to do the migration will obviously be key, and that was the
>> one thing I didn't se
> On Jun 1, 2016, at 10:19 AM, Tim Northover via llvm-dev
> wrote:
>
> On 1 June 2016 at 10:12, Dan Liew via cfe-dev wrote:
>> the directories for each submodule will stay empty. Thus it isn't
>> necessary to pull down all the sources when using git submodules.
>> This would need support from
On 1 June 2016 at 17:02, John Criswell wrote:
> Do you have a set of volunteers lined up to do such a migration? Getting
> people willing to do the migration will obviously be key, and that was the
> one thing I didn't see in the original email.
Hi John,
Well, first we need to know if people are
>> Regarding the issue of git sub-modules and keeping Clang/LLVM in sync,
>> perhaps we should just put Clang and LLVM into a single git repository and
>> add a CMake option to disable compilation of Clang (the same could be done
>> for other LLVM sub-projects for which bisection and other nifty
+1 from me
On Tue, May 31, 2016 at 12:51 PM, Tim Northover via llvm-dev <
llvm-...@lists.llvm.org> wrote:
> On 31 May 2016 at 12:31, Renato Golin via cfe-dev
> wrote:
> > What do people think? Any issue not covered that we should?
>
> I'm in favour of the move. Git-svn just about works most of t
On 1 June 2016 at 18:12, Dan Liew wrote:
>> So clone llvm ; cd tools / ; clone ...
>> --
>> good luck with this.. I foresee near religious opinions on the horizon..
>
> As do I.
Isn't that solved by the llvm-projects repository format?
--renato
___
On 1 June 2016 at 10:12, Dan Liew via cfe-dev wrote:
> the directories for each submodule will stay empty. Thus it isn't
> necessary to pull down all the sources when using git submodules.
> This would need support from the build system though. I'm not sure
> what the build system would do right n
Dear Renato,
Do you have a set of volunteers lined up to do such a migration? Getting
people willing to do the migration will obviously be key, and that was
the one thing I didn't see in the original email.
Regarding the issue of git sub-modules and keeping Clang/LLVM in sync,
perhaps we sho
On 1 Jun 2016, at 17:02, John Criswell via llvm-dev
wrote:
>
> Regarding the issue of git sub-modules and keeping Clang/LLVM in sync,
> perhaps we should just put Clang and LLVM into a single git repository and
> add a CMake option to disable compilation of Clang (the same could be done
> for
https://llvm.org/bugs/show_bug.cgi?id=27963
Bug ID: 27963
Summary: static variables are not listed with "(lldb) target
variable" when initialized in-place
Product: lldb
Version: 3.8
Hardware: PC
OS: Linux
On 1 June 2016 at 05:16, Douglas Gregor wrote:
> Performance can also be an issue; it takes a bunch of fast bots to keep up
> with developers testing their pull requests, especially when what you’re
> testing is a very large C++ code base. That said, “test and merge on success”
> workflows are
Ok , currently the problem that I am facing is that there are cases in
which eh_frame should have been used for frame 0 but it isn't and the
assembly unwind just gives wrong information which could only be detected
if the debugger tried to extract more frames. Now the usage of
AddOneMoreFrame in Un
38 matches
Mail list logo
