git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Konstantin Khomoutov <kostix@bswap.ru>
To: "git@vger.kernel.org" <git@vger.kernel.org>
Subject: Re: Merge selected files or folders
Date: Fri, 22 Mar 2024 12:56:40 +0300	[thread overview]
Message-ID: <20240322095640.saas2lxwmitrwoki@carbon> (raw)
In-Reply-To: <87bk76fvvr.fsf@osv.gnss.ru>

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


  reply	other threads:[~2024-03-22 10:12 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-21 16:50 Merge selected files or folders Richard Kerry
2024-03-21 17:50 ` Junio C Hamano
2024-03-22  9:39   ` Sergey Organov
2024-03-22  9:56     ` Konstantin Khomoutov [this message]
2024-03-22 10:27       ` Dragan Simic
2024-03-22 12:24   ` stefan.naewe
2024-03-22 17:23     ` Junio C Hamano

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=20240322095640.saas2lxwmitrwoki@carbon \
    --to=kostix@bswap.ru \
    --cc=git@vger.kernel.org \
    /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).