> Sorry, I forgot all about hash-objects X-<. It was a convenient > way to try out new things such as 'gitlink'. Thanks for the > clarification. > > As to unification, I am not sure if there are a lot to unify. > Everybody starts with type, length and a LF, but after that each > type has its own format constraints. A grand unified command > that knows about format constraints of every type under the sun > does not sound like a good approach. While we have only handful > types (and I expect things will stay that way) it is not a big > deal either way, though. > Oops, sorry, I forgot that "modular" in C means something else than in the OO-World... You are right. Probably it is best to have one tool handle each type. Actually what I am aiming for is not the internal structure. I am more concerned about cleaning up the user-interface. When I started learning git I found it very annoying and inconsistent that there are commands for creating a tag and a tree in a validated fashion, but the command for creating blobs was named "git-hash-object -w" and also could create all other objects without validating them at all. Also, AFAIK there is currently no way of creating a commit object with validating. I am well aware that all functionality neccessary already exists. I just want to prevent people learning git in future to have the same frustrating experience as I did. Obviously renaming / moving code around like that would break nearly all tools build ontop of git. Therefore I would prefer to use aliasing. If you feel like this would introduce too many unneccessary commands, I would instead focus on improving the documentation. Bj - : send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html