Re: Cloning empty repositories, was Re: What is the idea for bare repositories?

Junio C Hamano <gitster@pobox.com> writes:

I do not like the approach of policy by force. It assumes that the developers know better than the users what the users are going to do with git.

For example, I use git for tracking and versioning installations and updaters of complex programs. They are basically built into a directory tree, and this tree is checked into a bare repository in a branch corresponding to a particular customer. The trees are _target_ trees created completely by something akin to make install. So every checkin is from scratch. The checkins for a particular customer happen in one branch so that it is easy to generate a diff and from that an updater (the diff gets converted into a batch file removing old files and a zip file unpacking new files over the old ones).

There simply is no common reference/starting point for the disparate branches. I have some "README" in master, but that is an utterly stupid and unnatural starting point.

One might argue that one should use one repository per customer and just share the objects (many of which are similar). But that disallows making diffs between the trees of different customers. Since the purpose of git here is just to track history and not do any sort of merging or rebasing, there are no interesting ancestry connections between branches.

Am I stupid for using git for this sort of thing? I believe not. And yet git developers choose to call me stupid because my work flow does not lend any sense to a common ancestor commit.

And they will continue to take resources. And since the trend goes more and more into name-calling on those who still feel that their workflow justifies disparate branches without common registered ancestry, it will increasingly drain the most important resources of all: goodwill and enthusiasm.