brechtm | 3 years ago | on: Dotfiles Management
brechtm's comments
brechtm | 7 years ago | on: We need a new generation of source control
While I do present a proof-of-concept implementation using hooks, a proper implementation would require some changes to the git client, I imagine.
brechtm | 9 years ago | on: How to Ship Side Projects
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?
[1] http://www.opqode.com/rinoh [2] http://www.mos6581.org/rinohtype/
brechtm | 9 years ago | on: How to Ship Side Projects
brechtm | 9 years ago | on: Funding Open Source with Marketing Money
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.
brechtm | 10 years ago | on: Call for Amiga Developers: Kickstarting PowerPC and 68k software development [pdf]
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.
brechtm | 10 years ago | on: Incomplete List of Mistakes in the Design of CSS
[1] http://www.opqode.com [2] http://www.mos6581.org/rinohtype_status_update_1
(I'm RinohType's author)
brechtm | 10 years ago | on: Call for Amiga Developers: Kickstarting PowerPC and 68k software development [pdf]
brechtm | 12 years ago | on: Exploring an alternative to git-subtree
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.
brechtm | 12 years ago | on: Exploring an alternative to git-subtree
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.
brechtm | 12 years ago | on: Exploring an alternative to git-subtree
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).
brechtm | 12 years ago | on: Show HN: RinohType – A modern LaTeX in 6500 lines of Python
brechtm | 12 years ago | on: Show HN: RinohType – A modern LaTeX in 6500 lines of Python
But I'm sure there's still a bug in my PDF font handing code :)
brechtm | 12 years ago | on: Show HN: RinohType – A modern LaTeX in 6500 lines of Python
The table rendering got messed up when I rewrote the line spacing code. Fixing the table rendering would just require an adjustment of the table style definition.
brechtm | 12 years ago | on: Show HN: RinohType – A modern LaTeX in 6500 lines of Python
RinohType should eventually be able to replace LaTeX though, so it is not that far-fetched either. Also, the first paragraph of the article should help temper that excitement.
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.