On Mon, Dec 10, 2018 at 12:21:05PM +0900, Junio C Hamano wrote: > I think v3 (which we see above) describes what it wants to do > clearly enough and implements what it wants to do cleanly. I do not > think the patch itself has much room for further improvement. > > When I re-read the final patch and all the earlier comments I made > in the thread that began at [*1*], I still do not see in what > practical workflow and usecase the users would find the feature this > change adds useful. > > For each new feature, I want a story we can sell it to the users: > "if your workflow is like this or that, you would find yourself > wanting to do this, which was (impossible|cumbersome) to do before; > with this new thing, you can". > > And the "story" is not "If you have remote.$name.url and want to > move its value to remote.$name.pushurl while setting the former to a > new value, then..." I want to know why the user gets in such a > situation in the first place. > > To be helped by the feature, the user > > (1) must first have a remote.$name.url (but not remote.$name.pushurl) > > (2) that URL must also be usable for pushing > > (3) and then has another URL that can be used for fetching > > (4) and somehow that new URL is more suitable for fetching than the > original one. > > When all of the above holds, then "set-url --save-to-push" can be > used to move the original URL that can be used for both fetching and > pushing to remote.$name.pushurl and set remote.$name.url to the new > value with a single command. But is that a sensible situation to be > in the first place? The following is the story that led to me writing the feature in the first place: I have a project that's been developed on my own machine. I want to deploy it onto a server to test, so I use SSH key forwarding and clone the project with the SSH URL onto the server. After fixing some small bugs, I'll push the changes directly from the server up. Now that the server is running, I only touch the repo on the server occasionally. I want to pull updates from the main repository without necessarily having to use SSH key forwarding because I might be forgetful and forget to start ssh-agent or I might have someone else administer the server who doesn't have key-access to the repository. However, I also don't want to get rid of my ability to push over SSH so, in this case, I'd run `git remote set-url --save-to-push origin <HTTPS_URL>`. Although it's definitely not an every day activity, I've run into the use case a few times where having this ability would definitely be useful. > > I guess it would help the readers if the documentation (or proposed > log message) were more explicit that this is to help the project > originator more than the project followers, perhaps. My working > assumption during the review discussion on this patch has been that > there are orders-of-magnitude many project followers who start from > fetching and locally tweaking without ever publishing than those who > start to pushing to a project from day one of joining, or the day > they themselves initiated the project. And for these majority > "followers", the first URL is often the one to fetch, which may not > necessarily be usable for pushing, and that URL is advertised for > the wider general public as the most suitable URL for fetching the > project's source. So to these people, neither (2) or (4) would > hold. > > But for project initiators and those joining a project with write > access from day one, the story may be a bit different. They may > start with a single URL that can be used for both fetching and > pushing, which means (2) would hold for them, unlike for the > majority of users. > > I am still not sure what a good example situation is that makes (4) > hold, though. Perhaps you originally had a R/W URL that always > require authentication, but now you want to use an anonymous R/O URL > for your fetch traffic without having to authenticate? If there is > a model situation to make all of these four hold, perhaps it can be > added somewhere to help users who would find the new feature useful > discover it. If the above makes sense to you, I can try to distill the use-case down to its essence and include it documentation for the patch. > > Without that, I remain unconvinced. > > Thanks. > > > [Reference] > > *1* https://public-inbox.org/git/1d1b0fe85ddd89cf8172e730e8886d5b4a9ea7eb.1540627720.git.liu.denton@xxxxxxxxx/
