Reveal by history that several commits are independent from each other?

Reveal by history that several commits are independent from each other?

[Ignat Insarov]

# Reveal by history that several commits are independent from each other?

Suppose I am working on a feature `Search` for which I need to add some
configuration and some types first. So, I have three patches:

1. Add some configuration. To be more descriptive, I have to add some fields to
   the structure that holds the configuration of my program, like say what URL
   the search service is found at, and a way to parse these fields from the
   configuration files.

2. Add some types. To be more descriptive, I have to add a structure with fields
   like _«search string»_, _«case sensitivity»_ and so on, and a way to convert
   this structure to JSON so that it can be sent to the search service.

3. Add the logic that looks into the configuration structure, sends a search
   request to the appropriate search service and returns the results.

See that there is a partial but not total order of dependency on these patches:
_{3 > 2; 3 > 1}_. I want to wire this information into the repository.

One way to go about it is as follows: make a branch with patch 1, another branch
with patch 2, merge 1 into 2, then add patch 3 on top. This would create the
desired lozenge structure for me, showing to everyone that I believe patches 1
and 2 to be independent prerequisites for patch 3.

Is this a reasonable practice? Is there any prior art? What are the troubles to
look forward to?

There are some other version control systems, say `darcs` and `pijul`, that work
with a partial order of patches, but I do not have any experience working with
them.

One problem I foresee is that `git` will mess up my carefully crafted branching
structure when I try to rebase the patches 1, 2 and 3 together.

Re: Reveal by history that several commits are independent from each other?

[Junio C Hamano]

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.