I'm amazed at the number of projects that don't have even the simplest description as to what problem the software purports to solve. This well-intentioned project strikes me as among the more egregious examples.

The README contains almost zero information as to why the project was created, which problems it aims to rectify, and why you might want to use it. That this information may or may not be contained in an embedded video is of no relevance to someone (like myself) who has neither the time nor ability at this particular moment to watch anything on video that could have been more succinctly explained in 2-3 sentences. It won't be bookmarked or favorited for later perusal -- just ignored.

Please understand I mean this as constructively as possible: it's hard to create something and share it with the world, and for that your efforts are most highly commended. I suggest adding a general introduction/description and some use cases to both the project site and README file. That will go a long way toward garnering the attention of those who might otherwise simply shrug and walk away.

Thanks for the feedback. We should have done this a while ago. It's easy to forget that other people have no idea what we are building. Cheers.

https://github.com/freshshell/fresh/commit/4ebf599aa61b54b66... and https://github.com/freshshell/fresh/commit/000d7ce00b9029881...

If anyone is just looking for a way to manage and sync dotfiles without any of the sharing features (which are interesting but a little scary), you might want to check out my thing: https://bitbucket.org/davidn/dotstuff

Fresh handles local files too: https://github.com/twe4ked/dotfiles/blob/master/config/fresh...

Edit: https://github.com/freshshell/fresh#local-files

If you're looking for a mature alternative, there's homesick @ https://github.com/technicalpickles/homesick. I use it everywhere and it's great. Unfortunately, it does have a ruby dependency.

One of the big features of fresh is that it is able to merge configuration from multiple sources into a single output file. This applies to both shell (aliases) as well as configuration files.

For example, @twe4ked uses my tmux configuration but also has his own additions using the following:

    fresh jasoncodes/dotfiles tmux.conf --file
    fresh config/tmux.conf --file

Here's my `.freshrc` for examples of how you can use fresh. https://github.com/twe4ked/dotfiles/blob/master/config/fresh...

Looking forward to hearing what HN thinks of fresh. We've already got a bunch more features planned. http://github.com/freshshell/fresh/issues

You are asking someone to execute a shell script directly from the internet, which is questionable in the first place. And then you're making it much much worse by asking them to do it with a non-https link, meaning that someone can trivially execute a MITM attack.

Your webpage doesn't have any explanation other than a video. I can read a paragraph or two in a couple of seconds--I'm not going to take a minute and a half (and stop listening to the music I'm listening to) to watch a video. The GitHub README doesn't really have any information about what it is either.

I haven't actually tried this, because I have no idea what it is. The other comment in here linked to an example .freshrc file--I noted that every line that's not a comment starts with the string 'fresh ', which seems like an obvious annoyance. Even if you want it to just be a shell script you can execute, you could support a batch mode to do something like this, for example:

    fresh batch <<'BATCH'
    config/vimrc --file
    config/gemrc --file
    config/pryrc --file
    BATCH

Here's the install script (https://raw.github.com/freshshell/fresh/master/install.sh). You can have a read though if you like. I don't know any safer ways to install applications. SSL is a good idea though.

We will add some more info to the home page but we were trying to keep most of the info in the README.

> The GitHub README doesn't really have any information about what it is either.

What else would you like to know?

The batch mode is a good idea, however the way we're doing it is a tried and true method used by many dev tools Bundler, Vundle, etc.

Interesting, but I think I'll stick with my own system[1]. I organize by task, not repo or program. Also I try to do a minimum of symlinking, instead relying on convention and PATH manipulation.

Edit: I don't mean to discourage you, by the way. The more variety in dotfile management the better.

[1]: http://bugsplat.info/2012-08-11-task-oriented-dotfiles.html

Organising by task sounds very similar to our goals.

One of fresh's major features is being able to source a subset of another's dotfiles (at a per file level). For example, in my office we are all using fresh to source common git aliases.

This module/task idea is certainly interesting and is something we have been thinking about. Thanks for your feedback.

Whats to stop malicious git repos changing an alias after you have already added it to your freshrc? I think locking to a specific git ref needs to be top priority.

Absolutely. This is on the road map (https://github.com/freshshell/fresh/issues/11). At the moment running `fresh update` is the only way to update the source repos. I realise this isn't ideal, but we never update repos without you knowing.

Locking to a specific git reference (https://github.com/freshshell/fresh/issues/11) has been implemented. You can now use `--ref` to lock to a particular git reference. `fresh update` will grab the new version.

I like the idea of locking an entry to a git ref, I've created a ticket on the issue tracker: https://github.com/freshshell/fresh/issues/25.

Edit: woops it was already a ticket, closed mine.