[kwhkim]

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.