Ignat Insarov <kindaro@xxxxxxxxx> writes:
> Is this a reasonable practice? Is there any prior art? What are the troubles to
> look forward to?
You can maintain such a history structure if you really wanted to,
and rebase with "git rebase --rebase-merges" while keeping the merge
structure, but I am not sure if this is worth the effort.
For example, you mentioned "rebase", but consider the reason why why
are you rebasing in the first place.
You made a diamond structure because 3 depends on both 1 and 2,
*AND* both 1 and 2 needed whatever was in their ancestor.
1---3
/ /
----O---2
Now do 1 and 2 need a lot more than their original ancestor offers
(hence you are rebasing forward), or do they depend on less (hence
you are rebasing backward, porting the change to older codebase)?
It is likely that you are rebasing not for these reasons. You are
"rebasing to a newer upstream", aren't you? But why? You developed
these three commits on O and whatever the others did in the upstream
you weren't even aware of, hence there is no way your work depend on
them. Even then, perhaps for some other reasons, you are somehow
expected to rebase on a newer upstream.
What does that mean in the overall picture? The diamond structure
you created does capture some local inter-commit dependency, but in
the larger history, there are ancestry relationships that have
nothing to do with such dependency (e.g. where in the global picture
your diamond sits on by rebasing). It is unclear how you tell which
parent-child relationship encodes the dependency and which ones are
just "this commit happened to have seen by whoever maintains the
primary history before the other ones". And unless you can maintain
the entire history and enforce the property that you can pick any
random parent-child pair and they are always "child depends on what
the parent has", it is dubious how much value you can extract from
the history by only doing so very locally.
And that is where my "I am not sure if this is worth" comes from.
Another non-essential detail is that Git and other tools tend to
give special meaning to the first parent chain. In your diamond
structure, parents 1 and 2 of commit 3 have equal standing and it is
not like one is more important than the other. So things like "git
log --first-parent" and GUI tools written around the idea that
first-parent chain is more special may not work very well for some
parts of your history (i.e. the part that employs your "topology
shows the minimum dependency" convention).
Just my random thoughts.
