From: Chris Torek <chris.torek@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Philip Oakley <philipoakley@iee.email>,
"Curtin, Eric" <Eric.Curtin@dell.com>,
Konstantin Tokarev <annulen@yandex.ru>,
Christian Couder <christian.couder@gmail.com>,
"git@vger.kernel.org" <git@vger.kernel.org>,
"Geary, Niall" <Niall.Geary@dell.com>,
"rowlands, scott" <Scott.Rowlands@dell.com>,
Michael Haggerty <mhagger@alum.mit.edu>,
"Coveney, Stephen" <Stephen.Coveney@dell.com>
Subject: Re: Collaborative conflict resolution feature request
Date: Tue, 16 Jun 2020 08:56:26 -0700 [thread overview]
Message-ID: <CAPx1Gvf5R6b1NoUWHkaqLMaj6dr51hERVvuVe1X9k3NEafnBhg@mail.gmail.com> (raw)
In-Reply-To: <CAPx1GvdT6sZRtu8q1R9=fA-mE9pi1Ag-gKEzQfwbGap+KqSoSg@mail.gmail.com>
On Mon, Jun 15, 2020 at 10:32 AM Chris Torek <chris.torek@gmail.com> wrote:
> I've thought about this (some) myself in the past. It seems to me that what
> is needed is the ability to pass the complete unmerged state on.
A few further thoughts:
* Given one or more saved merges and either a clean state or an
ongoing merge, we need a tool to combine these. There are a lot of
corner cases here but in general, if merge X has file F in conflict and
merge Y has file F resolved, we can take the resolution from Y.
* Partial merges (in the work-tree copy of a file) that are not yet added
may be the trickiest. A simple heuristic would be to look for the
conflict markers and see if one work-tree copy has a resolution
where another work-tree copy has a conflict. Or, though this is
harder, use the ours/theirs copies in the saved index trees to find
actual conflicted regions and compare this to the work-tree copy
to find resolved regions.
* There is also an obvious question about what to do when combining
two different proposed resolutions where the stage-zero and/or
work-tree copies of the files don't match.
None of these preclude the basic ability to save and restore—and of
course transport, through fetch/push—the unmerged state, which I think
is the required enabling technology. The ideas above are more for
combining parallel merge efforts. If it's acceptable for dev A to merge
his/her part and pass the result to dev B, who merges theirs, and so
on, the above is not required.
Chris
next prev parent reply other threads:[~2020-06-16 15:56 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-12 14:08 Collaborative conflict resolution feature request Curtin, Eric
2020-06-13 11:33 ` Johannes Sixt
2020-06-13 12:08 ` Christian Couder
2020-06-13 12:38 ` Curtin, Eric
2020-06-13 13:14 ` Philip Oakley
2020-06-13 16:44 ` Junio C Hamano
2020-06-15 9:51 ` Sergey Organov
2020-06-15 11:04 ` Philip Oakley
2020-06-16 17:17 ` Stefan Moch
2020-06-17 18:32 ` Curtin, Eric
2020-06-17 21:17 ` Sergey Organov
2020-06-13 17:10 ` Christian Couder
2020-06-13 19:22 ` Junio C Hamano
2020-06-13 19:34 ` Junio C Hamano
2020-06-14 11:05 ` Philip Oakley
2020-06-14 13:00 ` Konstantin Tokarev
2020-06-15 9:28 ` Curtin, Eric
2020-06-15 11:31 ` Philip Oakley
2020-06-15 16:57 ` Junio C Hamano
2020-06-15 17:32 ` Chris Torek
2020-06-16 15:56 ` Chris Torek [this message]
2020-06-15 19:37 ` Philip Oakley
2020-06-17 18:30 ` Junio C Hamano
2020-06-18 8:11 ` demerphq
2020-06-18 8:53 ` Curtin, Eric
2020-06-18 9:28 ` Curtin, Eric
2020-06-18 10:14 ` demerphq
2020-06-19 9:17 ` Curtin, Eric
2020-06-20 16:09 ` Christian Couder
2020-06-21 0:20 ` Curtin, Eric
2020-06-16 9:08 ` Christian Couder
2020-06-15 12:55 ` Sergey Organov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAPx1Gvf5R6b1NoUWHkaqLMaj6dr51hERVvuVe1X9k3NEafnBhg@mail.gmail.com \
--to=chris.torek@gmail.com \
--cc=Eric.Curtin@dell.com \
--cc=Niall.Geary@dell.com \
--cc=Scott.Rowlands@dell.com \
--cc=Stephen.Coveney@dell.com \
--cc=annulen@yandex.ru \
--cc=christian.couder@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=mhagger@alum.mit.edu \
--cc=philipoakley@iee.email \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).