git@vger.kernel.org mailing list mirror (one of many)
 help / Atom feed
From: Elijah Newren <newren@gmail.com>
To: Stefan Beller <sbeller@google.com>
Cc: git <git@vger.kernel.org>, Junio C Hamano <gitster@pobox.com>
Subject: Re: [PATCH 1/3] t7405: add a file/submodule conflict
Date: Tue, 10 Jul 2018 10:30:13 -0700
Message-ID: <CABPp-BE1kqjiGPqJfrsj8AiFnWg0CUZErUnDb8dAvXWkt7cDMA@mail.gmail.com> (raw)
In-Reply-To: <CAGZ79kYK4uwUeDECoabrXJesVzgFBKNejV3reJOXhMyYxUjXyw@mail.gmail.com>

On Tue, Jul 10, 2018 at 8:53 AM, Stefan Beller <sbeller@google.com> wrote:
> On Tue, Jul 10, 2018 at 8:28 AM Elijah Newren <newren@gmail.com> wrote:

>> 2) I didn't just check what was currently failing but other things
>> that should be true for this test.
>>
>> For item 2, I've had multiple cases in the past where I created a
>> minimal test, only to find that if I had more carefully checked the
>> expected results that it would have prevented a future bug.  Also, it
>> was harder in the future to figure out, because I no longer remembered
>> the context for the test setup.  So, in this test I check the contents
>> of the index, make sure that the submodule is still present, and then
>> I finally check for the thing that currently fails:
>>
>> commit B added a file called 'path'; its contents should appear
>> somewhere in the directory for the user to use when trying to resolve
>> the failed merge.  It cannot appear at 'path' (there's a submodule in
>> the way from commit A), but it should be present somewhere, and in
>> particular I'd expect it in the same directory.  So, I simply grep all
>> files in the current directory for the string (and ignore errors about
>> 'grep: path is a directory').
>>
>> Does that help?  If so, I'll submit a reroll with the changes and a
>> few extra comments.
>
> That does help; yes, I thought
> * we want to check for the file content of the file to be somewhere
>   (maybe path.file?)

Yes.  I wanted to avoid nailing down the expected pathname until the
code was in place that handled this case.  merge-recursive currently
elsewhere uses path~$BRANCH to workaround conflicting paths, but I had
a (half-baked-so-far) idea for changing some of the path-conflict
stuff which would involve different names.  So, I just left it
undecided until implemented.

> * equally we'd want to have the submodule somewhere; you seem
>   to expect it at path (we could have moved it to path.sub or path.git,
>   but that involves extra work as we have to update the .gitmodules
>   file to have the correct path <->name mapping)

Yes I wanted it at path for a specific reason: git can detect renames
of files, and now of directories, but not of submodules, so it seems
more important to keep the submodule where it is when possible.
(merge_file_1() has code running counter to this, but that pre-dates
submodules and should be updated, IMO.)

> * good call with the index, I skimmed over the ls-files calls not thinking
>   what they'd check.
>
> So for now only the "file content is missing" part is failing the test,
> whereas the rest is successful.
>
> Thanks for the explanation!
> Stefan

:-)

  reply index

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-07 20:44 [PATCH 0/3] Add testcases showing suboptimal submodule/path conflict handling Elijah Newren
2018-07-07 20:44 ` [PATCH 1/3] t7405: add a file/submodule conflict Elijah Newren
2018-07-09 21:11   ` Stefan Beller
2018-07-10 15:28     ` Elijah Newren
2018-07-10 15:53       ` Stefan Beller
2018-07-10 17:30         ` Elijah Newren [this message]
2018-07-07 20:44 ` [PATCH 2/3] t7405: add a directory/submodule conflict Elijah Newren
2018-07-07 20:44 ` [PATCH 3/3] t7405: verify 'merge --abort' works after submodule/path conflicts Elijah Newren
2018-07-11  3:56 ` [PATCH v2 0/3] Add testcases showing suboptimal submodule/path conflict handling Elijah Newren
2018-07-11  3:56   ` [PATCH v2 1/3] t7405: add a file/submodule conflict Elijah Newren
2018-07-11  3:56   ` [PATCH v2 2/3] t7405: add a directory/submodule conflict Elijah Newren
2018-07-11  3:56   ` [PATCH v2 3/3] t7405: verify 'merge --abort' works after submodule/path conflicts Elijah Newren

Reply instructions:

You may reply publically 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-BE1kqjiGPqJfrsj8AiFnWg0CUZErUnDb8dAvXWkt7cDMA@mail.gmail.com \
    --to=newren@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=sbeller@google.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

git@vger.kernel.org mailing list mirror (one of many)

Archives are clonable:
	git clone --mirror https://public-inbox.org/git
	git clone --mirror http://ou63pmih66umazou.onion/git
	git clone --mirror http://czquwvybam4bgbro.onion/git
	git clone --mirror http://hjrcffqmbrq6wope.onion/git

Newsgroups are available over NNTP:
	nntp://news.public-inbox.org/inbox.comp.version-control.git
	nntp://ou63pmih66umazou.onion/inbox.comp.version-control.git
	nntp://czquwvybam4bgbro.onion/inbox.comp.version-control.git
	nntp://hjrcffqmbrq6wope.onion/inbox.comp.version-control.git
	nntp://news.gmane.org/gmane.comp.version-control.git

 note: .onion URLs require Tor: https://www.torproject.org/
       or Tor2web: https://www.tor2web.org/

AGPL code for this site: git clone https://public-inbox.org/ public-inbox