NetBSD is ready (cmake-3.5.2).
It now runs 7.0 kernel, 7.99.29 userland and newer GNU toolchain (GCC
5.3, LD 2.26).
http://lab.llvm.org:8011/buildslaves/lldb-amd64-ninja-netbsd7
On 26.05.2016 18:57, Zachary Turner via lldb-dev wrote:
> Windows LLDB is done
>
> On Thu, May 26, 2016 a
Hello,
I posted this query a while ago, i still have no answers, I am
currently working on Bug 27687 (PrintStackTraces), so the reason for the
failure is the erroneous unwinding of the frames from the zeroth frame. The
error is not detected in AddOneMoreFrame, since it only checks for 2 more
(I’ve already filed a couple of Radars about this; rdar://24025436 and
rdar://26090553, for those with Radar access.)
The crashlog.py script that ships with LLDB/Xcode is broken. It has a few
outright bugs, for which I have fixes, and it also relies on an external script
that has undocumented
Just an FYI. Later today I’ll be updating the CMake minimum version to 3.4.3.
In advance of the transition I’ve posted a bunch of patches:
LLVM: http://reviews.llvm.org/D20822
Clang: http://reviews.llvm.org/D20823
Compiler-RT: http://reviews.llvm.org/D20824
LLDB: http://reviews.llvm.org/D20826
li
flood gates on those kinds of cascading changes in
case these patches need to be reverted for some reason.
Thanks,
-Chris
> On May 31, 2016, at 11:22 AM, Chris Bieneman via lldb-dev
> wrote:
>
> Just an FYI. Later today I’ll be updating the CMake minimum version to 3.4.3.
> In
Folks,
There has been some discussion on IRC about SVN hosting and the perils
of doing it ourselves. The consensus on the current discussion was
that moving to a Git-only solution would have some disvantages, but
many advantages. Furthermore, not hosting our own repos would save us
a lot of headac
peanut gallery comments from a git hater (We use git for all source
revision control)
On Wed, Jun 1, 2016 at 3:31 AM, Renato Golin via cfe-dev
wrote:
> Folks,
>
> There has been some discussion on IRC about SVN hosting and the perils
> of doing it ourselves. The consensus on the current discussio
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 the time,
but I find it makes committing to release branches particularly
painful. It also randomly corrupts its datab
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 the time,
> b
> On May 31, 2016, at 12:31 PM, Renato Golin via llvm-dev
> wrote:
> There has been some discussion on IRC about SVN hosting and the perils
> of doing it ourselves. The consensus on the current discussion was
> that moving to a Git-only solution would have some disvantages, but
> many advantages.
I'm in favor of both going to git as the source of truth, and then
switching the hosting to github.
Echoing everyone else, this unlocks a lot of good stuff that I won't
repeat, and most of it can be handled independently from the VCS move.
The major blocker I see for the move is figuring out how
On Tue, May 31, 2016 at 3:31 PM, Renato Golin via cfe-dev
wrote:
> Folks,
>
> There has been some discussion on IRC about SVN hosting and the perils
> of doing it ourselves. The consensus on the current discussion was
> that moving to a Git-only solution would have some disvantages, but
> many adv
Likewise, I'd definitely be in favor of doing so. It would be great to have
the entire LLDB development community on GitHub instead of the current story.
Kate Stone k8st...@apple.com <mailto:k8st...@apple.com>
Xcode Low Level Tools
> On May 31, 2016, at 1:16 PM, Chris Lattne
On 31 May 2016 at 21:24, Aaron Ballman wrote:
> Are we sure that github's svn integration works with common tools on
> Windows, like TortoiseSVN?
That's a good question. Can you try them out and report back?
cheers,
--renato
___
lldb-dev mailing list
l
> On May 31, 2016, at 1:16 PM, Chris Lattner via llvm-dev
> wrote:
>
>> On May 31, 2016, at 12:31 PM, Renato Golin via llvm-dev
>> wrote:
>> There has been some discussion on IRC about SVN hosting and the perils
>> of doing it ourselves. The consensus on the current discussion was
>> that mov
May 31, 2016, at 12:12 PM, Chris Bieneman via lldb-dev
> wrote:
>
> One more thing I want to note on this thread.
>
> For anyone looking at the patches. I’ve intentionally tried to make them
> minimal. After the patches have landed and stayed on trunk without issue for
>
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.com/Documentation/user-submodules.htm
> (somehow conceptually similar to Android manifests XML files
On Tue, May 31, 2016 at 04:24:08PM -0400, Aaron Ballman via cfe-dev wrote:
> On Tue, May 31, 2016 at 3:31 PM, Renato Golin via cfe-dev
> wrote:
> > Folks,
> >
> > There has been some discussion on IRC about SVN hosting and the perils
> > of doing it ourselves. The consensus on the current discussi
On Tue, May 31, 2016 at 4:27 PM, Renato Golin wrote:
> On 31 May 2016 at 21:24, Aaron Ballman wrote:
>> Are we sure that github's svn integration works with common tools on
>> Windows, like TortoiseSVN?
>
> That's a good question. Can you try them out and report back?
From my very simple testing
> 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.com/Documentation/user-submodules.htm
>
On Tue, May 31, 2016 at 01:45:30PM -0700, Matthias Braun wrote:
> To be more exact here: I usually do not checkout llvm svn at a higher
> level because that forces me back to svn (which last time I used it did
> not have built-in support for bisection, not sure if that changed
> recently).
svn-bis
On 31 May 2016 at 13:45, Mehdi Amini via lldb-dev
wrote:
> Apparently I wasn't very clear: llvm and clang (and the others projects)
> would be simple decoupled, individual git repositories. You would be able to
> check them out however you want and commit to them individually.
&g
> On May 31, 2016, at 2:07 PM, Tim Northover wrote:
>
> On 31 May 2016 at 13:45, Mehdi Amini via lldb-dev
> wrote:
>> Apparently I wasn't very clear: llvm and clang (and the others projects)
>> would be simple decoupled, individual git repositories. You would
> On May 31, 2016, at 2:01 PM, Bill Kelly via llvm-dev
> wrote:
>
> Chris Lattner via llvm-dev wrote:
>> Personally, I’m hugely in favor of moving llvm’s source hosting to github at
>> some point, despite the fact that I continue to dislike git as a tool and
>> consider monotonicly increasing v
Strong +1 to move to an external hosted git sooner rather than later!
1) I personally had very good experiences with git submodules. They are
certainly harder to get used to as you have to learn a bunch of extra magic on
top of the already magical git: i.e. "git clone --recurse-submodules", then
> On May 31, 2016, at 1:31 PM, Joerg Sonnenberger via llvm-dev
> wrote:
>
> On Tue, May 31, 2016 at 04:24:08PM -0400, Aaron Ballman via cfe-dev wrote:
>> On Tue, May 31, 2016 at 3:31 PM, Renato Golin via cfe-dev
>> wrote:
>>> Folks,
>>>
>>> There has been some discussion on IRC about SVN host
+1 for git
Best regards,
Alexey Bataev
> 31 мая 2016 г., в 22:31, Renato Golin via cfe-dev
> написал(а):
>
> Folks,
>
> There has been some discussion on IRC about SVN hosting and the perils
> of doing it ourselves. The consensus on the current discussion was
> that moving to a Git-only solut
Chris Lattner via llvm-dev wrote:
> Personally, I’m hugely in favor of moving llvm’s source hosting to github at
> some point, despite the fact that I continue to dislike git as a tool and
> consider monotonicly increasing version numbers to be hugely beneficial.
For whatever it's worth, our proje
> On May 31, 2016, at 1:42 PM, Matthias Braun wrote:
>
>>
>> On May 31, 2016, at 1:31 PM, Joerg Sonnenberger via llvm-dev
>> wrote:
>>
>> On Tue, May 31, 2016 at 04:24:08PM -0400, Aaron Ballman via cfe-dev wrote:
>>> On Tue, May 31, 2016 at 3:31 PM, Renato Golin via cfe-dev
>>> wrote:
> On May 31, 2016, at 2:05 PM, Joerg Sonnenberger via llvm-dev
> wrote:
>
> On Tue, May 31, 2016 at 01:45:30PM -0700, Matthias Braun wrote:
>> To be more exact here: I usually do not checkout llvm svn at a higher
>> level because that forces me back to svn (which last time I used it did
>> not
My company is using submodules for the better or worse. It's not a perfect
solution but it can work when using a version of git recent enough and some
tooling.
The magic command to update everything to the current commit pointed by
each submodule : git submodules update --init --recursive
To get t
On Tue, May 31, 2016 at 02:43:02PM -0700, Matthias Braun wrote:
>
> > On May 31, 2016, at 2:05 PM, Joerg Sonnenberger via llvm-dev
> > wrote:
> >
> > On Tue, May 31, 2016 at 01:45:30PM -0700, Matthias Braun wrote:
> >> To be more exact here: I usually do not checkout llvm svn at a higher
> >> l
> On May 31, 2016, at 11:31 AM, jing...@apple.com wrote:
>
>
>> On May 31, 2016, at 12:52 AM, Ravitheja Addepally via lldb-dev
>> wrote:
>>
>> Hello,
>> I posted this query a while ago, i still have no answers, I am
>> currently working o
> On May 31, 2016, at 3:01 PM, Joerg Sonnenberger via llvm-dev
> wrote:
>
> On Tue, May 31, 2016 at 02:43:02PM -0700, Matthias Braun wrote:
>>
>>> On May 31, 2016, at 2:05 PM, Joerg Sonnenberger via llvm-dev
>>> wrote:
>>>
>>> On Tue, May 31, 2016 at 01:45:30PM -0700, Matthias Braun wrote:
> On May 31, 2016, at 3:38 PM, Robinson, Paul wrote:
>
>
>
>> -Original Message-
>> From: llvm-dev [mailto:llvm-dev-boun...@lists.llvm.org] On Behalf Of Mehdi
>> Amini via llvm-dev
>> Sent: Tuesday, May 31, 2016 2:38 PM
>> To: Bill Kelly
>> Cc: LLVM Dev; Clang Dev; LLDB Dev
>> Subject:
> On May 31, 2016, at 4:06 PM, Robinson, Paul wrote:
>
>
>
>> -Original Message-
>> From: mehdi.am...@apple.com [mailto:mehdi.am...@apple.com]
>> Sent: Tuesday, May 31, 2016 3:54 PM
>> To: Robinson, Paul
>> Cc: Bill Kelly; Clang Dev; LLDB Dev; llvm-...@lists.llvm.org
>> Subject: Re: [l
> -Original Message-
> From: mehdi.am...@apple.com [mailto:mehdi.am...@apple.com]
> Sent: Tuesday, May 31, 2016 3:54 PM
> To: Robinson, Paul
> Cc: Bill Kelly; Clang Dev; LLDB Dev; llvm-...@lists.llvm.org
> Subject: Re: [llvm-dev] GitHub anyone?
>
>
> > On May 31, 2016, at 3:38 PM, Robin
> -Original Message-
> From: llvm-dev [mailto:llvm-dev-boun...@lists.llvm.org] On Behalf Of Mehdi
> Amini via llvm-dev
> Sent: Tuesday, May 31, 2016 2:38 PM
> To: Bill Kelly
> Cc: LLVM Dev; Clang Dev; LLDB Dev
> Subject: Re: [llvm-dev] GitHub anyone?
>
>
> > On May 31, 2016, at 2:01 PM,
On 5/31/2016 4:46 PM, Mehdi Amini via cfe-dev wrote:
> Apparently I wasn't very clear: llvm and clang (and the others projects)
> would be simple decoupled, individual git repositories. You would be able to
> check them out however you want and commit to them individually.
> There would be an ext
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 the time,
> b
> On May 31, 2016, at 1:16 PM, Chris Lattner via cfe-dev
> wrote:
>
>> On May 31, 2016, at 12:31 PM, Renato Golin via llvm-dev
>> wrote:
>> There has been some discussion on IRC about SVN hosting and the perils
>> of doing it ourselves. The consensus on the current discussion was
>> that movi
TL;DR :-)
Git-submodules works fine for bisecting for read-only use. I have the repo
to do that.
https://github.com/llvm-project/llvm-project-submodule
With a simple hooks/post-checkout, It should help effective bisecting.
https://github.com/chapuni/llvm-project-scripts/blob/master/hooks/post-che
;
> >> On May 31, 2016, at 12:52 AM, Ravitheja Addepally via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >>
> >> Hello,
> >> I posted this query a while ago, i still have no answers, I am
> currently working on Bug 27687 (PrintStackTraces), so
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
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
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 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
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
___
+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
>> 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
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
> 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 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 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
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 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
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 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: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 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 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 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 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 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 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 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 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
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
> 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 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
> On Wed, Jun 1, 2016 at 12:27 AM, Jason Molenda wrote:
>
> > On May 31, 2016, at 11:31 AM, jing...@apple.com wrote:
> >
> >
> >> On May 31, 2016, at 12:52 AM, Ravitheja Addepally via lldb-dev
> >> wrote:
> >>
> >> Hello,
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
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
(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
Seems win64 almost works fine out of the box. 1 minor thing is needed:
diff --git
a/source/Plugins/Process/Windows/Common/x64/RegisterContextWindows_x64.cpp
b/source/Plugins/Process/Windows/Common/x64/RegisterContextWindows_x64.cpp
index 103cff4..4b37c3f 100644
---
a/source/Plugins/Process/W
e frames in the
> stack. I want to run both the unwinders and select the one that gives more
> number of frames.
> >
> > On Wed, Jun 1, 2016 at 12:27 AM, Jason Molenda
> wrote:
> >
> > > On May 31, 2016, at 11:31 AM, jing...@apple.com wrote:
> > >
> &
On Wed, Jun 1, 2016 at 6:31 PM, Renato Golin wrote:
> I think we should start two other threads: one about git tooling on Windows
> and one about infrastructure problems migrating to git.
Some developers on Windows prefer to use GUI tools like TortoiseSVN to
command line tools for version control
Am 02.06.2016 um 14:43 schrieb Aaron Ballman via cfe-dev:
On Wed, Jun 1, 2016 at 6:31 PM, Renato Golin wrote:
> I think we should start two other threads: one about git tooling on Windows
> and one about infrastructure problems migrating to git.
Some developers on Windows prefer to use GUI tool
On 2 June 2016 at 13:43, Aaron Ballman via lldb-dev
wrote:
> Are there suitable GUI tools for git on Windows for projects as
> complex as LLVM? I believe MSVC has some integration, but I've not
> used it before. Perhaps other tools exist that match the integration
> and stability
A little summary...
After a lot of discussion, I think we converged to a few issues that
we need to solved before we finally decide to move.
Firstly, the responses were overwhelmingly positive (I counted 20 of
the ~25 people strongly supporting and another 2~3 weakly supporting).
This is a good i
Renato,
> Firstly, the responses were overwhelmingly positive (I counted 20 of
> the ~25 people strongly supporting and another 2~3 weakly supporting).
> This is a good indication that the move could be very beneficial to
> the community as a whole, including downstream infrastructure, not
> just
I personally find this email thread very hard to follow and read (this isn’t
anyones fault.. its just a lot of replies). I am sure others do as well. I
think it would be good to have a form/survey of some sort that can get feedback
from users such as: who they are, how they use LLVM/contribution
You could try Git GUI [1]. I don't know if it's any good, I've only
used Git BASH on Windows (never had any problems with it).
Diana
[1] https://git-for-windows.github.io/
On 2 June 2016 at 15:43, Aaron Ballman via cfe-dev
wrote:
> On Wed, Jun 1, 2016 at 6:31 PM, Renato Golin wrote:
>> I think
My two cents worth: our group tries very hard to avoid Git because we find it
immature, hard to use, and unreliable. I know others feel differently but our
vote is to stay with SVN. If distributed repositories are a priority we’d be
much happier with Mercurial.
skw
> On Jun 2, 2016, at 11:21
On Thu, Jun 02, 2016 at 04:48:36PM +0100, Renato Golin via llvm-dev wrote:
> * Git developer tooling is a growing trend, while SVN tooling is
> dying. This is not just about GUIs, but repository management (GitHub,
> GitLab, BitBucket, etc versus SourceForge), bisects, branches,
> remotes, hooks,
My personal 2 cents is that I’d love to see us move to github and a git-native
workflow. I’m already on a mostly git workflow and the only thing that tears me
out of it is git-svn, which corrupts itself way too often.
As a late-comer on the thread I do have a few thoughts I want to share based o
> On Jun 2, 2016, at 11:01 AM, d...@cray.com wrote:
>
> Mehdi Amini via llvm-dev writes:
>
>>> Personally, I’m hugely in favor of moving llvm’s source hosting to
>>> github at some point, despite the fact that I continue to dislike
>>> git as a tool and consider monotonicly increasing version n
Looks good.
> On Jun 2, 2016, at 1:40 AM, Carlo Kok via lldb-dev
> wrote:
>
> Seems win64 almost works fine out of the box. 1 minor thing is needed:
>
>
> diff --git
> a/source/Plugins/Process/Windows/Common/x64/RegisterContextWindows_x64.cpp
> b/source/Plugins
> On Jun 2, 2016, at 11:03 AM, d...@cray.com wrote:
>
> Tim Northover via cfe-dev writes:
>
>> On 31 May 2016 at 13:45, Mehdi Amini via lldb-dev
>> wrote:
>>> Apparently I wasn't very clear: llvm and clang (and the others
>>> proj
> On Jun 2, 2016, at 9:21 AM, Tanya Lattner via llvm-dev
> wrote:
>
> I personally find this email thread very hard to follow and read (this isn’t
> anyones fault.. its just a lot of replies). I am sure others do as well. I
> think it would be good to have a form/survey of some sort that can
> On Jun 2, 2016, at 9:28 AM, Scott Warren via llvm-dev
> wrote:
>
> My two cents worth: our group tries very hard to avoid Git because we find it
> immature, hard to use, and unreliable.
I'm willing to take such claims into account, but they would have to come with
a technical justification
> On Jun 2, 2016, at 10:53 AM, Chris Bieneman via llvm-dev
> wrote:
>
> My personal 2 cents is that I’d love to see us move to github and a
> git-native workflow. I’m already on a mostly git workflow and the only thing
> that tears me out of it is git-svn, which corrupts itself way too often.
> > How do you get monotonically increasing number with a history graph?
>
> I think what we're trying to get is a "pushed" revision number, i.e.
> tracking the state of the upstream repositories at a given time.
I think I've mentioned this before but internally we are (mostly) using
"rev-list --
> On Jun 2, 2016, at 11:22 AM, Robinson, Paul wrote:
>
>>> How do you get monotonically increasing number with a history graph?
>>
>> I think what we're trying to get is a "pushed" revision number, i.e.
>> tracking the state of the upstream repositories at a given time.
>
> I think I've mentio
> On Jun 2, 2016, at 11:22 AM, d...@cray.com wrote:
>
> Matthias Braun via cfe-dev writes:
>
>> 3. Make sure we have ala llvm-project-submodules setup in the official
>> account. (Optional or necessary for the buildbots?)
>
>> 7. Make sure bisecting with llvm-project-submodules is a good exper
> they would have to come with a technical justification. Just claiming "it is
> unreliable" does not make it a reality.
Of course I don't expect anyone to accept a claim because I say so. The
relative merits of Git and SVN have been widely discussed for years and most
interested parties have a
> On Jun 2, 2016, at 11:51 AM, d...@cray.com wrote:
>
> Mehdi Amini via cfe-dev writes:
>
>> My opinion is that submodules or not is an implementation details. For
>> the sake of this high-level discussion we should be able to keep it as
>> "submodules" meaning "some system to integrate and man
3101 - 3200 of 9283 matches
Mail list logo
