0

I'm looking for a sequence of git commands to acquire changes that attempt to do something similar to my changes, but not from master/main, but from another contributor to the repo's branch.

I would normally use the following if rebasing from master:

git checkout TopicA
git rebase master
git push origin TopicA
git push --set-upstream origin TopicA

The setup for the repo is currently:

                F"---G"---H"---I TopicB
                |
A---B---C---D---E  master
                |
                F'---G'---H'---J   TopicA

I need to replace the o' changes of TopicA with the o" changes of TopicB.

ETA: So the desired layout is:

               F"---G"---H"---I TopicB
               |
A---B---C---D--E  master
               |
               F"---G"---H"---J  TopicA

My instinct is to replace 'master' with 'TopicB' in my sequence, but that was not the impression I got from the documentation on rebase.

My other thought would be to make a new branch (TopicC) forked off of TopicB, and then delete TopicA and then rename TopicC to TopicA.

I don't like the latter approach because I need to adapt some changes from TopicA into the changes that are present in TopicB.

So far I've read through the git-rebase(1) Man Page, and am left a bit confused and perplexed by it, and don't want to try too many things that could damage the repo or either my TopicA branch or the TopicB branch.

I'm wondering if

git rebase--onto TopicB

will be all I'd need, especially after reviewing Merging changes from a branch based off a topic branch to a different topic branch in git though I'm a little unclear whether that case and my case are the same.

The other suggested question: Git rebase to a different branch while excluding a certain branch did not seem helpful.

I'm using Git Bash for handling my git commands. I also have TortoiseGit available, but Git Bash is my preferred tool.

bartCharon
  • 13
  • 3

2 Answers2

2

If you wish topic A were, for the moment at least, absolutely identical to topic B, then make them the same commit. Assuming that topicA already exists:

git switch topicA
git reset --hard topicB

That will drop all the commits already on topic A and start topic A all over again where topic B is now.

matt
  • 515,959
  • 87
  • 875
  • 1,141
  • 1
    And remember, just about everything is undoable. So don't be scared. – matt Feb 06 '23 at 19:10
  • I always use `checkout, checkout -B` but this seems better. For example it might not remove recorded upstream tracker. – konsolebox Feb 06 '23 at 19:12
  • Ok, I understand where you're coming from with this answer, but I don't think this is what I want either, since I need to be able to view changes currently in TopicA to revise TopicB's changes, and perhaps this wasn't clear in my question, I bolded where I need to adapt changes currently in TopicA into TopicB w/o editing TopicB. [My understanding being that there would be issues with merging TopicA local vs TopicA remote if one was TopicB and the other wasn't while implementing the A changes to B's pulled ones] – bartCharon Feb 06 '23 at 19:31
  • I didn't understand any of that comment, sorry. You can have copies of the same commits in different branches but that is not what the diagram shows. That is why I asked you if you really meant what you were saying. – matt Feb 06 '23 at 19:52
  • Ok, that's my bad. How could I make it clearer that that's needed? I thought I was clear with saying I didn't like the delete branch, rename copied branch approach b/c of the need to adapt some changes from A to B... by adding commits to the diagrams to show differences? – bartCharon Feb 06 '23 at 20:02
  • Is that clearer now? – bartCharon Feb 06 '23 at 20:34
  • I don't see the difficulty. My solution causes both branches to be identical for the moment. Nothing about my solution prevents you from then adding a commit to topic A and a different commit to topic B; they can "grow" normally from there. Is the problem here that you don't understand what a branch is? Because if so, I can suggest some reading... :) – matt Feb 06 '23 at 20:45
  • On the other hand it seems to me that the diagrams are so different now from how I remember them when I wrote this answer that it isn't at all the same question any more. – matt Feb 06 '23 at 21:04
0

Your proposed command

git rebase --onto TopicB

would result in

A---B---C---D---E---F"---G"---H"---I---F'---G'---H'---J TopicA

You want

git rebase --onto H" H'

H" being the last commit you want to take from TopicB and H' being the last commit you don't want from TopicA. Run this while on the TopicA branch. You can get the commit ids for H" and H' from TortoiseGit as explained by this answer.

Note that since you're concerned about damaging your repo you could first create a new branch from TopicA

git branch TopicA-backup

Then if you decide you don't like the state TopicA ends up in you can restore it with

git reset TopicA-backup

and delete the backup branch with

git branch -d TopicA-backup

For more detail on the syntax of the rebase command have a look at Matt's answer here.

Calum Halpin
  • 1,945
  • 1
  • 10
  • 20