top button
Flag Notify
    Connect to us
      Site Registration

Site Registration

How to apply commits from one branch to another branch (tree structure is different) in GIT?

+1 vote
1,047 views

I have two branch in one repository that I need to maintain for 2 different deliveries.
Say branch1 and branch2 in test.git repo.

test.git
- branch1
foo_v1/text.txt
foo_v2/text.txt
- branch2
foo/text.txt

branch1 is developers branch all source looks version'ed manner and branch2 is superset for branch1, example foo_v1 and foo_v2 are the directories in branch1 where developer will update the latest one here foo_v2 and branch2 foo is same as the latest one of branch1 for an instance.

Suppose developer send 10 patches on branch1 where are changes in terms of _/ then I need to apply on my local repo branch1, till now is fine then I need to apply same 10 patches on to my branch2 where source tree which is quite question here how can I do.

posted Mar 14, 2014 by Jagan Mishra

Share this question
Facebook Share Button Twitter Share Button LinkedIn Share Button

1 Answer

+1 vote

You might be able to use the subtree option in recursive merge. Try something like:

 git cherry-pick -X subtree=foo 

This tells git to apply the changes to the "foo" directory in your current branch (branch2).

answer Mar 14, 2014 by Sumit Pokharna
How do I do this? Suppose I'm in branch1 with two commits on foo_v2 and I need to apply them
on branch2 where in foo.
Since this uses cherry-pick, the changes that you want to apply have to be on branch1 already.

Let's say your branch1 looks like:
 --A--B--C--D
and branch2 looks like:
 --1--2--3--4

And you want to apply commits B and C on branch2, but they modify "foo_v1/" on branch1. You can tell git to apply the commits onto the directory "foo/" on branch2:
 git checkout branch2 # make sure you're on branch2
 git cherry-pick -X subtree=foo B C # pick the commits

If there's no conflict, the commits should apply cleanly, and your branch2 would become like:
 --1--2--3--4--B'--C'--
Similar Questions
+1 vote

I have a question about merge commits. Now when I perform git pull from somebody. Sometimes I'm getting a merge commit where I should write a merge commit message. Sometimes it does not happen, I just hit the git pull and it pulls the updates without creating a merge commit.

What is the difference? note that the files modified in the new commit -when getting a merge commit- are only maintained by a single user. And how can I avoid these merge commits as long as the file is maintained by one user ?

+1 vote

I have the following setup "trunk and branch A (created from trunk)"

Now, what I want to do is only commit my changes to the trunk and make sure that every committed change is replicated into branch A. This should be an automatic commit, triggered by the commit to trunk, while being aware of the fact that no other changes should be done in branch A but the autocommit from trunk.

Another "would-like" requirement is that the commit metadata like author and commit time/date are kept, but this is not a must have. Is that possible with svn, maybe with autocommit hooks? If not, what other way would you see to achieve that?

+2 votes

Can someone help me on how to delete an intermediate commit?

0 votes

There are shorthands for going back from HEAD, but not for the initial commit, AFAICT.

I often want to do this when rebasing, and have come to tagging the initial commit in my repos with INITIAL.

Is there a better syntax I'm missing?

+2 votes

In coreboot we try to check for whitespace errors before committing. Of course a pre-commit hook is the way to go, but unfortunately it is not so simple (at least for me) as the following requirements exist.

  1. Only the files actually committed should be checked. That means running git commit -a, abort that and then running git commit some/file should only check some/file for whitespace errors.

  2. There are certain files that are allowed to have whitespace errors. In our case these are *.patch and *.diff files which by design seem to contain whitespace error.

Currently the whole tree is checked, which takes a lot of time. I tried to come up with a patch, but failed so far. Best would be to have

$ git diff --check --only-committed-files --exclude "*patch$"

where I could not find a way for the last to switches.

Currently, I would use

$ git diff-index --cached --name-only $against -- | grep -v patch$

and pass that list to some whitespace check program. Unfortunately that still does not fulfill the first requirement. What am I missing to solve this elegantly?

...