On Wednesday, November 14, 2007 at 11:32:32 (-0800) Junio C Hamano writes:
quoted text
>Sergei Organov <osv@javad.com> writes:
>
>> Junio C Hamano <gitster@pobox.com> writes:
>>
>>> His second point is also a real issue.  If you allowed cloning
>>> an empty repo (either bare or non-bare), then you and Bill can
>>> both clone from it, come up with an initial commit each.  Bill
>>> pushes his initial commit first.  Your later attempt to push
>>> will hopefully fail with "non fast forward", if you know better
>>> than forcing such a push, but then what?  You need to fetch, and
>>> merge (or rebase) your change on top of Bill's initial commit,
>>> and at that point the history you are trying to merge does not
>>> have any common ancestor with his history.
>>
>> Just a wild idea. Doesn't it make sense to introduce perfect ultimate
>> common ancestor of the universe, probably calling it "the NULL commit"?
>> At first glance it seems that it can help to avoid corner cases
>> automagically.
>...
>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). ...

We have several users who have been using git for the past 9 months
and they each find this unreasonably complicated.  We realize it is
work, perhaps not of the highest importance, but it's also easy for
more experienced users to simply pooh-pooh the ideas that newer users
have as "silly" because instead of the two steps they would like, they
can "just" do the five "easy" steps.

Well, here's what we'd like:

% mkdir new_repo
% cd new_repo
% git --bare init

[on another machine:]
% git clone git://host/new_repo
% cd new_repo
% git init
[add content]
% git commit -a -m "Initial stuff"
% git push

So, this is hard work, and other priorities intrude.  Ok.

Instead, we have to 1) figure out how to do this right, because it's
difficult to remember and not intuitive, and 2) once we have "figured
it out", really figure it out, because there are a few gotchas:

% mkdir new_repo
% cd new_repo
% git --bare init

% mkdir new_repo
% cd new_repo
[add content]
% git commit -a -m "Initial stuff"
% git config remote.origin.url git://host/new_repo
% git push
[ach! fails!  what's up??]
[poke, read, poke some more, try other things..]
[try setting the remote.origin.fetch?  No, that doesn't work]
[try setting branch.master.remote?  Just edit by hand??]
% git push master
[fails again; read some more; think, think, think...]
% git push origin master
[aha! finally it works]

But now, I have a repo in which I cannot just say "git push" to update
my remote repo.

So, if we can't have clone "do the right thing", then it would be nice
if we had something to allow us to do this, perhaps an argument to git
init:

% mkdir new_repo
% cd new_repo
% git --bare init

[on another machine:]
% mkdir new_repo
% cd new_repo
% git init --mirror git://host/new_repo
[add content]
% git commit -a -m "Initial stuff"
% git push

Where 'git init --mirror <blah>' just sets up the config file
properly.

Something to think about ...


Bill
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html