* branch --set-upstream considered harmful
@ 2010-06-06 19:21 Jay Soffian
2010-06-07 5:10 ` Tay Ray Chuan
2010-06-07 8:44 ` Michael J Gruber
0 siblings, 2 replies; 6+ messages in thread
From: Jay Soffian @ 2010-06-06 19:21 UTC (permalink / raw
To: git
Say I have an existing branch and it doesn't have a tracking config.
(My local users often just do "checkout -b topic" instead of "checkout
-b topic origin/master".)
I would naively expect this to work, while on that branch:
(topic)$ git branch --set-upstream origin/master
But, um no:
(topic)$ git branch --set-upstream origin/master
Branch origin/master set up to track local branch topic.
Doh!
Well, maybe this works:
(topic)$ git branch --set-upstream origin/master topic
Branch origin/master set up to track local branch topic.
Doh!^2
Well, maybe we can say "HEAD" since that seems to mean "the current
branch" everywhere else in gitland:
(topic)$ git branch --set-upstream HEAD origin/master
Branch HEAD set up to track remote branch master from origin.
(Aside, being able to create a branch named HEAD is surely a bug, right?)
Finally after exhausting all other possibilities (or finally making
sense of --set-upstream in the man page), we realize:
(topic)$ git branch --set-upstream topic origin/master
Branch topic set up to track remote branch master from origin.
Trying to make myself feel better, I realize that this works:
(topic)$ git branch topic --set-upstream origin/master
So here's how I'm thinking about fixing it, but maybe I'm just making
it even more confusing. What say you:
(topic)$ git branch --set-upstream=origin/master
Branch topic set up to track remote branch master from origin.
--track would be similarly enhanced, which allows a little more
flexibility in creating a branch thusly:
$ git branch --track=origin/master topic
Which creates topic, starting from HEAD, but tracking origin/master.
(And I'd do the same for checkout's --track option.)
I recognize that having both positional and non-positional forms of
--track/--set-upstream may be confusing, but I think it's less
confusing than set-upstream's current semantics, I'm loathe to
introduce yet another option, and I don't want to break backward
compatibility.
Flames?
j.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: branch --set-upstream considered harmful
2010-06-06 19:21 branch --set-upstream considered harmful Jay Soffian
@ 2010-06-07 5:10 ` Tay Ray Chuan
2010-06-07 5:19 ` Jay Soffian
2010-06-07 8:44 ` Michael J Gruber
1 sibling, 1 reply; 6+ messages in thread
From: Tay Ray Chuan @ 2010-06-07 5:10 UTC (permalink / raw
To: Jay Soffian; +Cc: git
Hi,
On Mon, Jun 7, 2010 at 3:21 AM, Jay Soffian <jaysoffian@gmail.com> wrote:
> Say I have an existing branch and it doesn't have a tracking config.
> (My local users often just do "checkout -b topic" instead of "checkout
> -b topic origin/master".)
>
> I would naively expect this to work, while on that branch:
>
> (topic)$ git branch --set-upstream origin/master
Hmm, I can see where the confusion is coming from - you're treating
git-branch as a "branch modifier", when it really is a "branch
creator" - unless you use -f, of course.
> [snip]
> So here's how I'm thinking about fixing it, but maybe I'm just making
> it even more confusing. What say you:
>
> (topic)$ git branch --set-upstream=origin/master
> Branch topic set up to track remote branch master from origin.
I was under the impression that long-style options took "=".
--
Cheers,
Ray Chuan
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: branch --set-upstream considered harmful
2010-06-07 5:10 ` Tay Ray Chuan
@ 2010-06-07 5:19 ` Jay Soffian
2010-06-07 6:37 ` Thomas Rast
0 siblings, 1 reply; 6+ messages in thread
From: Jay Soffian @ 2010-06-07 5:19 UTC (permalink / raw
To: Tay Ray Chuan; +Cc: git
On Mon, Jun 7, 2010 at 1:10 AM, Tay Ray Chuan <rctay89@gmail.com> wrote:
>> (topic)$ git branch --set-upstream origin/master
>
> Hmm, I can see where the confusion is coming from - you're treating
> git-branch as a "branch modifier", when it really is a "branch
> creator" - unless you use -f, of course.
Given --set-upstream's implementation and documentation, I assume it
is primarily intended to be used with an existing branch:
--set-upstream
If specified branch does not exist yet or if --force has been
given, acts exactly like --track. Otherwise sets up configuration
like --track would when creating the branch, except that where
branch points to is not changed.
If it isn't, then there's no way to do what it does other than two
magical git config commands.
>> (topic)$ git branch --set-upstream=origin/master
>> Branch topic set up to track remote branch master from origin.
>
> I was under the impression that long-style options took "=".
Git is inconsistent. Some do, some don't. But --set-upstream is
currently an argumentless switch. If I were to proceed as I suggested,
it would be both an argumentless switch and an option which takes an
argument. That means these would be equivalent:
$ git branch --set-upstream=origin/master master
$ git branch --set-upstream master origin/master
But these WOULD NOT:
$ git branch --set-upstream=origin/master
$ git branch --set-upstream origin/master
j.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: branch --set-upstream considered harmful
2010-06-07 5:19 ` Jay Soffian
@ 2010-06-07 6:37 ` Thomas Rast
2010-06-07 7:37 ` Jay Soffian
0 siblings, 1 reply; 6+ messages in thread
From: Thomas Rast @ 2010-06-07 6:37 UTC (permalink / raw
To: Jay Soffian; +Cc: Tay Ray Chuan, git
Jay Soffian wrote:
>
> Git is inconsistent.
[...]
> $ git branch --set-upstream=origin/master
> $ git branch --set-upstream origin/master
Doesn't this just make it *more* confusing?
Either we document this, and the user will be left wondering why we
have two almost identical (and by the conventions of many other
programs, including git-send-email, *equivalent*) syntaxes doing,
well, something not quite entirely unlike the same.
Or we don't, and the user will eventually typo it and wonder WTF he
just did wrong.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: branch --set-upstream considered harmful
2010-06-07 6:37 ` Thomas Rast
@ 2010-06-07 7:37 ` Jay Soffian
0 siblings, 0 replies; 6+ messages in thread
From: Jay Soffian @ 2010-06-07 7:37 UTC (permalink / raw
To: Thomas Rast; +Cc: Tay Ray Chuan, git
On Mon, Jun 7, 2010 at 2:37 AM, Thomas Rast <trast@student.ethz.ch> wrote:
> Jay Soffian wrote:
>>
>> Git is inconsistent.
> [...]
>> $ git branch --set-upstream=origin/master
>> $ git branch --set-upstream origin/master
>
> Doesn't this just make it *more* confusing?
>
> Either we document this, and the user will be left wondering why we
> have two almost identical (and by the conventions of many other
> programs, including git-send-email, *equivalent*) syntaxes doing,
> well, something not quite entirely unlike the same.
>
> Or we don't, and the user will eventually typo it and wonder WTF he
> just did wrong.
Please take a step back and see my original message. The thing that
motivated this is that the existing invocation is, I claim,
bass-ackwards. I was merely looking for a backwards compatible
solution that doesn't introduce yet another argument. But, maybe
set-upstream hasn't been around so long that breaking it (i.e., making
it an option that requires an argument) wouldn't be a bad idea.
Enough talk, I'll send up a patch when I get some more time.
j.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: branch --set-upstream considered harmful
2010-06-06 19:21 branch --set-upstream considered harmful Jay Soffian
2010-06-07 5:10 ` Tay Ray Chuan
@ 2010-06-07 8:44 ` Michael J Gruber
1 sibling, 0 replies; 6+ messages in thread
From: Michael J Gruber @ 2010-06-07 8:44 UTC (permalink / raw
To: Jay Soffian; +Cc: git
Jay Soffian venit, vidit, dixit 06.06.2010 21:21:
> Say I have an existing branch and it doesn't have a tracking config.
> (My local users often just do "checkout -b topic" instead of "checkout
> -b topic origin/master".)
>
> I would naively expect this to work, while on that branch:
>
> (topic)$ git branch --set-upstream origin/master
>
> But, um no:
>
> (topic)$ git branch --set-upstream origin/master
> Branch origin/master set up to track local branch topic.
>
> Doh!
>
> Well, maybe this works:
>
> (topic)$ git branch --set-upstream origin/master topic
> Branch origin/master set up to track local branch topic.
>
> Doh!^2
>
> Well, maybe we can say "HEAD" since that seems to mean "the current
> branch" everywhere else in gitland:
>
> (topic)$ git branch --set-upstream HEAD origin/master
> Branch HEAD set up to track remote branch master from origin.
>
> (Aside, being able to create a branch named HEAD is surely a bug, right?)
>
> Finally after exhausting all other possibilities (or finally making
> sense of --set-upstream in the man page), we realize:
>
> (topic)$ git branch --set-upstream topic origin/master
> Branch topic set up to track remote branch master from origin.
>
> Trying to make myself feel better, I realize that this works:
>
> (topic)$ git branch topic --set-upstream origin/master
>
> So here's how I'm thinking about fixing it, but maybe I'm just making
> it even more confusing. What say you:
>
> (topic)$ git branch --set-upstream=origin/master
> Branch topic set up to track remote branch master from origin.
>
> --track would be similarly enhanced, which allows a little more
> flexibility in creating a branch thusly:
>
> $ git branch --track=origin/master topic
>
> Which creates topic, starting from HEAD, but tracking origin/master.
> (And I'd do the same for checkout's --track option.)
>
> I recognize that having both positional and non-positional forms of
> --track/--set-upstream may be confusing, but I think it's less
> confusing than set-upstream's current semantics, I'm loathe to
> introduce yet another option, and I don't want to break backward
> compatibility.
>
> Flames?
I'm sorry, but you're completely right. I created a tracking branch
config *for* a remote branch myself, and created one for the HEAD branch
before looking up the man page and wondering about the braindead
non-semantic way it works. We have that braindeadness in other places as
well, e.g. "git rebase branchname" which does not rebase "branchname" at
all (but the current branch).
Ok, you want flame? I'll give you flame: This is not going to change. We
have a "naturally grown" ui, and we don't do any changes to make it
conceptually consistent unless it does not change any existing
behaviour. [I'm exaggerating, of course, but you wanted flame, didn't you? ]
I like your --set-upstream= solution, by the way. Maybe people find it
less confusing if there's an "--upstream=upstream" long option (no
"set") and a "--set-upstream" subcommand. You know we have subcommands
as options as well as arguments:
branch --set-upstream
config --get etc.
remote add etc.
noted edit etc.
svn init etc.
submodule add etc.
Speaking of consistency :|
Michael
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2010-06-07 8:45 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-06-06 19:21 branch --set-upstream considered harmful Jay Soffian
2010-06-07 5:10 ` Tay Ray Chuan
2010-06-07 5:19 ` Jay Soffian
2010-06-07 6:37 ` Thomas Rast
2010-06-07 7:37 ` Jay Soffian
2010-06-07 8:44 ` Michael J Gruber
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).