Re: Newbie grief

In message <4F9F28F5.2020403@palm.com>, Rich Pixley writes:

    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, etc.

    That would seem to be the obvious and intuitive behavior, not
    arbitrarily preventing the transfer.

I still don't see how git isn't providing this to you, with the caveat that in git, a single commit with a specific SHA1 hash is constant. You may modify it (making it a new commit), modify its history (making it a new commit), or add new commits after it. Git doesn't number commits the way other VCS do, which may be the source of confusion.

A specific commit with a specific SHA1 can be at the head of multiple branches. Those branch may be local to the repository, local tracking branches, or remote tracking branches.

Contrarywise, the head of the "master" (or any) branch (or ref) may point to any SHA1. My master branch may point to one SHA1, yours may point to another. You can look at my version of master and I can look at your version of master (permissions permitting). After appropriate network operations, either you, or I, at will, can merge these heads just like we'd merge any other two commits, push, etc. With appropriate naming conventions, we can even continue parallel updates where I can make updates to your version of master and you can make updates to my version of master, in addition to our own.

For example, in the diagram http://mercurial.selenic.com/wiki/Head rev2 might be your version of master and rev3 might be my version. Both might exist in my repository and both might exist in your repository, and both might have the symbolic name "master" associated with it, and git would keep it entirely straight.

    >    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?

It does! It can! What is forbidden is for me update what you have checked out. Can you conceive of a revision control system where I commit I would make would change what you have checked out? (Well, I can, ClearCase with dynamic views, and it is more horrible than you can imagine—I've had compile fail because the files changed underneath my feet between the start of the compile and the end of the compile). And what happens if the file I changed is also the file you are in the middle of changing? Is your change going to overwrite mine? Is mine going to overwrite yours? This way leads to insanity.

    You can always commit your change right on top of what's checked
    out, creating a second head for that branch.

With git, you must always commit your change right on top of what's checked out, though of course you may decide to change what's checked out and "float" the changes you made over to the new head (trivial, as long as there are not conflicts between the two heads and the changes you made). However, only the user of the repository is allowed to do this. A remote user is not allowed to change what's checked out.

    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.

Yes there is. Consider this use case. You can I both spot DIFFERENT bugs. You and I both start editing filea. I fix my problem one way which involves lines 10, 100, and 500, you fix your problem which involves line 10, 100, and 200. I'm typing faster than you so I commit/push first. If I can update your HEAD, at that point I've changed the file you are editing. You save and my change is lost.

Now this is where you say, if git only supported multiple HEADs the problem would go away. I could update my version of master and you could update your version of master and there would be no conflict. And...of course you can with git. I don't update your master, what you have checked out, I update what you know is my master. Then when you are done, you get to say "merge my master with your master" or "instead of committing this change on my branch, let me try this last change I made on top of the changes you made" or whatever you want to say.

    > 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.

And...git does this. Your changes are made on your HEAD (your branch). My changes are made on my HEAD (my branch). Never the twain shall meet until someone says "merge" (or "rebase").

The key to all of this is the namespace naming convention. refs/remotes/<remotename>/<branchname> (or more informally <remotename>/<branchname>) is a remote tracking branch, or my idea of what your branches (HEADs) currently are. These are (kinda/sorta) read-only reference which are only updated when you specifically ask them to be updated, or if I decide to update what you believe I have (kinda rude, but allowed).

So let us consider a specific example. There is a repository which everyone call's "Rich" (they don't need to use the same name, but it reduces confusion), a repository everyone calls "Seth", and a central repository everyone calls "origin".

Location Branchname -------- ---------- origin foo (bare) rodger foo rodger origin/foo rodger seth/foo seth foo seth origin/foo seth rodger/foo

I make a change in my foo. I can push the change into origin's foo, rodger's seth/foo (and technically origin/foo but that is more than just rude). You can take my change and store it in seth/foo.

At any point, after you have the changes (either because I push them or you fetch them) you can then merge your work with my work.

So...what's not possible?

					-Seth Robertson