Re: Improving the git remote command
On Tue, Aug 26, 2014 at 01:33:12PM -0400, Jeff King wrote: On Tue, Aug 26, 2014 at 10:24:35AM -0700, Junio C Hamano wrote: Jeff King p...@peff.net writes: ... But we are left with three options: 1. Add git remote list with verbose output. This is bad because it differs gratuitously from git remote. 2. Add git remote list with non-verbose output. This is good because it means git remote is just a shortcut for git remote list, which is consistent with other parts of git. But it is potentially bad if -v is a better output format. 3. Add git remote list with verbose output, and tweak git remote to match. This is bad because it breaks backwards compatibility. The proposal is for (1). I think we agree that (3) is out. The question is whether (1) or (2) is the least bad. I would imagine that those who want list of remotes programatically would read from git config output and it would be with less friction to change the output from git remote, a command that is solely to cater to end-user humans, to suit people's needs, so I am not sure if (3) is immediately out. Yeah, I touched on that earlier. I would personally consider git remote to be a porcelain, and git config to be the appropriate plumbing for accessing those values. However, it's a little tricky to robustly get the list of remotes with git config. So I would not be surprised if scripts have used git remote to do the same thing (I know for a fact that some internal scripts at GitHub did this, though I recently cleaned them up so I do not have a vested interest either way at this point). That does not mean those scripts are right and we cannot change things, but it may be a matter of practicality. We have some internal scripts at Disney Animation that rely on git remote output so I would vote for #3 personally as well. I know that git config is porcelain, and I can get remote.(.*).url, but that's not obvious and I highly doubt that anyone does that. What if we said that git remote list --porcelain == git remote and then just leave git remote output as-is so that we don't have to have a flag day when we break people's scripts? Those that want verbose output can use git remote list. Having said that, my preference is 0. Do nothing, but document the default to listing better if needed. and then 2. above, and then 1. Yeah, I'd agree with that. Ditto. -- David -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Improving the git remote command
David Aguilar dav...@gmail.com writes: We have some internal scripts at Disney Animation that rely on git remote output so I would vote for #3 personally as well. I take it that you mean you would vote _against_ #3 which will break the expectation. I know that git config is porcelain, and I can get remote.(.*).url, but that's not obvious and I highly doubt that anyone does that. Perhaps that is something worth fixing. What if we said that git remote list --porcelain == git remote and then just leave git remote output as-is so that we don't have to have a flag day when we break people's scripts? I suspect that it is not likely a workable solution. The commands being Porcelain by definition means that people aimed to make their output consumable by humans, and the current git remote, which may be what your script happens to use, is not by design the best representation of the information for all the script writers to want to call _good_. If we were to do git remote list, I'd imagine it would be far more useful to have --format=format specifiers option so that you can do something like git remote list --format=%(name) %(url) (%(direction)) Then scripts can explicitly ask for what they want and have less chance of getting broken (I say less because what %(specifier) stands for could be changed either to fix mistakes or by mistake). Having said that, my preference is 0. Do nothing, but document the default to listing better if needed. and then 2. above, and then 1. Yeah, I'd agree with that. Ditto. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Improving the git remote command
On Wed, 2014-08-27 at 13:35 -0700, Junio C Hamano wrote: David Aguilar dav...@gmail.com writes: We have some internal scripts at Disney Animation that rely on git remote output so I would vote for #3 personally as well. I take it that you mean you would vote _against_ #3 which will break the expectation. I know that git config is porcelain, and I can get remote.(.*).url, but that's not obvious and I highly doubt that anyone does that. Perhaps that is something worth fixing. What if we said that git remote list --porcelain == git remote and then just leave git remote output as-is so that we don't have to have a flag day when we break people's scripts? I suspect that it is not likely a workable solution. The commands being Porcelain by definition means that people aimed to make their output consumable by humans, and the current git remote, which may be what your script happens to use, is not by design the best representation of the information for all the script writers to want to call _good_. If we were to do git remote list, I'd imagine it would be far more useful to have --format=format specifiers option so that you can do something like git remote list --format=%(name) %(url) (%(direction)) Then scripts can explicitly ask for what they want and have less chance of getting broken (I say less because what %(specifier) stands for could be changed either to fix mistakes or by mistake). Having said that, my preference is 0. Do nothing, but document the default to listing better if needed. and then 2. above, and then 1. Yeah, I'd agree with that. Personally, I have always disliked that git remote only shows remote names, which is almost entirely useless to me as a human. Obviously it is easiest way to actually get the remote names out. I would much prefer changing the output so that git remote shows all the output.. But yes, this does potentially break expected output from a git command that might be used by scripts. I end up typing git remote and forgetting the -v a lot of the time, so I have to re-run the command. It has also confused many new people I've had to teach git. Regards, Jake
Re: Improving the git remote command
I often write `git remote list` before finaly using `git remote -v` but it isn't intuitive. I am proposing to add `git remote list` as a shortcut for `git remote -v` I suffer from the same problem. I think your proposal is a logical and nice idea. Philippe -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Improving the git remote command
On Tue, Aug 26, 2014 at 11:29:32AM +0200, Rémy Hubscher wrote: I'd like to add a list parameter to the `git remote` command. We already have: - `git remote add` - `git remote rename` - `git remote delete` I often write `git remote list` before finaly using `git remote -v` but it isn't intuitive. Right now the list operation is done by giving no arguments at all. This is a bit unlike other parts of git, which would usually define git remote list and then say that if no command is given, list is the default. But... I am proposing to add `git remote list` as a shortcut for `git remote -v` This is somewhat different. I would have expected git remote list to do the same thing as git remote (i.e., list without -v). I guess it does not have to, though. Perhaps -v should have been the default all along. I do not use git remote myself, so I don't know if -v is what most people use. But changing the output of git remote now is probably a bad thing (I expect some people may depend on parsing it to get the list of remotes; they should probably use the git-config plumbing to do the same thing, but it's actually rather tricky to do it that way). -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Improving the git remote command
Perhaps -v should have been the default all along. I do not use git remote myself, so I don't know if -v is what most people use. But changing the output of git remote now is probably a bad thing (I expect some people may depend on parsing it to get the list of remotes; they should probably use the git-config plumbing to do the same thing, but it's actually rather tricky to do it that way). Just to be clear, the proposal is not about changing the output of git remote. Anyway, it got me curious about other git commands reguarding list, and I was very surprised because I couldn't find another one. I mean git remote actually behaves like git branch and git tag. I have no clue why I expect list to work with git remote. It's probably because git branch and git tag expect a name, and there list can only be expressed by no name or with some flags. On the other hand, git remote expects a subcommand (add, delete, etc) and there what logically maps to list is the subcommand list, no name being more expected to produce a list of the subcommands. Philippe -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Improving the git remote command
On Tue, Aug 26, 2014 at 06:19:20PM +0200, Philippe Vaucher wrote: Perhaps -v should have been the default all along. I do not use git remote myself, so I don't know if -v is what most people use. But changing the output of git remote now is probably a bad thing (I expect some people may depend on parsing it to get the list of remotes; they should probably use the git-config plumbing to do the same thing, but it's actually rather tricky to do it that way). Just to be clear, the proposal is not about changing the output of git remote. I know. But we are left with three options: 1. Add git remote list with verbose output. This is bad because it differs gratuitously from git remote. 2. Add git remote list with non-verbose output. This is good because it means git remote is just a shortcut for git remote list, which is consistent with other parts of git. But it is potentially bad if -v is a better output format. 3. Add git remote list with verbose output, and tweak git remote to match. This is bad because it breaks backwards compatibility. The proposal is for (1). I think we agree that (3) is out. The question is whether (1) or (2) is the least bad. Anyway, it got me curious about other git commands reguarding list, and I was very surprised because I couldn't find another one. I mean git remote actually behaves like git branch and git tag. I have no clue why I expect list to work with git remote. Branch and tag take --list. Remote is the odd one out in that its subcommands do not have dashes. git-stash also takes commands without dashes (and has a list command), but its default mode is to create a stash, not to list. It's probably because git branch and git tag expect a name, and there list can only be expressed by no name or with some flags. On the other hand, git remote expects a subcommand (add, delete, etc) and there what logically maps to list is the subcommand list, no name being more expected to produce a list of the subcommands. Yeah. Branch and tag need dashed subcommands because otherwise it is ambiguous with creating tag called list, functionality that existed before --list was added. Git-remote was defined with subcommands from day one, so it can get away with it. Git-stash is sort of in the category as git-remote there, except that save can actually take an argument. So to provide it you can't say git stash foobar, but instead have to say git stash save foobar (it actually used to allow the former, but you can imagine the annoyance when you typo git stash lsit). -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Improving the git remote command
Jeff King p...@peff.net writes: ... But we are left with three options: 1. Add git remote list with verbose output. This is bad because it differs gratuitously from git remote. 2. Add git remote list with non-verbose output. This is good because it means git remote is just a shortcut for git remote list, which is consistent with other parts of git. But it is potentially bad if -v is a better output format. 3. Add git remote list with verbose output, and tweak git remote to match. This is bad because it breaks backwards compatibility. The proposal is for (1). I think we agree that (3) is out. The question is whether (1) or (2) is the least bad. I would imagine that those who want list of remotes programatically would read from git config output and it would be with less friction to change the output from git remote, a command that is solely to cater to end-user humans, to suit people's needs, so I am not sure if (3) is immediately out. Having said that, my preference is 0. Do nothing, but document the default to listing better if needed. and then 2. above, and then 1. Yeah. Branch and tag need dashed subcommands because otherwise it is ambiguous with creating tag called list, functionality that existed before --list was added. Git-remote was defined with subcommands from day one, so it can get away with it. Git-stash is sort of in the category as git-remote there, except that save can actually take an argument. So to provide it you can't say git stash foobar, but instead have to say git stash save foobar (it actually used to allow the former, but you can imagine the annoyance when you typo git stash lsit). Yeah, and there also is this one: http://thread.gmane.org/gmane.comp.version-control.git/231376/focus=231478 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Improving the git remote command
On Tue, Aug 26, 2014 at 10:24:35AM -0700, Junio C Hamano wrote: Jeff King p...@peff.net writes: ... But we are left with three options: 1. Add git remote list with verbose output. This is bad because it differs gratuitously from git remote. 2. Add git remote list with non-verbose output. This is good because it means git remote is just a shortcut for git remote list, which is consistent with other parts of git. But it is potentially bad if -v is a better output format. 3. Add git remote list with verbose output, and tweak git remote to match. This is bad because it breaks backwards compatibility. The proposal is for (1). I think we agree that (3) is out. The question is whether (1) or (2) is the least bad. I would imagine that those who want list of remotes programatically would read from git config output and it would be with less friction to change the output from git remote, a command that is solely to cater to end-user humans, to suit people's needs, so I am not sure if (3) is immediately out. Yeah, I touched on that earlier. I would personally consider git remote to be a porcelain, and git config to be the appropriate plumbing for accessing those values. However, it's a little tricky to robustly get the list of remotes with git config. So I would not be surprised if scripts have used git remote to do the same thing (I know for a fact that some internal scripts at GitHub did this, though I recently cleaned them up so I do not have a vested interest either way at this point). That does not mean those scripts are right and we cannot change things, but it may be a matter of practicality. Having said that, my preference is 0. Do nothing, but document the default to listing better if needed. and then 2. above, and then 1. Yeah, I'd agree with that. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
