Re: Newbie grief

Rich> I want to be able to fetch changes to the branch I currently have checked out. Rich> Git blocks this because it doesn't know how to cope with the working directory Rich> in that situation.

It does? I can always "git fetch origin" in my repo, and the remote branches are in "origin/master, origin/foo, origin/bar". Totally separate from my working tree.

If I want to *examine* them, I can make a WIP commit, or use "git stash", and then check them out headless:

  git stash save
  git checkout origin/master
  ## examine
  ## now go back
  git checkout master
  git stash pop

and now I can see what the upstream looks like.  Or just diff them:

  git diff ..origin/master

Rich> Merging is straightforward. Even updating, (checkout), is fairly Rich> straightforward. But the insistence on a single tip means that if Rich> I commit directly to a non-tip commit, git doesn't know what to do Rich> with the branch pointer. If it leaves it at my commit, then the Rich> other changes are essentially orphaned. If it leaves it at the Rich> other changes, then my commit is essentially orphaned. While it's Rich> probably possible to force git to do this anyway, including Rich> orphaning one set of changes, doing so is of limited value since Rich> the git interface makes the assumption that branches have a single Rich> tip anyway.

So, make a set of related names for your branches. It's better with names anyway.

Rich> Pushing is blocked in git. Git simply refuses some push requests Rich> which have obvious and fairly straightforward semantics.

 git push master:from-merlyn/master

And now someone can look at "from-merlyn/master", and know that it's from me, and related to master, and either incorporate it into the real master, or cherry-pick from it, or whatever. Solved.

Rich> You and I want to share a branch and we each have local, Rich> unattended cache/mirror repositories that we would like to use to Rich> pass data between us. This doesn't work in git because the first Rich> time you and I make simultaneous changes, whether they collide or Rich> not, the unattended repositories become wedged. They each refuse Rich> to talk to the other until someone manually unwedges them.

No, you do it like above. Some *person* has to sign off the merge each time. But we can share the unmerged changeset through other branches.

Rich> I want that if you and say, Sitaram commit conflicting changes to Rich> a shared branch, it's easy for me to recognize that the conflict Rich> exist and easy for me to resolve that conflict in my own Rich> repository. I want the source code control system to keep track Rich> of those things, show them to me/us, and to track and show my Rich> resolution to you. This stuff should all be automatic. It Rich> shouldn't require explicit testing, manual pulling, nor explicit Rich> discussion between the three of us. It shouldn't prohibit that Rich> either, but it shouldn't require it.

You're asking a lot of an automated system. I think you're trying to get a system to replace the communication you should be doing as a developer.