design/assistantgit-annexhttp://git-annex.branchable.com/design/assistant/git-annexikiwiki2013-11-27T22:47:37Zcomment 1http://git-annex.branchable.com/design/assistant/comment_1_a48fcfbf97f0a373ea375cd8f07f0fc8/Jimmy2013-11-27T22:47:37Z2012-06-02T12:06:37Z
Will statically linked binaries be provided for say Linux, OSX and *BSD? I think having some statically linked binaries will certainly help and appeal to a lot of users.
comment 2http://git-annex.branchable.com/design/assistant/comment_2_6d3552414fdcc2ed3244567e6c67989d/joeyh.name2013-11-27T22:47:37Z2012-06-04T19:45:00Z
Jimmy, I hope to make it as easy as possible to install. I've been focusing on getting it directly into popular Linux distributions, rather than shipping my own binary. The OSX binary is static, and while I lack a OSX machine, I would like to get it easier to distribute to OSX users.
comment 3http://git-annex.branchable.com/design/assistant/comment_3_05223be50c889b2ed6bc4abf74116450/Jimmy2013-11-27T22:47:37Z2012-06-07T20:22:55Z
I'd agree getting it into the main distros is the way to go, if you need OSX binaries, I could volunteer to setup an autobuilder to generate binaries for OSX users, however it would rely on users to have macports with the correct ports installed to use it (things like coreutils etc...)
comment 4http://git-annex.branchable.com/design/assistant/comment_4_fbbd93b55803ae21e6ba4b6568c2fafd/joeyh.name2013-11-27T22:47:37Z2012-06-08T01:56:52Z
<p>I always appreciate your OSX work Jimmy...</p>
<p>Could it be put into macports?</p>
comment 5http://git-annex.branchable.com/design/assistant/comment_5_f4e9af3fed6c27e8ff39badb9794064d/Jimmy2013-11-27T22:47:37Z2012-06-08T07:22:34Z
<p>In relation to macports, I often found that haskell in macports are often behind other distros, and I'm not willing to put much effort into maintaining or updating those ports. I found that to build git-annex, installing macports manually and then installing haskell-platform from the upstream to be the best way to get the most up to date dependancies for git-annex.</p>
<p>fyi in macports ghc is at version 6.10.4 and haskell platform is at version 2009.2, so there are a significant number of ports to update.</p>
<p>I was thinking about this a bit more and I reckon it might be easier to try and build a self contained .pkg package and have all the needed binaries in a .app styled package, that would work well when the webapp comes along. I will take a look at it in a week or two (currently moving house so I dont have much time)</p>
comment 6http://git-annex.branchable.com/design/assistant/comment_6_c7ad07cade1f44f9a8b61f92225bb9c5/Jimmy2013-11-27T22:47:37Z2012-06-08T15:21:18Z
<p>It's not much for now... but see <a href="http://www.sgenomics.org/~jtang/gitbuilder-git-annex-x00-x86_64-apple-darwin10.8.0/">http://www.sgenomics.org/~jtang/gitbuilder-git-annex-x00-x86_64-apple-darwin10.8.0/</a> I'm ignoring the debian-stable and pristine-tar branches for now, as I am just building and testing on osx 10.7.</p>
<p>Hope the autobuilder will help you develop the OSX side of things without having direct access to an osx machine! I will try and get gitbuilder to spit out appropriately named tarballs of the compiled binaries in a few days when I have more time.</p>
comment 7http://git-annex.branchable.com/design/assistant/comment_7_609d38e993267195a80fecd84c93d1e2/joeyh.name2013-11-27T22:47:37Z2012-06-09T18:07:51Z
Thanks, that's already been useful to me. You might as well skip the debian-specific "bpo" tags too.
macportshttp://git-annex.branchable.com/design/assistant/comment_9_d052e2142da8b4838fb1edf791ea23ae/Wichert2013-11-27T22:47:37Z2012-06-12T13:00:34Z
<p>The average OSX user has a) no idea what macports is, and b) will not be able to install it. Anything that requires a user to do anything with a commandline (or really anything other than using a GUI installer) is effectively a dealbreaker. For our use cases OSX is definitely a requirement, but it must only use standard OSX installation methods in order to be usable. Being in the appstore would be ideal, but standard dmg/pkg installers are still common enough that they are also acceptable.</p>
<p>FWIW this is the same reason many git GUIs were not usable for our OSX users: they required separate installation of the git commandline tools.</p>
Watch also possible with git?http://git-annex.branchable.com/design/assistant/comment_10_f2233fad55c20686cf299bf6788f1f23/klomp.eu2013-11-27T22:47:37Z2012-06-15T17:25:30Z
<p>Hi,</p>
<p>it seems that you put a lot of efforts in handling race conditions. Thats great. I wonder if the watch can also be used with git (i.e. changes are commited into git and not as annex)? I know that other projects follow this idea but why using different tools if the git-annex assistant could handle both...</p>
Homebrew instead of MacPortshttp://git-annex.branchable.com/design/assistant/comment_8_22b818e1a2a825efb78139271a14f944/Matt2013-11-27T22:47:37Z2012-06-22T04:26:02Z
<p><a href="http://mxcl.github.com/homebrew/">Homebrew</a> is a much better package manager than MacPorts IMO.</p>
comment 11http://git-annex.branchable.com/design/assistant/comment_11_a38f0f21c2346e65b786d791b6829f9b/Shayne2013-11-27T22:47:37Z2012-08-13T00:37:35Z
<p>Yeah definately go with homebrew rather than macports if possible. macports and fink, whilst great systems, have a tendency to sort of create their own alternative-dimension of files within the system that just dont always feel particularly well integrated. As a result "brew" has become increasingly more popular to the point its almost ubuquitous now.</p>
<p>Plus its brew-doctor thing is awesome.</p>
<p>The best approach though thats agnostic to distro systems is to simply go for a generic installer.</p>
Multiple annexes?http://git-annex.branchable.com/design/assistant/comment_12_5e991177d6577384f39a36ae02f5f574/Jörn2013-11-27T22:47:37Z2012-09-20T16:10:29Z
<p>Thank you for this great piece of software which is now becoming even better with the assistant.</p>
<p>Just one question: will one instance of the assistant be able to track multiple git annex repositories each building up their own network of annexes OR would I need to run multiple instances of the assistant?</p>
<p>Thanks,
Jörn</p>
comment 13http://git-annex.branchable.com/design/assistant/comment_13_f8625c6f43b58847840df338a73b7972/joeyh.name2013-11-27T22:47:37Z2012-09-20T16:21:11Z
@Jörn, two days ago I added support in the webapp for multiple independent repositories. So you can create independent repos using it, and switch between them from a menu. Under the hood there are multiple git-annex assistant daemons running, but this is an implementation detail; it's not like these use any more memory or other resources than would a single daemon that managed multiple repositories.
you rock! & roadmap update?http://git-annex.branchable.com/design/assistant/comment_14_c37ef5931b0f5c1f808083e0d636a208/anarcat [id.koumbit.net]2013-11-27T22:47:37Z2012-09-21T04:25:58Z
<p>joey, you rock. I just want to push on that point - it doesn't seem like there's that many tools that do what git-annex is trying to do out there, and you seem to be doing an incredible job at doing it, so this is great, keep going!</p>
<p>i was wondering - i am glad to see the progress, but it is unclear to me where you actually are in the roadmap. are things going according to plan? are we at month 3? 4? or 1-4? <img src="http://git-annex.branchable.com/smileys/smile.png" alt=":)" /> just little updates on that roadmap section above would be quite useful!</p>
<p>thanks again!</p>
comment 15http://git-annex.branchable.com/design/assistant/comment_15_68c98a27083567f20c2e6bc2a760991b/joeyh.name2013-11-27T22:47:37Z2012-09-21T05:25:53Z
<p>We're on month 4 of work, and most of months 1-3 is done well enough for a first pass. Very little of what's listed in month 4 has happened yet, due to my being maybe 2 weeks behind schedule, but bits of <a href="http://git-annex.branchable.com/design/assistant/cloud/">cloud</a> are being planned.</p>
<p>I've made a small adjustment, I think it'll make sense to spend a month on user-driven features before getting into Android.</p>
Maybe a DEB?2http://git-annex.branchable.com/design/assistant/comment_16_8e6788c817c60371d2a2f158e1a65f87/gdr-go22013-11-27T22:47:37Z2012-09-27T09:44:14Z
Month 3 was all about easy setup, so I kind of expected to download a deb package and just install it, not to download a whole bunch of haskell libraries. Is there a chance that you will release some packages?
comment 17http://git-annex.branchable.com/design/assistant/comment_17_97bdfacac5ac492281c9454ee4c0228e/joeyh.name2013-11-27T22:47:37Z2012-09-27T18:44:11Z
@gdr A package with the assistant is available in Debian unstable.
for OSX, package managers (homebrew and macports) are really second-classhttp://git-annex.branchable.com/design/assistant/comment_18_53137b2df4913496c0afb2d895aa4ee2/Georg2013-11-27T22:47:37Z2013-07-24T07:24:49Z
at least with regards to wide spread use. I agree with Wichert, the average OSX user won't use them. I myself would go with homebrew (because it is far less of a pain than macports), but actually static built binaries that are just dragged from a DMG to your programs folder is the way to go if you can't go osx app store. It's just how most Apple users are wired. PKG would be fine, too, since most will know them, but those are really only needed if you need to place stuff in /Library/Frameworks or things like that. If it can be done as a all-inclusive OSX .app, do it that way and just pack it up in a .DMG.
windows porthttp://git-annex.branchable.com/design/assistant/comment_19_ff1b0ba57e22ed757ec3fc5400b5e43e/András2013-11-27T22:47:37Z2013-07-25T07:50:19Z
I'd love to use the Windows port of the assistant by Christmas. Keep up the good work! <img src="http://git-annex.branchable.com/smileys/smile.png" alt=":)" />
comment 20http://git-annex.branchable.com/design/assistant/comment_20_099da245e3276fa84f5e14312d186621/joeyh.name2013-11-27T22:47:37Z2013-07-25T18:22:51Z
@Georg, DMG have been built for OSX for a long time. See <a href="http://git-annex.branchable.com/install/OSX/">OSX</a>