Re: What's cooking in git.git (Dec 2018, #01; Sun, 9)

From: Junio C Hamano <gitster@pobox.com>
Date: Dec 10, 2018, 03:21 UTC
Message-ID: <xmqqo99u2hjy.fsf@gitster-ct.c.googlers.com>
In-Reply-To: <20181209090300.GA32640@archbookpro.localdomain>

Denton Liu <liu.denton@gmail.com> writes:

Show 17 quoted lines

> 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.

Show 10 quoted lines

>> * 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@gmail.com/