Ship octotree as part of GitLab

This is OK by the authors https://github.com/buunguyen/octotree/issues/265#issuecomment-188947504 and the code is MIT.

Added ~123454 label

We should improve button that triggers tree opening. I don't like current position near project name. Should be on sidebar instead. cc @skyruler

Milestone changed to 8.8

Added ~155950 label

This is less useful now that we have the fuzzy file finder, but it would still be nice I think.

@sytses For sure, when exploring a new project, I always expand the lib or src or app folder and go from there to get an overview of the project. That's nearly impossible with the current file browser.

@DouweM agree, we should do this

@dzaporozhets agree :) lets do it near the logo

@skyruler Preferably in a way that is still accessible with collapsed sidebar!

@DouweM In the future I want to hide sidebar at least for mobile devices. It will be accessible :)

Added ~19492 label

Milestone changed to 8.10

Added Product work label

Milestone changed to %Backlog

Came across this issue, which is really great ;) hacked together a quick mockup to get some visuals of this!

It needs to take into account of course that this is a repo specific navigation element ;)

it misses the hide file tree button though

mentioned in issue #4179 (closed)

mentioned in issue #13586 (closed)

From what I can see, people want to be able to browse their code using a file tree mode. Something like that:

This is not the same as having a project tree in a sidebar that pops up in the UI, like what Octotree offers.

So what would be the use cases for a sidebar like Octotree?

Jumping to a file.
See the list of files while reviewing a MR, or when creating an issue.
Referencing a file name (or path) by clicking on a file/folder in the sidebar, and pasting this path to the field the cursor is.

What's missing from the design by @dimitrieh are:

a way to know the branch for the files we are viewing and the ability to change it
the ability to copy the path of a file
ability to open a file in a new window

@regisF I like your idea :) its differs from the original idea but is a bit more minimal and less of a big visual change. I'll create a new mockup for this ;)

Reassigned to @dimitrieh

Created a mockup with the updated looks of taken into mind https://gitlab.com/gitlab-org/gitlab-ce/issues/19616#note_13554002

expanded:

cc: @tauriedavis @cperessini @hazelyang

Thanks @dimitrieh Remember, what you've just designed is not really the Octotree integration. It's a new feature.

Could you create a separate issue (and cross link with this one) for what you've designed? A name could be File tree in file browser.

After that, we need to design the sidebar powered by Octotree (also please add to your design the comments I've made to the design). Thanks a lot!

@dimitrieh Were you able to create an issue for the repository file tree?

mentioned in issue #20962 (closed)

@tauriedavis @regisF just did! https://gitlab.com/gitlab-org/gitlab-ce/issues/20962

@regisF

a way to know the branch for the files we are viewing and the ability to change it

This needs to be in there indeed.

the ability to copy the path of a file

You explained this feature by:

Referencing a file name (or path) by clicking on a file/folder in the sidebar, and pasting this path to the field the cursor is.

Could you elaborate further? How you want to see this at work and your usecase?

ability to open a file in a new window

Right click open in new tab/window?

As the other issue is well underway in its design, I think its good to look at this issue itself again. I want to propose something bold in the light of this issue: https://gitlab.com/gitlab-org/gitlab-ce/issues/20680.

It basically says that the sidebar is not needed, as it currently mostly duplicates navigation found elsewhere throughout the interface. Another thing is, that the sidebar always is a hard interface element as it takes up a lot_ of vertical space. Why not utilize that space for something that needs vertical space + would be handy to have at hand throughout navigating a repository (issues/mr etc)? or to quote @regisF :

See the list of files while reviewing a MR, or when creating an issue.

The following mockup is by no means a final product, just a quick compilation of what it could look like, or at least to explain the idea:

just exploring a different way of how we could integrate this feature

About the ability to reference a filename:

Could you elaborate further? How you want to see this at work and your usecase?

My idea was to be able to insert a full path+filename inside a comment, mainly during code reviews, so people could say something like Love this idea, similar to /app/views/index.html. However, as each element of this tree is clickable and would link to the file, we can still to right-click and insert the link inside the comment to make our point.

About the removal of the current content of the sidebar by the tree, this is another discussion. Can you see if we can have both the current content of the sidebar and the octotree together - by having a toggle at the top or something?

@regisF thanks I was thinking the same a way a bit.

let's review some options:

just exploring some options

style 1 tabs:

style2 second sidebar:

although I am also thinkin of a direct option to show the file tree when the sidebar is collapsed... like next to the bars icon that right now reveals the sidebar..

idea's welcome.. will continue on this tomorrow

created the icon real quick myself, is it recognizable?

possibly we could think along with the user... on which pages does the user want the file tree to be the preferable "sidebar"? then change default behaviour of sidebar to filetree etc

another option:

@tauriedavis @hazelyang @jschatz1 @cperessini what do you think of a solution like this, for this issue? (plz see previous post for more details)

I think that the tab approach was interesting. I separated it from the hamburger/pin so they can keep working the way they do now.

The style doesn't really fit, but could something like this work?

I'm kind of confused The file tree tab would only be visible on projects right?

Do you think it would be confusing to combine global navigation with project specific navigation within the same UI element?

@tauriedavis I think we are going to need to think more context related... make the sidebar context related... make the sidebar adjust to different content views so to say. In that regard we can finally create a real reason for the sidebar to exist..

To go on to your question, yes only inside a project this option would be available in the sidebar

I see, thanks for the clarification! If thats the case then we would need to get https://gitlab.com/gitlab-org/gitlab-ce/issues/20680 sorted out before this.

I see a lot of duplication in the sidebar, like mentioned in that issue. Just need to make sure we aren't combining global and context because that was where the confusion was coming from originally.

mentioned in issue #20680 (closed)

With DZ's comment here, I think we need to relook at the designs for this.

@tauriedavis yeah waiting for follow up comment on that issue for this issue as this would not replace or make away with the current sidebar, but improve/add to it.

cc: @dzaporozhets

Just need to make sure we aren't combining global and context because that was where the confusion was coming from originally.

@tauriedavis @dimitrieh @cperessini thats what I am afraid of. We did redesign in 8.9/8.10 mostly to make sidebar static with global context. With file tree in left sidebar we again destroy navigation hierarchy because global and local navigation mixed inside one UI element.

Left sidebar is global navigation and has no relation to what happens with content block. So we want render tree navigation inside content are as its part of project and belong to context. Ideally in this area:

Because tree view belongs to project it:

should be under project name
should be outside of left sidebar as it

Let's see if we can make it logically correct and nice at same time

@dzaporozhets agreed.

@dzaporozhets

I created a mockup of this a while back ago as can be seen in this previous comment: https://gitlab.com/gitlab-org/gitlab-ce/issues/13723#note_12745921 or:

point is that this space it never used ever with the current sidebar:

so the problem basically comes down to 2 things:

we just had a redesign, meaning we should not change to much to fast
we do not want to create navigation hierarchy confusion

So we wait?

As for the implementation in the sense of "within the content block":

These are wireframing/light weight mockups:

point is that this space it never used ever with the current sidebar:

@dimitrieh on my 12" laptop there is no unused space :)

so the problem basically comes down to 2 things: we just had a redesign, meaning we should not change to much to fast we do not want to create navigation hierarchy confusion So we wait?

@dimitrieh I don't ask to wait. I asked to respects current UI and navigation hierarchy while design feature :)

As for the implementation in the sense of "within the content block": These are wireframing/light weight mockups:

@dimitrieh thats looks much better

Is this issue still about adding octotree, or has it morphed into recreating the same functionality?

@elygre I'd say we don't know yet. What we need to figure out first, is where and how we would display such a tree.

Doesn't that imply recreating the same functionality? I would assume that "Integrating octotree" would mean taking the octotree code and shipping it with GitLab, integrated so that you don't have to install or configure it. Looking for other ways to display the tree tells me that this will not be octotree anymore, but rather an separate feature in GitLab.

Now, a separate GitLab feature may be good, possibly better, than an integrated octotree. However, it should be clear what it is.

just tinkering around for https://gitlab.com/gitlab-org/gitlab-ce/issues/13680

I was thinking of another sidebar on the left, but that would a tad to much, space would not be utilized. so what about a button implementation.

thoughts compared to previous mockup:

sidebar on the right is part of a view, say the issue view. a file tree can make sense in more places. I like the previous mockup better, but if we want to move it down a notch this could be done.

not in line yet with style, but lets see..

mentioned in issue #13680 (moved)

@elygre effectively we want to see the same information in app, functioning in the best possible way, how we call this is less important imo

@dimitrieh I think the distinction between including an upstream product and creating a similar product is quite important.

The GitHub issue above opens with the question "Are you open to having us ship octotree as part of GitLab?". In a follow-up comment, the author of Octotree wrote "I don't think contributing back is necessary as there's no reason to keep GitLab support in Octotree if the feature is built-in." True, I think: If GitLab provides the GitLab support on top of Octotree, then Octotree does not need this. However, if GitLab "forks" Octotree, it is quite possible that the Octotree author would like to keep GitLab support in, to have a single user experience across multiple platforms.

Personally, I don't really care which option is chosen, but I think it's important to be clear about it.

Added usability label

@elygre thanks for the explanation.

@jschatz1 @awhildy ? what will we do.. planning for this feature etc?

I feel like we should focus on building this feature for GitLab users, and not just existing Octotree users. That leads me to think we should approach it as what design feels best within GitLab, and makes sense in our existing navigation, layout and hierarchy. It could end up being that what works best is actually very similar to what Octotree does today, but I want to start from a place of making sure that GitLab feels like a cohesive suite of functionality.

I do agree with hierarchically, the file tree makes sense to feel a part of the project / content area, and not the global navigation.

@dimitrieh Do you think there is a way to incorporate the button to toggle the file tree that uses the existing GitLab commanding/navigation? Like, ideally we don't create a special floating button, but instead find a place that groups it with similar functionality in the content area (as long as it makes sense).

@awhildy yes its quite a challenge to find that spot, where it would fit in.

just to review some old content from earlier comment, what you think of this (for placement)

or where would you expect it? as this is cross-tab-navigation.., but still project specific

@awhildy I was tinkering around in the webinspector when I though I could give this another try.. just to spring up some inspiration for possible implementations.

A whole sidebar in collapsed state is too much imo.. or we should fill it with information we need ?

not inline, and looks bad:

"okey"

button implemention is possible, but not inline with right side bar on MR & issue views (this one looks the best though)

Just curious - What does this file tree offer that the repository tab does not?

Good question @tauriedavis. When I installed it and played around with it, it was nice to be able to jump from file to file instead of into a file, then back out to the file list to go to another file. That being said, Octotree might just be an evolution of our repository/files tab. Is it really something that is 'Project' wide, or is it just that when you are in Repository/Files, and you tap on a file, the file list collapses into a file tree?

The other thing to consider: there has been a lot of explorations/talks around incorporating an IDE in one way or another. All IDEs I've seen have a file tree. Jumping quickly between files seems most helpful when you are editing them, right? Maybe that is the right way to solve this problem?

@awhildy I agree. Why don't we incorporate what we are missing into GL Repo tab. I think it should be repo only. Why not like Sublime does.

Dropdown the fuzzy search from the top of the screen and allow them to redirect that way.

@awhildy Mmh interesting thoughts here.

Basically this is just another version of the files view, but has a special functionality that is summonable throughout your project, to view this information inline with any other view your at.

This is basically what the repository view does not.. you can't view it inline with other information, unless you split your screen and view it in another browser tab.

So yes.. its project wide, or at least thats what it is supposed to be.

One of the usecases mentioned before is someone discussing something within a MR, when in need of viewing the file or file hierarchy.

I do think this functionality is thought of more in the classical git way. I mean when you open a repo on github.. the first thing you see above the Readme.md of the repo is the actual file tree. GitLab doesn't do this... this feature would incorporate that in some sense.

@jschatz1 I think seeing file hierarchy is one of the main selling points of this feature.. like getting a birds eye view. Fuzzy search doesn't do that. Although I am a big fan of this magical search command line feature popping up everywhere throughout applications I don't think it solves what octo tree tries to solve.

A good question to ask is perhaps, what do we really need from this functionality... are their enough usecases/potential users? I mean there is extension for it (which is actively used by a niche public).. what could we improve on that to make this actually usable for everyone...

currently this should be solved by making it native in gitlab.. does that justify this? although the idea still appeals to me.

just to give some thoughts of myself.. I do kind of like seeing your files, like on github when you open a repo. However I do feel GitLab is more than just a versioning backup. its the complete package, one where in files are not perse central?!?

its the complete package, one where in files are not central

This is where my original question came from. I'm not sure having the repo front and center is a primary concern for most users. I'm curious if there are other use cases other than the need to view a file or file hierarchy when reviewing an MR. If that is the primary concern (and if it is a common one), I think the solution can be addressed at the MR level, not the project level.

unassigning myself from this now.. as this clearly needs more thought.

Assignee removed

Agree with @tauriedavis.

An idea: Have a floating button in the right-bottom corner and it will work like the way the gif shows below.

I assume people don't need to see the sidebar and the filetree at the same time. When opened one of them, the other one will close.
This way will work well for the smaller screens (like 12" or 13") and also doesn't make the screen look heavy.

@hazelyang impressed here! seems to me as a subtle addition to the sidebar!

How would you see this in a place without the sidebar?, just the button i presume?

Nice @hazelyang, I think this is a good solution

How would you see this in a place without the sidebar?, just the button i presume?

I think the idea is maybe it only exists in merge requests if that is the only known use case for needing to see the file tree. That is, until we hear whether there are other use cases.

I've been thinking about this one. I like the location of this better then the top left, but still have concerns about a floating button. It's easy to fragment the UI and complicate it with too many UI surfaces. A floating button doesn't allow users to have any expectations on what it will do or relate it with other parts of the app. I worry that it just creates more noise and something else for the user to understand it's behavior, etc.

I've been trying to decide if it makes any sense to add it to the sidebar. I like @hazelyang's approach of having it use the same type of surface as the sidebar when it is expanded. But I am unsure if conceptually it relates to the other items in the sidebar.

I'll keep thinking about this. I just worry that it is easy to go overboard on floating buttons. But I do really like the interaction of it. Maybe I just need to consider the role of floating buttons. Thanks!

Totally agree with @tauriedavis. I think this should only exist on MRs for now.

@awhildy this looks pretty neat! Although the icon should be more implicit :)

as for mobile ui, how would you think this would work..as the whole sidebar collapses to 1 button?

Now I am thinking of a toggle at the top of the expanded sidebar.. which toggles between default state and filetree:

at the top of the sidebar.. as in mobile viewport..the sidebar scrolls.

I think this works better at the bottom of the sidebar. The filetree is separate from the MR information presented in the sidebar so mixing them together is confusing to me. The Todo button and the file tree button are completely separate so clicking on that and having the sidebar switch would be unexpected to me. I would assume this would bring me to a list of my todos or something similar.

@tauriedavis the solution I was looking for was for the mobile viewport, otherwise I am fine with @awhildy concept and indeed think it works best, instead of at the top

Yes, the file tree button should be visually and conceptually separate from other UI items. This will help us integrate it on other screens.

Mentioned in issue #25110 (moved)

Sorry to have let this issue go quiet for a while. A few thoughts that I'm still thinking through. Let me know if you have ideas on them!

Do we think it feels odd to have large navigational elements (global side bar, top nav, and now this) on potentially 3 sides of the screen? I'm worried it can start to feel confusing as to where to look for navigation. Maybe this isn't a problem, though, if most people have the global sidebar hidden most of the time.
Does it make sense to be able to navigate to the full file view from this pane, and if so how? I think it does -- you can imagine that while using this pane, you get lost and can't find the file you are looking for. A quick click that lets it 'expand' to the full file view page means now you can filter, sort and search through your files.

I still see the potential with this feature but I keep struggling to know if we really need it. That being said...

Yes it's odd. And yes we should find a way to not have another new navigational system. The button should be on the sidebar somehow and not add another button out of nowhere.
Not sure about this. Why would we need to have the full view that the current "tiny" view can't provide? As we navigate deeper and deeper, we just put a back button at the top, perhaps show the path (../../controllers for instance).

Added code review label

Do we think it feels odd to have large navigational elements (global side bar, top nav, and now this) on potentially 3 sides of the screen? I'm worried it can start to feel confusing as to where to look for navigation. Maybe this isn't a problem, though, if most people have the global sidebar hidden most of the time.

I definitely think this is a concern. It could be alleviated if we move the left sidebar to the topbar like suggested here: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/7591

Does it make sense to be able to navigate to the full file view from this pane, and if so how? I think it does -- you can imagine that while using this pane, you get lost and can't find the file you are looking for. A quick click that lets it 'expand' to the full file view page means now you can filter, sort and search through your files.

I don't see a reason to not allow it. I agree with @regisF about showing the path and perhaps adding a search. I think that would provide everything needed from the full page mode.

Apart from the coolness of the feature in itself, we haven't addressed, I feel, why developers or project members in general would need it.

I just want to say , I am not sure if we are thinking of doing this as in taking octotree and putting it in directly. We could not put octotree in directly and we would not want to. We would obviously want to roll our own. The code to Octotree is meant to hook into whatever we have available and it has to do some major hacks in order to get it working. There is of course no reason to hack anything. We can just write this ourselves.

This entire process annoys me tremendously. In the beginning, some guy creates Octotree. You may like, or you may not. GitLab approaches him, asks if it's ok that they take over, more or less telling him that "we've got it". He even states "I don't think contributing back is necessary as there's no reason to keep GitLab support in Octotree if the feature is built-in".

And then you don't really do anything. It all grinds to a halt. The big guys rolled in, told the little people to stay away, and then did nothing.

It would have been much, much better if you had an open discussion with the guy, helped improve any challenges with the integration, and otherwise said "That's a great thing you have there. Keep at it!"

I also don't have a problem with improving the current codebase. The last time I looked at it, it was grabbing on whatever to stuff we had available, which is awesome, but also hacky. It would be better if we made stuff available for the hook up. There isn't a reason for us to put a hack in since we have control of the source code. So either we make stuff available for octotree to make the integration easier and we improve octotree or we roll our own.

removed ~123454 label

mentioned in issue #26834 (closed)

This has come up again in context of https://gitlab.com/gitlab-org/gitlab-ce/issues/26834#note_23360858.

I really appreciate @regisF's comment here: https://gitlab.com/gitlab-org/gitlab-ce/issues/13723#note_19737804. Are files truly a core way some people navigate around a project? If so, why or what are they trying to do? Starting at the problems will really help us come with the right solution, instead of starting with the solution. I have only seen a few quick comments of people saying they would like it, but there is not enough information to understand what problem they are trying to solve with it and why they use it. I also have no idea on the number of people who use it (do we just hear the vocal minority). Without that information, we are designing blind.

@awhildy : Here are some problems/scenarios to answer your question:

Casual review of a codebase. This can be a new team member. This can be a new engineering manager. This could be a newcomer looking at a codebase on an open source project on gitlab.com. They may not want to clone the repo to their local machine. Currently reviewing the codebase online is possible. But you cannot easily see the directory structure, or easily navigate around different files. This is pretty much what @DouweM said way up in this thread: https://gitlab.com/gitlab-org/gitlab-ce/issues/13723#note_4051477.
Code review outside of the main merge request flow (https://gitlab.com/gitlab-org/gitlab-ee/issues/1767). Similar to above, but one step after "causal review". Now the person wants to start leaving comments, @-mentioning people on files/commits, but not necessarily start a merge request. And they still don't want to clone/download the codebase yet. The current file navigation allows this (after we implement comments on files). But again, with more friction, and not allowing to see the directory structure, similar to above.
Less technical users: Plenty of non-developers make changes to our handbook. People may want to make changes to a static website using GitLab Pages. In particular, GitLab Pages and static sites can be finally our first step into the non-software world and other industries. GitLab Pages integrated with Issues+Merge Requests is a really great way to do online publishing projects. Non-technical users could make content changes just like a dynamic site / blogging site with the static site being deployed automatically. (An example of a growing vertical industry is academia making open source textbooks on github.com that are typically LaTeX source code projects. e.g. https://github.com/bcrowell/calculus. I haven't seen one that integrates with Pages yet. But imagine instead of publishing to PDF locally with LaTeX, it just publishes to GitLab pages. A non-technical calculus professor can make an entire open source textbook within GitLab, with minimal tech support from a TA who just sets up gitlab-ci in the beginning.) But our UI still has a lot of technical jargon and friction. If we have some file tree solution, it is one small step in this direction, and would help our less technical users not worry about a console terminal, or have to care about git or branching, and all that technical detail.
Documentation sites: Similar to above, many documentation sites use GitHub Pages. Obviously we want to get a piece of the pie. I assume most documentation maintainers do their edits on their local machines. But it can't hurt if we reduce the friction and allow people to make quick edits online.

In sum, any file tree solution is a massive benefit to the web-ability of file browsing. Solving this problem significantly pushes us toward making our product much more web-friendly, and thus, opens it up to many more users beyond developers or folks with a lot of technical ability. As with many features, it is hard to gauge how this would be used by our existing users. But there is a clear benefit to our future growth in terms of other types of user non-technical or less technical users.

So that's why I really don't care too much about any design that allows you to see both a file directory and a gitlab issue at the same time. It may be nice if it can be achieved with low cost. But those problems are much further away. Just file browsing and problems related to browsing files (such as comment threads in a file view) are the immediate problems to be solved. Further integrations with other features of GitLab are later problems.

I tried to keep this problem-based, and not solution-based . I totally agree that's the right approach! Let me know your thoughts and we can see if makes sense to start attacking this problem bit by bit now.

@tauriedavis : Could you take a look at https://gitlab.com/gitlab-org/gitlab-ce/issues/13723#note_24460171 and add any thoughts? Thanks!

mentioned in issue #29089 (moved)

mentioned in issue #29529 (closed)

mentioned in issue #28161 (closed)

removed ~122770 label

mentioned in issue #29778 (closed)

Please add this, or plz commit some resources to supporting octotree once again.

First there was octotree for gitlab. Then gitlab reached out to embrace and extend the plugin, and in the end there was https://en.wikipedia.org/wiki/Embrace,_extend_and_extinguish.

@sytses @DouweM @elygre @dzaporozhets Hello! I just wanted to link a small Chrome(later FF) extension called Reposplit that I developed. It tries to accomplish part of what is being discussed here, tho I may add many more features in the future. It is compatible with both Github and Gitlab so far(make sure you install >= v0.2.0). Any feedback is very much welcome!

Off-topic: Is there a way to @everyoneWhoDiscussedThisIssue ? :)

Off-topic: Is there a way to @everyoneWhoDiscussedThisIssue ? :)

@git-toni looks like a feature idea

Off-topic: Is there a way to @everyoneWhoDiscussedThisIssue ? :)

@git-toni You mean a regular comment on the MR, so that everyone gets a notification email? :)

Something like Slack's @channel may be a bit too prone to abuse, especially with public projects like this.

Off-topic: Is there a way to @everyoneWhoDiscussedThisIssue ? :)

Agree with @DouweM - everyone who is a participant will get notified via email already!

@tauriedavis @DouweM @dzaporozhets If everyone is already notified as Taurie says, then it's exactly what I meant, so all covered :)

mentioned in issue #31890 (closed)

My effort here (https://gitlab.com/gitlab-org/gitlab-ce/issues/31890) should make this nessesary. Closing

closed

I started off looking for Octotree for gitlab, went through their issues list and now this one. @jschatz1 's PR does not work for me because I don't use VSCode and with Octotree, I specifically want a in-browser based navigation for files. Otherwise I'd use my own editor's file navigation.

What's the current status? ( briefly scanned this thread ) It seems like the initiative has been abandoned. I tried Reposplit but doens't seem to work for my private hosted gitlab source.

@mordrax indeed Reposplit is a young project, it has private gitlab repos in its todolist (see readme).

I don't use VSCode and with Octotree, I specifically want a in-browser based navigation for files. Otherwise I'd use my own editor's file navigation.

? Look at the screenshots it's an in-browser solution, based on https://github.com/Microsoft/monaco-editor

Thanks for the quick reply @vindarel , i'm confused what screenshots you're referring to. Do you mean the monaco-editor? reposplit? or screenshots further up in this thread? Honestly, I spent 10 minutes reading this thread but couldn't see what I'm meant to do.

And are you suggesting that I install monaco-editor to be able to browse a gitlab source tree?

In summary, is there an option (with a privately hosted gitlab repo) to view the source tree as an alternative to octotree/github as of now?

@mordrax Were you not looking at the issue #31890 (closed) referenced just above your comment ?

I don't think you have an option for a private gitlab repo right now. For Github: Octotree and for public Gitlab: Reposplit.

I specifically want a in-browser based navigation for files.

@mordrax, #31890 (closed) is an in-browser IDE. It is not VSCode. You are able to navigate files and/or edit them. @vindarel is referring to the screenshots in that issue - #31890 (closed).

marked this issue as related to #31890 (closed)

@sarrahvesselov when the integrated editor will be released? any estimated date?

Thanks

Ok, I get it, if it's built into gitlab as a file editor for READMEs then that would work.

Seems a massive overkill and scope blowout from this yr old thread though. Would have been great if the octotree + gitlab team worked together to make navigation work... a yr ago. I struggle to find a usecase for editing files in browser when it's so much easier to edit with preferred IDE and push changes. Hence octotree solving the only problem needing to be solved, navigation.

It will be available as an experimental feature in the next release @iamfreee.

Seems a massive overkill and scope blowout from this yr old thread though.

It was conceived of and implemented independently of this thread. It just happens to take care of issues mentioned here.

mentioned in issue #37808

mentioned in issue #37934

reopened

mentioned in issue #38011

moved to gitlab#4370

Hey!

GitLab is moving all development for both GitLab Community Edition and Enterprise Edition into a single codebase. The current gitlab-ce repository will become a read-only mirror, without any proprietary code. All development is moved to the current gitlab-ee repository, which we will rename to just gitlab in the coming weeks. As part of this migration, issues will be moved to the current gitlab-ee project.

If you have any questions about all of this, please ask them in our dedicated FAQ issue.

https://gitlab.com/gitlab-org/gitlab-ee/issues/13855

You can also find more information here:

https://gitlab.com/gitlab-org/gitlab-ee/issues/13304
https://about.gitlab.com/2019/08/23/a-single-codebase-for-gitlab-community-and-enterprise-edition/

Frequently Asked Questions

For an up to date list of questions and answers, please take a look at https://gitlab.com/gitlab-org/gitlab-ee/issues/13855

What will we do with the repository names?

https://gitlab.com/gitlab-org/gitlab-ee/ will become https://gitlab.com/gitlab-org/gitlab, and https://gitlab.com/gitlab-org/gitlab-ce will become https://gitlab.com/gitlab-org/gitlab-foss.

Why rename gitlab-ce to gitlab-foss?

Using "gitlab" and "gitlab-ce" would be confusing, so we decided to rename gitlab-ce to gitlab-foss to make the purpose of this FOSS repository more clear

I created a merge requests for CE, and this got closed. What do I need to do?

You will need to create a merge request at https://gitlab.com/gitlab-org/gitlab-ee/. This link will eventually redirect to https://gitlab.com/gitlab-org/gitlab.

How does the licensing work in this new setup?

Everything in the ee/ directory is proprietary. Everything else is free and open source software. If your merge request does not change anything in the ee/ directory, the process of contributing changes is the same as when using the gitlab-ce repository.

Will you accept merge requests on the gitlab-ce/gitlab-foss project after it has been renamed?

No. Merge requests submitted to this project will be closed automatically.

Will I still be able to view old issues and merge requests in gitlab-ce/gitlab-foss?

Yes.

How will this affect users of GitLab CE using Omnibus?

No changes will be necessary, as the packages built remain the same.

How will this affect users of GitLab CE that build from source?

Once the project has been renamed, you will need to change your Git remotes to use this new URL. GitLab will take care of redirecting Git operations so there is no hard deadline, but we recommend doing this as soon as the projects have been renamed.

Where can I see a timeline of the remaining steps?

https://gitlab.com/gitlab-org/gitlab-ee/issues/13304

Will community contributions submitted to the new "gitlab" repository be available in the new gitlab-foss repository?

Yes, these changes will be synced to gitlab-foss automatically, several times per day.

locked this issue

Ship octotree as part of GitLab

potential iteration:

Designs

Child items ...

Activity

Frequently Asked Questions

Admin message

Admin message

Ship octotree as part of GitLab

potential iteration:

Relates to

Activity

Frequently Asked Questions