4

I have a repository with a repo/.git/config file where aliases are defined.

Is there a handy way to import those aliases in the repo-clone/.git/config file generated by the git clone repo repo-clone command ?

The two repositories are on different devices so I cannot use this solution witch uses the global configuration file ($HOME/.gitconfig).

EDIT

I found a new answer, more related to this particular case of importing aliases when cloning, please see comments below.

  • 1
    I think the right place for such aliases would be in a tracked file in the repository itself, with it being up to the creator of the new repository to copy them into `.git/config` if desired. `.git/config` contains configuration that is *associated* with a repository, not *part* of it. – chepner Dec 18 '18 at 17:05
  • 1
    *…putting in a script with whatever commands you want in the root directory of your project and asking users to run it when they first clone.* – phd Dec 18 '18 at 17:58
  • https://stackoverflow.com/a/31605421/7976758 – phd Dec 18 '18 at 18:00
  • @chepner You point out a very interesting thing ! It seems that you can't indicate that some of the aliases you defined for this repository are in fact *part* of it. As aliases are included in the config file they have to respect the same constraints. – NullPointerWizard Dec 19 '18 at 09:07

1 Answers1

3

You cannot set aliases in the target repo's configuration merely as an automatic result of cloning. Such a feature would be open to pretty wild abuse, since it would mean that I could trick you into running arbitrary code of my choosing by getting you to clone my repo and having it set an alias you don't expect over a command you're likely to use.

"But, Mark, aliases can't override built-in git commands."

Ok, but if I'm trying to propagate some sort of malware, I probably only have to fool some of the people some of the time. A lot of people have a "co" alias, or struggle with typing "chekcout" when they mean "checkout"; so I can alias things like that. You probably don't want to blindly accept those configurations from any old clone operation you might execute.

You can create a script that sets the alias configurations and include it in your repo. Then someone who clones the repo can run the script (if they trust you, or have examined the script and are satisfied that it's safe).

For a trusted repo, you could even set up a hook to run on checkout or something, so that the alias configuration can be updated as the repo content changes. Again it would be up to the local user whether to actually configure this hook or not, as is necessary for security.

Mark Adelsberger
  • 42,148
  • 4
  • 35
  • 52
  • My problem stands in a trusted environment (no cloning from outside) but I understand the security concerns. Configuring hooks may be a bit tricky for regular users so I will go for an additional "script setup step" after cloning. With the additional links provided higher it looks like the best solution, given the security constraints. I just need to provide users aliases in order to manage the branch logic I imagined and I was hoping for a "ready for use" thing. – NullPointerWizard Dec 19 '18 at 08:51
  • Found the `--config` (or `-c`) option of the git clone command (Ex: `git clone --config alias.last='log -1 HEAD'`). This is not exactly automatic but I guess it can do the job if you have a few aliases to set up. – NullPointerWizard Dec 19 '18 at 09:31