4

Can I perform 'merge' that updates only existing files in current branch?

For example, I have branch1: /file1, /x/file2, /file3. And branch2: /file1, /x/file2, /z/file4. I want to update files file1 and file2 in second branch with files from first.

As a solution I see creating separate commits in branch1 for that files, and than use chery-pick in second branch.

UPD: Thanks to @fge, I've founded that solution (not so simple as I had expected):

git co branch2
git co branch1 -- ./
git reset ./
git ci -a
git clean -f
prcu
  • 903
  • 1
  • 10
  • 23
  • 2
    You might want to elaborate on what you're actually trying to accomplish here. Are these two long-lived branches? Are you going to have to do merges like this a lot? Are the undesired files all in one directory, representing something cohesive? Will you want to get the nonexistent files and the changes to them sometime later? Did those files ever exist in the current branch? – Cascabel Jan 07 '12 at 18:28
  • 1
    Could you write the git commands out please? I know that "co" stands for "checkout", but can't figure out what "ci" stands for. Thanks. – Andrei Sep 08 '16 at 10:12
  • Ok found some of the shortcuts for git (.gitconfig) here: https://githowto.com/aliases. So "ci" stands for "commit" if i'm not mistaken. – Andrei Sep 08 '16 at 10:25

2 Answers2

1

You can proceed as such while on branch2:

git checkout branch1 -- file1 x/file2

Then git add the modified files and commit the result.

If you want to have the commit message of branch1 as well, you could commit with git commit -c branch1.

Note that branch1 really is a refspec. A branch in git is nothing but a commit, but as a commit has links to its parent(s), it is, in effect, a "branch".

fge
  • 119,121
  • 33
  • 254
  • 329
  • The 'merge' was in quotes. Hence my solution. – fge Jan 07 '12 at 18:09
  • That's not what I really want, but maybe it's the easiest way. This way does not resolve conflicts in files & there's need to list all necessary files. Bash loops and ls can help. – prcu Jan 07 '12 at 20:13
  • This is fine for a few files, what if there are too many to make this practical? – fred Oct 31 '21 at 15:35
1

Go ahead with the merge as you would normally. Next, amend that nw commit to the shape you want by deleting the extra files:

git merge other_branch
rm file another_file #etc
git add -A
git commit --amend -C HEAD

You now have a merge comit (2 parent commits defined). Commands such as 

git branch --contains

will work properly now. Do this only if you want a proper merge.

Adam Dymitruk
  • 124,556
  • 26
  • 146
  • 141
  • This may bring in unwanted commits/changes from the second branch. OP never said he wanted to bring in _all_ changes from the other branch, just a set of files. – fge Jan 07 '12 at 18:11
  • It's probably *dangerous* to mark this as a merge, even though the OP doesn't realize it. If you do a merge, then rewrite things so that you don't actually include all the changes from the merge commits, then you'll never pick up the rest of those changes with a later merge. – Cascabel Jan 07 '12 at 18:26
  • That's right, fge. Result is not usual merge. There would be two different commits after this operation. So I've written 'merge' in quotes. – prcu Jan 07 '12 at 19:45
  • Jefromi, I wrote about solution with separate commits & chery-pick. I just thought that there was some built-in solution in git. – prcu Jan 07 '12 at 19:51
  • Then this is not a merge and those other files will be brought in if/when those commits are merged in. That's dangerous. – Adam Dymitruk Jan 07 '12 at 22:10
  • Edited my answer to have the disclaimer saying that this will make the commits behave like they have bee merged. – Adam Dymitruk Jan 07 '12 at 22:15
  • @Jefromi, I would consider that a feature, not a bug of this approach. – svick Jan 07 '12 at 22:56
  • @svick: It *entirely* depends on the goals of the OP, which were not clear - and the OP is definitely *not* the only person who will ever see this. If you're trying to permanently keep/discard parts of things, it's great. If you're trying to temporarily get part, then pick up the rest later, it'll bite you later. (It also makes the history potentially confusing - a commit appears to be an ancestor, but its changes don't make it in!) So it's good to be cautious and make sure everyone knows what they're doing. – Cascabel Jan 08 '12 at 00:45