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

[Pulkit Goyal]

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/20190520/c15c445c/attachment.html>