Junio C Hamano wrote:
Andreas Ericsson <ae@xxxxxx> 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@xxxxxx
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
-
: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html