Re: Newbie grief

[Rich Pixley <rich.pixley@palm.com>]

On 5/1/12 11:42 , Randal L. Schwartz wrote:
>>>>>> "Rich" == Rich Pixley<rich.pixley@palm.com>  writes:
>
> Rich>  What I'm talking about is the situation where a branch can have multiple,
> Rich>  childless commits.  I've switched to calling these "tips" for this
> Rich>  discussion.
>
> But in git, a branch *is* what you're calling a "tip".

And therein lies the problem.

> What do you find lacking about git branches, in terms of sharing?

A number of situations.  But the short answer is that git completely 
lacks the ability to cope with potential collisions in the repository - 
even collisions that can be handled completely automatically, even when 
the collision can be handled completely in the repository graph, (as 
distinct from lexical or file content resolutions).

I want to be able to fetch changes to the branch I currently have 
checked out.  Git blocks this because it doesn't know how to cope with 
the working directory in that situation.  Merging is straightforward. 
Even updating, (checkout), is fairly straightforward.  But the 
insistence on a single tip means that if I commit directly to a non-tip 
commit, git doesn't know what to do with the branch pointer.  If it 
leaves it at my commit, then the other changes are essentially orphaned. 
  If it leaves it at the other changes, then my commit is essentially 
orphaned.  While it's probably possible to force git to do this anyway, 
including orphaning one set of changes, doing so is of limited value 
since the git interface makes the assumption that branches have a single 
tip anyway.

Pushing is blocked in git.  Git simply refuses some push requests which 
have obvious and fairly straightforward semantics.  There are ways in 
git to accomplish the more general task of information exchange by 
reversing the initiation request, (pulling), by partitioning the data 
into branches, etc.  But the straightforward, intuitive request to push 
is, in git, frequently blocked for no particular reason.  (Pushes are 
analogous to the previous situation of fetching to my current branch.)

You and I want to share a branch and we each have local, unattended 
cache/mirror repositories that we would like to use to pass data between 
us.  This doesn't work in git because the first time you and I make 
simultaneous changes, whether they collide or not, the unattended 
repositories become wedged.  They each refuse to talk to the other until 
someone manually unwedges them.

I want that if you and say, Sitaram commit conflicting changes to a 
shared branch, it's easy for me to recognize that the conflict exist and 
easy for me to resolve that conflict in my own repository.  I want the 
source code control system to keep track of those things, show them to 
me/us, and to track and show my resolution to you.  This stuff should 
all be automatic.  It shouldn't require explicit testing, manual 
pulling, nor explicit discussion between the three of us.  It shouldn't 
prohibit that either, but it shouldn't require it.

These are all fairly common situations today.  And it wouldn't be so bad 
if nothing else solved these problems either.  But we've had source code 
control solutions that solved all of these issues for over a decade now. 
  Going backwards to git seems like a pain in that context.

--rich