git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Jeff King <peff@peff.net>
Cc: Jay Soffian <jaysoffian@gmail.com>,
	Marc Branchaud <marcnarc@xiplink.com>,
	Miles Bader <miles@gnu.org>,
	git@vger.kernel.org
Subject: Re: setting up tracking on push
Date: Tue, 10 Mar 2009 21:37:21 -0700	[thread overview]
Message-ID: <7vwsaw7jzy.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: <20090311020409.GA31365@coredump.intra.peff.net> (Jeff King's message of "Tue, 10 Mar 2009 22:04:09 -0400")

Jeff King <peff@peff.net> writes:

>   # track origin/master with a different branch
>   git branch --track=origin/master other_branch

Isn't this one confusing with "git branch other_branch origin/master" (I
thought --track is the default these days)?

In any case, I find these "branch --retrack" proposals too confusing and
probably overengineered.

I need to ask a more fundamental question.  Is it really useful for people
to be able to re-track arbitrary remote/branch with an existing branch?

The only use case I've heard in this thread and nearby is where you are
the one who started the history of the branch, and pushed it into a public
repository as a new branch, making the result _the_ most authoritative
one.  After that, everybody else will be able to have a local branch that
tracks the authoritative one with "branch --track frotz origin/frotz", and
you will be the only one left unable to do so because you already have
that frotz branch.

And for that use case, I find it sensible if we had a way to easily say
"This branch hasn't been tracking anything so far (because it is the
originator of the history), but now it will give up its authority and
start tracking the one it is pushing into", and it would make sense to
somehow link that to the invocation of "git push".

    Side note.  I would also accept "It is only one person in the world,
    who can edit .git/config and be done with it; why bother complicate
    the UI for other people" as a valid argument against it, though ;-).

In that "my private branch gave autority to the branch at my public
repository" case, it is of course easy to re-clone (or "branch -m" away
and then re-fetch) like everybody else, but then you would lose the reflog
from the time before the branch went public, so it is not a solution but a
poor workaround.

I somehow think it would not make any sense to say "This branch used to
track that branch but now it will start tracking this other one".  People
of course can come up with contrived example to claim it is a useful
operation, but in real life, would it really be?  "The authoritative
repository has moved" is not an example.  It would merely be a change in
remote.<name>.url.  "The upstream renamed the branch" is not an example
either.  It falls into "Don't do that, then.  It will confuse everybody"
case.

  parent reply	other threads:[~2009-03-11  4:39 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-06  3:07 setting up tracking on push Miles Bader
2009-03-06  3:17 ` John Tapsell
2009-03-06  4:49 ` Jay Soffian
2009-03-06 10:45   ` Johannes Schindelin
2009-03-06 11:15     ` Miles Bader
2009-03-06 14:15       ` Jeremy O'Brien
2009-03-06 15:43         ` Jay Soffian
2009-03-06 16:29           ` Miles Bader
2009-03-10 20:26             ` Marc Branchaud
2009-03-10 23:09               ` Jeff King
2009-03-11  1:52                 ` Jay Soffian
2009-03-11  2:04                   ` Jeff King
2009-03-11  2:59                     ` Jay Soffian
2009-03-11  3:06                       ` Jeff King
2009-03-11  3:40                         ` Jay Soffian
2009-03-11  3:44                         ` Jay Soffian
2009-03-11  3:57                           ` Jeff King
2009-03-11  4:15                             ` Jay Soffian
2009-03-24  9:58                               ` Jakub Narebski
2009-03-11  4:37                     ` Junio C Hamano [this message]
2009-03-11  4:56                       ` Miles Bader
2009-03-11  5:03                         ` Miles Bader
2009-03-11  5:22                       ` Jay Soffian
2009-03-11 21:39                         ` Marc Branchaud
2009-03-11  6:32                       ` Jeff King
2009-03-11 10:02                       ` Nanako Shiraishi
2009-03-11 16:40                         ` Jeff King
2009-03-12  0:08 ` John M. Dlugosz
2009-03-12  0:58   ` Jay Soffian
2009-03-12  1:11     ` Junio C Hamano
2009-03-12  1:16       ` Jay Soffian
2009-03-12  1:14     ` Jay Soffian
2009-03-12  1:21       ` Jay Soffian
2009-03-15  3:28       ` John M. Dlugosz
2009-03-15 12:36         ` Jay Soffian
2009-03-16  1:07           ` John M. Dlugosz
2009-03-16  1:43             ` Jay Soffian
2009-03-15 18:33         ` Junio C Hamano

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=7vwsaw7jzy.fsf@gitster.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=jaysoffian@gmail.com \
    --cc=marcnarc@xiplink.com \
    --cc=miles@gnu.org \
    --cc=peff@peff.net \
    /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 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 NNTP newsgroup(s).