I needed to do a very big git rebase to reorganize all the repository. In order to keep my tree, I used git rebase --preserve-merges --onto master bf40caa develop
At first everything worked fine, all the merges are preserved and work OK, however, in source tree I'm left with the following tree:
(To be clear, d25b5ad is the initial commit, and there's no more commits before this one)
That's because, although d12020e parent is b0427f6, as they are created right in the same time we lose the order. I know this can be solved by changing to ancestor order instead of date order, but I wonder if there's some way to keep these commits ordered... Maybe adding a delay of 1 second between commits when rebasing? How could I do that?
edit: @Enrico Campidoglio, no it's not a duplicate of that other question.... Doing in that way it gets even messier... Let's get a bit more into detail:
In this case I had one big repository that had two modules. We started with one module (let's call it A) and once it was """finished""" we started with the other right away (let's call it B), in the same tree. Then we decided that we should split each one of these modules to their own repository, so what I wanted to do is to push all the tree up to where A was finished to the module-A-repository, and to push "only" the module B commits the the module-B-repository.
The thing is that we can't do just that, because the first commit of B depends on the whole tree left by A. So I made an orphan commit containing the project state as it was when A was finished (this commit is the "Initial commit" in the screenshot) and did the rebase of the B commits onto this commit.
Then note that if I do as that possible duplication it won't solve it, because this Initial commit is done "now", that's way after the first commit of B.
However, now I see there's another solution: Make this Initial commit date one before the first commit of B, then run the "possible duplicate"'s solution.
