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

Junio C Hamano [off-list ref] writes:

But cloning void to start the same project by multiple people
and pushing their initial commits as roots to start a project
indicates the lack of developer communication (besides, it just
feels like a bad style, a hangover from centralized SCM
mentality, but that is fine).

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.

But this time, the "feature" is not a zero cost thing.  As
Matthieu said in the thread, we do not let you do so right now.
Which means that it would involve new development, the code
changes would risk regressing behaviour existing users rely on,
and we would need testing for that.  These all take resources.

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.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum