{"thread":{"id":"37414","subject":"Improving the git remote command","startedAt":"2014-08-26T09:29:32Z","lastAt":"2014-08-27T21:22:40Z","messageCount":10,"participants":["Rémy Hubscher","Philippe Vaucher","Jeff King","Junio C Hamano","David Aguilar","Keller, Jacob E"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"248283","messageId":"53FC537C.4080206@gmail.com","threadId":"37414","inReplyTo":null,"subject":"Improving the git remote command","fromName":"Rémy Hubscher","fromEmail":"hubscher.remy@gmail.com","sentAt":"2014-08-26T09:29:32Z","receivedAt":"2014-08-26T09:29:32Z","isPatch":false,"sender":{"key":"hubscher.remy@gmail.com","avatar":null},"body":"Hi,\n\nI'd like to add a list parameter to the `git remote` command.\n\nWe already have:\n \n - `git remote add`\n - `git remote rename`\n - `git remote delete`\n\nI often write `git remote list` before finaly using `git remote -v` but\nit isn't intuitive.\n\nI am proposing to add `git remote list` as a shortcut for `git remote -v`\n\nWhat do you think?\n\nRémy\n"},{"id":"248284","messageId":"CAGK7Mr6s3UFDUD-6_yi2aK7PRF08YK2Jq=NBR_CtN7YPzP_oPA@mail.gmail.com","threadId":"37414","inReplyTo":"53FC537C.4080206@gmail.com","subject":"Re: Improving the git remote command","fromName":"Philippe Vaucher","fromEmail":"philippe.vaucher@gmail.com","sentAt":"2014-08-26T10:05:54Z","receivedAt":"2014-08-26T10:05:54Z","isPatch":false,"sender":{"key":"philippe.vaucher@gmail.com","avatar":null},"body":"> I often write `git remote list` before finaly using `git remote -v` but\n> it isn't intuitive.\n>\n> I am proposing to add `git remote list` as a shortcut for `git remote -v`\n\nI suffer from the same problem. I think your proposal is a logical and\nnice idea.\n\nPhilippe\n"},{"id":"248299","messageId":"20140826124027.GE29180@peff.net","threadId":"37414","inReplyTo":"53FC537C.4080206@gmail.com","subject":"Re: Improving the git remote command","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2014-08-26T12:40:27Z","receivedAt":"2014-08-26T12:40:27Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Aug 26, 2014 at 11:29:32AM +0200, Rémy Hubscher wrote:\n\n> I'd like to add a list parameter to the `git remote` command.\n> \n> We already have:\n> \n> - `git remote add`\n> - `git remote rename`\n> - `git remote delete`\n> \n> I often write `git remote list` before finaly using `git remote -v` but\n> it isn't intuitive.\n\nRight now the list operation is done by giving no arguments at all. This\nis a bit unlike other parts of git, which would usually define \"git\nremote list\" and then say that if no command is given, \"list\" is the\ndefault.\n\nBut...\n\n> I am proposing to add `git remote list` as a shortcut for `git remote -v`\n\nThis is somewhat different. I would have expected \"git remote list\" to\ndo the same thing as \"git remote\" (i.e., list without \"-v\"). I guess it\ndoes not have to, though.\n\nPerhaps \"-v\" should have been the default all along. I do not use \"git\nremote\" myself, so I don't know if \"-v\" is what most people use. But\nchanging the output of \"git remote\" now is probably a bad thing (I\nexpect some people may depend on parsing it to get the list of remotes;\nthey should probably use the git-config plumbing to do the same thing,\nbut it's actually rather tricky to do it that way).\n\n-Peff\n"},{"id":"248317","messageId":"CAGK7Mr7BPvV6oO_t4x_1m9sDtWBgPWUqDq+3kZx6rVYAhY+wqA@mail.gmail.com","threadId":"37414","inReplyTo":"20140826124027.GE29180@peff.net","subject":"Re: Improving the git remote command","fromName":"Philippe Vaucher","fromEmail":"philippe.vaucher@gmail.com","sentAt":"2014-08-26T16:19:20Z","receivedAt":"2014-08-26T16:19:20Z","isPatch":false,"sender":{"key":"philippe.vaucher@gmail.com","avatar":null},"body":"> Perhaps \"-v\" should have been the default all along. I do not use \"git\n> remote\" myself, so I don't know if \"-v\" is what most people use. But\n> changing the output of \"git remote\" now is probably a bad thing (I\n> expect some people may depend on parsing it to get the list of remotes;\n> they should probably use the git-config plumbing to do the same thing,\n> but it's actually rather tricky to do it that way).\n\nJust to be clear, the proposal is not about changing the output of \"git remote\".\n\nAnyway, it got me curious about other git commands reguarding \"list\",\nand I was very surprised because I couldn't find another one. I mean\n\"git remote\" actually behaves like \"git branch\" and \"git tag\". I have\nno clue why I expect \"list\" to work with \"git remote\".\n\nIt's probably because \"git branch\" and \"git tag\" expect a name, and\nthere \"list\" can only be expressed by \"no name\" or with some flags. On\nthe other hand, \"git remote\" expects a subcommand (add, delete, etc)\nand there what logically maps to \"list\" is the subcommand \"list\", \"no\nname\" being more expected to produce a list of the subcommands.\n\nPhilippe\n"},{"id":"248318","messageId":"20140826163741.GA14983@peff.net","threadId":"37414","inReplyTo":"CAGK7Mr7BPvV6oO_t4x_1m9sDtWBgPWUqDq+3kZx6rVYAhY+wqA@mail.gmail.com","subject":"Re: Improving the git remote command","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2014-08-26T16:37:41Z","receivedAt":"2014-08-26T16:37:41Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Aug 26, 2014 at 06:19:20PM +0200, Philippe Vaucher wrote:\n\n> > Perhaps \"-v\" should have been the default all along. I do not use \"git\n> > remote\" myself, so I don't know if \"-v\" is what most people use. But\n> > changing the output of \"git remote\" now is probably a bad thing (I\n> > expect some people may depend on parsing it to get the list of remotes;\n> > they should probably use the git-config plumbing to do the same thing,\n> > but it's actually rather tricky to do it that way).\n> \n> Just to be clear, the proposal is not about changing the output of\n> \"git remote\".\n\nI know. But we are left with three options:\n\n 1. Add \"git remote list\" with verbose output. This is bad because it\n differs gratuitously from \"git remote\".\n\n 2. Add \"git remote list\" with non-verbose output. This is good because\n it means \"git remote\" is just a shortcut for \"git remote list\",\n which is consistent with other parts of git. But it is potentially\n bad if \"-v\" is a better output format.\n\n 3. Add \"git remote list\" with verbose output, and tweak \"git remote\"\n to match. This is bad because it breaks backwards compatibility.\n\nThe proposal is for (1). I think we agree that (3) is out. The question\nis whether (1) or (2) is the least bad.\n\n> Anyway, it got me curious about other git commands reguarding \"list\",\n> and I was very surprised because I couldn't find another one. I mean\n> \"git remote\" actually behaves like \"git branch\" and \"git tag\". I have\n> no clue why I expect \"list\" to work with \"git remote\".\n\nBranch and tag take \"--list\". Remote is the odd one out in that its\nsubcommands do not have dashes. git-stash also takes commands without\ndashes (and has a list command), but its default mode is to create a\nstash, not to list.\n\n> It's probably because \"git branch\" and \"git tag\" expect a name, and\n> there \"list\" can only be expressed by \"no name\" or with some flags. On\n> the other hand, \"git remote\" expects a subcommand (add, delete, etc)\n> and there what logically maps to \"list\" is the subcommand \"list\", \"no\n> name\" being more expected to produce a list of the subcommands.\n\nYeah. Branch and tag need dashed subcommands because otherwise it is\nambiguous with creating tag called \"list\", functionality that existed\nbefore \"--list\" was added. Git-remote was defined with subcommands from\nday one, so it can get away with it. Git-stash is sort of in the\ncategory as git-remote there, except that \"save\" can actually take an\nargument. So to provide it you can't say \"git stash foobar\", but instead\nhave to say \"git stash save foobar\" (it actually used to allow the\nformer, but you can imagine the annoyance when you typo \"git stash\nlsit\").\n\n-Peff\n"},{"id":"248324","messageId":"xmqq7g1vjh9o.fsf@gitster.dls.corp.google.com","threadId":"37414","inReplyTo":"20140826163741.GA14983@peff.net","subject":"Re: Improving the git remote command","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-08-26T17:24:35Z","receivedAt":"2014-08-26T17:24:35Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> ... But we are left with three options:\n>\n> 1. Add \"git remote list\" with verbose output. This is bad because it\n> differs gratuitously from \"git remote\".\n>\n> 2. Add \"git remote list\" with non-verbose output. This is good because\n> it means \"git remote\" is just a shortcut for \"git remote list\",\n> which is consistent with other parts of git. But it is potentially\n> bad if \"-v\" is a better output format.\n>\n> 3. Add \"git remote list\" with verbose output, and tweak \"git remote\"\n> to match. This is bad because it breaks backwards compatibility.\n>\n> The proposal is for (1). I think we agree that (3) is out. The question\n> is whether (1) or (2) is the least bad.\n\nI would imagine that those who want list of remotes programatically\nwould read from \"git config\" output and it would be with less\nfriction to change the output from \"git remote\", a command that is\nsolely to cater to end-user humans, to suit people's needs, so I am\nnot sure if (3) is immediately \"out\".\n\nHaving said that, my preference is \n\n 0. Do nothing, but document the \"default to listing\" better if\n needed.\n\nand then 2. above, and then 1.\n\n> Yeah. Branch and tag need dashed subcommands because otherwise it is\n> ambiguous with creating tag called \"list\", functionality that existed\n> before \"--list\" was added. Git-remote was defined with subcommands from\n> day one, so it can get away with it. Git-stash is sort of in the\n> category as git-remote there, except that \"save\" can actually take an\n> argument. So to provide it you can't say \"git stash foobar\", but instead\n> have to say \"git stash save foobar\" (it actually used to allow the\n> former, but you can imagine the annoyance when you typo \"git stash\n> lsit\").\n\nYeah, and there also is this one:\n\n http://thread.gmane.org/gmane.comp.version-control.git/231376/focus=231478\n"},{"id":"248327","messageId":"20140826173312.GB16394@peff.net","threadId":"37414","inReplyTo":"xmqq7g1vjh9o.fsf@gitster.dls.corp.google.com","subject":"Re: Improving the git remote command","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2014-08-26T17:33:12Z","receivedAt":"2014-08-26T17:33:12Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Aug 26, 2014 at 10:24:35AM -0700, Junio C Hamano wrote:\n\n> Jeff King writes:\n> \n> > ... But we are left with three options:\n> >\n> > 1. Add \"git remote list\" with verbose output. This is bad because it\n> > differs gratuitously from \"git remote\".\n> >\n> > 2. Add \"git remote list\" with non-verbose output. This is good because\n> > it means \"git remote\" is just a shortcut for \"git remote list\",\n> > which is consistent with other parts of git. But it is potentially\n> > bad if \"-v\" is a better output format.\n> >\n> > 3. Add \"git remote list\" with verbose output, and tweak \"git remote\"\n> > to match. This is bad because it breaks backwards compatibility.\n> >\n> > The proposal is for (1). I think we agree that (3) is out. The question\n> > is whether (1) or (2) is the least bad.\n> \n> I would imagine that those who want list of remotes programatically\n> would read from \"git config\" output and it would be with less\n> friction to change the output from \"git remote\", a command that is\n> solely to cater to end-user humans, to suit people's needs, so I am\n> not sure if (3) is immediately \"out\".\n\nYeah, I touched on that earlier. I would personally consider \"git\nremote\" to be a porcelain, and \"git config\" to be the appropriate\nplumbing for accessing those values. However, it's a little tricky to\nrobustly get the list of remotes with \"git config\". So I would not be\nsurprised if scripts have used \"git remote\" to do the same thing (I know\nfor a fact that some internal scripts at GitHub did this, though I\nrecently cleaned them up so I do not have a vested interest either way\nat this point).\n\nThat does not mean those scripts are right and we cannot change things,\nbut it may be a matter of practicality.\n\n> Having said that, my preference is \n> \n> 0. Do nothing, but document the \"default to listing\" better if\n> needed.\n> \n> and then 2. above, and then 1.\n\nYeah, I'd agree with that.\n\n-Peff\n"},{"id":"248410","messageId":"20140827163617.GA66615@gmail.com","threadId":"37414","inReplyTo":"20140826173312.GB16394@peff.net","subject":"Re: Improving the git remote command","fromName":"David Aguilar","fromEmail":"davvid@gmail.com","sentAt":"2014-08-27T16:36:18Z","receivedAt":"2014-08-27T16:36:18Z","isPatch":false,"sender":{"key":"davvid@gmail.com","avatar":"https://avatars.githubusercontent.com/u/13196?v=4"},"body":"On Tue, Aug 26, 2014 at 01:33:12PM -0400, Jeff King wrote:\n> On Tue, Aug 26, 2014 at 10:24:35AM -0700, Junio C Hamano wrote:\n> \n> > Jeff King writes:\n> > \n> > > ... But we are left with three options:\n> > >\n> > > 1. Add \"git remote list\" with verbose output. This is bad because it\n> > > differs gratuitously from \"git remote\".\n> > >\n> > > 2. Add \"git remote list\" with non-verbose output. This is good because\n> > > it means \"git remote\" is just a shortcut for \"git remote list\",\n> > > which is consistent with other parts of git. But it is potentially\n> > > bad if \"-v\" is a better output format.\n> > >\n> > > 3. Add \"git remote list\" with verbose output, and tweak \"git remote\"\n> > > to match. This is bad because it breaks backwards compatibility.\n> > >\n> > > The proposal is for (1). I think we agree that (3) is out. The question\n> > > is whether (1) or (2) is the least bad.\n> > \n> > I would imagine that those who want list of remotes programatically\n> > would read from \"git config\" output and it would be with less\n> > friction to change the output from \"git remote\", a command that is\n> > solely to cater to end-user humans, to suit people's needs, so I am\n> > not sure if (3) is immediately \"out\".\n> \n> Yeah, I touched on that earlier. I would personally consider \"git\n> remote\" to be a porcelain, and \"git config\" to be the appropriate\n> plumbing for accessing those values. However, it's a little tricky to\n> robustly get the list of remotes with \"git config\". So I would not be\n> surprised if scripts have used \"git remote\" to do the same thing (I know\n> for a fact that some internal scripts at GitHub did this, though I\n> recently cleaned them up so I do not have a vested interest either way\n> at this point).\n> \n> That does not mean those scripts are right and we cannot change things,\n> but it may be a matter of practicality.\n\nWe have some internal scripts at Disney Animation that rely on \"git remote\"\noutput so I would vote for #3 personally as well.\n\nI know that \"git config\" is porcelain, and I can get remote.(.*).url,\nbut that's not obvious and I highly doubt that anyone does that.\n\nWhat if we said that \"git remote list --porcelain\" == \"git remote\"\nand then just leave \"git remote\" output as-is so that we don't have to\nhave a flag day when we break people's scripts?\n\nThose that want verbose output can use \"git remote list\".\n\n> > Having said that, my preference is \n> > \n> > 0. Do nothing, but document the \"default to listing\" better if\n> > needed.\n> > \n> > and then 2. above, and then 1.\n> \n> Yeah, I'd agree with that.\n\nDitto.\n-- \nDavid\n"},{"id":"248440","messageId":"xmqqegw1d61r.fsf@gitster.dls.corp.google.com","threadId":"37414","inReplyTo":"20140827163617.GA66615@gmail.com","subject":"Re: Improving the git remote command","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-08-27T20:35:44Z","receivedAt":"2014-08-27T20:35:44Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"David Aguilar writes:\n\n> We have some internal scripts at Disney Animation that rely on \"git remote\"\n> output so I would vote for #3 personally as well.\n\nI take it that you mean you would vote _against_ #3 which will break\nthe expectation.\n\n> I know that \"git config\" is porcelain, and I can get remote.(.*).url,\n> but that's not obvious and I highly doubt that anyone does that.\n\nPerhaps that is something worth fixing.\n\n> What if we said that \"git remote list --porcelain\" == \"git remote\"\n> and then just leave \"git remote\" output as-is so that we don't have to\n> have a flag day when we break people's scripts?\n\nI suspect that it is not likely a workable solution. The commands\nbeing Porcelain by definition means that people aimed to make their\noutput consumable by humans, and the current \"git remote\", which may\nbe what your script happens to use, is not by design the best\nrepresentation of the information for all the script writers to\nwant to call _good_.\n\nIf we were to do \"git remote list\", I'd imagine it would be far more\nuseful to have --format=\"\" option so that you can\ndo something like\n\n\tgit remote list --format=\"%(name) %(url) (%(direction))\"\n\nThen scripts can explicitly ask for what they want and have less\nchance of getting broken (I say \"less\" because what %(specifier)\nstands for could be changed either to fix mistakes or by mistake).\n\n>> > Having said that, my preference is \n>> > \n>> > 0. Do nothing, but document the \"default to listing\" better if\n>> > needed.\n>> > \n>> > and then 2. above, and then 1.\n>> \n>> Yeah, I'd agree with that.\n>\n> Ditto.\n"},{"id":"248447","messageId":"1409174560.2715.15.camel@jekeller-desk1.amr.corp.intel.com","threadId":"37414","inReplyTo":"xmqqegw1d61r.fsf@gitster.dls.corp.google.com","subject":"Re: Improving the git remote command","fromName":"Keller, Jacob E","fromEmail":"jacob.e.keller@intel.com","sentAt":"2014-08-27T21:22:40Z","receivedAt":"2014-08-27T21:22:40Z","isPatch":false,"sender":{"key":"jacob.e.keller@intel.com","avatar":"https://avatars.githubusercontent.com/u/874719?v=4"},"body":"On Wed, 2014-08-27 at 13:35 -0700, Junio C Hamano wrote:\n> David Aguilar writes:\n> \n> > We have some internal scripts at Disney Animation that rely on \"git remote\"\n> > output so I would vote for #3 personally as well.\n> \n> I take it that you mean you would vote _against_ #3 which will break\n> the expectation.\n> \n> > I know that \"git config\" is porcelain, and I can get remote.(.*).url,\n> > but that's not obvious and I highly doubt that anyone does that.\n> \n> Perhaps that is something worth fixing.\n> \n> > What if we said that \"git remote list --porcelain\" == \"git remote\"\n> > and then just leave \"git remote\" output as-is so that we don't have to\n> > have a flag day when we break people's scripts?\n> \n> I suspect that it is not likely a workable solution. The commands\n> being Porcelain by definition means that people aimed to make their\n> output consumable by humans, and the current \"git remote\", which may\n> be what your script happens to use, is not by design the best\n> representation of the information for all the script writers to\n> want to call _good_.\n> \n> If we were to do \"git remote list\", I'd imagine it would be far more\n> useful to have --format=\"\" option so that you can\n> do something like\n> \n> \tgit remote list --format=\"%(name) %(url) (%(direction))\"\n> \n> Then scripts can explicitly ask for what they want and have less\n> chance of getting broken (I say \"less\" because what %(specifier)\n> stands for could be changed either to fix mistakes or by mistake).\n> \n> >> > Having said that, my preference is \n> >> > \n> >> > 0. Do nothing, but document the \"default to listing\" better if\n> >> > needed.\n> >> > \n> >> > and then 2. above, and then 1.\n> >> \n> >> Yeah, I'd agree with that.\n> >\n\nPersonally, I have always disliked that \"git remote\" only shows remote\nnames, which is almost entirely useless to me as a human. Obviously it\nis easiest way to actually get the remote names out.\n\nI would much prefer changing the output so that git remote shows all the\noutput.. But yes, this does potentially break expected output from a git\ncommand that might be used by scripts.\n\nI end up typing git remote and forgetting the -v a lot of the time, so I\nhave to re-run the command. It has also confused many new people I've\nhad to teach git.\n\nRegards,\nJake\n"}]}