Denton Liu <liu.denton@xxxxxxxxx> writes:
> On Sun, Dec 09, 2018 at 05:42:27PM +0900, Junio C Hamano wrote:
>> * dl/merge-cleanup-scissors-fix (2018-11-21) 2 commits
>> (merged to 'next' on 2018-11-21 at 217be06acb)
>> + merge: add scissors line on merge conflict
>> + t7600: clean up 'merge --squash c3 with c7' test
>>
>> The list of conflicted paths shown in the editor while concluding a
>> conflicted merge was shown above the scissors line when the
>> clean-up mode is set to "scissors", even though it was commented
>> out just like the list of updated paths and other information to
>> help the user explain the merge better.
>>
>> Will cook in 'next'.
>
> From our discussion[1], expect a reroll with the ability to do scissors
> cleanup in messages generated by git-merge. Unfortunately, it'll be a
> couple of weeks because of finals season.
OK, I'd imagine that it would be cleaner to do so as a fresh series,
instead of incremental updates on top of these two, so let's plan to
eject what we have in 'next' when it happens. Thanks for a heads-up.
>> * dl/remote-save-to-push (2018-11-13) 1 commit
>> - remote: add --save-to-push option to git remote set-url
>>
>> "git remote set-url" learned a new option that moves existing value
>> of the URL field to pushURL field of the remote before replacing
>> the URL field with a new value.
>>
>> I am personally not yet quite convinced if this is worth pursuing.
>
> Any way I could convince you otherwise?
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?
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.
Without that, I remain unconvinced.
Thanks.
[Reference]
*1* https://public-inbox.org/git/1d1b0fe85ddd89cf8172e730e8886d5b4a9ea7eb.1540627720.git.liu.denton@xxxxxxxxx/
