git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: git init with specified user.email

From
brian m. carlson <sandals@crustytoothpaste.net>
Date
Jan 8, 2026, 23:22 UTC
Message-ID
<aWA8I82PXXVjiMVR@fruit.crustytoothpaste.net>
In-Reply-To
<875x9cvx44.fsf@word>
On 2026-01-08 at 17:21:31, David Miguel Susano Pinto wrote:
Show 10 quoted lines
> git checkout has a --config option so one can do:
> 
>     git clone --config 'user.email=email-for-this-clone' ...
> 
> which I find nice to setup as git alias:
> 
>     clone-work = clone --config 'user.email=my-work-email'
> 
> (while leaving the default clone for my personal projects; or an alias
> for clone-personal with the work email as the clone default).

The reason this functionality exists is because it sets those configuration variables as soon as the repository is initialized and _before_ actually downloading the data. As an example, if you wanted to set a split index or a default line ending configuration, you'd want to set that before the index was created and the working tree was checked out, so you can't do that after the clone command completes.

Show 7 quoted lines
> I would like something similar for git init.  However, git init does not
> have a `--config` option.  I tried to use
> 
>     git -c 'user.email=my-work-email' init
> 
> but that's not working (I'm guessing it only picks up configurations
> mentioned on the man page for git-init).

`git -c` (where `-c` precedes the subcommand) is different. It sets the configuration option _for this command only_ and doesn't save it in the config. For instance, if you want to run a single diff command without colours, you can run `git -c color.diff=false diff`; that won't affect any of the configuration files.

The reason that Git doesn't provide a config option for `git init` is because, except for things like the hash algorithm and ref format, almost nothing is done to the repository when the command completes. There isn't even an index created, so setting configuration like split index in a separate configuration command isn't a problem.

> I am currently working around this with a template for work but would
> prefer to init with `-c` (or similar) or at least understand why this is
> not possible.
This is possible with an alias like so:
    init-work = "!f() { dir=\"$1\"; shift; git init \"$@\" \"$dir\"; git -C \"$dir\" config set user.email my-work-email; }"

This would work slightly differently in that you'd need to specify the directory first unless you wanted to adjust the alias to do more complicated shell parsing. You could also implement a shell script called `git-init-work` (using `git rev-parse --parseopt`[0] or otherwise) that would handle the complexities and it would work just like the alias as long as you put it in `PATH`.

One other approach that might work for you is the includeIf functionality in the config file. You could do something like this in your main config file:

    [includeIf "gitdir:~/checkouts/work/**"]
        path = ~/.config/git/config-work

And then set the `user.email` value in `~/.config/git/work`. That would mean that any repositories under `~/checkouts/work` would automatically have the config values in `~/.config/git/config-work` set.

[0] If you want an example of using `git rev-parse --parseopt`, you can see https://github.com/bk2204/dotfiles/blob/dev/bin/dct-mtree, which demonstrates some of the functionality. The manual page is also helpful.

-- 
brian m. carlson (they/them)
Toronto, Ontario, CA
Previous: David Miguel Susano Pinto
Message 2 of 2 in “git init with specified user.email”
  1. David Miguel Susano PintoJan 8, 2026
  2. brian m. carlsonJan 8, 2026

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.