From: "Shawn O. Pearce" <spearce@spearce.org>
To: Bill Lear <rael@zopyra.com>
Cc: Jeff King <peff@peff.net>, git@vger.kernel.org
Subject: Re: Dangers of working on a tracking branch
Date: Thu, 15 Feb 2007 17:49:02 -0500 [thread overview]
Message-ID: <20070215224902.GB27992@spearce.org> (raw)
In-Reply-To: <17876.57692.818802.89118@lisa.zopyra.com>
Bill Lear <rael@zopyra.com> wrote:
> On Thursday, February 15, 2007 at 17:09:18 (-0500) Shawn O. Pearce writes:
> >...
> >Lets say you patch git-clone to create these branches under
> >refs/heads, and also under refs/remotes/origin. Now someone else
> >modifies one of those branches, and you do a git-fetch to get the
> >latest. The tracking branch under refs/remotes/origin would update,
> >but not the one in refs/heads. Which means "jumping right in" may
> >actually cost you a lot more time, because you are now starting on
> >something that is several days old.
>
> Granted, but this would be the same as creating the branch by hand,
> then going rock-climbing over the weekend, while my colleagues toiled,
> and coming back on Monday to find 15 checkins on that branch, right?
Yes. Although if you pull something like that, your colleagues
may also be muttering things about you near the water cooler...
So Git may be the least of your problems. ;-)
> At which point I could .... rebase? Do a pull?
Rebase or pull, either would work. Rebase would clutter the
history less (no merge) but also tosses some history (no merge).
Its a tossup.
All I was trying to say was this may be more likely to happen,
as you will clone, work in that repository for a couple of weeks,
then get told to look at the `frotz` branch, as it has all the cool
stuff you were looking for. You peek at refs/heads/frotz, and
it has some cool stuff, but its 2 weeks out of date. Unless you
remember to pull `origin/frotz` to `frotz` first, you might spend
a while looking at stale code.
--
Shawn.
next prev parent reply other threads:[~2007-02-15 22:49 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-02-15 20:49 Dangers of working on a tracking branch Bill Lear
2007-02-15 21:00 ` Nicolas Pitre
2007-02-15 21:21 ` Bill Lear
2007-02-15 21:33 ` Bill Lear
2007-02-16 2:00 ` Jakub Narebski
2007-02-16 15:13 ` Bill Lear
2007-02-16 15:21 ` Jeff King
2007-02-16 15:27 ` Bill Lear
2007-02-16 15:52 ` Jeff King
2007-02-16 16:10 ` Santi Béjar
2007-02-16 16:34 ` Nicolas Pitre
2007-02-16 16:40 ` Bill Lear
2007-02-15 21:43 ` Jeff King
2007-02-15 21:53 ` Bill Lear
2007-02-15 21:58 ` Jeff King
2007-02-15 22:04 ` Bill Lear
2007-02-15 22:09 ` Shawn O. Pearce
2007-02-15 22:40 ` Bill Lear
2007-02-15 22:49 ` Shawn O. Pearce [this message]
2007-02-15 22:06 ` Jeff King
2007-02-15 22:30 ` Bill Lear
2007-02-15 22:14 ` Nicolas Pitre
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=20070215224902.GB27992@spearce.org \
--to=spearce@spearce.org \
--cc=git@vger.kernel.org \
--cc=peff@peff.net \
--cc=rael@zopyra.com \
/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.