Re: n-heads and patch dependency chains

From: Junio C Hamano <junkio@cox.net>
Date: Apr 4, 2006, 09:51 UTC
Message-ID: <7v1wwd8y9j.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <44323C52.2030803@op5.se>

Andreas Ericsson <ae@op5.se> writes:

Show 18 quoted lines

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

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*].

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.

But that is just my personal preference, and it does not necessarily have to stop people wishing to have that feature to have it, especially when there are enough of them.

> 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?

[Footnote]

*1* ... that's where "git checkout -m that-topic", perhaps
 followed by "git diff HEAD", comes in.