Hi Joel,
On 24/03/2022 13:42, Johannes Schindelin wrote:
Hi Joel,
please reply inline. What you did is called "top-posting" on this list and
is regularly discouraged.
On Tue, 22 Mar 2022, Joel Marshall wrote:
I have confirmed that this is still an issue under certain
circumstances. --rebase-merges works as expected if it is being used
with simple feature branches, ie one commit after the other, no
merges. Where things go off of the rails is when there are branches
and merges coming off of and going into a feature branch. At that
point using the --rebase-merges flag with rebase will create a similar
mess to the images of the logs I attached back in July of 2022.
I wonder what happened to my suggestions to use
`--rebase-merges=rebase-cousins` or `git fast-export --anonymize`. They
seem to have faded without any echo.
Ciao,
Johannes
The rebasing of merges can be confusing, with the different perspectives
(mental models) about which line of development the merges arrive from.
In support of Johannes' note, the stack overflow Q&A [1] does contain
some nice diagrams showing the different ways that a history can be
interpreted, and the effect that "cousins" have on the picture
(understanding not helped by many colloquial familial uses of 'cousins'
that are not technically correct ;-).
Your case of two parallel lines of development, with merges from one to
the other, being rebased from the original fork-point, does look to fit
that 'difference of mental model' confusion.
Does that SO Q&A help clarify the situation. If you are able to create a
similar simplified hierarchy (e.g. cut out the long linear sections) of
your scenario then it becomes easier to help.
Philip
[1]
https://stackoverflow.com/questions/56529435/what-is-the-behavior-of-the-cousins-options-in-git-rebase-rebase-merges
On Wed, Dec 8, 2021 at 3:46 PM Joel Marshall <joelmdev@xxxxxxxxx> wrote:
Hi all,
Sorry to drop off on this for so long. I think this is still a
possible outstanding issue, yes? If so I will work on getting you a
copy of the repo as I did archive a copy at the state originally
mentioned in this issue.
On Mon, Aug 10, 2020 at 10:46 AM Johannes Schindelin
<Johannes.Schindelin@xxxxxx> wrote:
Hi Joel,
On Thu, 23 Jul 2020, Joel Marshall wrote:
I saved the state of the repo in a copy so I could come back to it if
additional examples were needed but I had to clean up my live copy so
I could get back to work. I'll get you some additional screenshots in
the next few days. In the meantime, I'll try to give you some context
around what I'm doing here. The parent branch is my main dev branch
which consists of a series of clean branches and merges- the dev
branch basically looks like what you're seeing in the
--preserve-merges screenshot. I've also got a long running feature
branch that branches off of dev, and it also consists of many branches
and merges, each a subtask of the story related to the feature branch
as a whole. Occasionally to get the feature branch up to date with the
newest features I'll rebase the whole thing on top of dev, which
should result in an unbroken chain of branches and merges as seen in
the --preserve-merges screenshot. While you can't see it in the
--rebase-merges screenshot, those merges show no ancestors when viewed
in reverse chronological order- they just trail off into oblivion.
I could imagine that you might want to try this rebase with
`--rebase-merges=rebase-cousins`.
Otherwise, you might want to export your use case with `git fast-export
--anonymize` so that others (such as myself) have a chance of helping you.
Ciao,
Johannes
