{"thread":{"id":"58249","subject":"Reveal by history that several commits are independent from each other?","startedAt":"2022-08-01T14:03:11Z","lastAt":"2022-08-01T16:34:56Z","messageCount":2,"participants":["Ignat Insarov","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"460353","messageId":"CAB-2Q0_WmRue1gtaJGDGFoPwKdyyHf7dpuLoyZMDCXouxyP+BA@mail.gmail.com","threadId":"58249","inReplyTo":null,"subject":"Reveal by history that several commits are independent from each other?","fromName":"Ignat Insarov","fromEmail":"kindaro@gmail.com","sentAt":"2022-08-01T14:03:58Z","receivedAt":"2022-08-01T14:03:11Z","isPatch":false,"sender":{"key":"kindaro@gmail.com","avatar":null},"body":"# Reveal by history that several commits are independent from each other?\n\nSuppose I am working on a feature `Search` for which I need to add some\nconfiguration and some types first. So, I have three patches:\n\n1. Add some configuration. To be more descriptive, I have to add some fields to\n   the structure that holds the configuration of my program, like say what URL\n   the search service is found at, and a way to parse these fields from the\n   configuration files.\n\n2. Add some types. To be more descriptive, I have to add a structure with fields\n   like _«search string»_, _«case sensitivity»_ and so on, and a way to convert\n   this structure to JSON so that it can be sent to the search service.\n\n3. Add the logic that looks into the configuration structure, sends a search\n   request to the appropriate search service and returns the results.\n\nSee that there is a partial but not total order of dependency on these patches:\n_{3 > 2; 3 > 1}_. I want to wire this information into the repository.\n\nOne way to go about it is as follows: make a branch with patch 1, another branch\nwith patch 2, merge 1 into 2, then add patch 3 on top. This would create the\ndesired lozenge structure for me, showing to everyone that I believe patches 1\nand 2 to be independent prerequisites for patch 3.\n\nIs this a reasonable practice? Is there any prior art? What are the troubles to\nlook forward to?\n\nThere are some other version control systems, say `darcs` and `pijul`, that work\nwith a partial order of patches, but I do not have any experience working with\nthem.\n\nOne problem I foresee is that `git` will mess up my carefully crafted branching\nstructure when I try to rebase the patches 1, 2 and 3 together.\n"},{"id":"460357","messageId":"xmqqh72vzzve.fsf@gitster.g","threadId":"58249","inReplyTo":"CAB-2Q0_WmRue1gtaJGDGFoPwKdyyHf7dpuLoyZMDCXouxyP+BA@mail.gmail.com","subject":"Re: Reveal by history that several commits are independent from each other?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-08-01T16:34:45Z","receivedAt":"2022-08-01T16:34:56Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ignat Insarov <kindaro@gmail.com> writes:\n\n> Is this a reasonable practice? Is there any prior art? What are the troubles to\n> look forward to?\n\nYou can maintain such a history structure if you really wanted to,\nand rebase with \"git rebase --rebase-merges\" while keeping the merge\nstructure, but I am not sure if this is worth the effort.\n\nFor example, you mentioned \"rebase\", but consider the reason why why\nare you rebasing in the first place.\n\nYou made a diamond structure because 3 depends on both 1 and 2,\n*AND* both 1 and 2 needed whatever was in their ancestor.\n\n\t      1---3\n             /   /\n\t----O---2\n\nNow do 1 and 2 need a lot more than their original ancestor offers\n(hence you are rebasing forward), or do they depend on less (hence\nyou are rebasing backward, porting the change to older codebase)?\n\nIt is likely that you are rebasing not for these reasons.  You are\n\"rebasing to a newer upstream\", aren't you?  But why?  You developed\nthese three commits on O and whatever the others did in the upstream\nyou weren't even aware of, hence there is no way your work depend on\nthem.  Even then, perhaps for some other reasons, you are somehow\nexpected to rebase on a newer upstream.\n\nWhat does that mean in the overall picture?  The diamond structure\nyou created does capture some local inter-commit dependency, but in\nthe larger history, there are ancestry relationships that have\nnothing to do with such dependency (e.g. where in the global picture\nyour diamond sits on by rebasing).  It is unclear how you tell which\nparent-child relationship encodes the dependency and which ones are\njust \"this commit happened to have seen by whoever maintains the\nprimary history before the other ones\".  And unless you can maintain\nthe entire history and enforce the property that you can pick any\nrandom parent-child pair and they are always \"child depends on what\nthe parent has\", it is dubious how much value you can extract from\nthe history by only doing so very locally.\n\nAnd that is where my \"I am not sure if this is worth\" comes from.\n\nAnother non-essential detail is that Git and other tools tend to\ngive special meaning to the first parent chain.  In your diamond\nstructure, parents 1 and 2 of commit 3 have equal standing and it is\nnot like one is more important than the other.  So things like \"git\nlog --first-parent\" and GUI tools written around the idea that\nfirst-parent chain is more special may not work very well for some\nparts of your history (i.e. the part that employs your \"topology\nshows the minimum dependency\" convention).\n\nJust my random thoughts.\n"}]}