5

I have branched off trunk to a feature branch. In order to keep my branch up to date, I would like to frequently merge back from trunk (always up to date), but I don't like everything in trunk getting merged into my branch.

Is it possible to somehow merge from trunk only the files I have in the branch?

E.g, before merge:

Trunk
  File 1
  File 2
  File 3
  File 4
Branch
  File 2
  File 3

After merge, I have the following, which I don't want. I want to only merge File 2 and File 3 from trunk.

Branch
  File 1
  File 2
  File 3
  File 4
ProfK
  • 49,207
  • 121
  • 399
  • 775

2 Answers2

5
git merge --no-commit --no-ff trunk
git diff --name-only -z --diff-filter=A @ | xargs -0 git rm -f
git commit
jthill
  • 55,082
  • 5
  • 77
  • 137
  • This somehow looks good, but could you please explain what this does, in steps? – ProfK Apr 01 '20 at 06:20
  • It's exactly what it looks like: do the merge without committing, make a list of added files, remove everything on that list, then commit the result. – jthill Apr 01 '20 at 08:32
  • I still get over 100 changes staged for commit when I should have about 20. – ProfK Apr 06 '20 at 08:58
  • Sounds like a good subject for a SO question, put together the evidence you're looking at, figure out where it differs from what you expect, ping me in a comment if you like. – jthill Apr 06 '20 at 15:59
  • I think this is because I get modified files after the initial merge from dev, and your iterator using `diff-filter=A`. Maybe I must just step back and take a second look at how I'm working. I was under the problem impression that "files in my branch" are only files I have modified since branching, and looking for a way to merge only those files and new files back from trunk. – ProfK Apr 08 '20 at 08:44
5

Augmenting @jthill's approach, I would do 

git merge --no-commit --no-ff trunk
git diff --name-only -z --diff-filter=A @ | xargs -0 git rm -f
rm .git/MERGE_*
git commit

This would make git forget that it's doing a merge and would prevent files from being deleted when you finally want to merge back into your trunk.

As a comment though, this is not a very sustainable workflow, even if you write your own script to automatically do this every time. It's worth asking the question of why you feel like you need to do this.

It might be that: - The repo is too large -- Then you should think about splitting up the code - Your work is logically separate -- Then you should definitely think about splitting up the code - There is broken work in trunk -- Then you should implement a new workflow that doesn't merge broken code into trunk

Alternative solutions if you don't want to modify your workflow would be to:

If you want to overwrite the changes completely

git checkout trunk -- *
git commit

If you want to completely overwrite some files

git checkout trunk -- file2
git commit

Or, interactive rebase gives you the option to only select the commts you want. This also won't result in files being deleted later on

git rebase -i trunk

Personally, I'd look into changing your workflow. If you have more information on your situation, we'd be able to help you figure out other solutions.

Ben Thayer
  • 51
  • 4