Cloning instructions for users joining an existing project

When i create a new project as an administrator, i get a very useful page with the command-line instructions for ‘Git Global Setup’, ‘Create New Repo’, etc. but if i am a new user, joining an existing Project, i don’t see anything like that.
I see a “Download ZIP” drop-down on the project’s page, but not a “Clone Project” option (that would be very nice to have).
Does such a page exist? If yes, how do i navigate to it?

No, I don’t think this is implemented.

That is what I use the for. I include messages to the users about what the repo is for. Explain if the default branch has been change and what is expected of contributors.

thanks, i’ll try that. since you’ve mentioned a file, i guess there is no way to set it up from the UI ??? Where would this file normally be located on a RHEL/CentOS box ?

Thanks, @mojibakeumd.
that was a good suggestion - definitely easier to find than my attempt to use the WiKi page.
i didn’t realize earlier (before some googling) that is somehow special and will pop up automgically on the project’s tab

I think you figured this out based on your next comment, but you can setup the from the UI. I am using Omnibus 7.10.1 which when a new project is created there is a red “Add file” button on the project page. You can create the (just name it so) and commit. the is committed to the repo in the base of the repo, but I believe if you have in sub-directories as you browse the code in the project as you drill down into the directories you should see the for the sub-directory you are in if the exists.
I believe there is a pull request to have a repo template committed to a new project when a new project is created. Would be great if that was implemented as you could have custom, or custom_hooks when a new project is created.

just noticed a peculiar thing: i attempted to edit the file. The link from the Project’s README tab takes me to the …/blob/master/ which i edited and committed, and now it show updated content. However when i return to Project’s README tab, i see the old content, unmodified. Any ideas? Is GL caching it someplace? On another project, i’ve attempted to make the same changes 3 times, and every time i commit to master, it says that changes were committed successfully, but the file content shows the old one, as if nothing happened.
p.s. i have other users actively ‘pushing’ their work from their local repos. is the server falling behind and can’t process my changes down in Web UI?

@mrudd, the file ‘’ is just a normal text file that you include at the root level of your repo. There is nothing special about it. Gitlab is programmed to look for such a file, and if it finds one, display its contents on the Readme tab. Github and Bitbucket and several others also do this.

When you edit this file online with the web UI, it creates a temporary file on the hard disk, adds the text you type into the web form, and then adds it to the repo as a commit. This is an easy and convenient way to edit the file, but not the only way.

You can also edit it on your local computer, then commit any changes to your local repo. When you push your local repo back to the server, the updated Readme will automatically show up in the tab.

Keep in mind that this file CAN be different across branches. The one you first see will be the one from your default branch. Most of the time this is ‘master’. If you want to edit the default readme, you probably need to ensure you’re editing it on the ‘master’ branch. If you edit it anywhere else, the changes will only show up when you switch to that branch.

If for some reason the website ui is broken and not committing your changes, try editing it in your local repo using a text editor, and then committing and pushing it yourself.


thanks, @damccull

that’s exactly that - the Web UI appears to be ‘broken’ for some reason. I can edit, commit and push the file from my local repo to GitLab, and it works as expected. However, all attempts to edit any file, (i checked after i created this post) from multiple Pcs by various users fail with the same results. The message says that it was successfully committed, but no changes take affect… Almost, as if the temporary file that was created never gets committed to the repo. I think it has something to do with the size of the repository and some sort of an internal timeout in GitLab.

The main reason we are interested in this feature is to provide an easy edit/commit functionality to our non-developers (DBA’s, Testers, etc.).