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

Wrap all git commands automatically #85

Closed
nickserv opened this issue Jan 17, 2014 · 7 comments
Closed

Wrap all git commands automatically #85

nickserv opened this issue Jan 17, 2014 · 7 comments

Comments

@nickserv
Copy link
Collaborator

Homesick currently provides a command for every git command that can be executed through it manually. While this offers a convenient interface for some git commands, it means that we would have to add more homesick commands every time we wanted to use a git command that isn't provided. Instead, we could take the approach that tools like hub use and automatically provide all of git's interface by wrapping all of it with dynamic system calls. Homesick could intercept some git commands before shelling out to provide syntax sugar, and support the rest by only shelling out for compatibility.

Example

Advantages:

  • Makes git-related homesick commands a lot easier to manage, since it would make homesick more modular.
  • Adapts to changes in git's interface more easily.
  • If we offer all git functionality, it would be less confusing for new users to figure out how to use git commands through homesick.
  • In the end, this will probably make the code a bit lighter and more manageable, since we are currently wrapping a lot of git commands manually.

Disadvantages:

  • Because homesick is not strictly a git wrapper, some homesick commands may conflict with git commands (especially the help command). We could always fix this by adding a prefix command like homesick git, though.
  • We might need to do special things in terms of dynamically wrapping commands, especially for situations like clone where we would have to intercept where the repository is placed. Maybe we could still offer our own wrappers for commands like this, separate from out git interface.
  • This would most likely lead to breaking changes.
  • This would require us to shell out any automatically-provided git functionality to git itself, and would prevent us from using a git library for this part of homesick. However, we could always use a library elsewhere, and in my opinion switching to a git library is looking like it will be too difficult to be worth it anyway (see Use file/git libraries instead of always shelling out #74).
@technicalpickles
Copy link
Owner

This has been discussed before, see #69 for some background. I'd rather see something like homesick cd some-castle && git status, rather than have to wrap commands. Basically, let homesick manage the repositories being on disk, and symlinking it, and have it be easy to get into those directories to manipulate with git directly.

@nickserv
Copy link
Collaborator Author

I like that idea. I think this would help homesick follow the "do one thing well" principle better. However, I think some sort of homesick exec command would be useful for running a single command in a castle.

Examples:
homesick exec pwd
homesick exec git status

I'm starting to realize, though, that we may run into issues when specifying a castle for the homesick exec or homesick git command. Because wrapper commands could take any number of arguments, it would make more sense to specify things like the castle to use before exec or git. I think that to fix this ambiguity, and to try to improve the consistency of homesick commands in general, it may make sense to use a -c/--castle flag instead of hard-coding the position of the castle name into the command usage. What do you think? It's something that most commands need you to specify anyway, so I think it would be helpful for consistency, even if it involves more typing.

@JCook21
Copy link
Collaborator

JCook21 commented Apr 4, 2014

@nicolasmccurdy FWIW I was working on an exec command independently and have an implementation that's almost ready (without tests). If you like I could push it to my fork and perhaps we can work on this together.

@nickserv
Copy link
Collaborator Author

nickserv commented Apr 4, 2014

@JCook21 Sounds good, let me know and I can take a look at your implementation. By the way, how are you handling the UI for castle names at this point? (see my comment above)

@JCook21
Copy link
Collaborator

JCook21 commented Apr 4, 2014

@nicolasmccurdy have a look at https://github.com/JCook21/homesick/tree/exec. Let me know what you think. :)

@nickserv
Copy link
Collaborator Author

nickserv commented Apr 4, 2014

@JCook21 That looks pretty good so far. I've commented on one of your commits, since I'd rather move discussion on the exec command somewhere else. Feel free if you want to make an issue and/or pull request for it.

@JCook21
Copy link
Collaborator

JCook21 commented Jan 1, 2017

Closing this due to lack of discussion in almost 2 years.

@JCook21 JCook21 closed this as completed Jan 1, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants