Thank you for the info and the help. Just one argument...
On 4/30/12 16:31 , Seth Robertson wrote:
It seems that git is allergic to the dual head branch solution or
something, which is surprising and disappointing.
Git tracks your version of master separately from each other remote's
master. This is exactly dual/multiple heads.
No, it isn't at all.
Multiple heads are the idea that a single commit can "branch" in the
repository and that both commits can be HEADS of the same branch at once
in a single repository. This allows a potential collision to exist in
the repository and to be pushed and pulled through multiple
repositories. It also largely eliminates this entire discussion since
each of the intermediate repositories between, say, you and I can carry
the collision. Either you or I, at will, can merge these heads just
like we'd merge any other two commits, push/fetch, etc.
That would seem to be the obvious and intuitive behavior, rather than
arbitrarily preventing the transfer.
> What git *does* forbid
(by default) is:
1: Letting you update someone else's checked out (non-bare) repository
underneath them
Yeah. That "underneath them" thing is confusing. I don't see any
reason why that should necessarily be so.
Git knows what commit is checked out. That's HEAD, yes? So what's
wrong with letting it collect other commits from other repositories
while your working directory sits? You can always commit your change
right on top of what's checked out, creating a second head for that branch.
Yes, I've read that git-diff, etc, are all making assumptions that fail
in this case, but there's nothing significantly different about
collecting commits to other branches and collecting commits to the
branch you're currently checked out from. Either way, you're going to
need to merge those into your working directory before committing your
current changes will make much semantic sense. And if you don't want to
do that, you can always commit them directly onto HEAD, and thereby
create a new branch, at least temporarily. That's one of the huge
advantages of the daggy architecture.
2: Letting you update someone else's repository if they have more
recent changes than you do.
Again, if they have more recent changes, then my line of changes should
create a fresh HEAD on that branch. Then the repositories hold all of
our changes to be merged at our leisure.
From a UI perspective, that request has a valid, and relatively obvious
semantic. That git simply refuses to do anything except produce a
cryptic error message seems... well, sad.
Both of these defaults are really good ideas, but you can disable them
if you think you know better.
I know better for source code control systems that support the multiple
HEAD concept. I don't know better for git. So far, it looks to me as
though git is just plain failing here.
I thank you for your suggestions. It'll take me a few readings before I
follow them all. Regardless of how I think git _should_ behave, I'll
still need to figure something, so thank you.
--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