0

I have the following case

o--A--B--C <-origin/master
 \-D--E <-master

I would like to achieve the following

o--A--B--C--D--E <-origin/master

and also keeping the tags at D and E.

If I do a rebase then the D and E would be merged resulting D' and E'

o--A--B--C--D'--E' <-origin/master

Also the tags would not be moved and still pointing to hash of commit D and E.

Update 1

If I have file A.txt at C and file B.txt at D, the rebase will keep both A.txt and B.txt at commit D'. How can I do a rebase but preserve all the file structure and content what I had at D.?

Mokus
  • 10,174
  • 18
  • 80
  • 122
  • D and E will always stay there, nothing can change that. Rebasing and then manually moving the tags might be the best option. Also rebasing won't merge anything... what makes you think it will? – evolutionxbox Mar 12 '21 at 15:10
  • Question title is wrong. As per the post's description you want to rebase local master to origin's master, but title says the opposite. – Asif Kamran Malick Mar 12 '21 at 15:17
  • During rebase there are conflict and also will result to new hash. – Mokus Mar 12 '21 at 15:24
  • @OHLÁLÁ every command in git which modifies the history will create a new hash. This cannot be prevented – evolutionxbox Mar 12 '21 at 15:25
  • To clarify "Update 1", when you say "I have file", do you mean A.txt is a new file that is added in commit C? And is B.txt a new file that is added in commit D? – TTT Mar 12 '21 at 15:47
  • A.txt could have been added at Commit A,B,C, and B.txt.is added at D. But A.txt does.not exist at C. – Mokus Mar 12 '21 at 16:05
  • 1
    @OHLÁLÁ I assume you meant "But A.txt does not exist at **D**". So when you rebase D onto C to create D', A.txt will remain there because someone added it. If you don't want it anymore, then delete it and commit the delete. (You could amend D' to be D'' with the delete, or add another commit with the delete in it. – TTT Mar 12 '21 at 17:40

2 Answers2

0

If nodes D and E have tags, they will not be moved with the rebase. D and E are placeholder names for hashes, and are not git tags.

I think you may have been using the word tag incorrectly, or in a casual sense. But a git tag is exactly what you want.

JDługosz
  • 5,592
  • 3
  • 24
  • 45
0

First lets agree on what merge means. You wrote:

If I do a rebase then the D and E would be merged resulting D' and E'...

Instead of the word merged there, it makes more sense to say replayed. An actual merge in your case results in a new commit with two parents (from each branch).

There is no way to rebase and keep D and E commit IDs intact.

You must choose either rebase or merge. If you rebase, your commit IDs will change, and then you can make new tags for D' and E' (and perhaps discard your previous tags for D and E).

If you merge, the commit IDs for D and E will remain intact and you can use your existing tags, but you will have a merge commit and your history will not be in a straight line.

TTT
  • 22,611
  • 8
  • 63
  • 69
  • (won't D and E will remain intact as long as they're reachable?) – evolutionxbox Mar 12 '21 at 15:30
  • @evolutionxbox are you talking about them sitting off to the side and not having them in origin/master? I doubt that would be very useful. ;) – TTT Mar 12 '21 at 15:42