Git Alias not working in worktree

Dear Git User-group,

I am having a setup where I use worktrees and I was now experimenting with adding git aliases to work more efficiently with the commands. However I found that obviously it does not seem to work like I would like to have it:

My intention is to have a ".gitconfig" file as part of the repo so that all developers can easily get to the same configuration that was setup and also to have the config tracked as part of the repo. We are using Git for Windows v2.28 and also git 2.28 on Linux.

I printed my config from my windows machine below.
You will also see that I have two aliases defined now at two places:
-  The "sts" alias in an include file from my personal .gitconfig ni my HOME
-  The "st" alias in the include file that is part of the repository which is included in the config of the worktree

Only the "sts" alias is recognized by git and works, while the "st" is unknown. But both of the aliases show equally in the below "git config -list".

WHY is the one working and the other one not! HOW can I get both working equally?

Any hints or help is greatly appreciated. Thanks and best regards, Frank

me@MYPC /c/WORK/my_src/wt_KER-dev-B (Features/2.1/gitUtilities|SPARSE) $ git config --list --show-origin file:D:/Programs/GitForWindows/etc/gitconfig    http.sslcainfo=D:/Programs/GitForWindows/mingw64/ssl/certs/ca-bundle.crt file:D:/Programs/GitForWindows/etc/gitconfig    http.sslbackend=openssl file:D:/Programs/GitForWindows/etc/gitconfig    diff.astextplain.textconv=astextplain file:D:/Programs/GitForWindows/etc/gitconfig    filter.lfs.clean=git-lfs clean -- %f file:D:/Programs/GitForWindows/etc/gitconfig    filter.lfs.smudge=git-lfs smudge -- %f file:D:/Programs/GitForWindows/etc/gitconfig    filter.lfs.process=git-lfs filter-process file:D:/Programs/GitForWindows/etc/gitconfig    filter.lfs.required=true file:D:/Programs/GitForWindows/etc/gitconfig    credential.helper=manager file:D:/Programs/GitForWindows/etc/gitconfig    core.autocrlf=true file:D:/Programs/GitForWindows/etc/gitconfig    core.fscache=true file:D:/Programs/GitForWindows/etc/gitconfig    core.symlinks=false file:D:/Programs/GitForWindows/etc/gitconfig    pull.rebase=false file:C:/Users/myaccount/.gitconfig       user.name=My Name file:C:/Users/myaccount/.gitconfig       mailto:user.email=me@comp.de file:C:/Users/myaccount/.gitconfig       receive.denycurrentbranch=updateInstead file:C:/Users/myaccount/.gitconfig       include.path=.gitconfig.aliases file:C:/Users/myaccount/.gitconfig.aliases       alias.sts=status -s file:C:/WORK/my_src/_MAIN/.git/config core.repositoryformatversion=1 file:C:/WORK/my_src/_MAIN/.git/config core.filemode=false file:C:/WORK/my_src/_MAIN/.git/config core.bare=false file:C:/WORK/my_src/_MAIN/.git/config core.logallrefupdates=true file:C:/WORK/my_src/_MAIN/.git/config core.ignorecase=true file:C:/WORK/my_src/_MAIN/.git/config core.symlinks=true file:C:/WORK/my_src/_MAIN/.git/config core.longpaths=true file:C:/WORK/my_src/_MAIN/.git/config mailto:remote.origin.url=git@gitlab.xyz.com:project.git file:C:/WORK/my_src/_MAIN/.git/config remote.origin.fetch=+refs/heads/*:refs/remotes/origin/* file:C:/WORK/my_src/_MAIN/.git/config branch.master.remote=origin file:C:/WORK/my_src/_MAIN/.git/config branch.master.merge=refs/heads/master file:C:/WORK/my_src/_MAIN/.git/config extensions.worktreeconfig=true file:C:/WORK/my_src/_MAIN/.git/config fetch.prune=true file:C:/WORK/my_src/_MAIN/.git/config fetch.prunetags=true file:C:/WORK/my_src/_MAIN/.git/worktrees/wt_KER-dev-B/config.worktree include.path=C:/WORK/my_src/wt_KER-dev-B/.gitconfig file:C:/WORK/my_src/wt_KER-dev-B/.gitconfig   core.hookspath=devops/git/hooks file:C:/WORK/my_src/wt_KER-dev-B/.gitconfig   core.longpaths=true file:C:/WORK/my_src/wt_KER-dev-B/.gitconfig   extensions.worktreeconfig=true file:C:/WORK/my_src/wt_KER-dev-B/.gitconfig   fetch.prune=true file:C:/WORK/my_src/wt_KER-dev-B/.gitconfig   fetch.prunetags=true file:C:/WORK/my_src/wt_KER-dev-B/.gitconfig   alias.st=status file:C:/WORK/my_src/_MAIN/.git/worktrees/wt_KER-dev-B/config.worktree core.sparsecheckout=true

me@MYPC /c/WORK/my_src/wt_KER-dev-B (Features/2.1/gitUtilities|SPARSE) $ git st git: 'st' is not a git command. See 'git --help'.

The most similar commands are
        status
        sts

me@MYPC /c/WORK/my_src/wt_KER-dev-B (Features/2.1/gitUtilities|SPARSE) $ git sts M .gitconfig M devops/python/modules/gitUtilities.py

On 2020-09-25 at 16:44:25, Frank Illenseer wrote:

I'm not sure about what's causing the issue that you're having, but let me dissuade you from trying to store configuration in the repository. Git's security model doesn't permit untrusted configuration because configuration can be used to specify programs and execute arbitrary code. If you specify a config file that's in the repository and someone checks out a branch with a malicious config file, they can execute arbitrary code on that system.

If you want to provide settings, it would be better to provide a shell script that developers could _optionally_ run (after first verifying) that sets certain config options. Because that would be run only on demand by the user and can be inspected before running, it would be a lot more secure. In addition, if you're setting aliases, it's possible that the user may already have an alias for that option that they are used to and expect to work a certain way (e.g., my "git co" is recursive) and may not want your alias.

I realize you may be working in a corporate environment where users are somewhat more trusted, but take note that you probably don't let developers execute arbitrary code on each other's systems and social engineering attacks ("Hey, can you check out this branch and see why the code isn't working?") are easy. There's a big difference between "I ran this script" and "I checked out this branch".

Hopefully someone else can provide an answer to why your alias isn't working. I have some guesses, but no definitive answers at the moment. I'll try to play around with some things and figure it out over the next couple of days if nobody gets to it before me.

Thanks, Brian for your comments and input. - Definitely a good input and always good to keep security high-up in view! However in the secure corporate environment and with a lot of developers (not always doing what they are requested), the need to "enforce" something is more emerging...

Thus I would like to re-iterate the question and ask for your suspicions (as you mentioned you might have some) and/or others, if anyone can see why this is not working as I was assuming it to work...

Thanks and best regards, Frank

Hi All,

Does anyone have any idea as to why the alias definitions from the config of a worktree is not working? - I would still be interested in a solution to get this working.

Thanks and best regards, Frank

On Thu, Oct 22, 2020 at 8:06 AM Frank Illenseer <illenseer@altair.de> wrote:

For reference, the original question was posted in[1], and brian mentioned[2] that he would take a look at it. brian, did happen to investigate this at all?

[1]: https://lore.kernel.org/git/DM5PR03MB2826C04CC5AAF3B61BDDAFE2B5360@DM5PR03MB2826.namprd03.prod.outlook.com/ [2]: https://lore.kernel.org/git/20200925222801.GC1392312@camp.crustytoothpaste.net/

On October 22, 2020 3:07 PM, Eric Sunshine wrote:

Does the alias work in your main working directory and but not in the worktree? I'm trying to figure out how you would specify a worktree-specific alias in the first place since it is shared with all worktrees of the main clone.

Regards, Randall

-- Brief whoami:
 NonStop developer since approximately 211288444200000000
 UNIX developer since approximately 421664400
-- In my real life, I talk too much.