This makes use of the fact that .gitignore patterns are evaluated in order. It basically makes git only care about dotfiles in the home directory, files under .config, .ssh and .hammerspoon. Specific files/dirs that match that filter can still be ignored (e.g. .bash_history).
This is very straightforward and works quite well, so I don't see the need for yadm anymore. The one issue I have with it, is that in the terminal I'm always in a git context (shown in the shell prompt) in any directory under $HOME.
This sounds pretty much what I described in http://www.mos6581.org/git_subtree_alternative. This solution splits your changes between different branches at the time of commit, instead of afterwards like git-subtree does.
While I do present a proof-of-concept implementation using hooks, a proper implementation would require some changes to the git client, I imagine.
I'm working on a DITA (to PDF) renderer [1] based on rinohtype [2]. About a year ago I was in a startup coaching project. I was advised to put out an MVP ASAP. Since then, I've worked full-time on the project and only now I'm releasing what I believe is an MVP. One year ago, my product was functional, but it didn't allow easily styling the output PDF. I believe this is the feature that differentiates it with the competition. I feel that, without this feature in place, my product wouldn't offer anything interesing.
I could have also released an "MVP" much earlier, but say it couldn't render tables. Who would've taken it seriously then? Even if I added this feature at a later point, how many of the people that tried the first version would bother checking it out again?
For some (new) markets, I'm sure you could crank out an MVP in a month. But for existing markets, there's the established competition that sets the bar, no?
no doubt, you raise an excellent point--mvp is somewhat vague, hard to quantify, and there's no universal answer so unfortunately the answer is it depends on the idea/product/lifecycle. chances are if you're still trying to get a feel for a market, this could be an entirely new market, one that doesn't quite exist, or an existing one with incumbents, like airbnb as an example, an mvp could be like a simple mobile app with login (not even oauth based for facebook/twitter/google), listings, a way to book, and bill. don't implement user feedback on listings where they've stayed, don't implement icons for users, forgotten password is an email to support, etc, i'm sure you could find a million things that are needed, but what are the essentials for getting people to use your app satisfying some specific needs (crashing at a complete stranger's place). each feature doesn't really need all the bells and whistles, enough to get people to start using the basics. your assumptions and hypotheses about how the market would leverage this tool could be entirely off, so you might need to change direction (pivot more or less) and you'd need to get to this conclusion asap, sooner rather than later, etc. if you spent a year coding something you think would be perfect for a market you are defining or discovering, this could be a large waste of time, so fail fast as they say.
in your case, you seem to be quite clear about what you need, what the competitors have and don't have. but let me play devil's advocate because i don't know how much effort "[rendering] tables" would take or how much you've put in the past year, but let's just say you could put something out there in 6 months time as opposed to 12 months time, it probably will have some table rendering, not 100%, but do you think that would be advantageous or not?
thanks for the footnotes, much appreciated and good luck with your app!
Found and fixed the bug, should be working now. (For what it's worth, I was using fat arrow functions in javascript, which aren't supported in all browsers yet. Forgot to compile it down to ES2015.)
I've also been thinking a lot about sustainable open source software, mostly with respect to my own project, rinohtype.
I hate ads and block them whenever possible, and I believe most people hate them as well. I also have this feeling that the concept of advertising somehow doesn't rhyme with open source. It just doesn't feel right. Open source is about freedom and advertising is about being in-your-face. I don't know how to word this in a better way.
People turn to ads because it seems to be the only way to make some money from their work. There must be a better way! But how? The best I can come up with is some sort of automated royalty payment system. Commercial users of the software need to pay a license fee, which is divided among the contributors relative to their contributions. This last part is the hard part. I don't think lines of code is a good measure of the value of a contribution.
RinohType [1] combines a CSS-inspired style sheet system [2] with a powerful layout system based on boxes ("containers"). It currently only outputs to PDF but an SVG backend could be added without too much work...
I wonder how many Amiga users are left by now. I remember the heated discussions (on ANN) about whether Amiga should remain on the PPC track or go x86 (remember Amithlon?). Didn't stick around long enough, but it must've been a shock when Apple announced they were dropping PowerPC in favor of x86. Ah well...
In hindsight, by the time all those discussions happened on ANN, the platform (as a meaningful alternative to Apple or Windows) was dead anyway. A lot of energy was wasted on the comments section of ANN in those days that could have been spent on more productive endeavors.
I know I wasted too much time participating in flame wars on ANN in those days. In hindsight, I wish I had abandoned the Amiga much sooner and walk away with with mostly good memories.
That's me. (As in, creator of ANN and also someone who should have walked away sooner - although I did switch to Windows quite a few years before closing ANN).
Even by the last days of commodore the platform was already dead, dying, or at best on life support.
The Video Toaster may have extended the Amiga's usefulness by a few more years, but for most users by the early 90s a spiffed out 386 or 486 PC clone with vga and a sound blaster offered comparable performance & features to the AGA Amigas.
It was an amazing machine vastly superior to its competitors from 85 till the early 90s though.
I can certainly agree with that, I invested far too much time and money in the Amiga long after it was relevant. But I still have a fondness for the machine, it was elegant in a way that just isn't necessary anymore, time and moores law stands still for no man
I don't quite understand this one. "Now you’ll have to create a new commit...". At this point, you haven't yet created a top-level project commit at all.
That sentence intends to illustrate what can happen when you forget to push your submodule commit before commiting on the top-level repository.
Why was submodule better than just using a single repo and multiple remotes in this case?
I'm not sure what you mean with this.
Or put another way, what did you gain by having separate repos if all the repos branch and come back in exactly the same way.
We used submodules because the code in the submodules was shared with another team.
You want to also branch the submodules so as not to break another branch.
Interesting. This will indeed result in a more linear history, but I don't agree that the commits from the external repo should be absorbed into the main project's history, just as the subtree changes should not be present in new commits made in the main project (hence git-subrepo). So, no, git-subhistory is not exactly what I want :)
However, git-subhistory will produce a history better suited for consumption by gitk (and other tools, I assume). I would like to argue though, that these tools should be aware of subrepos instead.
git-subtree duplicates history. First you make a regular commit containing both your main project's changes and the subtree changes. Afterwards the subtree change is merged in again (or "subtree split --rejoin" or "subtree merge").
The advantage of git-subrepo is that your changes are immediately split up between the main project and the subrepo. Eventually, you should also be able to supply a separate commit message for the subrepo change (see "random ideas" section in the article).
To make this manageable, I added this .gitignore:
This makes use of the fact that .gitignore patterns are evaluated in order. It basically makes git only care about dotfiles in the home directory, files under .config, .ssh and .hammerspoon. Specific files/dirs that match that filter can still be ignored (e.g. .bash_history).This is very straightforward and works quite well, so I don't see the need for yadm anymore. The one issue I have with it, is that in the terminal I'm always in a git context (shown in the shell prompt) in any directory under $HOME.