Should the check command be removed?

[andsens]

The check command is a rather complicated piece of code and is not even complete without #46 (which would make it even more complex). Additionally it is slow, since it has to connect to the remote upstream to check for updates.

I do not use this command very much myself and was wondering whether a depreciation would be in order?

The two use scenarios as I can see it are:

1. Run check to see if there are any changes on the upstream remotes - which is a stupid scenario, because after that you would probably run pull anyways, so why not just run pull immediately?
2. You are wondering if there is anything you have not pushed upstream yet.

Scenario # 2 is very much an edge case and not enough of a feature to warrant an entire command.

[jrhorn424]

I'd be fine with this, as well as closing #46. I've been getting along fine without the feature.

[andsens]

During the last month I have been running with the new "check dirty working copy" feature and find it quite useful, if it weren't for the delay when checking the remote.
How about renaming check to status and let it only check whether the working copy is dirty?

Only problem I see is the naming clash with git status, but I myself find this rather useful, it's easier to remember. It would work as long as the majority of people don't expect homeshick status to do the same stuff as git status does.

Any comments?

[squaresurf]

I personally find it useful to have a single command. I think adding a --local-only flag or the likes is a bit more useful. I'm also a big fan of figuring out a system for #11. If we could solve #11 in a generic fashion it could be used across the board.

[andsens]

I personally find it useful to have a single command.

Fair enough, my frustration just stems from that it is sooo slow :-)

I think adding a --local-only flag or the likes is a bit more useful.

Huh, yeah. That could work. I also though that we could simply delay checking the remote after we have checked whether the working copy is dirty, that could save a little time in those cases. It's aquickfix, I know, but the change would still be a sound one.

[squaresurf]

Delaying does seem like a good first iteration. That change may need to update the tests though. I made sure that ahead and behind had priority over modified. We would just need to switch that since currently if a castle is (ahead or behind) and modified we show (ahead or behind).

[andsens]

We would just need to switch that since currently if a castle is (ahead or behind) and modified we show (ahead or behind).

Oh, right :-)
I actually think that giving precedence to modified would make more sense.

[squaresurf]

I actually think that giving precedence to modified would make more sense.

I agree.

[blech75]

@andsens, @squaresurf : i too desired a way to avoid the network hit when doing a check. see blech75/homeshick@9aee26a for something quick i whipped up.

lemme know what you think of the approach. it seemed reasonable enough, though i don't love the LOCAL_ONLY "flag". it would be nice to send an actual param into the check call, but i didn't have time to trace how subcommand-specific arguments work. maybe later.