dont append ".git" to git clone urls #12542

New Issue

GiteaMirror · 2025-11-02T10:13:29-06:00

GiteaMirror commented

2025-11-02 10:13:29 -06:00

Originally created by @milahu on GitHub (Feb 26, 2024).

Feature Description

gitea should use the same url for a repo's webinterface url and git clone url

currently, gitea / github / gitlab append the ".git" suffix to git clone urls
but technically, the ".git" suffix is not required for git clone

sourcehut has git clone urls without the ".git" suffix

example

https://try.gitea.io/milahu/random       # webinterface url
https://try.gitea.io/milahu/random.git   # clone url

Why do some repository URLs end in .git while others don't?

The convention is that the .git extension should be used for bare repositories, and left off of directories with a working tree. Git doesn't really care

Screenshots

No response

Originally created by @milahu on GitHub (Feb 26, 2024). ### Feature Description gitea should use the same url for a repo's webinterface url and git clone url currently, gitea / github / gitlab append the ".git" suffix to git clone urls but technically, the ".git" suffix is not required for `git clone` sourcehut has git clone urls without the ".git" suffix example ``` https://try.gitea.io/milahu/random # webinterface url https://try.gitea.io/milahu/random.git # clone url ``` [Why do some repository URLs end in .git while others don't?](https://stackoverflow.com/questions/11068576/why-do-some-repository-urls-end-in-git-while-others-dont) > The convention is that the .git extension should be used for bare repositories, and left off of directories with a working tree. Git doesn't really care ### Screenshots _No response_

GiteaMirror added the type/proposal label 2025-11-02 10:13:29 -06:00

GiteaMirror closed this issue

2025-11-02 10:13:29 -06:00

GiteaMirror commented

2025-11-02 10:13:29 -06:00

@silverwind commented on GitHub (Feb 26, 2024):

The .git suffix is a convention that indicates the repo is bare, and all repos on gitea are bare. I'm not sure if it's a good idea to remove because some non-standard clients may require it to be able to clone, given how ubiquitous it is. Could maybe be made an option.

@silverwind commented on GitHub (Feb 26, 2024): The `.git` suffix is a convention that indicates the repo is bare, and all repos on gitea are bare. I'm not sure if it's a good idea to remove because some non-standard clients may require it to be able to clone, given how ubiquitous it is. Could maybe be made an option.

GiteaMirror commented

2025-11-02 10:13:30 -06:00

@a1012112796 commented on GitHub (Feb 27, 2024):

In fact you can clone a repository without the .git suffix also.

@a1012112796 commented on GitHub (Feb 27, 2024): In fact you can clone a repository without the `.git` suffix also.

GiteaMirror commented

2025-11-02 10:13:30 -06:00

@milahu commented on GitHub (Feb 27, 2024):

some non-standard clients may require it

this theoretical minority of broken git clients
should not hurt the majority of working git clients

with working git clients, the ".git" suffix is just not needed
and is only a human-readable hint for the user
this applies to all protocols: file, https, ssh

git init test_repo
echo hello >test_repo/readme.txt
git -C test_repo add readme.txt
git -C test_repo commit -m "add readme.txt"

git init --bare test_repo.git
git -C test_repo push file://$PWD/test_repo.git
git -C test_repo.git log
git -C test_repo.git branch
git -C test_repo.git fetch file://$PWD/test_repo

mv test_repo.git test_repo_bare
git -C test_repo push file://$PWD/test_repo_bare
git -C test_repo_bare log
git -C test_repo_bare branch
git -C test_repo_bare fetch file://$PWD/test_repo

only gitlab is pedantic with its redirects and warnings
but also on gitlab, git clone etc just work without the ".git" suffix

$ git clone --depth=1 https://gitlab.com/milahu/random
Cloning into 'random'...
warning: redirecting to https://gitlab.com/milahu/random.git/
remote: Enumerating objects: 25, done.
remote: Counting objects: 100% (25/25), done.
remote: Compressing objects: 100% (19/19), done.
remote: Total 25 (delta 0), reused 25 (delta 0), pack-reused 0
Receiving objects: 100% (25/25), 24.43 KiB | 1.88 MiB/s, done.

@milahu commented on GitHub (Feb 27, 2024): > some non-standard clients may require it this theoretical minority of broken git clients should not hurt the majority of working git clients with working git clients, the ".git" suffix is just not needed and is only a human-readable hint for the user this applies to all protocols: file, https, ssh ``` git init test_repo echo hello >test_repo/readme.txt git -C test_repo add readme.txt git -C test_repo commit -m "add readme.txt" git init --bare test_repo.git git -C test_repo push file://$PWD/test_repo.git git -C test_repo.git log git -C test_repo.git branch git -C test_repo.git fetch file://$PWD/test_repo mv test_repo.git test_repo_bare git -C test_repo push file://$PWD/test_repo_bare git -C test_repo_bare log git -C test_repo_bare branch git -C test_repo_bare fetch file://$PWD/test_repo ``` only gitlab is pedantic with its redirects and warnings but also on gitlab, git clone etc just work without the ".git" suffix ``` $ git clone --depth=1 https://gitlab.com/milahu/random Cloning into 'random'... warning: redirecting to https://gitlab.com/milahu/random.git/ remote: Enumerating objects: 25, done. remote: Counting objects: 100% (25/25), done. remote: Compressing objects: 100% (19/19), done. remote: Total 25 (delta 0), reused 25 (delta 0), pack-reused 0 Receiving objects: 100% (25/25), 24.43 KiB | 1.88 MiB/s, done. ```

GiteaMirror commented

2025-11-02 10:13:30 -06:00

@nephatrine commented on GitHub (Feb 27, 2024):

What is the motivation for wanting to remove the .git suffix? Is there something it breaks or some hurdle it creates for users? You can use the url either with or without the .git for both the clone url and web interface url and it "just works" in every client I've tried at least. The current behavior aligns with github and other large git hosting platforms so I don't see why it should be changed simply because we can if there's no other justification.

@nephatrine commented on GitHub (Feb 27, 2024): What is the motivation for wanting to remove the `.git` suffix? Is there something it breaks or some hurdle it creates for users? You can use the url either with or without the `.git` for both the clone url and web interface url and it "just works" in every client I've tried at least. The current behavior aligns with github and other large git hosting platforms so I don't see why it should be changed simply because we can if there's no other justification.

GiteaMirror commented

2025-11-02 10:13:30 -06:00

@silverwind commented on GitHub (Feb 27, 2024):

It would likely break docker which requires git URLs to end with .git or start with git://, github.com/ or git@.

https://github.com/moby/moby/blob/master/builder/remotecontext/urlutil/urlutil.go

@silverwind commented on GitHub (Feb 27, 2024): It would likely break docker which requires git URLs to end with `.git` or start with `git://`, `github.com/` or `git@`. https://github.com/moby/moby/blob/master/builder/remotecontext/urlutil/urlutil.go

GiteaMirror commented

2025-11-02 10:13:31 -06:00

@milahu commented on GitHub (Feb 27, 2024):

What is the motivation for wanting to remove the .git suffix?

aesthetics. its as obsolete as the www. prefix of domains

It would likely break docker which requires git URLs to end with .git

ok, such heuristics are a reason to keep the .git suffix...

sorry for the noise .__.

@milahu commented on GitHub (Feb 27, 2024): > What is the motivation for wanting to remove the `.git` suffix? aesthetics. its as obsolete as the `www.` prefix of domains > It would likely break docker which requires git URLs to end with `.git` ok, such heuristics are a reason to keep the `.git` suffix... sorry for the noise .__.

GiteaMirror commented

2025-11-02 10:13:31 -06:00

@silverwind commented on GitHub (Feb 27, 2024):

For reference, there is https://github.com/docker/cli/issues/1738 about removing that restriction in docker, but it's been stale for a long time.

Overall, yes, I think it's better not to change this, at least not as the default.

@silverwind commented on GitHub (Feb 27, 2024): For reference, there is https://github.com/docker/cli/issues/1738 about removing that restriction in docker, but it's been stale for a long time. Overall, yes, I think it's better not to change this, at least not as the default.

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#12542