git-lfs / git-lfs

Git extension for versioning large files
https://git-lfs.com
Other
12.91k stars 2.03k forks source link

Multiple 'url.*..insteadof' keys with the same alias, take 2 #5386

Open intelfx opened 1 year ago

intelfx commented 1 year ago

(kind of a follow-up to #4412)

Describe the issue

I have a gitconfig hierarchy that defines multiple insteadOf entries for identical aliases.

I do this to keep a "clean" version of my gitconfig that I check in to my dotfiles, and a "private" gitconfig overlay that I do not check in, that is manually synced to the machines that have my private keys. Here's how it looks:

# ~/.gitconfig
[include]
path = ~/.gitconfig.private

[url "https://github.com/"]
insteadOf = gh:
insteadOf = git://github.com/
# ~/.gitconfig.private
[url "git@github.com:"]
insteadOf = gh:
insteadOf = git://github.com/
insteadOf = https://github.com/

This appears to work with Git 2.40.1 as I want it to (on machines that only have ~/.gitconfig, the HTTPS URL is used for GitHub, and on machines that have ~/.gitconfig.private, the SSH URL is used instead). However, Git LFS complains:

warning: Multiple 'url.*..insteadof' keys with the same alias: "gh:"
warning: Multiple 'url.*..insteadof' keys with the same alias: "git://github.com/"

Could Git LFS be changed to behave in the same way as Git? Or am I relying on "undefined" behavior here?

System environment

OS: up-to-date Arch

$ git config -l
include.path=~/.gitconfig.private
<...>
url.git@github.com:.insteadof=gh:
url.git@github.com:.insteadof=git://github.com/
url.git@github.com:.insteadof=https://github.com/
<...>
include.path=~/.gitconfig.machine
<...>
url.https://github.com/.insteadof=gh:
url.https://github.com/.insteadof=git://github.com/
url.git@github.com:.pushinsteadof=gh:
url.git@github.com:.pushinsteadof=git://github.com/
url.git@github.com:.pushinsteadof=https://github.com/
<...>

Output of git lfs env

git-lfs/3.3.0 (GitHub; linux amd64; go 1.19.4)
git version 2.40.1

warning: Multiple 'url.*..insteadof' keys with the same alias: "gh:"
warning: Multiple 'url.*..insteadof' keys with the same alias: "git://github.com/"
Endpoint=https://github.com/intelfx/dotfiles.git/info/lfs (auth=none)
  SSH=git@github.com:intelfx/dotfiles
warning: Multiple 'url.*..insteadof' keys with the same alias: "gh:"
warning: Multiple 'url.*..insteadof' keys with the same alias: "git://github.com/"
LocalWorkingDir=/home/intelfx
LocalGitDir=/home/intelfx/.git
LocalGitStorageDir=/home/intelfx/.git
LocalMediaDir=/home/intelfx/.git/lfs/objects
LocalReferenceDirs=
TempDir=/home/intelfx/.git/lfs/tmp
ConcurrentTransfers=8
TusTransfers=false
BasicTransfersOnly=false
SkipDownloadErrors=false
FetchRecentAlways=false
FetchRecentRefsDays=7
FetchRecentCommitsDays=0
FetchRecentRefsIncludeRemotes=true
PruneOffsetDays=3
PruneVerifyRemoteAlways=false
PruneRemoteName=origin
LfsStorageDir=/home/intelfx/.git/lfs
AccessDownload=none
AccessUpload=none
DownloadTransfers=basic,lfs-standalone-file,ssh
UploadTransfers=basic,lfs-standalone-file,ssh
GIT_EXEC_PATH=/usr/lib/git-core
git config filter.lfs.process = "git-lfs filter-process"
git config filter.lfs.smudge = "git-lfs smudge -- %f"
git config filter.lfs.clean = "git-lfs clean -- %f"
bk2204 commented 1 year ago

Hey,

Does this actually work as expected except for the warning, or is it producing incorrect behaviour beyond the warning? I suppose that we can remove the warning, which seems to have come in with this code from #1443.

intelfx commented 1 year ago

@bk2204 I believe it sometimes produces incorrect behavior, but I still need to narrow it down.

Specifically: in a private repository cloned via an HTTPS URL, git-lfs operations sometimes try to ask for my HTTPS credentials (despite that the SSH URL should have been substituted instead) whereas regular git operations (fetch or push) never ask for my HTTPS credentials.

I can try to debug this, I was just wondering if I'm relying on "undefined behavior" as far as git-lfs is concerned, or if this is something that you would be open to changing/fixing. The insteadOf precedence order does not seem to be documented.

bk2204 commented 1 year ago

I think we'd be open to changing this to behave as Git does, provided it has consistent behaviour.