Re: n-heads and patch dependency chains

[Andreas Ericsson <ae@op5.se>]

Junio C Hamano wrote:
> Andreas Ericsson <ae@op5.se> writes:
> 
> 
>>Sam Vilain wrote:
>>
>>>Junio C Hamano wrote:
>>>
>>>>[ made change on a test branch that bundles topic branches
>>>>  -- now want to commit back to the component topic branch ]
>>>>Would patch commutation calculus help with his problem?
>>>>
>>>
>>>I'd provisionally say "yes, that's the fit". It's just like having
>>>multiple topic branches all checked out at once, with commits going to
>>>the appropriate branch as necessary.
>>
>>Wouldn't "git commit -M -b topic", for committing to a different
>>branch than what is checked out (-b) and also to the checked out
>>branch (-M) have the same beneficial effects, but without the
>>complexity of hydras and patch dependency theory? It would only remove
>>the cherry-pick stage though, but perhaps it's good enough. Although
>>when I think about it, -b
>><branch> for committing to another branch and -B <branch> for doing
>>the above probably makes more sense.
> 
> 
> It feels to me that the above set of flags encourage a workflow
> that:
> 
>  (1) modify the source and run tests in "test" branch;
>  (2) have tool automatically adjust the change to match the other
>      branch (i.e. the topic to be checked in) automatically;
>  (3) make a commit, without a chance to do the final sanity
>      check in the context of the branch being committed.
> 

I don't fully understand 3 here. The workflow makes it easier to test 
how different topics work together, and make fixes to those that don't 
play well with others. Granted, it's not possible to test each topic by 
itself without checking it out, making the changes and re-compiling and 
so on, but since commits are so easy to undo I think it'd be nice to 
have the changes tracked. Another good thing is that fixes that apply on 
top of the "work-together" fixes, but that only make the topic branch 
build/work properly are completely rebase'able, and should result in a 
fast-forward merge since they share the same commit.


> An individual topic branch itself might not be even testable
> standalone, but at least I'd prefer to have a chance to double
> check if the "patch commuting" (or "cherry-pick stage") did a
> sensible thing [*1*].
> 

Understandable, and this workflow would still be available, but see below.


> As I said on the list in the past, I am from a school that
> believes in not committing anything that has not been
> tested/reviewed as a whole, especially when it comes to
> individual developers, so I am not sure it is a good idea
> in general to make it easy to do so to begin with.
> 

In short, you're from the school of centralized repositories. I used to 
be very careful about committing things too, but since I switched to git 
I happily commit smaller and more often, and regularly toss up a 
throw-away branch to make small commits that may or may not work and 
later apply the (tested) combined diff as a single commit or series of 
commits at points where I've tested one feature/fix to actually work as 
intended. This is nifty because people that help with testing can pull 
from my throw-away branch and get to work without me having to send them 
a tar-tree and a patch.

I believe in not *pushing* anything that hasn't been thoroughly tested, 
but the ability to track and commit possibly broken changes without it 
affecting the project as a whole is what makes git so great for me. In 
the CVS days distributed testing was a nuissance. With git it's smooth 
sailing.

> 
>>Those flags don't exist currently btw, in case someone's reading this
>>on the archives.
> 
> 
> I take it that you are volunteering to come up with an initial
> round of implementation of these flags?
> 

Unless someone can convince me I'm on the wrong track before I get off 
work, yes.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231