git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: "John Dlugosz" <JDlugosz@TradeStation.com>
To: "Junio C Hamano" <gitster@pobox.com>, "Bryan Donlan" <bdonlan@gmail.com>
Cc: "Jakub Narebski" <jnareb@gmail.com>, <git@vger.kernel.org>
Subject: RE: fetch and pull
Date: Mon, 9 Mar 2009 11:27:53 -0400	[thread overview]
Message-ID: <450196A1AAAE4B42A00A8B27A59278E70A116178@EXCHANGE.trad.tradestation.com> (raw)
In-Reply-To: <7vfxhpnl7g.fsf@gitster.siamese.dyndns.org>

Thanks for your thoughts.  I'm still trying to figure out not just the
basic meaning of the tools but what can be done with them.

=== Re: ===
With git that is not ancient (i.e. v1.5.0 or newer), there is no reason
to
have local "dev" that purely track the remote anymore.  If you only want
to go-look-and-see, you can check out the remote tracking branch
directly
on a detached HEAD with "git checkout origin/dev".
=== end ===

Yes, I figured out that since gitk shows the remote, there is no reason
to have local copies of any master (upstream) refs that I don't plan on
modifying.  After setting it to track remotes, I deleted all my unneeded
copies.

=== Re: ===
Which means that the only cases we need to make it convenient for users
are to handle these local branches that "track" remote ones when you do
have local changes, or when you plan to have some.
=== end ===

I also realized recently that, with the use of topic branches, the user
doesn't need to see the "old" (local copy of) dev to understand what
changed since he last looked.  The visible branch point with the topic
will serve as that marker.

The only time the local dev is used is when the developer is going to
add a commit for the completed topic.  But, dealing with it (only) then
would be more steps when doing that.  And the local dev would still be
visible and out-dated from day-to-day, and when keeping the topic
up-to-date with dev changes he would need to use origin/dev not just dev
in his commands to rebase or merge.

=== Re: ===
I'd actually say we should give users a convenient way to remove the
local
branches that are marked to track remote tracking branches but do not
have
anything interesting on their own (iow when they can fast-forward to
their
corresponding remote tracking branches), if the true motive behind this
thread is "'git push' will notice 'dev' that is left behind and gives
clutter".
=== end ===

I found that using the GUI was easy enough, when "converting" my local
to track remote branches.  If you mean make a way to have a local
version of a tracking branch transiently, that is, only when it is
interesting, then I think I like that idea.

=== Re: ===
So how about "git branch --prune --remote=<upstream>" that iterates over
local branches, and if

 (1) it is not the current branch; and
 (2) it is marked to track some branch taken from the <upstream>; and
 (3) it does not have any commits on its own;

then remove that branch?  "git remote --prune-local-forks <upstream>" is
also fine; I do not care about which command implements the feature that
much.
=== end ===

Since fetch is the command that does the tracking of remotes, how about
having an option to fetch that does this before proceeding with the
fetch?  That is what people really want if they think they want locals
to auto-track the remotes.

=== Re: ===
But in that case, you shouldn't mark "dev" as tracking the remote's
"dev"
to begin with, so the hypothetical "branch --prune --remote=<upstream>"
would not touch such a "fork to address old issues", and we'd be safe.
=== end ===

Does git now "associate" local branch names with the remotes, other than
by simply having the same name?

--John
(please excuse the footer; it's not my choice)

TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited.
  If you received this in error, please contact the sender and delete the material from any computer.

  reply	other threads:[~2009-03-09 15:30 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-06 19:04 fetch and pull John Dlugosz
2009-03-06 19:27 ` Junio C Hamano
2009-03-06 20:44 ` Jakub Narebski
2009-03-06 20:49   ` Junio C Hamano
2009-03-06 22:11     ` John Dlugosz
2009-03-06 22:21       ` Junio C Hamano
2009-03-07  8:00       ` Bryan Donlan
2009-03-07 20:15         ` Junio C Hamano
2009-03-09 15:27           ` John Dlugosz [this message]
2009-03-09 15:08         ` John Dlugosz
     [not found] <AcmmaYOKDtJohyDSQt2B3xvVeIPNPw==>
2009-03-16 19:00 ` John Dlugosz
2009-03-16 20:03   ` Jay Soffian
2009-03-16 20:39     ` John Dlugosz
2009-03-16 20:43       ` Sverre Rabbelier
2009-03-17  8:34         ` Jeff King
2009-03-17  8:36           ` Sverre Rabbelier
2009-03-16 22:14       ` Jay Soffian
2009-03-16 22:33         ` John Dlugosz
2009-03-17  0:09           ` Jay Soffian
2009-03-17 14:58             ` John Dlugosz
2009-03-17 16:21               ` Jay Soffian
2009-03-17 16:44                 ` John Dlugosz
2009-03-17 21:31                   ` Nanako Shiraishi
2009-03-18  8:58                     ` Björn Steinbrink
2009-03-18  9:37                       ` Junio C Hamano
2009-03-18 15:18                       ` John Dlugosz
2009-03-18 15:31                         ` Björn Steinbrink
2009-03-18 16:50                           ` John Dlugosz
2009-03-18  0:37                   ` Jeff King

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

  List information: http://vger.kernel.org/majordomo-info.html

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

  git send-email \
    --in-reply-to=450196A1AAAE4B42A00A8B27A59278E70A116178@EXCHANGE.trad.tradestation.com \
    --to=jdlugosz@tradestation.com \
    --cc=bdonlan@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=jnareb@gmail.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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).