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