Skip to content

Change {Key: key, Value: xxx} to {key: xxx} - #17

Open
kuyacarlo wants to merge 5 commits into
dotzero:masterfrom
kuyacarlo:feat/minify-config
Open

Change {Key: key, Value: xxx} to {key: xxx}#17
kuyacarlo wants to merge 5 commits into
dotzero:masterfrom
kuyacarlo:feat/minify-config

Conversation

@kuyacarlo

@kuyacarlo kuyacarlo commented Jun 26, 2026

Copy link
Copy Markdown

changed the config file to key:value instead of Key: value, Value: value

How about current installs?

Upon update, it would migrate from old configuration to new configuration in place.

Note: after this update, the config won't be backwards compatible.

Possible Fix

Put the new config into the config directly with XDG

@dotzero

dotzero commented Jun 30, 2026

Copy link
Copy Markdown
Owner

Thanks for the PR! I really like the direction of moving toward XDG support, but I have some concerns about the current implementation.

One of the goals of the current architecture is to allow complete isolation of any Git configuration, not just user identity settings.

For example, it’s currently possible to do something like:

git-profile add work core.autocrlf input

With the approach proposed in this PR, the tool becomes limited to just three settings: user.name, user.email, and user.signingkey.

I’d like to preserve the existing flexibility, since it allows users to isolate and manage arbitrary Git configuration values, not only identity-related ones.

- test: add testing for old and new config formats
- feat: sort by configuration keys when using `list` command
@kuyacarlo

Copy link
Copy Markdown
Author

Thanks for the PR! I really like the direction of moving toward XDG support, but I have some concerns about the current implementation.

Thanks, I was totally wondering on how to remove homedir entirely, since its deprecated and all. ATM, only root.go uses it. We can find another library, or just homebrew it such as below. Not sure if I should add it in this PR, however.

func ParseFilePath(fp string) (string, error) {
	if fp == "" {
		return "", fmt.Errorf("empty path")
	}

	// ~ to home
	if fp == "~" {
		return xdg.Home, nil
	}

	// ~/path to home/path
	if strings.HasPrefix(fp, "~/") {
		return filepath.Join(xdg.Home, fp[2:]), nil
	}

	// ~username unsupported, SSH config shouldn't need this probably
	if strings.HasPrefix(fp, "~") && fp[1] != '/' {
		return "", fmt.Errorf("unsupported: ~username expansion")
	}

	// clean it up
	return filepath.Clean(fp), nil
}

One of the goals of the current architecture is to allow complete isolation of any Git configuration, not just user identity settings.

For example, it’s currently possible to do something like:

git-profile add work core.autocrlf input

With the approach proposed in this PR, the tool becomes limited to just three settings: user.name, user.email, and user.signingkey.

I’d like to preserve the existing flexibility, since it allows users to isolate and manage arbitrary Git configuration values, not only identity-related ones.

This is absolutely my bad, I was very conflicted on whether I should use what's on the files themselves, or be flexible, along with my somewhat inexperience with go, of which I played safe. On that note, the new commits does allow for flexibility specified in your comment.

@kuyacarlo kuyacarlo changed the title Change {Key: user.xxx, Value: xxx} to {user.xxx: xxx} Change {Key: key, Value: xxx} to {key: xxx} Jun 30, 2026
CI failed on mismatched OldEntry/OldConfig doc comments; also apply
golangci wsl blank-line fixes so local act matches upstream lint.

Co-authored-by: Cursor <cursoragent@cursor.com>
@kuyacarlo

Copy link
Copy Markdown
Author

Fixed the CI lint failure.

The build job was failing on revive exported-comment checks in internal/oldconfig/oldconfig.go (OldEntry / OldConfig / New). Also applied the related wsl blank-line fixes so golangci-lint is clean.

Verified locally with go test ./..., golangci-lint run ./..., and act -j build.

@dotzero

dotzero commented Jul 27, 2026

Copy link
Copy Markdown
Owner

Could we avoid migrating ~/.gitprofile in place? As written, simply loading an existing config rewrites it in the new map format, which is a breaking change for current users and for any tooling that reads that file.

I’d suggest treating the new format as an XDG config: first try $XDG_CONFIG_HOME/git-profile/config.json (or the default XDG config directory). If it is absent, fall back to the existing ~/.gitprofile and keep parsing/saving it in its current array-based format.

This lets us introduce the new format and location without silently changing users’ existing configs. An explicit migration command could be added later if we want to move legacy configs to XDG.

Avoid in-place migration of existing configs. Prefer the XDG path for
the map format, and fall back to ~/.gitprofile in array format.

Co-authored-by: Cursor <cursoragent@cursor.com>
@kuyacarlo

Copy link
Copy Markdown
Author

Addressed the in-place migration concern.

Config resolution now prefers $XDG_CONFIG_HOME/git-profile/config.json (map format). If that file is absent, it falls back to ~/.gitprofile and keeps reading/writing the legacy array format. Existing ~/.gitprofile files are no longer rewritten on load.

New installs create the XDG path. An explicit migrate command can come later if we want to move legacy configs over.

Add an explicit `git-profile migrate` to copy ~/.gitprofile to the
XDG path in map format without rewriting the legacy file in place.

Co-authored-by: Cursor <cursoragent@cursor.com>
@kuyacarlo

Copy link
Copy Markdown
Author

Also added an explicit migrate command:

git-profile migrate

It copies ~/.gitprofile to $XDG_CONFIG_HOME/git-profile/config.json in the map format, leaves the legacy file in place, and refuses to overwrite an existing XDG config unless --force is passed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants