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

# 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.

Ignat Insarov <kindaro@gmail.com> writes:

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.