Re: Git rescue mission

From: Jakub Narebski <jnareb@gmail.com>
Date: Feb 8, 2007, 22:29 UTC
Message-ID: <200702082329.12572.jnareb@gmail.com>
In-Reply-To: <17867.40122.51865.575762@lisa.zopyra.com>

Bill Lear wrote: [cut]

With git 1.5.0-rc4 cloned repository, with globbing refspecs for origin you don't have the problem. When you are on branch 'master', "git pull" fetches and merges 'origin/master' into 'master'. When on any other branch, "git pull" would fetch only (unless configured otherwise).

Note: you cannot pull into 'master' if you are not on 'master' because
of possibility of merge conflict: you need working area for that.

Show 7 quoted lines

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

In CVS branches are totally f**ked up. And enforced update before commit workflow doesn't help, also. Get rid of bad CVS habits. Please.

Show 7 quoted lines

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

It's the only option.

Show 7 quoted lines

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

So do fetch, and do pull only when changes are ready...

RTFM. Take a look at http://git.or.cz/gitwiki/GitLinks namely section "Seminars and presentations", read new Git User's Manual also at http://www.fieldses.org/~bfields/git-user-manual.html, browse GitWiki.

By the way, the workflow looks slightly different if you pull directly from one another (A pulls or fetches from B, B pulls or fetches from A), and if you have one central public bare repository (A pulls or fetches from 'public' and pushes her changes to 'public', B pulls or fetches from 'public' and pushes his changes to 'public'). In the latter git asks you to pull (fetch) before pushing if you are not up to date. Notice that it is on push, not on commit!

We should really update http://git.or.cz/gitwiki/GitWorkflows ... but how to make diagrams: ASCII art is hard because it needs monospace, upload of images attachements is not possible...

-- 
Jakub Narebski
Poland