>>>>> "Rich" == Rich Pixley <rich.pixley@xxxxxxxx> writes: 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. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <merlyn@xxxxxxxxxxxxxx> <URL:http://www.stonehenge.com/merlyn/> Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.posterous.com/ for Smalltalk discussion -- 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