From: Elijah Newren <newren@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: "Git Mailing List" <git@vger.kernel.org>,
"Jonathan Nieder" <jrnieder@gmail.com>,
"Nguyễn Thái Ngọc" <pclouds@gmail.com>
Subject: Re: [RFC PATCH 4/7] merge-recursive: fix assumption that head tree being merged is HEAD
Date: Mon, 11 Jun 2018 09:15:06 -0700 [thread overview]
Message-ID: <CABPp-BFhneCqGBRT3qtS_d2eUdjgj+5PWsyWJ7XGHBD6dxunqQ@mail.gmail.com> (raw)
In-Reply-To: <CABPp-BERW3VtKxwKZ=-K6=pdVZydHRRKKGce2S=sttqfcDeRDA@mail.gmail.com>
On Tue, Jun 5, 2018 at 12:14 AM, Elijah Newren <newren@gmail.com> wrote:
> On Sun, Jun 3, 2018 at 8:19 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> Elijah Newren <newren@gmail.com> writes:
>>
>>> `git merge-recursive` does a three-way merge between user-specified trees
>>> base, head, and remote. Since the user is allowed to specify head, we can
>>> not necesarily assume that head == HEAD.
>>>
>>> We modify index_has_changes() to take an extra argument specifying the
>>> tree to compare the index to. If NULL, it will compare to HEAD. We then
>>> use this from merge-recursive to make sure we compare to the
>>> user-specified head.
>>>
>>> Signed-off-by: Elijah Newren <newren@gmail.com>
>>> ---
>>>
>>> I'm really unsure where the index_has_changes() declaration should go;
>>> I stuck it in tree.h, but is there a better spot?
>>
>> I think I saw you tried to lift an assumption that we're always
>> working on the_index in a separate patch recently. Should that
>> logic apply also to this part of the codebase? IOW, shouldn't
>> index_has_changes() take a pointer to istate (as opposed to a
>> function that uses the implicit the_index that should be named as
>> "cache_has_changes()" or something?)
>>
>> I tend to think this function as part of the larger read-cache.c
>> family whose definitions are in cache.h and accompanied by macros
>> that are protected by NO_THE_INDEX_COMPATIBILITY_MACROS so if we
>> were to move it elsewhere, I'd keep the header part as-is and
>> implementation to read-cache.c to keep it together with the family,
>> but I do not see a huge issue with the current placement, either.
>
> That's good point; the goal to lift assumptions on the_index should
> probably also apply here. I'll make the change.
> (And it was actually Duy's patch that I was reviewing, but close
> enough.) I'll take a look at moving it to read-cache.c as well.
Making it not depend on the_index will require changes to make
diff-lib.c not depend on the_index first, so this is going to have to
wait for Duy's changes mentioned at
https://public-inbox.org/git/CACsJy8Ba74iSPf4_zFxuV=_uNJgL6Z2QunOvAvi3qab-6EWi5g@mail.gmail.com/.
I'll re-roll this series on top of Duy's when it comes out.
next prev parent reply other threads:[~2018-06-11 16:15 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-03 6:58 [RFC PATCH 0/7] merge requirement: index matches head Elijah Newren
2018-06-03 6:58 ` [RFC PATCH 1/7] t6044: verify that merges expected to abort actually abort Elijah Newren
2018-06-03 6:58 ` [RFC PATCH 2/7] t6044: add a testcase for index matching head, when head doesn't match HEAD Elijah Newren
2018-06-03 6:58 ` [RFC PATCH 3/7] merge-recursive: make sure when we say we abort that we actually abort Elijah Newren
2018-06-03 6:58 ` [RFC PATCH 4/7] merge-recursive: fix assumption that head tree being merged is HEAD Elijah Newren
2018-06-03 13:52 ` Ramsay Jones
2018-06-03 23:37 ` brian m. carlson
2018-06-04 2:26 ` Ramsay Jones
2018-06-04 3:19 ` Junio C Hamano
2018-06-05 7:14 ` Elijah Newren
2018-06-11 16:15 ` Elijah Newren [this message]
2018-06-03 6:58 ` [RFC PATCH 5/7] t6044: add more testcases with staged changes before a merge is invoked Elijah Newren
2018-06-03 6:58 ` [RFC PATCH 6/7] merge-recursive: enforce rule that index matches head before merging Elijah Newren
2018-06-03 6:58 ` [RFC PATCH 7/7] merge: fix misleading pre-merge check documentation Elijah Newren
2018-06-07 5:27 ` Elijah Newren
2018-07-01 1:24 ` [PATCH v2 0/9] Fix merge issues with index not matching HEAD Elijah Newren
2018-07-01 1:24 ` [PATCH v2 1/9] read-cache.c: move index_has_changes() from merge.c Elijah Newren
2018-07-01 1:24 ` [PATCH v2 2/9] index_has_changes(): avoid assuming operating on the_index Elijah Newren
2018-07-03 19:44 ` Junio C Hamano
2018-07-01 1:24 ` [PATCH v2 3/9] t6044: verify that merges expected to abort actually abort Elijah Newren
2018-07-01 1:24 ` [PATCH v2 4/9] t6044: add a testcase for index matching head, when head doesn't match HEAD Elijah Newren
2018-07-10 20:39 ` SZEDER Gábor
2018-07-11 3:09 ` [RFC PATCH 2/7] " Elijah Newren
2018-07-01 1:24 ` [PATCH v2 5/9] merge-recursive: make sure when we say we abort that we actually abort Elijah Newren
2018-07-01 1:25 ` [PATCH v2 6/9] merge-recursive: fix assumption that head tree being merged is HEAD Elijah Newren
2018-07-03 19:57 ` Junio C Hamano
2018-07-01 1:25 ` [PATCH v2 7/9] t6044: add more testcases with staged changes before a merge is invoked Elijah Newren
2018-07-01 1:25 ` [PATCH v2 8/9] merge-recursive: enforce rule that index matches head before merging Elijah Newren
2018-07-03 20:05 ` Junio C Hamano
2018-07-01 1:25 ` [PATCH v2 9/9] merge: fix misleading pre-merge check documentation 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-BFhneCqGBRT3qtS_d2eUdjgj+5PWsyWJ7XGHBD6dxunqQ@mail.gmail.com \
--to=newren@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=jrnieder@gmail.com \
--cc=pclouds@gmail.com \
/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).