HomeAboutPostsTagsProjectsRSS

Git

Updated
Words1164
TagsRead2 minutes

Issue

When I decided to manage my sketchybar configuration as a git submodule within my Nix Flakes setup, I encountered an unexpected obstacle. Attempting to run darwin-rebuild was met with failure as the system couldn’t locate the source of the local directory. It’s a known issue as discussed in the Submodules of flakes are not working thread.

Overcoming the Submodule Challenge

I devised a workaround that resolved the problem and ensured proper file execution permissions. Before diving into the implementation details, I must emphasize the necessity of updating the flake.lock file. This is a critical step to ensure submodule is recognized by nix:

nix flake lock --update-input config-sketchybar-src

Solution

In flake.nix define the submodule directory as input

{
    inputs = {
      # submodule directory
      config-sketchybar-src = {
        url = "git+file:./config-sketchybar";
        flake = false;
      };
    };

    outputs = inputs@{ self, nixpkgs, darwin, home-manager, ... }:
    let username = "nohzafk";
    in {
      darwinConfigurations."MacBook-Pro" = darwin.lib.darwinSystem {
        system = "aarch64-darwin";
        specialArgs = { inherit inputs username; };
        modules = [
          ./configuration.nix
          ./system-preferences.nix
          {
            users.users."${username}" = {
              name = "${username}";
              home = "/Users/${username}";
            };
          }
          home-manager.darwinModules.home-manager
          {
            home-manager.useGlobalPkgs = true;
            home-manager.useUserPackages = true;
            home-manager.users."${username}".imports = [ ./home.nix ];
            home-manager.extraSpecialArgs = { inherit inputs username; };
          }
        ];
      };
    };
}

in home.nix

{ inputs, username, config, pkgs, ... }: {
    imports = [
       ./config-window-manager.nix
    ];
}

in config-window-manager.nix

{ inputs, lib, pkgs, ... }: {
let
  sketchybar-config =
    pkgs.callPackage ./pkg-sketchybar-config.nix { inherit inputs pkgs; };
in {
  home.packages =
    lib.mkBefore = [ sketchybar-config ];

  home.file.".config/sketchybar".source = sketchybar-config;

}

finally in pkg-sketchybar-config.nix

{ inputs, pkgs, ... }:
pkgs.stdenv.mkDerivation {
  name = "sketchybar-config";

  dontConfigure = true;
  dontUnpack = true;
  src = inputs.config-sketchybar-src;

  installPhase = ''
    mkdir -p $out
    cp -r $src/config/sketchybar/* $out

    # Find all .sh files and substitute 'jq' with the full path to the jq binary
    find $out -type f -name "*.sh" | while read script; do
      substituteInPlace "$script" \
        --replace 'jq' '${pkgs.jq}/bin/jq'
    done

    chmod -R +x $out
  '';
}

In the end, the satisfaction of having your local directory seamlessly integrated as a git submodule and functioning perfectly within the Nix ecosystem is well worth the effort.

Updated
Words445
TagsRead2 minutes

When building Docker images, it is common to configure Git within the image using commands like git config --global user.name and git config --global user.email. These commands update the global Git configuration for the user during the image build process. However, when running git commit inside a container that is spawned from the image, you may encounter a “please tell me who you are” error. This error occurs because the Git configuration set during the build process does not persist in the container.

The Issue

The git config --global command updates the global Git configuration for the user running the command. By default, the configuration is stored in a .gitconfig file located in the home directory of the user. When you add the git config commands to your Dockerfile, they only affect the image build process and do not persist when a container is created.

Solution Methods

Method 1: Set Git Config at Runtime

One way to resolve this issue is by setting the Git configuration within the container at runtime. This can be done manually or by adding the commands to a startup script. For example, you can run the following commands when starting the container:

git config --global user.name "Your Name"
git config --global user.email "email@example.com"

By setting the Git configuration at runtime, it ensures that the configuration is applied consistently whenever a container is started.

Method 2: Copy a Prepared .gitconfig File

Another approach is to prepare a .gitconfig file on your host system with the desired settings and then copy it into the Docker image. This method allows you to define the Git configuration outside of the Docker build process.

To do this, create a .gitconfig file on your host system with the desired Git settings. For example:

[user]
    name = Your Name
    email = email@example.com

Next, include the following line in your Dockerfile:

COPY .gitconfig /root/.gitconfig

This line copies the .gitconfig file from the host system into the /root/.gitconfig path within the image. When a container is created from the image, it will include the copied .gitconfig file, ensuring that the Git configuration is persisted.

Conclusion

When using Git within Docker containers, it is important to ensure that the Git configuration persists across container runs. This can be achieved by setting the Git configuration at runtime or by copying a prepared .gitconfig file into the container. By following these approaches, you can avoid the “please tell me who you are” error and have consistent Git configurations within your Docker containers.