brechtm

Joined 13 years ago

Karma
197
Submissions
20
Member since
Nov 3
http://www.mos651.org
View on Hacker News

Recent submissions

Comment · 3 years ago
I started out with yadm but ended up symlinking its .git directory to ~/.git to be able to browse/stage/commit in Fork (https://fork.dev).

To make this manageable, I added this .gitignore:

  \*
  !.\*
  !.hammerspoon/\*/\*
  !.config/\*/\*
  !.ssh/config
  .DS_Store
  .bash_history
  .tig_history
  .lesshst
  .python_history
  .wget-hsts
  .zsh_history
  .CFUserTextEncoding
  .Xauthority
  /.config/mcd/.cache/
  /.config/mcd/.local/
  /.config/legendary/
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.

Comment · 7 years ago
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.

Comment · 10 years ago
Comment · 10 years ago
Doesn't seem to work on Safari (9.1.3 on macOS).
Comment · 10 years ago
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.

Comment · 11 years ago
ckemp1, as in Christian Kemp, creator of ANN.lu?

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.

Comment · 11 years ago
Comment · 11 years ago
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...
Comment · 12 years ago
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.

Comment · 12 years ago
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.

Comment · 12 years ago
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).

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton