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
