{"thread":{"id":"26376","subject":"[1.8.0] Change branch --set-uptream to take an argument","startedAt":"2011-02-01T06:57:03Z","lastAt":"2011-02-04T08:54:02Z","messageCount":8,"participants":["Jay Soffian","Matthieu Moy","Junio C Hamano","Miles Bader","Stefan Haller"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"160157","messageId":"AANLkTinUn2SMijphe3EmPMVOOwBjPB5ffFwwqZVxQmW0@mail.gmail.com","threadId":"26376","inReplyTo":null,"subject":"[1.8.0] Change branch --set-uptream to take an argument","fromName":"Jay Soffian","fromEmail":"jaysoffian@gmail.com","sentAt":"2011-02-01T06:57:03Z","receivedAt":"2011-02-01T06:57:03Z","isPatch":false,"sender":{"key":"jaysoffian@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155970?v=4"},"body":"Proposal:\n\nCurrently it is very easy to misinvoke --set-upstream if you assume it\ntakes an argument:\n\ne.g.\n\n  (master)$ git branch --set-upstream origin/master\n  Branch origin/master set up to track local branch master.\n\nIn order to make its usage unambiguous, and to allow it to be used w/o\nspecifying the current branch, require it to take an argument like so:\n\n  (master)$ git branch --set-upstream=origin/master\n\n(I've misinvoked it so often, I've had to train myself to always\ninvoke it this way: git branch master --set-upstream origin/master)\n\nRisks:\n\nHands which have become trained to use it as it currently is, scripts, etc.\n\nMigration plan:\n\nIntroduce the new syntax to the man page and git branch for 1.7.x and\nemit a warning whenever the current syntax is used. In 1.8, break the\ncurrent syntax.\n\n(Though I'm not sure whether the options parser allows for both\n--set-upstream and --set-upstream=<arg>)\n\nj.\n"},{"id":"160161","messageId":"vpqzkqg5dsq.fsf@bauges.imag.fr","threadId":"26376","inReplyTo":"AANLkTinUn2SMijphe3EmPMVOOwBjPB5ffFwwqZVxQmW0@mail.gmail.com","subject":"Re: [1.8.0] Change branch --set-uptream to take an argument","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2011-02-01T09:01:25Z","receivedAt":"2011-02-01T09:01:25Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Jay Soffian <jaysoffian@gmail.com> writes:\n\n> Currently it is very easy to misinvoke --set-upstream if you assume it\n> takes an argument:\n\nYour proposal sounds interesting, but I'd like to see something more\nglobal: right now, some commands take a --track option and other take\na --set-upstream. In short, I'd like to see this --track deprecated\n(since it's not actually about remote-tracking ...).\n\n> (Though I'm not sure whether the options parser allows for both\n> --set-upstream and --set-upstream=<arg>)\n\nThere are already many instances of this. When <arg> is mandatory, you\ncan write either --option <arg> or --option=<arg> (like \"git log\n--grep pattern\" Vs \"git log --grep=pattern\"), and when <arg> is\noptional, you can write either --option alone, or --option=<arg> (like\n\"git diff --color-words\" and \"git diff --color-words=.\").\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"160217","messageId":"AANLkTimOLPVp0EdhTsrPcF7gtykh3o-yE7KimBSJwfY3@mail.gmail.com","threadId":"26376","inReplyTo":"vpqzkqg5dsq.fsf@bauges.imag.fr","subject":"Re: [1.8.0] Change branch --set-uptream to take an argument","fromName":"Jay Soffian","fromEmail":"jaysoffian@gmail.com","sentAt":"2011-02-01T21:14:07Z","receivedAt":"2011-02-01T21:14:07Z","isPatch":false,"sender":{"key":"jaysoffian@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155970?v=4"},"body":"On Tue, Feb 1, 2011 at 4:01 AM, Matthieu Moy\n<Matthieu.Moy@grenoble-inp.fr> wrote:\n> Jay Soffian <jaysoffian@gmail.com> writes:\n>\n>> Currently it is very easy to misinvoke --set-upstream if you assume it\n>> takes an argument:\n>\n> Your proposal sounds interesting, but I'd like to see something more\n> global: right now, some commands take a --track option and other take\n> a --set-upstream. In short, I'd like to see this --track deprecated\n> (since it's not actually about remote-tracking ...).\n\nThere are a few things at work here. --track/--no-track are used to\noverride the branch.autosetupmerge configuration and are supported by\ncheckout and branch. --set-upstream is only supported by branch, and\nis subtly different from --track.\n\nThere is also branch.autosetuprebase, for which there is no\ncommand-line option to override.\n\nThese options/configs control how branch.<name>.{merge,remote,rebase}\nare set. --track/--no-track only take effect when the branch is\ncreated. --set-upstream can be used when the branch is created, or\nafter the fact.\n\n(Aside, the names of the config params are starting to look\nsub-optimal, but it's probably not worth the pain of changing them.)\n\nI suppose a more comprehensive proposal looks like this:\n\n1. Deprecate --track and --no-track (remove from documentation and\nusage). I wonder if anyone ever uses them?\n\n2. Deprecate --set-upstream as its usage is confusing.\n\n3. Add -u <name> to both checkout and branch to specify the upstream\nbranch. It is used with checkout -b in cases where an upstream would\nnot normally be configured, either because it's not the default\naccording to branch.autosetupmerge or because the start-point is not a\nbranch. It is used with branch when creating a branch in a similar\nmanner to how it's used with checkout when creating a branch, but may\nalso be used to reset the upstream after the fact like so:\n\n   $  git branch -u <upstream> [<branch>]\n\n4. Add --pull-default={rebase,merge} to both checkout and branch used\nfor setting/unsetting branch.<name>.rebase during initial branch\ncreation, or after the fact in the case of git-branch. It is an error\nto try to set --pull-default if the upstream is not configured, either\nautomatically or via -u.\n\n>> (Though I'm not sure whether the options parser allows for both\n>> --set-upstream and --set-upstream=<arg>)\n>\n> There are already many instances of this. When <arg> is mandatory, you\n> can write either --option <arg> or --option=<arg> (like \"git log\n> --grep pattern\" Vs \"git log --grep=pattern\"), and when <arg> is\n> optional, you can write either --option alone, or --option=<arg> (like\n> \"git diff --color-words\" and \"git diff --color-words=.\").\n\nSorry. What I meant was that you'd need the ability to differentiate\nbetween \"--set-upstream=foo\" and \"--set-upstream foo\" due to\ngit-branch's existing semantics. Right now:\n\n$ git branch --set-upstream topic origin/master\n\nCreates topic from origin/master and sets topic's upstream to\norigin/master. If --set-upstream suddenly starts taking an argument,\nthat means something completely different: create a new branch named\norigin/master starting at HEAD and set its upstream to \"topic\".\n\nI think we're better off just deprecating --set-upstream and\nintroducing the more convenient -u.\n\nj.\n"},{"id":"160218","messageId":"7v7hdj1mo7.fsf@alter.siamese.dyndns.org","threadId":"26376","inReplyTo":"AANLkTinUn2SMijphe3EmPMVOOwBjPB5ffFwwqZVxQmW0@mail.gmail.com","subject":"Re: [1.8.0] Change branch --set-uptream to take an argument","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-02-01T21:15:36Z","receivedAt":"2011-02-01T21:15:36Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jay Soffian <jaysoffian@gmail.com> writes:\n\n> Proposal:\n>\n> Currently it is very easy to misinvoke --set-upstream if you assume it\n> takes an argument:\n>\n> e.g.\n>\n>   (master)$ git branch --set-upstream origin/master\n>   Branch origin/master set up to track local branch master.\n\nWith \"git branch <name>\" (or for that matter \"git branch -d <name>\"), we\nare manipulating some attribute of the branch <name> (namely, \"what does\nit point at\", \"does it exist?\") not of the current branch.  So it is\nnatural to expect that some attribute of the named branch origin/master is\nbeing changed.\n\n> In order to make its usage unambiguous, and to allow it to be used w/o\n> specifying the current branch, require it to take an argument like so:\n>\n>   (master)$ git branch --set-upstream=origin/master\n\nEven though I think I understand the issue you are trying to tackle, I\nthink your proposal seems to make things worse.  In either \"--set-upstream\nA\" or \"--set-upstream=A\", it is unclear if you are manipulating \"what\nother branch does this follow\" attribute of A or the current branch.\n\nI think it was a misdesign to allow --set-upstream without argument to\ndefault to the current branch.  Wouldn't it be simpler to just fix the\nparser so that \"--set-upstream A\" and \"--set-upstream=A\" both mean the\nsame thing?  The branch whose attribute is manipulated defaults to the\ncurrent one in either case.\n\nIOW, I don't think\n\n>   (master)$ git branch --set-upstream origin/master\n>   Branch origin/master set up to track local branch master.\n\nis a sane behaviour from day one, and is simply a bug.  Changing this\nbehaviour would merely be a bugfix, not a flag-day event that changes an\nestablished behaviour.\n\nBut that may be just me.  I don't use --set-upstream myself, and people\nmay have learned to be comfortable with the current behaviour.\n\n        If there are people who want to keep the current behaviour, please\n        speak up.  Then we can introduce the usual migration procedure to\n        first add a configuration to flip the behaviour (default off),\n        then warn if you use 0-argument --set-upstream to default to the\n        current branch without setting the configuration, and eventually\n        flip the default to always require argument to --set-upstream.\n\n> (I've misinvoked it so often, I've had to train myself to always\n> invoke it this way: git branch master --set-upstream origin/master)\n\nIf \"git branch master --set-upstream origin/master\" is accepted, we have\nanother bug in its parser to fix.  The canonical command line should\nalways be dashed-options, then refs and then pathspecs.\n"},{"id":"160219","messageId":"AANLkTi=gvVwh-H9FiGz6SQeJYwxmnnViYsDQX=RYRjb6@mail.gmail.com","threadId":"26376","inReplyTo":"7v7hdj1mo7.fsf@alter.siamese.dyndns.org","subject":"Re: [1.8.0] Change branch --set-uptream to take an argument","fromName":"Jay Soffian","fromEmail":"jaysoffian@gmail.com","sentAt":"2011-02-01T21:27:13Z","receivedAt":"2011-02-01T21:27:13Z","isPatch":false,"sender":{"key":"jaysoffian@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155970?v=4"},"body":"On Tue, Feb 1, 2011 at 4:15 PM, Junio C Hamano <gitster@pobox.com> wrote:\n> IOW, I don't think\n>\n>>   (master)$ git branch --set-upstream origin/master\n>>   Branch origin/master set up to track local branch master.\n>\n> is a sane behaviour from day one, and is simply a bug.  Changing this\n> behaviour would merely be a bugfix, not a flag-day event that changes an\n> established behaviour.\n\nOkay, our emails criss-crossed. I agree with that, but my other email\nproposes adding -u <name> with correct behavior and just deprecating\n--set-upstream. I suppose we could instead (or in addition) just fix\n--set-upstream.\n\nI guess please reply to the other email so we don't keep criss-crossing. :-)\n\nj.\n"},{"id":"160254","messageId":"buohbcn3wp5.fsf@dhlpc061.dev.necel.com","threadId":"26376","inReplyTo":"AANLkTi=gvVwh-H9FiGz6SQeJYwxmnnViYsDQX=RYRjb6@mail.gmail.com","subject":"Re: [1.8.0] Change branch --set-uptream to take an argument","fromName":"Miles Bader","fromEmail":"miles@gnu.org","sentAt":"2011-02-02T04:08:22Z","receivedAt":"2011-02-02T04:08:22Z","isPatch":false,"sender":{"key":"miles@gnu.org","avatar":"https://gravatar.com/avatar/01069b69593af7bff28e2f97afeb3644ae6fe2f5f56cb3a8cf34c5fb8c36efe5?d=mp&s=160"},"body":"Jay Soffian <jaysoffian@gmail.com> writes:\n> Okay, our emails criss-crossed. I agree with that, but my other email\n> proposes adding -u <name> with correct behavior and just deprecating\n> --set-upstream. I suppose we could instead (or in addition) just fix\n> --set-upstream.\n\nBTW, you're just talking about \"git branch\", right?\n\n['cause the way \"--set-upstream\" works with \"git push\" is perfect, and\nshouldn't be changed...]\n\n-miles\n\n-- \nSelfish, adj. Devoid of consideration for the selfishness of others.\n"},{"id":"160255","messageId":"AANLkTi=qn-Jf32iOHsaFwwcwp4_UWxcwG+t1VepO0FrC@mail.gmail.com","threadId":"26376","inReplyTo":"buohbcn3wp5.fsf@dhlpc061.dev.necel.com","subject":"Re: [1.8.0] Change branch --set-uptream to take an argument","fromName":"Jay Soffian","fromEmail":"jaysoffian@gmail.com","sentAt":"2011-02-02T04:18:31Z","receivedAt":"2011-02-02T04:18:31Z","isPatch":false,"sender":{"key":"jaysoffian@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155970?v=4"},"body":"On Tue, Feb 1, 2011 at 11:08 PM, Miles Bader <miles@gnu.org> wrote:\n> Jay Soffian <jaysoffian@gmail.com> writes:\n>> Okay, our emails criss-crossed. I agree with that, but my other email\n>> proposes adding -u <name> with correct behavior and just deprecating\n>> --set-upstream. I suppose we could instead (or in addition) just fix\n>> --set-upstream.\n>\n> BTW, you're just talking about \"git branch\", right?\n>\n> ['cause the way \"--set-upstream\" works with \"git push\" is perfect, and\n> shouldn't be changed...]\n\nI was talking about git-branch and git-checkout. I didn't realize\ngit-push even had --set-upstream. Interestingly, -u is an alias for\n--set-upstream with git-push, but not with git-branch.\n\nj.\n"},{"id":"160381","messageId":"1jw5s11.1s3ezsbcgy9c0M%lists@haller-berlin.de","threadId":"26376","inReplyTo":"AANLkTimOLPVp0EdhTsrPcF7gtykh3o-yE7KimBSJwfY3@mail.gmail.com","subject":"Re: [1.8.0] Change branch --set-uptream to take an argument","fromName":"Stefan Haller","fromEmail":"lists@haller-berlin.de","sentAt":"2011-02-04T08:54:02Z","receivedAt":"2011-02-04T08:54:02Z","isPatch":false,"sender":{"key":"lists@haller-berlin.de","avatar":null},"body":"Jay Soffian <jaysoffian@gmail.com> wrote:\n\n> 1. Deprecate --track and --no-track (remove from documentation and\n> usage). I wonder if anyone ever uses them?\n\nI use --no-track quite frequently, and I always find it unfortunate that\nI have to (sometimes I forget).  I need it when I want to create a new\nlocal branch off of master, and my local master is not up to date, but\nI'm too lazy to bring it up to date because I have some other branch\nchecked out currently; so I do\n\n  $ git fetch\n  $ git checkout -b new_branch origin/master\n\nThis will by default make origin/master the upstream branch of\nnew_branch, which is never what I want.\n\nTo avoid the problem, I would have to\n\n  $ git checkout master\n  $ git pull\n  $ git checkout -b new_branch\n\nI guess I would like a config setting of\nbranch.autosetupmerge=onlyifnamematches or some such.\n\nI realize this is probably not related to the discussion of whether or\nhow --set-upstream should be fixed; I just wanted to comment on your\nquestion.\n\n\n-- \nStefan Haller\nBerlin, Germany\nhttp://www.haller-berlin.de/\n"}]}