Effects of merging a rebased branch in Git

Question

Background

I want to retro-actively create a sub-project from my Git repo.

Currently, I have something like this...

A-B-C (origin/master)

I see now that a subset of this codebase would be useful for some other, similar, projects so I forked and deleted a bunch of stuff.

A-B-C-D (sub-project/master)

where commit D deletes a bunch of code that was specific to the original/master project.

Now I can create other projects from sub-project/master...

A-B-C-D-OP1 (other-project/master)

And, if I have general purpose updates (commits that I want to apply to all the other projects) I can make them to sub-project/master and then pull them into all my other projects...

A-B-C-D-E (sub-project/master)

A-B-C-D-OP1-E (other-project/master)

What I'd like to do now is to merge these same commits from sub-project/master back into origin/master, but I know that this will result in...

A-B-C-D-E (origin/master)

with D deleting a bunch of code from origin/master, when what I really want is...

A-B-C-E (origin/master)

My Question

If I rebase sub-project/master, removing commit D

A-B-C-E (sub-project/rebase-branch)

I know that I could then merge sub-project/rebase-branch into original/master so that it too will look like I want it to...

A-B-C-E (origin/master)  

but what is going to happen if I then create additional commits on sub-project...

A-B-C-E-F (sub-project/rebase-branch)

and then merge sub-project/rebase-branch into other-project/master?

Will other-project/master result in this...?

A-B-C-D-OP1-E-F (other-project/master) 

leaving D in place?

or will the merge result in this...?

A-B-C-OP1-E-F (other-project/master)

removing D when adding F?

If it's the former, then I'm good to go. If it's the latter, then is there a viable solution to the dilemma I've outlined above? (Is it possible for me to modify sub-project in such a way that I could then merge additional commits added to sub-project into both origin/master and into other-project/master - leaving D in-place in the latter, but absent in the former?)

Answer 1

It sounds like you have found a subset of a project which can be spawned off as a library. You should maintain separate projects with completely separate repos (READ: no remotes set between each other). Make periodic "releases" of your library project that your other projects can use. You can use a tool such as gradle or maven to help you manage the dependency on your library project. Personally, I think this would be a better approach than trying to use git as a dependency management tool through merging commits.

Answer 2

As git has immutable history graph, when you do rebase, you just re-create same commits on top of different base. So, if you have history A-B-C-D-E, after rebase of E from D to C you'll get A-B-C-E'. If you merge it - it will have both commits in history E and E'.

So, it is possible to do, but I feel you are trying to use version control system as dependency management system, which is not the best thing to do. Try to reconsider how you use you components and separate them into independent projects.