Re: Merge selected files or folders

[Dragan Simic <dsimic@manjaro.org>]

On 2024-03-22 10:56, Konstantin Khomoutov wrote:
> On Fri, Mar 22, 2024 at 12:39:36PM +0300, Sergey Organov wrote:
> 
>>>> I'd like to merge only certain files, or folders, from another
>>>> branch.  What command or options should I be looking at to get
>>>> this done?
>>> 
>>> If you are using the verb "merge" in the way Git uses, then there is
>>> *no* option to do so and that is very much deliberate, as allowing
>>> such a operation will break your history.
>> 
>> No, it won't break history. The merge commit *content* does not break
>> *history* in any way. Path-limiting makes perfect sense when one is
>> about to create merge commit content and knows in advance the exact 
>> set
>> of paths the changes from which are to be included (or ignored).
> 
> This reminded me of the "disaster no. 2" in the rant, arguably famous 
> at the
> time [1], in particular:
> 
> | One user of Tortoise Git would do a pull, have a merge conflict, 
> resolve the
> | merge conflict, and then look carefully at his list of files to be 
> committed
> | back when he was committing the results. There were lots of files 
> there, and
> | he knew that the merge conflict only involved a couple of files. For 
> his
> | commit, he unchecked all the other files changes that he was not 
> involved
> | in, committed the results and pushed the commit.
> 
> My understanding is that the OP actually wanted to create a similar 
> situation
> consciously. It's quite possible that they intend to never merge the 
> results
> back into "the main line" but anyway.
> 
> The point is, the feature you're advocating is bound to be abused 
> exactly
> through this "this is my stuff, and there is the stuff I do not care 
> about"
> attitude.
> 
> Having said that, I do not oppose these features (not that my opinion 
> should
> have any weight; I'm just making things clear) as in the end the only 
> workable
> solution to have decent quality of a project's content is "gatekeeping" 
> the
> changes by the review process.
> 
>  1. https://randyfay.com/content/avoiding-git-disasters-gory-story

Here's a similar story...  A while back, when I used Subversion heavily,
I (ab)used a lot its ability to perform partial updates to the working 
copy,
i.e. to run "svn update <path>".  It can be highly useful if used _VERY_
carefully, but it's also quite dangerous.  Like a chainsaw.