Show HN: Git-pad: Git-native issue tracker(github.com)
github.com
Show HN: Git-pad: Git-native issue tracker
https://github.com/kwhkim/git-pad
If you want your issues free from vendor lock-in, editable offline, and simple to install and use, git-pad can help you.
3 comments
[deleted]
Just saw this — I posted a different take on the same problem the same day (git-native-issue, commits instead of files). Two independent projects converging on refs/issues/ is good signal.
The markdown files approach gives you grep/ag/rg search for free, which is a real advantage. And the repo-prefix + sequential ID scheme is definitely more memorable than UUIDs for daily use.
A couple of questions after reading the code:
- With a single refs/issues/latest branch for all issues, what happens when two contributors work offline on different issues and then push? Seems like it would produce a merge even though the issues are independent, does that cause friction in practice?
- On the ID scheme: gen_repo_id() generates 6 chars from a 22-letter alphabet. Two clones getting the same prefix is unlikely but not impossible. Have you considered what happens if it collides?
The markdown files approach gives you grep/ag/rg search for free, which is a real advantage. And the repo-prefix + sequential ID scheme is definitely more memorable than UUIDs for daily use.
A couple of questions after reading the code:
- With a single refs/issues/latest branch for all issues, what happens when two contributors work offline on different issues and then push? Seems like it would produce a merge even though the issues are independent, does that cause friction in practice?
- On the ID scheme: gen_repo_id() generates 6 chars from a 22-letter alphabet. Two clones getting the same prefix is unlikely but not impossible. Have you considered what happens if it collides?
Thank you for the seasoned opinion.
* It will produce a merge by default, but you can use `git pad merge --rebase` to rebase when possible. I thought a lot about this — "Do I need linear commits whenever possible?" I understand linear commits are easier to read, but I don't see other problems with merges per se. I think "who cares? No one will look at previous commits anyway." But there could be some friction — do you have anything specific in mind? Besides, you can use `git pad merge --rebase --audit` to tag the original commit before rebasing, for auditing purposes.
* It basically comes down to how many alphabets you need to guarantee no collision. Git's hashes have some probability of collision too. I don't recall the exact numbers, but for 100–1000 repos the chance of a repo-ID collision is extremely low. In the rare case of a collision, you can delete the `.local-repo-id` file and regenerate it. You would get merge conflicts though, so you'd need to reset to before the merge and rename the files. This is not implemented yet but people could do it manually using git commands and other linux commands.
* It will produce a merge by default, but you can use `git pad merge --rebase` to rebase when possible. I thought a lot about this — "Do I need linear commits whenever possible?" I understand linear commits are easier to read, but I don't see other problems with merges per se. I think "who cares? No one will look at previous commits anyway." But there could be some friction — do you have anything specific in mind? Besides, you can use `git pad merge --rebase --audit` to tag the original commit before rebasing, for auditing purposes.
* It basically comes down to how many alphabets you need to guarantee no collision. Git's hashes have some probability of collision too. I don't recall the exact numbers, but for 100–1000 repos the chance of a repo-ID collision is extremely low. In the rare case of a collision, you can delete the `.local-repo-id` file and regenerate it. You would get merge conflicts though, so you'd need to reset to before the merge and rename the files. This is not implemented yet but people could do it manually using git commands and other linux commands.