On Tue, Apr 4, 2023 at 9:00 AM Hongyi Zhao <hongyi.zhao@xxxxxxxxx> wrote:
[various previous conversations and methods-that-work snipped]
> But I still wonder why the following method doesn't work:
>
> werner@X10DAi:~$ git revert f18fbd1e16a1ca4215621768d17858c036086608
> --no-commit -- Public/CTAN/IDE/phonon/compile-install-phonon
> Public/CTAN/IDE/texstudio-org/texstudio.git.sh
> fatal: bad revision 'Public/CTAN/IDE/phonon/compile-install-phonon'
Neither `git cherry-pick` nor `git revert` allow specifying files.
There are some terminology issues here that, if clarified, may
help you in thinking about all of this. (Some of these may
involve language translation issues as well.)
In Git, a *commit* is an atomic entity consisting of two parts:
information about the commit itself (metadata such as the name
of the commit's author, some time stamps, and so on) and a
full snapshot of files.
A commit *is not* a *set of changes*. It *is* a snapshot. We
can form a sort of "changeset algebra" out of these things,
by which taking two snapshots and subtracting them produces a
delta, in the same way that taking two integers and subtracting
produces a delta:
delta = v2 - v1
In this algebra:
v1 + delta = v2
The same works in integer arithmetic, of course. In integer
arithmetic, a sum of any set of deltas can be used as a new delta.
But this is not true of "source code deltas" since one delta may
show a file being deleted entirely and another delta may show
the same file being changed. We lose some properties, such as
the ability to do order reversals (commutativity). So we must
be careful to treat deltas as nothing but deltas, and snapshots
as nothing but snapshots.
Now, `git cherry-pick` means: given some commit, find its parent
(singular), then use that parent/child pair to compute a delta.
Attempt to apply *that* delta to the *current commit and working
tree* snapshot.
Similarly, `git revert` means: given some commit, find its parent
(again, singular), and use that parent/child pair to compute a
delta. Attempt to reverse-apply that delta to the current commit
and working tree snapshot.
This kind of operation produces a new commit, so there's no such
thing as a partial revert or partial cherry-pick, at least in
terms of "things Git can do by itself". But we, as humans writing
programs, wish to *achieve* such things.
It's probably wisest to avoid calling these things "partial
reverts" or "partial cherry-picks". This is the terminology
issue: these phrases make sense to humans, but not to Git. You, a
human, can achieve these results, but if you ask Git to do a
revert or cherry-pick, Git will attempt to do a revert or cherry-
pick -- not a "partial revert", whatever you mean by that!
To do what you want, you will want to:
* compute the appropriate delta, then
* pick and choose some part(s) of this delta to apply or
reverse-apply
and there are many ways to do that, but none of them involve
using *only* `git revert`.
Chris
