All of
 help / color / mirror / Atom feed
From: Bill Lear <>
To: Linus Torvalds <>
Cc: Jakub Narebski <>
Subject: Re: Git rescue mission
Date: Thu, 8 Feb 2007 15:57:14 -0600	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

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


  parent reply	other threads:[~2007-02-08 21:58 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 [this message]
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

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \

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