Re: Newbie grief

[merlyn@stonehenge.com (Randal L. Schwartz)]

>>>>> "Rich" == Rich Pixley <rich.pixley@palm.com> 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@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.posterous.com/ for Smalltalk discussion