Re: Git rescue mission

[Bill Lear <rael@zopyra.com>]

On Thursday, February 8, 2007 at 09:27:50 (-0800) Linus Torvalds writes:
>On Wed, 7 Feb 2007, Bill Lear wrote:
>> 
>> I have a public bare repo on my machine that I have cloned to make a
>> private repo.  I just want to sync my branches on my public and
>> private repos.  I do not want to merge across branches, I just want to
>> "sync".
>
>Ok, others already replied, but here's a few rules to ease your mind in 
>general:
>
> - First off: you can always _trivially_ get back to whatever state you 
>   had before, as long as you committed it, and didn't have any dirty 
>   state (uncommitted patches) in your working tree.
>...

Well, I have read all of the very welcome advice and am comfortable
with all of it.

However, I still have a few open issues with the other branch of this
discussion, i.e., why can we not have an update operation that
respects branches in the first place, as 'git pull' seems to do, when
run from the master branch?  I do realize that the branch 'foo' in my
repo is different from the branch 'foo' in your repo.  However, I want
to track things, and "track" here is a very appropriate word.  Tracks
don't cross, and I don't want to cross my "logically equivalent"
branches (at least yet), even though, as Linus pointed out in great
detail, this is easy to undo (though, do see below for a qualification
of "easy").

So, why should I care?

Because, an ounce of prevention is worth a pound of cure.  So, if a
pound of undo is so very easy, then, in my mind, an ounce of
preventing the problem in the first place is at least 1/16th that.

When working in a peer-to-peer relationship, I often push and pull
with my peers, perhaps on a daily basis, perhaps weekly.  Just the
other day, my peer was the one who goofed up his branches and I pulled
them into my public repo, all tangled up, and did not realize it.
Thence pulled into my private repo, did lots of work, pushed back to
my public repo, and after more time intervened, realized something was
wrong.  It took a LOT of work (for me, I'm sure for others here it
would have been much, much less) for me to 1) figure out the genesis
of the problem, and 2) figure out how to undo it all without
destroying my subsequent work.  When we both do this, and merge
unexpectedly, at different points on one branch from a different
point on another, and then pollute each others' repos, it does become
rather ... well, annoying is the best way to put it.

In CVS, if I am on branch topic and say 'cvs update', it updates my
branch topic.  If I am on branch master and say 'cvs update', it
updates my branch master.  Etc., etc.  It doesn't matter that you move
from one branch to the other, the update behavior is the same.  In
git, if I am on master, things seem to work wonderfully --- one 'git
pull' and my entire repo is synced (that is, merged) as I expect with
the other repo.

I really don't want to do 'git fetch'.  I really want 'git pull'.  I
really want the changes put into my repo, from that repo's branch X
onto my branch X, and that repo's branch Y onto my branch Y.  I really
don't want to have to remember to switch to my master branch before I
do git pull (this, however, as it stands, does seem to me to be the
best option).  Perhaps I'll just write a script 'git-sync' that does
'git checkout master; git pull'...

Jakub is of course literally correct when he says "'Crossing of the
streams' is _required_ ... If you do parallel work ... you have to
do merges".  Again, I recognize that my "foo" branch is different
from your "foo" branch, and that when they come together they are
in fact merged, but logically they are one thing --- one stream of
shared work that we don't want to slip over into another one, at
least not until we are ready.

Again, thanks to everyone for their patience.  We really do enjoy
using git --- very cool, fast, and flexible.


Bill