Re: [lldb-dev] [cfe-dev] [llvm-dev] [Github] RFC: linear history vs merge commits

2019-02-04 Thread Justin Lebar via lldb-dev
I'm also in favor of linear history, option #1.

FWIW I don't think lacking tight controls to prevent merges is going to be
a huge deal.  We already restrict who can commit, and there are lots of
other rules you have to follow.

We might get an accidental merge or two every once in a while, but I expect
we'll all be able to live with that?

On Wed, Jan 30, 2019 at 10:53 PM Mehdi AMINI via cfe-dev <
cfe-...@lists.llvm.org> wrote:

>
>
> On Wed, Jan 30, 2019 at 1:19 PM Eric Christopher via cfe-dev <
> cfe-...@lists.llvm.org> wrote:
>
>> On Wed, Jan 30, 2019 at 12:42 PM David Greene via cfe-dev
>>  wrote:
>> >
>> > Bruce Hoult via llvm-dev  writes:
>> >
>> > > How about:
>> > >
>> > > Require a rebase, followed by git merge --no-ff
>> > >
>> > > This creates a linear history, but with extra null merge commits
>> > > delimiting each related series of patches.
>> > >
>> > > I believe it is compatible with bisect.
>> > >
>> > > https://linuxhint.com/git_merge_noff_option/
>> >
>> > We've done both and I personally prefer the strict linear history by a
>> > lot.  It's just much easier to understand a linear history.
>> >
>>
>> Agreed. Let's go with option #1.
>>
>>
> What is the practical plan to enforce the lack of merges? When we looked
> into this GitHub would not support this unless also forcing every change to
> go through a pull request (i.e. no pre-receive hooks on direct push to
> master were possible). Did this change? Are we hoping to get support from
> GitHub on this?
>
> We may write this rule in the developer guide, but I fear it'll be hard to
> enforce in practice.
>
> --
> Mehdi
>
> ___
> cfe-dev mailing list
> cfe-...@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev


Re: [lldb-dev] [llvm-dev] [Openmp-dev] Updates on SVN to GitHub migration

2018-10-22 Thread Justin Lebar via lldb-dev
>  It would be helpful to have instructions about the best way to move
local branches in those repositories to the monorepo and some scripts to
help with the transition.

I put together https://reviews.llvm.org/D53414.

On Mon, Oct 22, 2018 at 8:31 AM David Greene via llvm-dev <
llvm-...@lists.llvm.org> wrote:

> I had a short side-conversation at one of the roundtables about existing
> users of the subproject repositories.  It would be helpful to have
> instructions about the best way to move local branches in those
> repositories to the monorepo and some scripts to help with the
> transition.  I know someone posted an example project a while ago with
> some scripts but my sense is that those scripts were particular to that
> project and maybe not generally applicable.
>
> Once the monorepo goes live (tomorrow?), what happens to the existing
> subproject mirrors?  Do they get wiped away and replaced with history
> from the monorepo?  Or are entirely new mirrors created?  Or do they
> just continue to mirror SVN until SVN becomes read-only?
>
> The first option would essentially be a rewrite of history for the
> subproject repositories.  We'll need to know if/when that is going to
> happen.
>
>   -David
>
> Jonas Hahnfeld via Openmp-dev  writes:
>
> > (+openmp-dev, they should know about this!)
> >
> > Recapping the "Concerns"
> > (https://llvm.org/docs/Proposals/GitHubMove.html#id12) there is a
> > proposal of "single-subproject Git mirrors" for people who are only
> > contributing to standalone subprojects. I think this will be easy in
> > the transition period, we can just continue to move the current
> > official git mirrors. Will this "service" be continued after GitHub
> > becomes the 'one source of truth'? I'd strongly vote for yes, but I'm
> > not sure how that's going to work on a technical level.
> >
> > Thanks,
> > Jonas
> >
> > On 2018-10-20 03:14, Tom Stellard via llvm-dev wrote:
> >> On 10/19/2018 05:47 PM, Tom Stellard via lldb-dev wrote:
> >>> TLDR: Official monorepo repository will be published on
> >>> Tuesday, Oct 23, 2018.  After this date, you should modify
> >>> your workflows to use the monorepo ASAP.  Current workflows
> >>> will be supported for at most 1 more year.
> >>>
> >>> Hi,
> >>>
> >>> We had 2 round-tables this week at the Developer Meeting to
> >>> discuss the SVN to GitHub migration, and I wanted to update
> >>> the rest of the community on what we discussed.
> >>>
> >>> The most important outcome from that meeting is that we
> >>> now have a timeline for completing the transition which looks
> >>> like this:
> >>>
> >>
> >> Step 1:
> >>> Tues Oct 23, 2018:
> >>>
> >>> The latest monorepo prototype[1] will be moved over to the LLVM
> >>> organization github project[2] and will begin mirroring the current
> >>> SVN repository.  Commits will still be made to the SVN repository
> >>> just as they are today.
> >>>
> >>> All community members should begin migrating their workflows that
> >>> rely on SVN or the current git mirrors to use the new monorepo.
> >>>
> >>> For CI jobs or internal mirrors pulling from SVN or
> >>> http://llvm.org/git/*.git you should modify them to pull from
> >>> the new monorepo and also to deal with the new repository
> >>> layout.
> >>>
> >>> For Developers, you should begin using the new monorepo
> >>> for your development and using the provided scripts[3]
> >>> to commit your code.  These scripts will allow to commit
> >>> to SVN from the monorepo without using git-svn
> >>>
> >>>
> >>
> >> Sorry hit send before I was done.  Here is the rest of the mail:
> >>
> >> Step 2:
> >>
> >> Around the time of next year's developer meeting (1 year at the most),
> >> we will turn off commit access to the SVN server and enable commit
> >> access to the monorepo.  At this point the monorepo will become the
> >> 'one source of truth' for the project.  Community members *must* have
> >> updated their workflows by this date and are encouraged to begin
> >> updating workflows ASAP.
> >>
> >> A lot of people asked at the developer meeting about the future
> >> of bugzilla and phabricator and whether or not we will use
> >> github issues and pull requests.  These are important questions,
> >> but are unrelated to the migration of the code.
> >>
> >> We also came up with a TODO list for things we want to accomplish
> >> as a community in the next year and beyond related to github.  I
> >> am working on putting these into bugzilla so we can track progress
> >> better and I will send a follow-up email about this.
> >>
> >> -Tom
> >>
> >>>
> >>>
> >>>
> >>>
> >>> [1] https://github.com/llvm-git-prototype/llvm>> [2]
> https://github.com/llvm/>> [3]
> >>>
> https://llvm.org/docs/GettingStarted.html#for-developers-to-work-with-a-git-monorepo
> >>
> >>>
> >>> ___
> >>> lldb-dev mailing list
> >>> lldb-dev@lists.llvm.org
> >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev>>
> >>
> >> 

[lldb-dev] [FYI] Ongoing discussion on llvm-dev: "One or many git repositories?"

2016-07-21 Thread Justin Lebar via lldb-dev
We're having a discussion on the following question on llvm-dev:

Assuming we switch our canonical VCS to git, then
  - should we have one git repository per llvm subproject, or
  - should we have a single monolithic git repository.

https://groups.google.com/forum/#!topic/llvm-dev/aSc9BxXtboc

This will affect all of us, so I wanted to loop in these lists.
Please respond on llvm-dev, not here, so we don't fork the thread.

Regards,
-Justin
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev