Re: Merge selected files or folders
- From
- Dragan Simic <dsimic@manjaro.org>
- Date
- Mar 22, 2024, 10:27 UTC
- Message-ID
- <838ca1b39625dea6827fa623abb51792@manjaro.org>
- In-Reply-To
- <20240322095640.saas2lxwmitrwoki@carbon>
On 2024-03-22 10:56, Konstantin Khomoutov wrote:
Show 53 quoted lines
> 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.