From: Elijah Newren <newren@gmail.com>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: "Christian Couder" <christian.couder@gmail.com>,
"Git Mailing List" <git@vger.kernel.org>,
"Junio C Hamano" <gitster@pobox.com>,
"Christian Couder" <chriscool@tuxfamily.org>,
"Ævar Arnfjörð Bjarmason" <avarab@gmail.com>,
"Taylor Blau" <me@ttaylorr.com>
Subject: Re: [RFC PATCH 0/2] Introduce new merge-tree-ort command
Date: Tue, 11 Jan 2022 13:15:33 -0800 [thread overview]
Message-ID: <CABPp-BEQ5BBEgB21hUNBuioOfMry_x2nKOLgY8=v2w8eGXrsyw@mail.gmail.com> (raw)
In-Reply-To: <CABPp-BHJvFx0fxobYZ2vauK=KfCLF_7So8xABLjqr9rx4SVy-w@mail.gmail.com>
On Mon, Jan 10, 2022 at 9:59 AM Elijah Newren <newren@gmail.com> wrote:
>
> On Mon, Jan 10, 2022 at 5:49 AM Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
> >
...
> >, therefore it expects the resolved conflicts to
> > be in _files_. I don't think that there is a way to reasonably handle
> > symlink target conflicts or directory/file/symlink conflicts, but there
> > might be.
>
> You really need (mode,oid) pairs to be provided by the user. That
> fixes the executable issue I mentioned above, and makes it clear how
> to handle symlinks and file/symlink conflicts.
>
> directory/file are still handled by providing individual files, but
> ordering traversal becomes really tricky. The directory/file case
> might even require the pre_resolved_conflicts to be pulled out of that
> loop somehow. It'd take some investigative work, or some deep
> thought, or both.
I think I came up with a solution to this during my run yesterday,
though I haven't tried or tested it. Instead of modifying the loop
over plist.items, you instead add a preliminary loop over
pre_resolved_conflicts that modifies opt->priv->paths (and add this
preliminary loop just before the items from opt->priv->paths are added
to plist.items). In that preliminary loop, you need to make sure that
(a) any files in pre_resolved_conflicts corresponding to existing
_files_ in opt->priv->path result in updating that item's clean &
is_null & mode & oid state, (b) any files in pre_resolved_conflicts
that correspond to existing _directories_ in opt->priv->path need the
value to be expanded to be a conflict_info instead of just a
merged_info, you need to set the df_conflict bit, and don't update the
merge_info fields but do update the extended conflict_info ones, (c)
any new files in pre_resolved_conflicts result in new entries
opt->priv->paths, (d) any leading directories of new files in
pre_resolved_conflicts are appropriately handled, meaning: (d1) new
opt->priv->paths are created if the directory path wasn't in
opt->priv->paths before, (d2) a tweak to df_conflict for the directory
item if it previously existed in opt->priv->paths but only as a file
(possibly also necessitating expanding from a merged_info to a
conflict_info), (d3) no-op if the directory already existed in
opt->priv->paths and was just a directory (and in this case, you can
stop walking the parent directories to the toplevel).
Then, after this preliminary loop that modifies opt->priv->paths, the
rest can just proceed as-is.
That should handle new files, new directories, and all directory/file
conflicts. Yeah, it's a bunch to look at, but directory/file
conflicts are always a bear.
next prev parent reply other threads:[~2022-01-11 21:15 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-05 16:33 [RFC PATCH 0/2] Introduce new merge-tree-ort command Christian Couder
2022-01-05 16:33 ` [RFC PATCH 1/2] merge-ort: add " Christian Couder
2022-01-05 17:08 ` Elijah Newren
2022-01-05 16:33 ` [RFC PATCH 2/2] merge-ort: add t/t4310-merge-tree-ort.sh Christian Couder
2022-01-05 17:29 ` Elijah Newren
2022-01-05 16:53 ` [RFC PATCH 0/2] Introduce new merge-tree-ort command Elijah Newren
2022-01-05 17:32 ` Elijah Newren
2022-01-07 17:58 ` Christian Couder
2022-01-07 19:06 ` Elijah Newren
2022-01-10 13:49 ` Johannes Schindelin
2022-01-10 17:56 ` Junio C Hamano
2022-01-11 13:47 ` Johannes Schindelin
2022-01-11 17:00 ` Ævar Arnfjörð Bjarmason
2022-01-11 22:25 ` Elijah Newren
2022-01-12 18:06 ` Junio C Hamano
2022-01-12 20:06 ` Elijah Newren
2022-01-13 6:08 ` Junio C Hamano
2022-01-13 8:01 ` Elijah Newren
2022-01-13 9:26 ` Ævar Arnfjörð Bjarmason
2022-01-12 17:54 ` Junio C Hamano
2022-01-13 9:22 ` Ævar Arnfjörð Bjarmason
2022-01-10 17:59 ` Elijah Newren
2022-01-11 21:15 ` Elijah Newren [this message]
2022-02-22 13:08 ` Johannes Schindelin
2022-01-11 22:30 ` Johannes Schindelin
2022-01-12 0:41 ` Elijah Newren
2022-02-22 12:44 ` Johannes Schindelin
2022-01-07 19:54 ` Johannes Schindelin
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='CABPp-BEQ5BBEgB21hUNBuioOfMry_x2nKOLgY8=v2w8eGXrsyw@mail.gmail.com' \
--to=newren@gmail.com \
--cc=Johannes.Schindelin@gmx.de \
--cc=avarab@gmail.com \
--cc=chriscool@tuxfamily.org \
--cc=christian.couder@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=me@ttaylorr.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.
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).