HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
leighmcculloch
docker-unison
Shell2015–2016
leighmcculloch / docker-unison · Archived

docker-unison

A docker data container using Unison for fast folder sync. An alternative to slow boot2docker volumes on OS X.

Systems & InfrastructureDevOps & Cloud
Explore on GitHubRead Hacker News discussions
2Distinct people
2Mentions
0Explicit recommenders
168GitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

A docker data container using Unison for fast folder sync. An alternative to slow boot2docker volumes on OS X.

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 5:04:57 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by month2 dated mentions

Observed mentions: 2015-08-13 09:10:18 UTC to 2016-10-19 14:26:41 UTC.

012015-08-01 00:00:00 UTC to 2015-09-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 commentsAug 20152015-09-01 00:00:00 UTC to 2015-10-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2015-10-01 00:00:00 UTC to 2015-11-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2015-11-01 00:00:00 UTC to 2015-12-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2015-12-01 00:00:00 UTC to 2016-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2016-01-01 00:00:00 UTC to 2016-02-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2016-02-01 00:00:00 UTC to 2016-03-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2016-03-01 00:00:00 UTC to 2016-04-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 commentsMar 20162016-04-01 00:00:00 UTC to 2016-05-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2016-05-01 00:00:00 UTC to 2016-06-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2016-06-01 00:00:00 UTC to 2016-07-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2016-07-01 00:00:00 UTC to 2016-08-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2016-08-01 00:00:00 UTC to 2016-09-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2016-09-01 00:00:00 UTC to 2016-10-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2016-10-01 00:00:00 UTC to 2016-11-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 commentsOct 2016

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
Aug 20152015-08-01 00:00:00 UTC2015-09-01 00:00:00 UTC101
Sep 20152015-09-01 00:00:00 UTC2015-10-01 00:00:00 UTC000
Oct 20152015-10-01 00:00:00 UTC2015-11-01 00:00:00 UTC000
Nov 20152015-11-01 00:00:00 UTC2015-12-01 00:00:00 UTC000
Dec 20152015-12-01 00:00:00 UTC2016-01-01 00:00:00 UTC000
Jan 20162016-01-01 00:00:00 UTC2016-02-01 00:00:00 UTC000
Feb 20162016-02-01 00:00:00 UTC2016-03-01 00:00:00 UTC000
Mar 20162016-03-01 00:00:00 UTC2016-04-01 00:00:00 UTC000
Apr 20162016-04-01 00:00:00 UTC2016-05-01 00:00:00 UTC000
May 20162016-05-01 00:00:00 UTC2016-06-01 00:00:00 UTC000
Jun 20162016-06-01 00:00:00 UTC2016-07-01 00:00:00 UTC000
Jul 20162016-07-01 00:00:00 UTC2016-08-01 00:00:00 UTC000
Aug 20162016-08-01 00:00:00 UTC2016-09-01 00:00:00 UTC000
Sep 20162016-09-01 00:00:00 UTC2016-10-01 00:00:00 UTC000
Oct 20162016-10-01 00:00:00 UTC2016-11-01 00:00:00 UTC101

What Hacker News says

2 sources
sytse·Oct 19, 2016
At GitLab we're exploring an idea that may turn the tide. I agree that online editors don't seem the way forward. The problems are: - People have wildly different preferences (TextMate, Sublime, Atom, VScode, vim, emacs, etc.) - It is really hard to get an online IDE right. The most advanced version is probably Eclipse Che and they have an API to do autosuggest by looking in all the files. Also see https://gitlab.com/gitlab-org/gitlab-ce/issues/22863 "It ought to be enough if one can trigger opening a buffer in a local editor, which accesses a local webserver provided by your browser, backed by the textarea, and having a means of updating the textarea on save via a POST issued from, say, Emacs to Firefox's textarea-httpd." I think the better approach is to sync the entire directory so you can do global search and replace and autosuggest.
Read the rest
My idea of how to make the IDE sync work: 1. You click on an icon in GitLab, it is next to where we now show the url for the terminal. 2. The icon opens a url, with a schema specific for our solution (although we should open source the protocol so others can reuse it). In the url is the following information: server and project location, pod and container to connect to, a token to identify the user. 3. Beforehand the user has installed a local client that is registered to handle this type of schema. 4. The filesystem of the container is synched to the users machine by the local client (I propose to a default directory system specific to the local client). 5. The local client also opens up the favorite editor of the user (make this configurable with smart default by seeing what editors are installed via which). 6. The local editor talks to an endpoint of GitLab, similar to how our terminal works. 7. GitLab uses kubernetes/docker exec to run unison and fswatch on the container (this is a different approach that the volume approach suggested in https://github.com/leighmcculloch/docker-unison#docker ). 8. GitLab makes a reference implementation of this for MacOS, using unison and fswatch. The community will hopefully make Linux and Windows clients. What do people think? Also see https://gitlab.com/gitlab-org/gitlab-ce/issues/22876
In Introducing Google Cloud Shell’s new code editor
elvis635·Aug 13, 2015
Docker under OSX is a real pain to solve ASAP. I've set Docker on my Linux machine and it's working like a charm. Then I had to do the same for my coworkers running OSX, the vbox shared folders are definitely unusable. Now it's been few days that I'm trying to find the best way to have a two-way sync in order to sync back changes from docker to the OSX folder (eg. when you upload a file and it's saved in the /public folder, otherwise it'll be lost) So far I've used docker-osx-dev[0] for 1 way sync (with rsync) and it's working nicely.. they also plan to add the support to unison for a 2way sync I've also found docker-unison[1] but I haven't found a way to have it working correctly I'd like to try with boot2docker-xhyve, but it only runs on Yosemite and later [0] https://github.com/brikis98/docker-osx-dev [1] https://github.com/leighmccull
Read the rest
och/docker-unison
In Announcing Docker ToolBox

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.