[lldb-dev] [llvm-dev] [cfe-dev] GitHub anyone?
Mehmet Erol Sanliturk via lldb-dev
lldb-dev at lists.llvm.org
Tue May 31 13:56:44 PDT 2016
On Tue, May 31, 2016 at 1:23 PM, Reid Kleckner via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> 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 we want to
> coordinate versions between the related LLVM projects. I hear *terrible*
> things about submodules, so I'd prefer a different sync mechanism, even if
> it is a bad reimplementation of repo, gclient, submodules, and all the
> other multi-repo sync tools.
In previous months , I have studied many thousands of Github repositories ,
and cloned many of them locally to compile and run .
The following difficulties may exist during LLVM works :
If a directory contains large number ( approximately more than thousand )
of files , only a part of these files are displayed and others are not
allowed to view . You may check this from OS repositories .
During cloning , if there is a reference to another repository , clone
--recursive are giving errors about contained @ sign . In that case it is
necessary to enter into sub-directories and manually clone that referenced
sub-module ( or a script should do this ) . Instead of --recursive , the
other statements may be used , but all of them have
When "Download" is selected for repository , sub-modules are not downloaded
into respective sub-directories . It is necessary to visit such directories
manually one by one and download , expand , and adjust these directory
When a file is viewed in Github and returned back , Github is switching to
the top of the directory , not aligning the page at the current cursor
position . When there are large number of files in a directory , it is
causing difficulty to go down to the current cursor position again and
continue from there .
A limited kind and size of files are shown to the user . There are many
kinds that it is possible to only viewing the content is to save repository
locally . To my experience , any single file in a repository directory is
not permitted to download to view it in that case .
I consider revision numbers as only a disastrous design : A very long
number conveying nothing other than inconvenience . Therefore it will not
be possible to specify "revert to _a_simple_number_" elegantly . I do not
know what will be shown to say "revert to _a_cryptic_number_" .
Previously it was possible to search Github for repositories on supplied
keywords . Now , they have disabled that feature . Now , it seems only
Internet searches may find a repository ( to my experience , only very few
of them are found ) , or it may be listed in their category lists to find
only ones selected by Github .
The most affecting points are the above ones for me as a "visitor user" of
Github repositories .
I do not have any experience as "developer user" of Github .
Mehmet Erol Sanliturk
> On Tue, May 31, 2016 at 12:31 PM, Renato Golin via cfe-dev <
> cfe-dev at lists.llvm.org> 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. Furthermore, not hosting our own repos would save us
>> a lot of headaches, admin costs and timed out connections.
>> TL;DR: GitHub + git submodules  could replace all the functionality
>> we have currently with SVN.
>> (also GitLab, BitBucketc, etc).
>> Here are some of the arguments made on IRC...
>> 1. Due to SVN, we can't re-write history. If we use some GitHub
>> properties , we could have the same effect.
>> 2. Due to SVN, we have a mandatory time sequence, so commits go first
>> in LLVM, then Clang (for example), and buildbots don't get lost. If we
>> use submodules , we can have a similar relationship, but in a more
>> explicit way, and the problem could be solved elegantly.
>> 3. Some people still can only use SVN. For that, GitHub has an SVN
>> interface  to the repositories.
>> 4. We currently host our own SVN/Git, ViewVC and Klaus, Phabricator,
>> etc. Not only this incurs in additional admin cost, but it also gets
>> outdated, locally modified, and it needs to be backed up, etc. GitHub
>> gives all that for us for free.
>> 5. We can still use Bugzilla (and lock GitHub's own bug system), but
>> we can also use GitHub's system to manage releases (it's actually
>> quite good for that).
>> 6. GitHub has automated testing of merge requests, meaning we can have
>> pre-commit tests enabled on a set of fast bots, triggered by GitHub's
>> own validation hooks. Even though that wouldn't cover everything,
>> having a few pre-commit bots would considerably reduce the need to
>> revert patches .
>> 7. With git submodules, we'd probably want to follow the same style we
>> have today (llvm-projects/<prj>) instead of modelling how they look in
>> tree (llvm/tools/clang still as a symlink).
>> 8. Once we're solo Git, we can shop around *much* more easily. By
>> using SVN, we're basically forced to host, or choose Source Forge.
>> Using just Git, we can choose GitLab, BitBucket and many others, if
>> GitHub is not appealing enough. Essentially, it doesn't matter where
>> you are, the tools are good, there and largely replaceable [citation
>> What do people think? Any issue not covered that we should? How would
>> that disrupt downstream users? Would it be a temporary disruption, but
>> with long lasting benefits? Or will it just break everything for you?
>>  https://git-scm.com/book/en/v2/Git-Tools-Submodules
>>  https://help.github.com/articles/support-for-subversion-clients/
>> cfe-dev mailing list
>> cfe-dev at lists.llvm.org
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the lldb-dev