Re: Newbie grief

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


On 5/1/12 11:42 , Randal L. Schwartz wrote:
"Rich" == Rich Pixley<rich.pixley@xxxxxxxx>  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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Newbies FAQ]     [Linux Kernel Development]     [Free Online Dating]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Free Online Dating]     [Photo]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]     [Linux Resources]

Add to Google