[I'm going to assume not copying the list on your reply to me was an oversight, since there's nothing in the text to indicate it was supposed to confidential or personal in any way]. [second, sorry about the multiple emails!] On Tue, May 1, 2012 at 10:55 PM, Rich Pixley <rich.pixley@xxxxxxxx> wrote: > > On 4/30/12 20:44 , Sitaram Chamarty wrote: >> >> I've been reading the thread with interest. >> >> People who know far more than I do about git, its innards, and its >> design have been responding in this thread so consider this a git >> *user*'s point of view: >> >> On Tue, May 1, 2012 at 6:45 AM, Rich Pixley<rich.pixley@xxxxxxxx> wrote: >> >>> 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 >> >> That is bizarre; I have no other word for it. >> >> I teach git (occasionally), and if this feature existed I would >> totally ignore it in my teaching material because I wouldn't know how >> to defend or explain the need for "hydra branches". >> >> It's like having two people with the same first name *and* last name >> (a situation that is not impossible in real life, but is rare and >> almost always requires special handling). >> >> Does Hg do this? > > Yes, it does. "Hg merge" by default merges a second head into your > current working directory. > > It's a conceptual leap, I concur. Believe me, I'm going through the It's a conceptual leap I can do without; I'm bowing out of this discussion. There's an ambiguity in the branch name now that, to me, is both confusing and unnecessary. It's like each branch name is now an array variable instead of a scalar. We all know when arrays are better than a bunch of similarly named scalars, but in *this* context I don't see why it is needed. The fact that, (in later emails to others), you called this a basic beginning need, or words to that effect, is just icing on top. > reverse cultural shock now that git doesn't have this facility. But it's a > leap whose idea has been around for over 20 years. It wasn't until the > daggy source code control systems like monotone showed up that it became > practical, but that was a decade ago now. > > The big win, of course, is that we can both push to the same repository, > (and through multiple repositories), and we can decide later whether we want > to merge or branch permanently. > >> That would explain why my (admittedly half-hearted) >> attempts to learn it have failed -- whatever tutorial I used must have >> been written with the idea that hydra branches are intuitive and >> logical and sane, but did not express the concept as clearly and >> succinctly as you did. >> >> Thanks for this insight; my next attempt to understand Hg, should I >> ever be forced into it, might actually succeed! > > It's really pretty simple. Your commit, (or push, or pull), always > succeeds, even if it's not at the tip of a branch. If it's not at the tip > of a branch, then it creates a new tip. > > The word "head" here is problematic since git uses it in a totally > different way. In git, "HEAD" refers to whatever commit is currently > checked out. In hg, "head" refers to a childless commit. It doesn't even > need to be on a named branch. > > --rich -- Sitaram -- 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