Hi,
Solar wrote:
You see, there exists documentation and online help for Git and Subversion. There wouldn't for whatever you would cook up. Even if it were good, it would still mean that anybody who wants so much as check out your OS sources would have to go through your VCS... which, if your OS is going to be so radically different that porting isn't straightforward, means a hen-and-egg problem, as YourVCS-clients will probably not be available for other operating systems than YourOS.
I can write the documentation, sure. Online help would be a problem though, and this is probably the first point in this thread that we agree on. As for people checking out my OS sources, I'll have a client and a server written in C targeting UNIX-like OSes; in fact the initial ones are going to be such. Besides, I'd need them myself while developing the initial custom programming language compiler (also written in C targeting UNIX-like OSes) and also while developing the OS, until I develop a "native" compiler and the OS actually becomes self-hosting.
Quote:
Or simply eschew self-hosting capabilities for now. That will allow you to do thinks very specific to YourOS, while still enjoying a fully grown toolchain on the host OS.
But being self-hosting is part of the fun! Sure it's impractical because I'd need to develop a toolchain that will run on both Linux and my OS (two different versions), but it makes the OS more impressive when accomplished.
nullplan wrote:
Regarding your technical points, I would heavily object to your branches-are-subdirs approach. That just leads to heavy duplication of files without no real benefit. What do you mean by "everybody lost uncommitted changes"? If you really want this, you can already have such a layout with "git worktree".
I think this is a valid objection and, now that I think of it, I tend to agree. Indeed, when having 100 branches, it's too much. Concerning losing uncommitted changes, I think I had it happen to me in another case, but not when checking out another branch (sorry, I misremembered it
).
Quote:
Honestly, the only thing I would change about Git is the command naming and default parameters. git pull --rebase should be the default. merge should never do a fast-forward, there should be an explicit command to do that. I feel that git reset and git reset --hard could have better names (maybe point-at instead of reset and --checkout instead of --hard). Same for git revert. The interfaces to some commands such as git stash could be much better.
I agree; some of git's defaults are bad. Command naming is a minor usability issue too. As for git stash, I don't remember I've ever used it (probably that's why I lost those changes anyway); I think task switching in git should be easier anyway.
Regards,
glauxosdever