Displaying 20 results from an estimated 20000 matches similar to: "Git Transition status?"
2017 Jan 17
5
Git Transition status?
On Jan 13, 2017, at 1:37 PM, Mehdi Amini via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> The main outcome of the BoF had the dev meeting was that we agree’d that moving to GitHub was the best choice forward for LLVM (IIRC only one person in the room expressed concerned about GitHub, but he said he had personal grief with them and nothing specific for LLVM).
>
> The unknown that
2017 Jan 17
2
Git Transition status?
> On Jan 17, 2017, at 3:01 PM, Robinson, Paul <paul.robinson at sony.com> wrote:
>
> - As Medhi says, according to surveys and discussions in forums like the LLVM Dev Meeting BoF, most people who care are in favor of mono-repo.
>
> From the online surveys, I think the split was roughly 50:50.
>
> I don’t know on what data you’re basis this on. I looked very closely
2017 Jan 16
3
Git Transition status?
So the Github-Importer screws up the old dark places of the SVN-History and
the scripts try to handle this?
2017-01-13 22:57 GMT+01:00 James Y Knight via llvm-dev <
llvm-dev at lists.llvm.org>:
> I've been working on some scripting for re-converting the svn repository
> into git.
>
> The existing git conversions are entirely sufficient for day-to-day
> development
2016 Oct 13
11
GitHub Survey?
> On 2016-Sep-18, at 09:51, Renato Golin via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>
> Folks,
>
> After feedback from Chris and Mehdi, I have added one long text answer
> to *each* critical questions (impact on productivity), so that people
> can extend their reasoning.
>
> But I have not made them compulsory, so that people that don't know
> much
2016 Sep 01
4
GitHub Survey?
Folks,
It's 1st of September, and we don't have the document nor the survey
ready. With the US meeting on 3-4 November, that leaves us only 2
months to do everything, and I'm not sure we'll be able to if we delay
much more.
Being the devil's advocate and hoping this doesn't spiral down
(again), there were a few pertinent questions left unanswered from the
previous
2016 Oct 13
2
GitHub Survey?
> On 2016-Oct-13, at 11:23, Mehdi Amini <mehdi.amini at apple.com> wrote:
>
> Hi,
>
> Thanks a lot Duncan, I really like this! I totally support adopting this scheme now. See inline a few quite minor comments.
>
> Renato: are you still interested and available now to set-up the survey? We should close on this *this week*.
>
>
>> On Oct 12, 2016, at 7:07
2016 Oct 13
3
GitHub Survey?
> On Oct 13, 2016, at 11:03 AM, Robinson, Paul via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>
> | 6. How important is cross-project blame, grep, etc.?
> <>
> I don't understand "cross-project blame" as it works on one file at a time?
True, not straightforward blame.
My workflow when trying to track the history of some code involves frequently
2017 Jan 17
4
Git Transition status?
> On Jan 17, 2017, at 7:24 AM, David Chisnall <David.Chisnall at cl.cam.ac.uk> wrote:
>
> On 17 Jan 2017, at 01:17, Chris Lattner via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>>
>> - Monorepo is the “natural” way to use git. Submodules are possible to use, but add significant complexity.
>
> Having used submodules in a couple of projects, I’ve not
2016 Oct 13
2
GitHub Survey?
> On Oct 13, 2016, at 11:56 AM, Renato Golin <renato.golin at linaro.org> wrote:
>
> Hi Duncan,
>
> I don't understand your concerns.
>
> First, the choice between sub-modules and mono-repo has been put
> forward as the only two choices because people felt that, if we let it
> open, we'd have too many different implementation details and we'd
>
2020 Jun 19
3
Inclusive language in LLVM: can we rename `master` branch?
I mean, we could change it twice? There are about a hundred scripts out
there for doing it.
-eric
On Fri, Jun 19, 2020 at 11:40 AM Keane, Erich <erich.keane at intel.com> wrote:
> Do we have any ability to reach out to github (at least?) to see what they
> are going to do? I’d very much like to avoid being the odd-project-out
> here.
>
>
>
>
>
>
>
>
2016 Jul 26
56
[RFC] One or many git repositories?
Hi Duncan,
> […]
> 2. Those working on projects *outside* the monolithic repo will get the downsides of both: a monolithic repo that they are only using parts of, and multiple repos that are somehow version-locked.
>
> 3. For many (most?) developers, changing to a monolithic git repo is a *bigger* workflow change than switching to separate git repos. Many people (and at least some
2020 Jun 19
3
Inclusive language in LLVM: can we rename `master` branch?
That's a good point, we should definitely be respectful of the build bot
owners time, that said I think it's the coordination that takes the time
rather than the change :)
On Fri, Jun 19, 2020 at 11:48 AM Keane, Erich via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> My understanding is the biggest concern about the name change is the
> ‘cost’ associated with needing to
2020 Jun 19
6
Inclusive language in LLVM: can we rename `master` branch?
To be clear: I’m concerned about the amount of our infrastructure (as well as downstream infrastructure, this would be actually pretty painful for both of my downstreams) that the community would have break/need fixing as a part of that. So I want this to happen ONCE.
I think it is well motivated now, but switching from ‘default’ to ‘main’ when that becomes the ‘standard’ one seems way less
2020 Jun 19
2
Inclusive language in LLVM: can we rename `master` branch?
There's really no guarantee that things will shake out the same in near
term between the projects.
-eric
On Fri, Jun 19, 2020 at 11:31 AM Keane, Erich <erich.keane at intel.com> wrote:
> I’m a bit mixed on this. While yes, we should change this as soon as is
> practical, it would be a shame to pick something sufficiently different
> from the rest of the world, as that would
2016 Jul 28
0
[RFC] One or many git repositories?
> On Jul 28, 2016, at 12:05 PM, Justin Lebar <jlebar at google.com> wrote:
>
>>> The decision of whether or not to include these projects
>>> affects only read-write consumers of these projects -- of which there
>>> are relatively few people.
>>
>> Maybe there are few, but the impact is non-insignificant. Also I think the opinions of the
2016 Jul 28
0
[RFC] One or many git repositories?
> On Jul 28, 2016, at 10:53 AM, Justin Lebar <jlebar at google.com> wrote:
>
> Thanks again for your thoughts, Chris.
>
>> As a straw man I would suggest the following criteria for inclusion into the mono-repo:
>>
>> (1) Projects in the mono-repo must be tightly coupled to specific versions or commits of other projects in the mono-repo
>
> I'm fine
2020 Jun 19
5
Inclusive language in LLVM: can we rename `master` branch?
I disagree with your timing concerns. Changing is still straightforward and
I'd like to see this done within 1-2 weeks.
Thanks.
-eric
On Fri, Jun 19, 2020 at 12:22 PM Chris Tetreault <ctetreau at quicinc.com>
wrote:
> +1 to waiting until git and/or github decide on a new name for the default
> branch. I think there is a compelling reason to change the name of the
> default
2020 Jun 19
4
Inclusive language in LLVM: can we rename `master` branch?
As I mentioned on another thread, we also use the term "slave" for the
BuildBot builders. In the past, I was told this was due to being stuck on
an old version of BuildBot. Fortunately, there is already work in progress
to update BuildBot to a newer version. Since that's also going affect all
the build machines, perhaps changing the name of the main branch should
happen
2020 Jun 19
2
Inclusive language in LLVM: can we rename `master` branch?
While I appreciate this sentiment we should not block our changes on a
project over which we have no control. Changing the name and the
documentation is easy and we should do this today.
Thanks.
-eric
On Fri, Jun 19, 2020 at 10:49 AM Petr Penzin via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> +1
>
> Git uses `master` branch in quite a few places in its docs and `git init`
2016 Aug 19
5
[RFC] GitHub Survey - Please review
On 19 August 2016 at 19:35, Justin Bogner <mail at justinbogner.com> wrote:
> I think you misunderstood what I meant here. Whether "moving to git"
> will affect my workflow depends very much on "how we're moving to
> git".
That's exactly what I understood. :)
> For example, if we do a monorepo, I may now need to lay code out
> differently on my