From: Elijah Newren <newren@gmail.com>
To: Git Mailing List <git@vger.kernel.org>
Subject: RFC: Merge-related plans
Date: Mon, 28 May 2018 13:48:50 -0700 [thread overview]
Message-ID: <CABPp-BFQJZHfCJZ1qvhvVcMd-_sOfi0Fkm5PexEwzzN+Zw2akw@mail.gmail.com> (raw)
Hi everyone,
I have some merge-related plans (and work in progress) that I'd like
to get some feedback on in order to find what order would be best to
address things in, if there are special steps I should take while
approaching some of the bigger items, and even if folks disagree with
any of the plans.
Currently, I would like to:
A) Fix cases where directory rename detection does not work with
rebase/am due to how they call merge-recursive.
Notes: Could just wait for D & E to land before fixing.
Alternatively, email RFC to list now explaining issues and how the
fix has performance implications; poll for opinions on whether to
fix before or after D.
B) Implement a remerge-diff ability (compare a merge commit to what an
"automatic merge" would look like)[1].
Notes: Possibly for cherry-picks and reverts too. Depends on C &
E.
C) Modify/extend how path-based and mode-based conflicts are
communicated to the user.
Notes: Particularly important as a mechanism for handling
challenges[2] with implementing the remerge-diff ability. Need to
send RFC to list with ideas to get feedback.
D) Improve merge performance.
Notes: Includes 4-5 specific optimizations[5], some of which I
expect to be somewhat invasive and thus may make more sense to just
make part of the new merge strategy implemented in E. Biggest
optimization depends on F.
E) Write a new merge strategy meant to replace merge-recursive.
Notes: Suggested by Junio[3][4]. Depends on F & G.
F) Make file collision conflict types more consistent.
Notes: Specifically, make rename/rename(2to1) & rename/add
conflicts behave more like add/add[6][7]. Depends on part of G.
Would prefer H to be accepted first.
G) Improve merge-related portion of testsuite.
Notes: Intended to help test new merge strategy with more
confidence. Will include approximately a dozen edge and corner
cases where merge-recursive currently falls short. Started at [8];
see also [9].
H) Miscellaneous code cleanups irritating me while working on other
changes[10].
My current plan was to work roughly in reverse, from H to A. Some questions:
* Does any of this look objectionable?
* Should I post RFC questions on A and C earlier?
* Should I split D and G? (Current plan was to keep D together, but
split G into five short slightly inter-dependent topics)
* E is kind of big. Are there any specific things folks would like to see
with how that is handled?
Thanks,
Elijah
[1] https://bugs.chromium.org/p/git/issues/detail?id=12 [remerge-diff]
[2] https://public-inbox.org/git/CABPp-BEsTOZ-tCvG1y5a0qPB8xJLLa0obyTU===mBgXC1jXgFA@mail.gmail.com/
[remerge-diff challenges]
[3] https://public-inbox.org/git/xmqqd147kpdm.fsf@gitster.mtv.corp.google.com/
[Ideal world merge strategy]
[4] https://public-inbox.org/git/xmqqk1ydkbx0.fsf@gitster.mtv.corp.google.com/
[New strategy]
[5] Some of which are included in
https://public-inbox.org/git/20171120221944.15431-1-newren@gmail.com/
[perf improvements]
[6] https://public-inbox.org/git/CAPc5daVu8vv9RdGON8JiXEO3ycDVqQ38ySzZc-cpo+AQcAKXjA@mail.gmail.com/
[discussion of add/add conflict resolution]
[7] https://public-inbox.org/git/20180305171125.22331-1-newren@gmail.com/
[file collision consistency RFC series]
[8] https://public-inbox.org/git/20180524070439.6367-1-newren@gmail.com/
[testcase cleanup]
[9] https://public-inbox.org/git/CABPp-BFc1OLYKzS5rauOehvEugPc0oGMJp-NMEAmVMW7QR=4Eg@mail.gmail.com/
[weird corner cases]
[10] https://public-inbox.org/git/20180522004327.13085-1-newren@gmail.com/
[code cleanups]
next reply other threads:[~2018-05-28 20:48 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-28 20:48 Elijah Newren [this message]
2018-05-29 18:19 ` RFC: Merge-related plans Stefan Beller
2018-05-29 21:03 ` Elijah Newren
2018-05-29 22:12 ` Stefan Beller
2018-05-30 4:21 ` Elijah Newren
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
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CABPp-BFQJZHfCJZ1qvhvVcMd-_sOfi0Fkm5PexEwzzN+Zw2akw@mail.gmail.com \
--to=newren@gmail.com \
--cc=git@vger.kernel.org \
/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.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
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 read-only IMAP folder(s) and NNTP newsgroup(s).