From: Junio C Hamano <gitster@pobox.com>
To: Ignat Insarov <kindaro@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: Reveal by history that several commits are independent from each other?
Date: Mon, 01 Aug 2022 09:34:45 -0700 [thread overview]
Message-ID: <xmqqh72vzzve.fsf@gitster.g> (raw)
In-Reply-To: <CAB-2Q0_WmRue1gtaJGDGFoPwKdyyHf7dpuLoyZMDCXouxyP+BA@mail.gmail.com> (Ignat Insarov's message of "Mon, 1 Aug 2022 17:03:58 +0300")
Ignat Insarov <kindaro@gmail.com> 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.
prev parent reply other threads:[~2022-08-01 16:34 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-01 14:03 Reveal by history that several commits are independent from each other? Ignat Insarov
2022-08-01 16:34 ` Junio C Hamano [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqh72vzzve.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=kindaro@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).