Can has untrack command

[kastermester]

Pretty please!

[andsens]

Hm, this is actually a bit tricky. How do you on a machine different from where the untrack command was issued know whether the file was deleted or simply untracked?
This would also affect the implementation strategy for #28.

[ghost]

+1.

[darkfeline]

I can see two ways this would work: either the file is removed from the castle locally and put back into its location in home, and on other machines the same thing happens there, or the file is removed from the castle locally and put back into its location in home, and on other machines we simply remove the symlink and don't create a local copy.

Either way, there'll need to be tracking info in homes(h)ick. How about doing it like this? On each machine, in each castle keep a log of what files were untracked and when the castles were last updated, then sync it a la diff or changeset.

[ghost]

Could an easier option be to ask user what to do? You do an update and if file is removed, you ask user if he wants to keep the local copy or not.

[andsens]

@darkfeline

On each machine, in each castle keep a log of what files were untracked and when the castles were last updated, then sync it a la diff or changeset.

I think we need to keep it simple here. To me keeping a logfile would be a big increase in complexity and the first case where there would be any need to configure/log stuff. So far, homeshick has gotten by perfectly well without that.

@edvinasme

Could an easier option be to ask user what to do? You do an update and if file is removed, you ask user if he wants to keep the local copy or not.

It would become quite cumbersome to go through those prompts on every single machine you update. Again, the mandate is simplicity, so prompts should really only be added if absolutely necessary.

@darkfeline

the file is removed from the castle locally and put back into its location in home, and on other machines the same thing happens there

THAT I think is the proper solution. Just move the file back to the symlink location and remove it from the castle. The same should happen on other machines, exactly like you suggest. It's the simplest solution and it would probably be what the user would expect.
The complicated way to go about this on other machines would be to

• git fetch
• figure out which files were deleted (diff to origin with filter=D)
• check out the latest versions of these files and copy them to the symlink locations
• git merge FETCH_HEAD

Disadvantages of that approach:

• checking out latest versions of files before they were deleted is a potential snafu that can bring with it a whole bunch of bugs
• You wouldn't expect homeshick to actually update the files before untracking them on remote machines. It may be a bonus in some cases, but I'd just find it confusing.

The simple way

• git fetch
• figure out which files were deleted (diff to origin with filter=D)
• copy those files from the current working copy to the symlink location (almost like homeshick untrack but without deleting the file in the repo)
• git merge FETCH_HEAD

Advantages

• code reuse with homeshick untrack
• it doesn't touch the working copy

[darkfeline]

@andsens +1 Sounds good. What makes sense "git-wise" is to check out the lastest version before copying it out, but as a user copying out as-is is more intuitive. Though I can imagine times where I would feel the former is more intuitive than the latter... Perhaps that should be an option?

[binarykitchen]

Any news? I'd still very welcome an untrack command

[binarykitchen]

Ping?

[binarykitchen]

@andsens @darkfeline @kastermester @sorccu Hello folks, it's been a while

Tell me, is this repository still maintained?

It's great and has potential. It would be sad to see it dying. Or did you find something better?

[andsens]

@binarykitchen Still maintained. I fix bugs and stuff. Implementing new features though is just something that I take my sweet time doing. I have a plan for how to do this, but it might be a while.

Beyond this I am thinking of reimplementing the homeshick argument parsing with docopt.sh once I find the time.

The reason I'm not super active is because I consider most of homeshick "done" tbh. It works and does its job, so there's no reason to fiddle a lot with it.

I use homeshick everyday on loads of machines...

[binarykitchen]

@andsens Wow, thanks.

Where to start? I've already sorted the problem mentioned in this thread myself with manual git commands. The reason I posted recently is because, I'm like you, use homeshick every day, and it's wonderful, yet it has been quiet for a while.

And this makes me a bit nervous when it comes to sensitive dotfiles. Imagine the .ssh folder. I'm the type to ditch code / packages which haven't been maintained nor updated for a while.

Yes, if it's "done", no need to fiddle but maybe show at least it's still maintained and being cared of. Just saying. It's like removing npm packages older than 2 years from your project and finding replacements without honouring the original inventor :(

[andsens]

All totally valid concerns. I should probably add a disclaimer to the readme stating something like I explained above.
Regarding security concerns, I think you're OK. homeshick itself doesn't really implement any security related stuff but relies on other tooling to do that for it, meaning if you keep those tools (git, bash) up-to-date you should be fine.

I've also really held back on implementing more features because right now homeshick is super easily auditable. You can jump in and with a cursory glance determine that everything is likely to be fine. If you look at the issue list you can also see that they are all enhancements.

Another feature I have been kind of missing though is conditional linking and some kind of file templating/combining. Those are both pretty big things though. So I have kind of worked around it, and not needed it that much.