Re: Feature that allows the user to merge only specific files/folders from another branch

"Sugiarto, Titania" [off-list ref] writes:

I have a suggestion for Git, which includes a feature that allows
the user to merge (I want to highlight merge here, not replace)
specific files/folders from another branch.  I feel like a lot of
users have spoken about this online but up until now, there hasn't
been an update regarding such feature.

What happens when a branch does three different things, and you
merge that branch to the mainline but taking only changes for one of
these three things?  You get changes only to specific files merged,
which is what you seem to be talking about here.

You can do so with "git merge --no-commit", followed by selectively
reverting the working tree changes to the state recorded in HEAD
with either Git tools or your editor, and concluded by "git commit",
but anybody doing so must consider the implications for doing so.

We need to remember that a merge commit is this declaration:

   I inspected and understand what this side branch does and what we
   have done in the mainline, and came up with this tree state as
   the merge result.  It is my belief that this result suits the
   objective of the project better than either of these two branch
   tips I am merging together.

After you made such a declaration on the mainline branch, you made
everbody to agree that among three things the side branch did, two
of them that you did not take were bad idea and should be discarded
(anybody who do not subscribe to that idea can go elsewhere and feel
free to no longer work on the same mainline).

But what happens 3 months after you make such a merge somebody else
(and it could well be you) realize that they want one of the other
two remaining changes out of that same branch?  As you have already
made such a one-third merge, they cannot merge the same branch again
to resurrect the two other changes you have already discarded
earlier.

You'd need to find these discarded two other changes _somehow_ if
you need to resurrect them later, but how?

When a bug is reported on such a state after the merge, the author
of that side branch may remember that the bug is addressed by one of
these two changes you did not include in the merge, but if anybody
asks Git "is the branch that supposed to include the bugfix already
merged to the mainline?" they will get "Yes".  In other words, they
run "git log mainline..three-things-branch" and they will get an
empty result because you made that one-third merge.  The release
manager will scratch their head until they realize what you did,
picking only one of the three things the branch did, but recording
that as a merge with that branch that did three things.

Chaos.

Might be worthwhile to consider?

So,... not really.