New project welcome page does not propose the possibility to run git config for local project

mentioned in issue #469513 (closed)

assigned to @mh4ckt3mh4ckt1c4s

added Category:Source Code Management groupsource code labels

added devopscreate sectiondev labels

added featureenhancement label

added typefeature label

changed milestone to %Backlog

marked this issue as related to #27206

Hi @mh4ckt3mh4ckt1c4s, thanks for creating this issue!

I see @mle already linked Empty repository project page - simplify command line instructions, as related. Looking at your description and the description of the other issue, I'd like to propose:

change the heading copy to Git setup
remove --global flag from the code block
add a paragraph under the headline that will link to our documentation on how to set up credentials globally:

copy	link
Learn how to set up your credentials globally.	https://docs.gitlab.com/ee/topics/git/how_to_install_git/#configure-git

@mle WDYT?

added UX frontend labels

mentioned in issue #469506 (closed)

Hi @psjakubowska, thanks for your insights. I started working on this and wanted to change this block to 2 blocks (one with the --local flag, and one with the --global one), then I realized that it would be nice to reorganize this page hierarchy, as you just suggested in #469506 (closed). We can work on these two issues in parallel to determine what is the best outcome for this.

I missed #27206 when creating these issues. FYI I created #469513 (closed) with @slejeune to keep track of changes we wanted to make to the empty project welcome page. If there are other issues mentioning changes to the empty project page, you can add them here, we'd be glad to hear about them.

I agree adding a documentation link is a good thing, but I really believe that both git config blocks should be available. There is a big gain available here for developers, especially since #469486 (closed) have been resolved, to be able to quickly copy and paste the exact good command without having to type them or change a flag. But if there is a choice to make, I'll go with your proposition, because it is the most used one and the git default.

In hindsight a dropdown may not be the best choice. Maybe proposing the 2 blocks one after another is the simplest solution. Or adding a toggle (see below) to the page to change between local and global views. From my developer POW it really amounts to have the less clicks possible and to be able to copy-paste exact commands that are frequently used. I suppose that adding documentation at the beginning of the page allows someone that does not know how to proceed to be quickly redirected to documentation, while people who know what they want can just copy paste the good blocks and get going. I'm not an UX expert though, so happy to hear your thoughts on this.

100%! Though I think that if we go with the tabs for the section below, that tabs for this might be a better choice than a dropdown or a toggle. My thinking is that expecting a similar interaction from the user, makes it more predictable, ergo a better design.

So for the sake of transparency, we would use something like:

.scrolling-tabs-container.inner-page-scroll-tabs
  %ul.nav-links.scrolling-tabs.mobile-separator.nav.nav-tabs.gl-mb-5
    %li
      = link_to '#', data: { target: "div#LocalContent", action: "LocalContent", toggle: 'tab'} do
        = "Local"
    %li
      = link_to '#', data: { target: "div#GlobalSContent", action: "GlobalContent", toggle: 'tab'} do
        = "Global"
  .tab-content.gl-tab-content
    .tab-pane#LocalContent.active{:role => "tabpanel"}
      = "LOCAL CONTENT GOES HERE"
    .tab-pane#GlobalContent{:role => "tabpanel"}
      = "GLOBAL CONTENT GOES HERE"