{"thread":{"id":"24025","subject":"branch --set-upstream considered harmful","startedAt":"2010-06-06T19:21:57Z","lastAt":"2010-06-07T08:44:22Z","messageCount":6,"participants":["Jay Soffian","Tay Ray Chuan","Thomas Rast","Michael J Gruber"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"143100","messageId":"AANLkTiln_xxnF-e33YA7kkfbBBcBMd40xag8JTW0eqws@mail.gmail.com","threadId":"24025","inReplyTo":null,"subject":"branch --set-upstream considered harmful","fromName":"Jay Soffian","fromEmail":"jaysoffian@gmail.com","sentAt":"2010-06-06T19:21:57Z","receivedAt":"2010-06-06T19:21:57Z","isPatch":false,"sender":{"key":"jaysoffian@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155970?v=4"},"body":"Say I have an existing branch and it doesn't have a tracking config.\n(My local users often just do \"checkout -b topic\" instead of \"checkout\n-b topic origin/master\".)\n\nI would naively expect this to work, while on that branch:\n\n  (topic)$ git branch --set-upstream origin/master\n\nBut, um no:\n\n  (topic)$ git branch --set-upstream origin/master\n  Branch origin/master set up to track local branch topic.\n\nDoh!\n\nWell, maybe this works:\n\n  (topic)$ git branch --set-upstream origin/master topic\n  Branch origin/master set up to track local branch topic.\n\nDoh!^2\n\nWell, maybe we can say \"HEAD\" since that seems to mean \"the current\nbranch\" everywhere else in gitland:\n\n  (topic)$ git branch --set-upstream HEAD origin/master\n  Branch HEAD set up to track remote branch master from origin.\n\n(Aside, being able to create a branch named HEAD is surely a bug, right?)\n\nFinally after exhausting all other possibilities (or finally making\nsense of --set-upstream in the man page), we realize:\n\n  (topic)$ git branch --set-upstream topic origin/master\n  Branch topic set up to track remote branch master from origin.\n\nTrying to make myself feel better, I realize that this works:\n\n  (topic)$ git branch topic --set-upstream origin/master\n\nSo here's how I'm thinking about fixing it, but maybe I'm just making\nit even more confusing. What say you:\n\n  (topic)$ git branch --set-upstream=origin/master\n  Branch topic set up to track remote branch master from origin.\n\n--track would be similarly enhanced, which allows a little more\nflexibility in creating a branch thusly:\n\n  $ git branch --track=origin/master topic\n\nWhich creates topic, starting from HEAD, but tracking origin/master.\n(And I'd do the same for checkout's --track option.)\n\nI recognize that having both positional and non-positional forms of\n--track/--set-upstream  may be confusing, but I think it's less\nconfusing than set-upstream's current semantics, I'm loathe to\nintroduce yet another option, and I don't want to break backward\ncompatibility.\n\nFlames?\n\nj.\n"},{"id":"143133","messageId":"AANLkTikUkkWQl7cYuPiKGaJFYL_JlIGFCXXf7En8t0FN@mail.gmail.com","threadId":"24025","inReplyTo":"AANLkTiln_xxnF-e33YA7kkfbBBcBMd40xag8JTW0eqws@mail.gmail.com","subject":"Re: branch --set-upstream considered harmful","fromName":"Tay Ray Chuan","fromEmail":"rctay89@gmail.com","sentAt":"2010-06-07T05:10:07Z","receivedAt":"2010-06-07T05:10:07Z","isPatch":false,"sender":{"key":"rctay89@gmail.com","avatar":"https://avatars.githubusercontent.com/u/61553?v=4"},"body":"Hi,\n\nOn Mon, Jun 7, 2010 at 3:21 AM, Jay Soffian <jaysoffian@gmail.com> wrote:\n> Say I have an existing branch and it doesn't have a tracking config.\n> (My local users often just do \"checkout -b topic\" instead of \"checkout\n> -b topic origin/master\".)\n>\n> I would naively expect this to work, while on that branch:\n>\n>  (topic)$ git branch --set-upstream origin/master\n\nHmm, I can see where the confusion is coming from - you're treating\ngit-branch as a \"branch modifier\", when it really is a \"branch\ncreator\" - unless you use -f, of course.\n\n> [snip]\n> So here's how I'm thinking about fixing it, but maybe I'm just making\n> it even more confusing. What say you:\n>\n>  (topic)$ git branch --set-upstream=origin/master\n>  Branch topic set up to track remote branch master from origin.\n\nI was under the impression that long-style options took \"=\".\n\n-- \nCheers,\nRay Chuan\n"},{"id":"143135","messageId":"AANLkTildT6TRd0sPlv1QbCLO7oOPHM-L1yWNIdhdp0ex@mail.gmail.com","threadId":"24025","inReplyTo":"AANLkTikUkkWQl7cYuPiKGaJFYL_JlIGFCXXf7En8t0FN@mail.gmail.com","subject":"Re: branch --set-upstream considered harmful","fromName":"Jay Soffian","fromEmail":"jaysoffian@gmail.com","sentAt":"2010-06-07T05:19:39Z","receivedAt":"2010-06-07T05:19:39Z","isPatch":false,"sender":{"key":"jaysoffian@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155970?v=4"},"body":"On Mon, Jun 7, 2010 at 1:10 AM, Tay Ray Chuan <rctay89@gmail.com> wrote:\n>>  (topic)$ git branch --set-upstream origin/master\n>\n> Hmm, I can see where the confusion is coming from - you're treating\n> git-branch as a \"branch modifier\", when it really is a \"branch\n> creator\" - unless you use -f, of course.\n\nGiven --set-upstream's implementation and documentation, I assume it\nis primarily intended to be used with an existing branch:\n\n       --set-upstream\n           If specified branch does not exist yet or if --force has been\n           given, acts exactly like --track. Otherwise sets up configuration\n           like --track would when creating the branch, except that where\n           branch points to is not changed.\n\nIf it isn't, then there's no way to do what it does other than two\nmagical git config commands.\n\n>>  (topic)$ git branch --set-upstream=origin/master\n>>  Branch topic set up to track remote branch master from origin.\n>\n> I was under the impression that long-style options took \"=\".\n\nGit is inconsistent. Some do, some don't. But --set-upstream is\ncurrently an argumentless switch. If I were to proceed as I suggested,\nit would be both an argumentless switch and an option which takes an\nargument. That means these would be equivalent:\n\n$ git branch --set-upstream=origin/master master\n$ git branch --set-upstream master origin/master\n\nBut these WOULD NOT:\n\n$ git branch --set-upstream=origin/master\n$ git branch --set-upstream origin/master\n\nj.\n"},{"id":"143140","messageId":"201006070837.16713.trast@student.ethz.ch","threadId":"24025","inReplyTo":"AANLkTildT6TRd0sPlv1QbCLO7oOPHM-L1yWNIdhdp0ex@mail.gmail.com","subject":"Re: branch --set-upstream considered harmful","fromName":"Thomas Rast","fromEmail":"trast@student.ethz.ch","sentAt":"2010-06-07T06:37:16Z","receivedAt":"2010-06-07T06:37:16Z","isPatch":false,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Jay Soffian wrote:\n> \n> Git is inconsistent.\n[...]\n> $ git branch --set-upstream=origin/master\n> $ git branch --set-upstream origin/master\n\nDoesn't this just make it *more* confusing?\n\nEither we document this, and the user will be left wondering why we\nhave two almost identical (and by the conventions of many other\nprograms, including git-send-email, *equivalent*) syntaxes doing,\nwell, something not quite entirely unlike the same.\n\nOr we don't, and the user will eventually typo it and wonder WTF he\njust did wrong.\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"143143","messageId":"AANLkTim6JrB1JmwQYThSiVqubhb7Uy6HrZcQXbHNZEsl@mail.gmail.com","threadId":"24025","inReplyTo":"201006070837.16713.trast@student.ethz.ch","subject":"Re: branch --set-upstream considered harmful","fromName":"Jay Soffian","fromEmail":"jaysoffian@gmail.com","sentAt":"2010-06-07T07:37:52Z","receivedAt":"2010-06-07T07:37:52Z","isPatch":false,"sender":{"key":"jaysoffian@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155970?v=4"},"body":"On Mon, Jun 7, 2010 at 2:37 AM, Thomas Rast <trast@student.ethz.ch> wrote:\n> Jay Soffian wrote:\n>>\n>> Git is inconsistent.\n> [...]\n>> $ git branch --set-upstream=origin/master\n>> $ git branch --set-upstream origin/master\n>\n> Doesn't this just make it *more* confusing?\n>\n> Either we document this, and the user will be left wondering why we\n> have two almost identical (and by the conventions of many other\n> programs, including git-send-email, *equivalent*) syntaxes doing,\n> well, something not quite entirely unlike the same.\n>\n> Or we don't, and the user will eventually typo it and wonder WTF he\n> just did wrong.\n\nPlease take a step back and see my original message. The thing that\nmotivated this is that the existing invocation is, I claim,\nbass-ackwards. I was merely looking for a backwards compatible\nsolution that doesn't introduce yet another argument. But, maybe\nset-upstream hasn't been around so long that breaking it (i.e., making\nit an option that requires an argument) wouldn't be a bad idea.\n\nEnough talk, I'll send up a patch when I get some more time.\n\nj.\n"},{"id":"143149","messageId":"4C0CB166.9080407@drmicha.warpmail.net","threadId":"24025","inReplyTo":"AANLkTiln_xxnF-e33YA7kkfbBBcBMd40xag8JTW0eqws@mail.gmail.com","subject":"Re: branch --set-upstream considered harmful","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2010-06-07T08:44:22Z","receivedAt":"2010-06-07T08:44:22Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Jay Soffian venit, vidit, dixit 06.06.2010 21:21:\n> Say I have an existing branch and it doesn't have a tracking config.\n> (My local users often just do \"checkout -b topic\" instead of \"checkout\n> -b topic origin/master\".)\n> \n> I would naively expect this to work, while on that branch:\n> \n>   (topic)$ git branch --set-upstream origin/master\n> \n> But, um no:\n> \n>   (topic)$ git branch --set-upstream origin/master\n>   Branch origin/master set up to track local branch topic.\n> \n> Doh!\n> \n> Well, maybe this works:\n> \n>   (topic)$ git branch --set-upstream origin/master topic\n>   Branch origin/master set up to track local branch topic.\n> \n> Doh!^2\n> \n> Well, maybe we can say \"HEAD\" since that seems to mean \"the current\n> branch\" everywhere else in gitland:\n> \n>   (topic)$ git branch --set-upstream HEAD origin/master\n>   Branch HEAD set up to track remote branch master from origin.\n> \n> (Aside, being able to create a branch named HEAD is surely a bug, right?)\n> \n> Finally after exhausting all other possibilities (or finally making\n> sense of --set-upstream in the man page), we realize:\n> \n>   (topic)$ git branch --set-upstream topic origin/master\n>   Branch topic set up to track remote branch master from origin.\n> \n> Trying to make myself feel better, I realize that this works:\n> \n>   (topic)$ git branch topic --set-upstream origin/master\n> \n> So here's how I'm thinking about fixing it, but maybe I'm just making\n> it even more confusing. What say you:\n> \n>   (topic)$ git branch --set-upstream=origin/master\n>   Branch topic set up to track remote branch master from origin.\n> \n> --track would be similarly enhanced, which allows a little more\n> flexibility in creating a branch thusly:\n> \n>   $ git branch --track=origin/master topic\n> \n> Which creates topic, starting from HEAD, but tracking origin/master.\n> (And I'd do the same for checkout's --track option.)\n> \n> I recognize that having both positional and non-positional forms of\n> --track/--set-upstream  may be confusing, but I think it's less\n> confusing than set-upstream's current semantics, I'm loathe to\n> introduce yet another option, and I don't want to break backward\n> compatibility.\n> \n> Flames?\n\nI'm sorry, but you're completely right. I created a tracking branch\nconfig *for* a remote branch myself, and created one for the HEAD branch\nbefore looking up the man page and wondering about the braindead\nnon-semantic way it works. We have that braindeadness in other places as\nwell, e.g. \"git rebase branchname\" which does not rebase \"branchname\" at\nall (but the current branch).\n\nOk, you want flame? I'll give you flame: This is not going to change. We\nhave a \"naturally grown\" ui, and we don't do any changes to make it\nconceptually consistent unless it does not change any existing\nbehaviour. [I'm exaggerating, of course, but you wanted flame, didn't you? ]\n\nI like your --set-upstream= solution, by the way. Maybe people find it\nless confusing if there's an \"--upstream=upstream\" long option (no\n\"set\") and a \"--set-upstream\" subcommand. You know we have subcommands\nas options as well as arguments:\n\nbranch --set-upstream\nconfig --get etc.\nremote add etc.\nnoted edit etc.\nsvn init etc.\nsubmodule add etc.\n\nSpeaking of consistency :|\n\nMichael\n"}]}