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

Pulkit Goyal 7895pulkit at gmail.com
Wed May 15 12:55:52 EDT 2019


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

(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/20190515/642373ad/attachment.html>


More information about the Mercurial-devel mailing list