![]() The result is that you're now in detached HEAD state, and the rewritten commits are not currently on any branch. That's because if you do a rebase with a branch checked out, the branch moves with the rewritten commits, and it doens't sound like you want that. That's because rebase treats this argument as a negative ref - everything reachable from E (including E itself) will not be copied.Īlso note that I specified P as the final argument, rather than branch-A. Note that you specify E, not I, as the "upstream" argument. That might look like this: git rebase -onto Branch-B E P The way I would duplicate the changes of a range of commits (so long as that range doesn't include merges) is with git rebase using the -onto option. I still prefer to use rebase for ranges of commits, but I originally said it's the "easiest" way, and objectively that's not accurate since it requires extra manipulation of branches. Since you want to also get I, you should say E.P instead, but the idea of cherry-pick working "backwards" through the history doesn't make sense, or match the docs, or match my tests. ![]() Then you should get copies of the commits from M to P added to Branch-B. If you start with Branch-B checked out and say git cherry-pick I.P In other word, you need to rewrite history of either dev or test branch.Ī couple of git commands can do such rewrite, reset, rebase, filter-branch.Updated - I've been looking at this, and I can't see how the command you've specified would do what you're saying it did. If you really want only one pair of g-h or e-f to show up, well, since this is a list of commits of all branches in repo, one of the pair need to be vanished from the repo. test's own history is fine, only has g-h, not e-f. So what you see is a linear list of commits from many branches, not just test branch in your example. This representation is only visually linear, doesn't mean these commits are connected linearly. Now many git GUI softwares decide to show things in a linear list fashion, usually in reverse chronological order, like dev: a-b-c-d-e-f-i c(j) = c(d)+c(i) as of file content, j represent a file content state such that when diff against h, will be equal to d diff against c + i diff against f, en bref,.r(j) = r(h)+r(i) as of relation, since j is the child of 1st parent h & 2nd parent i.Here's how I would describe test branch after merged test: a-b-c-g-h-j Normally send PR from dev to test then merge: dev: a-b-c-d-e-f-i It features these two commits, which should not be there, since the pull request does not apply the changes which those commits describe. Here are the details of the completed PR request. The red commits have no associated changes and repeat exactly the messages of the orange commits. In red are commits from the pull request. OPTIONS - .:: Commits to cherry-pick.In orange are the commits that come from cherrypick. another 'do I know git' question let's say you have a big PR with 12 commits. See linkgit:git-merge1 for some hints on resolving such conflicts. Here is a setup for pull request, commits in red box have already been cherrypicked to the target branch. Here is a real life example of this issue: How can I achieve this? Or should I restructure the git workflow to prevent such things from happening?
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |