Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make git command a config option #36

Open
sentientmonkey opened this issue Sep 10, 2018 · 3 comments
Open

Make git command a config option #36

sentientmonkey opened this issue Sep 10, 2018 · 3 comments

Comments

@sentientmonkey
Copy link
Contributor

I've been trying to get magit (for emacs) and fugitive (for vim) to work well with git-together. One of the problems for both is that if they are launched and don't rely on aliases, then even if you change the "git binary" for those apps, it can't find the original git binary when using pass through commands. git-together assumes that git is in the current $PATH, so that breaks down when plugins are not using the default user's shell to exec commands. See #31 and #22 for examples.

One approach to fixing that could be to make the git binary configurable from here:

Command::new("git")

If this is set in the git-together config, this also could allow forwarding to other git proxy commands (like hub). I don't know when I'll have time to work on this, but opening the issue up for discussion.

@sentientmonkey
Copy link
Contributor Author

Example config:

[git-together]
	git-command = /usr/local/bin/git

or

[git-together]
	git-command = hub

This could also default back to relying on the shell's PATH and 'git' as the default option for older installs.

@sentientmonkey
Copy link
Contributor Author

I've been spiking this in a branch: https://github.com/sentientmonkey/git-together/tree/configure-git-exec

It does proxy out to the command now, but both intellij and magit bomb out trying to commit. I think the next step is to debug and see how they are interacting with git commit

@sentientmonkey
Copy link
Contributor Author

I think based on #31 one approach could be parsing out all of the git flags before the subcommand and then preserving them to forward down into the git command execution.

$ man git
 git [--version] [--help] [-C <path>] [-c <name>=<value>]
           [--exec-path[=<path>]] [--html-path] [--man-path] [--info-path]
           [-p|--paginate|-P|--no-pager] [--no-replace-objects] [--bare]
           [--git-dir=<path>] [--work-tree=<path>] [--namespace=<name>]
           [--super-prefix=<path>]
           <command> [<args>]

If that was handled, then our subcommand would be easier to recognize and the commit would work properly.

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

No branches or pull requests

1 participant