Is there a way to search over all git repositories with gitlab?
At the moment we are using the open source version of gitlab.
Since it is open source, there should be a way to enable it without switching to the commercial version....
A search over "all Git repositories" must first determine its scope: all branches or only the master branch.
Because a search across all branches is not easy to implement, and is discussed in this 2 years old issue 1086.
Searching across all repositories was also recently requested (issue 9794), but also not implemented yet.
A GraphQL query might come close of what you are looking for, but its API is still alpha, and might be limited to one project or group.
Related
The company I work for uses Clearcase, even though it was EOL'd on the platforms in which we run it years ago. It is ancient and fragile tech, but one thing it does have is a multisite support that allows for the synchronization of air-gapped repos. Because of security issues, we use secure USB sticks to copy packets and take them to the other side, then apply them with scripts.
Developers and DevOps people want to make a business case to migrate to GitLab, but I cannot find any mention of a feature in GitLab that would allow me to do easily do this. There's something about bundles, but the info I have found is years old and it doesn't seem like too many people are using it.
Does GitLab not support this? Simple synchronization of one repo to another over an air gap using some sort of secure media? If so, it's no wonder so many teams are still using ClearCase.
While not exactly easy, air-gap updates of Git repository is possible through the git bundle command.
It produces one file (with all the history, or only the latest commits for an incremental update), that you can:
copy and distribute easily (it is just one file after all)
clone or pull from(!)
This is not tied to GitLab, and can be applied to any Git repository.
From there, I have written before on migration from ClearCase to Git, and I usually:
do not import the full history, only major labels or UCM baselines
split VObs per project, each project being one Git repository
revisit what was versioned in Vobs: some large files/binaries might need to be .gitignore'd in the new Git repository.
You would not "migrate views": they are just workspace (be it static or dynamic). A simple clone of a repository is enough to recreate such a workspace (static here).
When I select all projects, I cannot search by commits or code.
Can I enable search by code or commits across all projects?
You can only do this across an entire instance for self-managed GitLab instances OR searching across repositories within a single organization/group in GitLab.com
For example, you can search across all of the gitlab-org group or any other group/namespace you have access to.
Currently, GitLab has not enabled global code search on gitlab.com. However, self-hosted GitLab Premium and Ultimate customers can leverage the advanced search feature and enable global code search for a self-managed instance with Elasticsearch.
That might be because a true global code search does not seem to be implemented yet, as illustrated by issue 556 or issue 14597.
Which is why there are alternatives like phillipj/gitlab-search (but only to search for contents across all your GitLab repositories)
i am pretty new to GitLab and have a question concerning branches and updating the local repo.
Around two weeks ago i cloned a project and did a bit of work on it (mainly added one branch). Other people also have local repositories of that same project (hope that makes sense). Now I would like to clone only a single branch of one of those local repos made by other people and include it into my local repo.... How do i do this? Ofc I can clone the branch into a different directory, but my goal is only having one directory with only one name in which that branch is contained, so that I can switch between the branches I had from the beginning and the new branch I cloned.
Basically, in order to be more clear: There is a project called a_proj. Me and another person have cloned a_proj and therefore have local repos on which we do work. The other person added a branch called a_branch which I don't have. I want to include a_branch into my version of a_proj.
Additionally i have a different question concerning updating a branch. What if some person does some work on their local version of a branch I also have on my Local and I want to include their changes, or even change my branch to their version. How could I do that?
Thank you a lot for any helpful answers on this topic. If there is constructive critic about this post or the way I think about GitLab I am happy to hear it, as already mentioned, this is a pretty new topic to me and I want to learn wherever i can!
Okay, i figured it out. Was pretty easy actually once one knows what to do. For information, i am using GitKraken so it might be different for different environments but essentially the idea is to add the other person's project as remote, (where ones own project should also be a remote named origin). Then one can add any branch of those remotes to the Local project, simply by checking out the wanted branch. It then gets added to the Local repository on which work can be done.
I guess that isn't anything new to anybody who uses GitLab but i'll just leave it here in case some noob (Like me) also has this question.
I started exploring Gitlab for version control management and I got an issue at the first step itsself. When ever I create a project its creating a new repository. I have few webapplications which are independent to each other. In that case do I need to use different repository for every project.
What I am looking for is what is what and when to use what but not able to find what is repository and what is project in gitlab website as well as through other sources as well.
Also I came across a term submodule, when can it be used. Can I create one global project and have all the webapplications as different submodules.
Can any one please help me in understanding the difference between those 3 and when to use what based on their intended way of usage. Also please help me by pointing to a good learning site where I can get the information of doing basic version control operations in gitlab.
Thanks.
Gitlab manages projects: a project has many features in addition of the Git repo it includes:
issues: powerful, but lightweight issue tracking system.
merge requests: you can review and discuss code before it is merged in the branch of your code.
wiki: separate system for documentation, built right into GitLab
snippets: Snippets are little bits of code or text.
So fear each repo you create, you get additional features in its associated project.
And you can manage users associated to that project.
See GitLab documentation for more.
The Git repo and Git submodule are pure Git notions.
In your case, a submodule might not be needed, unless you want a convenient way to remember the exact versions of different webapp repo, recorded in one parent repo.
But if that is the case, then yes, you can create one global project and have all the webapplications as different submodules.
Each of those submodules would have their own GitLab project (and Git repo).
Do you use Subversion while developing a website with drupal ?
I'm not talking about modules development, but websites development (i.e. adding hook functions, modifying template file.. etc)
thanks
Yes.
Anything that's got any kind of ongoing development or is going to change over time should be version controlled.
Even if you're just doing a very small project, the value of having a version history is indesputable, and being able to make changes without worrying about overwriting someone else's updates is priceless.
Yes, its's good keep a SVN repository synced with your local instance.For that purpose you can use Eclipse.
Yes, but we are moving to git in the near future because it offers a better feature set (distributed SCM ftw) and more options for managing our code base (git submodules, stashing, better hook integration, better merging support, rebasing, and so much more). For the time being we've got our repos setup like so:
/trunk
/branches/6.x/1.x/core
/branches/6.x/1.x/sitename.domain.edu
/branches/6.x/1.x/sitename2.domain.edu
/branches/6.x/1.1.x/core
/branches/6.x/1.1.x/sitename.domain.edu
...
/tags/6.x/1.x/core
/tags/6.x/1.x/sitename.domain.edu
/tags/6.x/1.x/sitename2.domain.edu
/tags/6.x/1.1.x/core
/tags/6.x/1.1.x/sitename.domain.edu
...
Each branch is a svn copy of the trunk repo (where we do most of our development) and each tag is a svn copy of it's corresponding branch. The core branch is the primary distro that we distribute to all of our sites that share the university's look and feel, and each subsite is a site with special modules, custom theme, or any other functionality that isn't part of the primary distro. It makes moving between drupal releases a lot easier, but you can start to run into problems merging occasionally. Also you run into performance issues when the repo starts to grow, which is part of the reasoning behind moving to git.
Yes. Version control is critical. Distributed version control systems such as Git, Mercurial, and Bazaar are particularly nice, and let you start committing immediately, without the need to push those changes to a central server.
My Drupal workflow: use Mercurial and its sub-repositories feature to create independent repositories for 1) Drupal + contributed modules, 2) theme, and 3) custom modules. That way, I can clone from a single URL, get my entire project, and be able to track changes to each distinct piece independently.