Re: Newbie grief

On 5/1/12 11:42 , Randal L. Schwartz wrote:

And therein lies the problem.

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