Google Summer of Code '19: Add functionality to store an unresolved merge-state

[Pulkit Goyal]

On Thu, May 23, 2019 at 11:12 PM Navaneeth Suresh <navaneeths1998 at gmail.com>
wrote:

> Hello all,
>
> Thanks for the comments. I found that a commit with an unresolved state
> should be similar to a normal merge commit with some metadata about the
> files which have unresolved conflicts. This is how I thought of creating a
> commit with unresolved files:
>
> * Flag the changeset as unresolved using the extra mapping {'internal':
> 'unresolved'}. (this will change when it move under shelve)
> * Copy `.hg/merge` contents to `.hg/merge/committed`
>

We will need some kind of way here to store multiple mergestates. Also
let's not use .hg/merge directory because it's already used for storing
mergestate of ongoing merge. Let's store this is .hg/unresolved-merges/ or
something like this.

> * Write multiple alternative content for unresolved files in
> `.hg/merge/committed/unresolved/[<filename-hex>.local,
> <filename-hex>.current, <filename-hex>.remote]`
>

Same as above, let's not use .hg/merge.

> * Add PATH of conflicted files to revlog metadata
>

As discussed on IRC, I am not sure what you meant.


> * Clean the merge-state (without deleting .hg/merge/committed)
> * Commit the changes
>

Sounds like a good start. I suggest to start bootstrapping the idea in an
extension.

>
> @marmoute this is trying to answer some of your questions from your old
> reply. I would really appreciate if you let us know how you think on this.
>
> On Tue, May 21, 2019 at 12:21 AM Pulkit Goyal <7895pulkit at gmail.com>
> wrote:
>
>>
>>
>> On Mon, 20 May, 2019, 21:20 Navaneeth Suresh, <navaneeths1998 at gmail.com>
>> wrote:
>>
>>> As of now, there are two approaches to make this work but, there are
>>> things to think through it.
>>>
>>> 1. @marmoute's hg commit --unresolved
>>>
>>> This will store the merge changeset as a "normal" visible commit.
>>> However, this changeset can have children and can make them publishable. A
>>> user only wants to publish this merge changeset under certain occasions
>>> only (hg push --unresolved maybe). Making this changeset does not have
>>> children makes it easier to do that. Also, after the user has committed the
>>> merge, according to the project description the working directory should
>>> update to p1.
>>>
>>> 2. hg shelve/unshelve --unresolved
>>>
>>> This will commit changesets as shelve changesets which are "internal"
>>> hidden commits and doesn't make them publish permanently. Updating the
>>> working directory to p1 is possible with this approach. I tried to
>>> visualize the DAG by changing the phase to draft and also using --debug
>>> command. If there are developer docs related to shelve, I would like to
>>> have a look at them.
>>>
>>
>> I think we don't have developer docs. Feel free to ask on IRC a codepath
>> which is hard to understand.
>>
>>
>>> I would like to know which one works for the community so that I can
>>> reach out to clear technical bits when gets stuck. Since the coding period
>>> will be starting on May 27th, I will very much appreciate if the plan gets
>>> finalized in this week.
>>>
>>
>> I am not sure if we will have exact plans on how we want to implement
>> this functionality this week. Discussing and implementing various
>> approaches are part of the project. Having said that, it's completely fine
>> and in accordance with the project.
>>
>> Talking about the above two approaches, the base functionality behind
>> both the approaches is the same i.e. 'creating a commit with unresolved
>> state'. In case of shelve such commits are marked as internal phase and in
>> case of `commit --unresolved`, that might be marked as draft or secret.
>>
>> I suggest starting with 2) and then we can develop 1) on top of that. We
>> definitely need to discuss more about how to exchange such commits/shelves,
>> but let's forget about that for now.
>>
>> I believe the subtask of 'creating a commit with unresolved state' will
>> have it's own set of problems and implementation details which need to be
>> discussed.
>>
>>>
>>> Thanks and regards,
>>> Navaneeth
>>>
>>>
>>> On Wed, May 15, 2019 at 11:58 PM Navaneeth Suresh <
>>> navaneeths1998 at gmail.com> wrote:
>>>
>>>> On Wed, 15 May, 2019, 10:26 PM Pulkit Goyal, <7895pulkit at gmail.com>
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Wed, May 15, 2019 at 7:53 PM Martin von Zweigbergk via
>>>>> Mercurial-devel <mercurial-devel at mercurial-scm.org> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> *From: *Navaneeth Suresh <navaneeths1998 at gmail.com>
>>>>>> *Date: *Wed, May 15, 2019 at 5:13 AM
>>>>>> *To: *Pierre-Yves David
>>>>>> *Cc: *mercurial-devel
>>>>>>
>>>>>> On Tue, May 14, 2019 at 5:51 PM Pierre-Yves David <
>>>>>>> pierre-yves.david at ens-lyon.org> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 5/12/19 8:31 PM, Navaneeth Suresh wrote:
>>>>>>>> > Hello everyone,
>>>>>>>> >
>>>>>>>> > I am Navaneeth Suresh, one of the GSoC '19 students with
>>>>>>>> Mercurial. I
>>>>>>>> > wanted to discuss my project on adding functionality to store an
>>>>>>>> > unresolved merge-state[1]
>>>>>>>> > <
>>>>>>>> https://www.mercurial-scm.org/wiki/SummerOfCode/Ideas2019#Add_functionality_to_store_an_unresolved_merge-state> with
>>>>>>>>
>>>>>>>> > the community. Having gone through past mailing list archives on
>>>>>>>> similar
>>>>>>>> > issues, I got some ideas on the implementation of the project.
>>>>>>>> However,
>>>>>>>> > there can be other alternatives and I might encounter some issues
>>>>>>>> which
>>>>>>>> > I might not aware of. So, I'm sharing my idea of implementation.
>>>>>>>> >
>>>>>>>> > As said by @marmoute, we are storing only one active unresolved
>>>>>>>> > merge-state.
>>>>>>>>
>>>>>>>> Yes, the active merge state exists in .hg/merge/. It is used for
>>>>>>>> the
>>>>>>>> operation the triggered a merge (hg merge, hg rebase, etc) and will
>>>>>>>> exist until the merge is concluded or aborted.
>>>>>>>>
>>>>>>>> As far as I understand your project, is to offer a third
>>>>>>>> alternative:
>>>>>>>> delaying the merge resolution until later. Right ?
>>>>>>>>
>>>>>>>
>>>>>>> Yes. For example, if a user wants to fix an urgent bug without
>>>>>>> losing their partly done enormous conflict resolution, this project will
>>>>>>> help them to store the conflicts and resume the resolution after fixing the
>>>>>>> bug. In the current scenario, they are only allowed to either fully discard
>>>>>>> or complete the partly done resolution to perform a new commit.
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> How do you see the final user experience? What is the workflow to
>>>>>>>> delay
>>>>>>>> and later conclude/abort a merge? (note: there are some UX details
>>>>>>>> from
>>>>>>>> you later in this email, but it probably worth being explained
>>>>>>>> independently).
>>>>>>>>
>>>>>>>
>>>>>>> From the UI point of view, it appeared to me as shelving with
>>>>>>> conflicts.
>>>>>>>
>>>>>>
>>>>>> Good idea.
>>>>>>
>>>>>>
>>>>>>> I thought of introducing two commands `hg store-conflicts` and `hg
>>>>>>> restore-conflicts`.
>>>>>>>
>>>>>>
>>>>>> Or even reuse `hg shelve` and `hg unshelve`?
>>>>>>
>>>>>
>>>>> I agree. `hg shelve --unresolved`.
>>>>>
>>>>
>>>> This project also involves publishing the conflict changesets so that
>>>> other users can also help in the resolution. This will violate the default
>>>> behaviour of shelve changesets if it comes under shelve. That's why I left
>>>> that idea on shelve.
>>>>
>>>>
>>>>> (I am still in-process of writing a reply to whole proposal)
>>>>>
>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mercurial-scm.org/pipermail/mercurial-devel/attachments/20190524/583dd1e7/attachment.html>