Neal Kreitzinger [off-list ref] writes:
A main purpose for the squash and fixup options is ...
"To make it look like you
did it all perfectly without making any mistakes" (or a reasonable
facsimile thereof). You insights on the cherry-picking of fixes is
interesting, but makes no sense in the context of unpublished work.
Why would you need to cherry-pick fixes to mistakes that have not yet
been propagated (published)?
...
I assume by 'generated changes' you mean the automerge in git...
My reading of the "need to split" example was not "bulk of work plus fixes
to mistakes". Imagine you are working on somebody else's code and for some
reason you want to do
s/setenv/xsetenv/g
all over the code, and also add a wrapper to implement xsetenv() function.
You _could_ do it in one single commit, but what happens when you try to
adjust to the updated upstream code, which may have added new callsites to
setenv()?
If you keep it as two patches, one is mechanical (i.e. s/setenv/xsetenv/g)
and the other is manual (i.e. implementation of xsetenv()), then you can
discard the text of the "mechanical" one from the old series and instead
run the substitution on the updated code, and then cherry-pick the
"manual" one.
If you did the mechanical one first, the resulting code would not compile
(lacks xsetenv() implementation), and then the second "manual" one would
"fix" it. In this simplified example, it is easy to flip the orders and
keep things work, but then you would get a complaint from clever compiler
or linker that xsetenv() implementation is defined but nobody uses it,
which is another kind of breakage. So it _is_ possible that you cannot
avoid breaking the system inside two patches, making them "all-or-none"
series.
[Neal Kreitzinger]
I assume by 'generated changes' you mean the automerge in git...
No. And to your questions of why I want this with unpublished work:
No. Like I wrote, I'm talking about published commits.
[Junio C Hamano]
My reading of the "need to split" example was not "bulk of work plus fixes
to mistakes". Imagine you are working on somebody else's code and for some
reason you want to do
s/setenv/xsetenv/g
all over the code, and also add a wrapper to implement xsetenv() function.
Yes - except there is no "mistakes" since it's deliberate. I'd do
s/setenv/xsetenv/g, which does too little (misses some preprocessor
stuff) or is too greedy, then commit anyway and clean up in next commit.
I could make and commit a much more complicated script to do it all, but
that's unhelpful when trying to read what the heck the change is doing.
And who knows what it'd do when run on a somewhat different codebase.
That example matches a future internal API change. My current issue
is changes generated with 'autoreconf' - after cleaning up an utter
libtool/automake mess by hand, which will break things if I don't
autoreconf in the same commmit.
You _could_ do it in one single commit, but what happens when you try to
adjust to the updated upstream code, which may have added new callsites to
setenv()?
Indeed. In this case, it'd be when cherry-picking from the devel branch
to the release branch. These still differ too much, a legacy of our old
CVS workflow.
If you keep it as two patches, one is mechanical (i.e. s/setenv/xsetenv/g)
and the other is manual (i.e. implementation of xsetenv()), then you can
discard the text of the "mechanical" one from the old series and instead
run the substitution on the updated code, and then cherry-pick the
"manual" one.
Yes. I'd order it in a sequence which never broke anything if I could.
Well, come to think of it: Possibly I could introduce some new code
which would only exist for the sake of patching over the temporary
breakage, and then delete that code again 2-3 commits later. In this
case, I'd among other things create an obsolete libtool.m4 which is
currently hiding inside aclocal.m4. Not sure if that makes more sense
than just having a few broken commits.
--
Hallvard
I wrote:
[Neal Kreitzinger]
quoted
I assume by 'generated changes' you mean the automerge in git...
No. And to your questions of why I want this with unpublished work:
No. Like I wrote, I'm talking about published commits.
Wait, I see - as-yet unpublished commits, yes. Which seem best to me to
publish that way. And which will get cherry-picked later, after commit
and testing.
--
Hallvard