Creating consistent commands
christianbundy opened this issue · 11 comments
It's trivial, but personally, I've found myself typing homesick link abc/xyz
– and after thinking about it, it seems like we have an issue with consistency between commands.
I think that we should decided on whether the command should be symlink
or link
(I prefer the latter for brevity), and format both commands to adhere to that. Either:
homesick link abc/xyz
homesick unlink abc/xyz
or
homesick symlink abc/xyz
homesick unsymlink abc/xyz
But mixing and matching commands is confusing, and I don't think that it's the best way to go.
+1
I would prefer link/unlink too.
On Wed, Nov 27, 2013 at 8:08 PM, Christian Bundy
notifications@github.comwrote:
It's trivial, but personally, I've found myself typing homesick link
abc/xyz – and after thinking about it, it seems like we have an issue
with consistency between commands.I think that we should decided on whether the command should be symlinkor
link (I prefer the latter for posterity), and format both commands to
adhere to that. Either:homesick link abc/xyz
homesick unlink abc/xyzor
homesick symlink abc/xyz
homesick unsymlink abc/xyzBut mixing and matching commands is confusing, and I don't think that it's
the best way to go.—
Reply to this email directly or view it on GitHubhttps://github.com//issues/62
.
I agree. I think this could be a good project to figure how we can refactor
the code base to be easier to manage as well. I think with the single file
approach it's makes it easier to add duplicate code and makes it harder to
manage the test suite.
On Nov 27, 2013 11:08 AM, "Christian Bundy" notifications@github.com
wrote:
It's trivial, but personally, I've found myself typing homesick link
abc/xyz – and after thinking about it, it seems like we have an issue
with consistency between commands.I think that we should decided on whether the command should be symlinkor
link (I prefer the latter for posterity), and format both commands to
adhere to that. Either:homesick link abc/xyz
homesick unlink abc/xyzor
homesick symlink abc/xyz
homesick unsymlink abc/xyzBut mixing and matching commands is confusing, and I don't think that it's
the best way to go.—
Reply to this email directly or view it on GitHubhttps://github.com//issues/62
.
I completely agree. What else would we be looking to do if we were to refactor?
What I am hoping to see out of the refactor is the ability to put each group of command in its own class/file e.g. symlink/unsymlink and the ability to have a test file for just these commands. I think this is going to make it easier to add/edit commands and make it easier for us to add some test coverage so its a bit less scary to change things.
I was originally planning on working on some install/uninstall commands that would basically wrap the clone/symlink process
If we are going to brevity, could also think about ln
to mirror the symlink command. Not sure what the inverse would look like.
Maybe rm
? Removing a symlink is the same process as removing a file, so it would make sense to ln
and rm
. I think that ln
is great either way though.
Yeah, I think I can get behind ln and rm.
@trobrock Nice idea on the refactoring. I already started some more trivial refactoring on my fork's refactor
branch (mostly just rubocop fixes for now). I was planning on doing more serious refactoring, and I can help you out if you'd like. We could also create an issue for refactoring if you think that would help.
@thenickperson a new issue is probably the way to go.