Re: n-heads and patch dependency chains

Sam Vilain <sam@vilain.net> writes:

I suspect people have hard time grasping _why_ you are jumping through hoops. At least I do. What problem are you trying to solve? You perhaps described your mechanism well enough, but it is not quite clear to me what kind of operations are made easier with this exercise, against which possible downside of it, if any, would be judged.

Git was born from necessity, and we have been aiming to have tools to do what are commonly needed. It is not surprising to see existing tools do not support modes of operations that are "unusual" (meaning, things we have not done with git so far). Also we do not tend to do things only because we can.

Now admittably I am guilty of having done a few things only because we can. Octopus is an example. Making an Octopus only because you can does not buy you much, other than its coolness value, and it would make exporting the history to other SCMs somewhat harder I suspect, and it makes bisecting more expensive [*1*].

For example, the point jdl raised during the discussion is far easier to understand. When working on multiple topics, he often needs to test them as a whole, so he pulls them into a test branch (can be a throwaway branch). When he needs to do fixups, it is most efficient to do compile/run test while still in the test branch, but after things test out, in order to keep logically different things separate, he needs to go back to relevant topic branches and make a commit. This is painful -- are there ways to make this easier [*2*]?

Would patch commutation calculus help with his problem?

I suspect patch commutation could be used to solve his problem, but if it does not, it does not mean what you are trying to do with hydra is not interesting. It just means from your descriptions it is not clear what real problems hydra is trying to solve, and I misunderstood that it is related to his problem (just like jdl did, I suspect).

So can you step back a bit and start from describing what problem you are trying to solve, before describing the mechanisms you think would help?

One thing I can think of that could potentially come out of your approach would be an alternative implementation of what StGIT does. Inside a local developer repository, being able to reorder patches and rewrite them flexibly is very useful.

While I agree with Linus's reaction "I want my merges fast", I am not necessarily so negative about the approach. For example, if you use it only as a tool to reorder and clean-up local development history to a presentable form (IOW, using hydra to manage your development, but the result exposed to the outside world is exported from that hydra into a more linear form, that does not give other people a heart attach when they look at the ancestry graph in gitk), you would not negatively affect other people who work with you.

[Footnote]

*1* Do not get me wrong. Octopus is sometimes the most natural way to express what happened, but the case it applies to is quite narrowly defined -- to merge in independent branches that happened to mature at the same time together. So the tool discourages you from making an Octopus that is not trivial, deliberately.

*2* I see two approaches, the more obvious being "git checkout -m that-topic". Just edit (but not update-index) on top of test, have "checkout -m" adjust your changes to the topic branch you want to commit to, make a commit there, and then come back to the test branch, and merge the topic branch again.

Another obvious strategy would be to make commits on top of
"test" and then cherry-pick them back on top of the relevant
topics later.
    
        topicA                  You have three topics
         o---o                  you need to test together...
        /
    ---o---o topicB
        \ 
         o---o
        topicC

 ==>
    
        topicA                  So merge them up and start testing.
         o---o
        /     \      
    ---o---o---T
        \     /
         o---o
        topicB

 ==>
     
        topicA                  But you find problems, and fix them
         o---o                  up as you go along...
        /     \      
    ---o---o---T---1---2
        \     /
         o---o
        topicB

 ==>
    
        topicA                  Later you cherry-pick them into
         o---o---1'             relevant topics.
        /
    ---o---o topicB
        \ 
         o---o---2'
        topicC

 ==>

        topicA                  Next round of test will continue
         o---o---1'             by rebuilding the test branch
        /         \
    ---o---o-------T
        \         /
         o---o---2'
        topicC