From: Jakub Narebski <jnareb@gmail.com>
To: Bill Lear <rael@zopyra.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>, git@vger.kernel.org
Subject: Re: Git rescue mission
Date: Thu, 8 Feb 2007 23:29:11 +0100 [thread overview]
Message-ID: <200702082329.12572.jnareb@gmail.com> (raw)
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.
> 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.
> 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.
> 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
prev parent reply other threads:[~2007-02-08 22:27 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-02-08 0:18 Git rescue mission Bill Lear
2007-02-08 0:22 ` Johannes Schindelin
2007-02-08 0:24 ` Bill Lear
2007-02-08 0:25 ` Johannes Schindelin
2007-02-08 0:34 ` Bill Lear
2007-02-08 0:48 ` Junio C Hamano
2007-02-08 4:28 ` Alexander Litvinov
2007-02-09 0:53 ` Junio C Hamano
2007-02-09 3:32 ` Alexander Litvinov
2007-02-08 15:27 ` Bill Lear
2007-02-08 15:56 ` Jakub Narebski
2007-02-08 23:24 ` Jeff King
2007-02-08 23:32 ` Bill Lear
2007-02-08 17:27 ` Linus Torvalds
2007-02-08 20:12 ` Kalle Pokki
2007-02-08 21:23 ` Linus Torvalds
2007-02-08 22:03 ` Kalle Pokki
2007-02-08 22:10 ` Shawn O. Pearce
2007-02-09 1:48 ` Theodore Tso
2007-02-09 1:58 ` Shawn O. Pearce
2007-02-09 2:01 ` Jakub Narebski
2007-02-10 16:05 ` Theodore Ts'o
2007-02-10 16:05 ` [PATCH] Print a sane error message if an alias expands to an invalid git command Theodore Ts'o
2007-02-10 16:05 ` [PATCH] Allow aliases to expand to shell commands Theodore Ts'o
2007-02-10 18:04 ` Linus Torvalds
2007-02-10 18:13 ` Theodore Tso
2007-02-10 20:34 ` Johannes Schindelin
2007-02-11 0:13 ` Theodore Tso
2007-02-11 16:03 ` Johannes Schindelin
2007-02-11 16:21 ` Theodore Tso
2007-02-11 16:36 ` Johannes Schindelin
2007-02-11 21:44 ` Junio C Hamano
2007-02-11 22:03 ` Johannes Schindelin
2007-02-12 3:56 ` Theodore Tso
2007-02-12 6:53 ` Shawn O. Pearce
2007-02-10 16:50 ` [PATCH] Print a sane error message if an alias expands to an invalid git command Junio C Hamano
2007-02-09 19:21 ` Git rescue mission Kalle Pokki
2007-02-08 21:57 ` Bill Lear
2007-02-08 22:13 ` Linus Torvalds
2007-02-08 22:33 ` Bill Lear
2007-02-08 23:25 ` Bill Lear
2007-02-08 23:33 ` Shawn O. Pearce
2007-02-08 23:40 ` Bill Lear
2007-02-08 23:50 ` Shawn O. Pearce
2007-02-09 0:03 ` Jakub Narebski
2007-02-09 0:17 ` Linus Torvalds
2007-02-09 8:58 ` Michael S. Tsirkin
2007-02-08 23:38 ` Jakub Narebski
2007-02-08 23:46 ` Linus Torvalds
2007-02-09 4:38 ` Junio C Hamano
2007-02-08 22:29 ` Jakub Narebski [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200702082329.12572.jnareb@gmail.com \
--to=jnareb@gmail.com \
--cc=git@vger.kernel.org \
--cc=rael@zopyra.com \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.