Merge selected files or folders

Merge selected files or folders

[Richard Kerry]

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?

What keywords should I be looking at?  When I ask Google I seem to find various answers which then get analysed as "actually don't do it like this, because it doesn't actually do a merge" or other unsatisfactory results.
My colleague is mostly working on "master" and I am mostly working on a branch.  In most cases my branch should fast-forward to the head of master, so I'd have thought that behind the scenes it would just need to re-point the commit identifier, so there ought to be a straightforward implementation of this.

I know git expects to merge a whole branch throughout the repository, but this seems like something I can't be the only person ever to want, so I assume there is a "proper" way of doing it.  Or do I merge all then clear everything I don't want, which seems tedious.

Regards,
Richard.


	

Re: Merge selected files or folders

[Junio C Hamano]

Richard Kerry <richard.kerry@eviden.com> writes:

> 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.

A "merge" commit in Git records the fact that *all* changes that
were done in each parent since the merged branches diverged have
been considered and the tree recorded by the merge commit is the
result.  Hence, if you later change your mind and "merge" other
changes from the same branch, it will result in no change at all, by
definition.

But if you are porting some changes made on another branch to the
current branch, and then planning to record the result as a regular
single parent commit, then there is no fundamental reason to forbid
such an operation.  It is what cherry-pick ought to be able to do,
even though I do not think it accepts a pathspec to limit currently.

Assuming a history of this shape:

      x---x---X (that other branch)
     /
    O---o---o---o---H	(current branch)

such a "cherry-pick" would essentially be applying all the changes
lead to X since the histories forked at O on top of H:

    $ git checkout H
    $ O=$(git merge-base X H)
    $ git diff $O X | git apply
    $ git commit -m "picked changes from branch X"

And if you want to limit the paths involved in the operation, the
"git diff" step can be given a <pathspec> to limit the changes that
are ported.

    $ git checkout H
    $ O=$(git merge-base X H)
    $ git diff $O X -- thisdir/ that/file | git apply
    $ git commit -m "picked changes from branch X"

Teaching "git cherry-pick" to accept a pathspec and natively 
perform something like the above is left as an exercise.

HTH

Re: Merge selected files or folders

[Sergey Organov]

Junio C Hamano <gitster@pobox.com> writes:

> Richard Kerry <richard.kerry@eviden.com> writes:
>
>> 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).

>
> A "merge" commit in Git records the fact that *all* changes that
> were done in each parent since the merged branches diverged have
> been considered and the tree recorded by the merge commit is the
> result.  Hence, if you later change your mind and "merge" other
> changes from the same branch, it will result in no change at all, by
> definition.

Yes, but it's not an argument against path limiting support in the merge
*command* that is just a helper to create merge commits. With this
feature in place I'd just tell "git merge" that I've already considered
all the other paths and decided that changes from them are irrelevant
and are not to be included.

> But if you are porting some changes made on another branch to the
> current branch, and then planning to record the result as a regular
> single parent commit, then there is no fundamental reason to forbid
> such an operation.  It is what cherry-pick ought to be able to do,
> even though I do not think it accepts a pathspec to limit currently.

I think both cherry-pick and merge can be given such a possibility, as
there is nothing wrong with it (see above), provided we do properly
document what we are actually doing.

>
> Assuming a history of this shape:
>
>       x---x---X (that other branch)
>      /
>     O---o---o---o---H	(current branch)
>
> such a "cherry-pick" would essentially be applying all the changes
> lead to X since the histories forked at O on top of H:
>
>     $ git checkout H
>     $ O=$(git merge-base X H)
>     $ git diff $O X | git apply
>     $ git commit -m "picked changes from branch X"
>
> And if you want to limit the paths involved in the operation, the
> "git diff" step can be given a <pathspec> to limit the changes that
> are ported.
>
>     $ git checkout H
>     $ O=$(git merge-base X H)
>     $ git diff $O X -- thisdir/ that/file | git apply
>     $ git commit -m "picked changes from branch X"
>
> Teaching "git cherry-pick" to accept a pathspec and natively 
> perform something like the above is left as an exercise.

Well, I'd argue that both cherry-pick and merge should learn to have
this useful feature, and it's much more useful for merges, as, unlike
single commits the cherry-pick deals with, the merges tend to be huge
from time to time, making manual amendments a real pain.

Do such patches have a chance of being accepted?

Thanks,
-- Sergey Organov

Re: Merge selected files or folders

[Konstantin Khomoutov]

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

Re: Merge selected files or folders

[Dragan Simic]

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.

RE: Merge selected files or folders

[stefan.naewe]

Classification - ISMS: Offen | VS: OFFEN



> -----Original Message-----
> From: Junio C Hamano <gitster@pobox.com>
> Sent: Thursday, March 21, 2024 6:51 PM
> To: Richard Kerry <richard.kerry@eviden.com>
> Cc: git@vger.kernel.org
> Subject: Re: Merge selected files or folders
> 
> Richard Kerry <richard.kerry@eviden.com> writes:
> 
> > 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.
> 
> A "merge" commit in Git records the fact that *all* changes that were done in each
> parent since the merged branches diverged have been considered and the tree
> recorded by the merge commit is the result.  Hence, if you later change your mind
> and "merge" other changes from the same branch, it will result in no change at all,
> by definition.
> 
> But if you are porting some changes made on another branch to the current
> branch, and then planning to record the result as a regular single parent commit,
> then there is no fundamental reason to forbid such an operation.  It is what cherry-
> pick ought to be able to do, even though I do not think it accepts a pathspec to limit
> currently.
> 
> Assuming a history of this shape:
> 
>       x---x---X (that other branch)
>      /
>     O---o---o---o---H	(current branch)
> 
> such a "cherry-pick" would essentially be applying all the changes lead to X since
> the histories forked at O on top of H:
> 
>     $ git checkout H
>     $ O=$(git merge-base X H)
>     $ git diff $O X | git apply
>     $ git commit -m "picked changes from branch X"
> 
> And if you want to limit the paths involved in the operation, the "git diff" step can be
> given a <pathspec> to limit the changes that are ported.
> 
>     $ git checkout H
>     $ O=$(git merge-base X H)
>     $ git diff $O X -- thisdir/ that/file | git apply
>     $ git commit -m "picked changes from branch X"

Isn't that the same as simply checking out the files/folders of "that other branch" and commiting the result ?

$ git checkout X -- this/dir that/file
$ git commit -m "picked changes from branch X"

Or am I missing something ?

> Teaching "git cherry-pick" to accept a pathspec and natively perform something like
> the above is left as an exercise.


Thanks,
Stefan

Re: Merge selected files or folders

[Junio C Hamano]

<stefan.naewe@atlas-elektronik.com> writes:

>> Assuming a history of this shape:
>> 
>>       x---x---X (that other branch)
>>      /
>>     O---o---o---o---H	(current branch)
>> ... 
>>     $ git checkout H
>>     $ O=$(git merge-base X H)
>>     $ git diff $O X -- thisdir/ that/file | git apply
>>     $ git commit -m "picked changes from branch X"
>
> Isn't that the same as simply checking out the files/folders of
> "that other branch" and commiting the result ?
>
> $ git checkout X -- this/dir that/file
> $ git commit -m "picked changes from branch X"
>
> Or am I missing something ?

You would lose the changes the history O..H made to this/dir/** and
that/file if you did that, no?