git revert with partial commit.

git revert with partial commit.

[Hongyi Zhao]

Hi here,

I want to revert a previous commit partially, as follows:

werner@X10DAi:~$ git log |grep -A3 -B5 -m1 texstudio
commit f18fbd1e16a1ca4215621768d17858c036086608
Author: Hongyi Zhao <hongyi.zhao@gmail.com>
Date:   Sun Aug 1 20:01:02 2021 +0800

    deleted:    Public/CTAN/IDE/phonon/compile-install-phonon
    deleted:    Public/CTAN/IDE/texstudio-org/texstudio.git.sh
    modified:   Public/repo/github.com/Dushistov/sdcv.git.sh
    deleted:    Public/repo/github.com/goldendict/stardict-relative/bigdict

More specifically, I just want to revert the following ones:

    deleted:    Public/CTAN/IDE/phonon/compile-install-phonon
    deleted:    Public/CTAN/IDE/texstudio-org/texstudio.git.sh

Is this possible?

Regards,
Zhao
-- 
Assoc. Prof. Hongsheng Zhao <hongyi.zhao@gmail.com>
Theory and Simulation of Materials
Hebei Vocational University of Technology and Engineering
No. 473, Quannan West Street, Xindu District, Xingtai, Hebei province

Re: git revert with partial commit.

[Torsten Bögershausen]

On Sun, Apr 02, 2023 at 05:17:30PM +0800, Hongyi Zhao wrote:
> Hi here,
>
> I want to revert a previous commit partially, as follows:
>
> werner@X10DAi:~$ git log |grep -A3 -B5 -m1 texstudio
> commit f18fbd1e16a1ca4215621768d17858c036086608
> Author: Hongyi Zhao <hongyi.zhao@gmail.com>
> Date:   Sun Aug 1 20:01:02 2021 +0800
>
>     deleted:    Public/CTAN/IDE/phonon/compile-install-phonon
>     deleted:    Public/CTAN/IDE/texstudio-org/texstudio.git.sh
>     modified:   Public/repo/github.com/Dushistov/sdcv.git.sh
>     deleted:    Public/repo/github.com/goldendict/stardict-relative/bigdict
>
> More specifically, I just want to revert the following ones:
>
>     deleted:    Public/CTAN/IDE/phonon/compile-install-phonon
>     deleted:    Public/CTAN/IDE/texstudio-org/texstudio.git.sh
>
> Is this possible?

It is.
Find the last commit that had those 2 files, in other word the commit
before f18fbd1e16a1ca4215621, say it is xyz.

git checkout xyz -- Public/CTAN/IDE/phonon/compile-install-phonon
should get the first file back into your working tree and staged.

(Of course, this is out of my head. And you should be able to "restore"
both files in one go.)

Good luck.

Re: git revert with partial commit.

[Junio C Hamano]

Torsten Bögershausen <tboegi@web.de> writes:

> Find the last commit that had those 2 files, in other word the commit
> before f18fbd1e16a1ca4215621, say it is xyz.
>
> git checkout xyz -- Public/CTAN/IDE/phonon/compile-install-phonon
> should get the first file back into your working tree and staged.
>
> (Of course, this is out of my head. And you should be able to "restore"
> both files in one go.)

If the (old) version of these files existed in one (old) commit,
yes, you should be able to do that.

Thanks.

Re: git revert with partial commit.

[Phillip Susi]

Hongyi Zhao <hongyi.zhao@gmail.com> writes:

> Hi here,
>
> I want to revert a previous commit partially, as follows:
>
> werner@X10DAi:~$ git log |grep -A3 -B5 -m1 texstudio
> commit f18fbd1e16a1ca4215621768d17858c036086608
> Author: Hongyi Zhao <hongyi.zhao@gmail.com>
> Date:   Sun Aug 1 20:01:02 2021 +0800
>
>     deleted:    Public/CTAN/IDE/phonon/compile-install-phonon
>     deleted:    Public/CTAN/IDE/texstudio-org/texstudio.git.sh
>     modified:   Public/repo/github.com/Dushistov/sdcv.git.sh
>     deleted:    Public/repo/github.com/goldendict/stardict-relative/bigdict
>
> More specifically, I just want to revert the following ones:
>
>     deleted:    Public/CTAN/IDE/phonon/compile-install-phonon
>     deleted:    Public/CTAN/IDE/texstudio-org/texstudio.git.sh
>
> Is this possible?

If you are comfortable with git-gui and gitk, then I would say just
revert it, then click ammend the previous commit in git-gui, and click
to unstage the changes you DON'T want to revert, then commit.  If you
want to do it from the command line, then git-revert, then git checkout
HEAD~1 -- ( the other 4 file names here ) will get back the other 4
files then you can git commit --amend.  Alternatively you can skip
git-revert and instead git checkout f18fbd1e16~1 -- (the two files that
you DO want to revert), then git commit.

Re: git revert with partial commit.

[Hongyi Zhao]

On Tue, Apr 4, 2023 at 2:36 AM Phillip Susi <phill@thesusis.net> wrote:
>
>
> Hongyi Zhao <hongyi.zhao@gmail.com> writes:
>
> > Hi here,
> >
> > I want to revert a previous commit partially, as follows:
> >
> > werner@X10DAi:~$ git log |grep -A3 -B5 -m1 texstudio
> > commit f18fbd1e16a1ca4215621768d17858c036086608
> > Author: Hongyi Zhao <hongyi.zhao@gmail.com>
> > Date:   Sun Aug 1 20:01:02 2021 +0800
> >
> >     deleted:    Public/CTAN/IDE/phonon/compile-install-phonon
> >     deleted:    Public/CTAN/IDE/texstudio-org/texstudio.git.sh
> >     modified:   Public/repo/github.com/Dushistov/sdcv.git.sh
> >     deleted:    Public/repo/github.com/goldendict/stardict-relative/bigdict
> >
> > More specifically, I just want to revert the following ones:
> >
> >     deleted:    Public/CTAN/IDE/phonon/compile-install-phonon
> >     deleted:    Public/CTAN/IDE/texstudio-org/texstudio.git.sh
> >
> > Is this possible?
>
> If you are comfortable with git-gui and gitk, then I would say just
> revert it, then click ammend the previous commit in git-gui, and click
> to unstage the changes you DON'T want to revert, then commit.  If you
> want to do it from the command line, then git-revert, then git checkout
> HEAD~1 -- ( the other 4 file names here ) will get back the other 4
> files then you can git commit --amend.  Alternatively you can skip
> git-revert and instead git checkout f18fbd1e16~1 -- (the two files that
> you DO want to revert), then git commit.

Thanks for your tips. I've also figured out the similar solution based
on the comment here [1], as shown below:

$ git show f18fbd1e16a1ca4215621768d17858c036086608 --
Public/CTAN/IDE/phonon/compile-install-phonon
Public/CTAN/IDE/texstudio-org/texstudio.git.sh | git apply --reverse
--3way

Because the commit I want to revert is done a long time ago, which is
not the parent of the commit I'm currently on, so I can't use the `~1`
which indicates that I want to go back one commit from my current
position.

[1] https://stackoverflow.com/questions/5669358/can-i-do-a-partial-revert-in-git

Best,
Zhao

Re: git revert with partial commit.

[Hongyi Zhao]

On Sun, Apr 2, 2023 at 10:16 PM Torsten Bögershausen <tboegi@web.de> wrote:
>
> On Sun, Apr 02, 2023 at 05:17:30PM +0800, Hongyi Zhao wrote:
> > Hi here,
> >
> > I want to revert a previous commit partially, as follows:
> >
> > werner@X10DAi:~$ git log |grep -A3 -B5 -m1 texstudio
> > commit f18fbd1e16a1ca4215621768d17858c036086608
> > Author: Hongyi Zhao <hongyi.zhao@gmail.com>
> > Date:   Sun Aug 1 20:01:02 2021 +0800
> >
> >     deleted:    Public/CTAN/IDE/phonon/compile-install-phonon
> >     deleted:    Public/CTAN/IDE/texstudio-org/texstudio.git.sh
> >     modified:   Public/repo/github.com/Dushistov/sdcv.git.sh
> >     deleted:    Public/repo/github.com/goldendict/stardict-relative/bigdict
> >
> > More specifically, I just want to revert the following ones:
> >
> >     deleted:    Public/CTAN/IDE/phonon/compile-install-phonon
> >     deleted:    Public/CTAN/IDE/texstudio-org/texstudio.git.sh
> >
> > Is this possible?
>
> It is.
> Find the last commit that had those 2 files, in other word the commit
> before f18fbd1e16a1ca4215621, say it is xyz.
>
> git checkout xyz -- Public/CTAN/IDE/phonon/compile-install-phonon
> should get the first file back into your working tree and staged.
>
> (Of course, this is out of my head. And you should be able to "restore"
> both files in one go.)

Thanks a lot for this nice trick, and it works like a charm.

> Good luck.

Best,
Zhao

Re: git revert with partial commit.

[Hongyi Zhao]

On Tue, Apr 4, 2023 at 8:20 AM Hongyi Zhao <hongyi.zhao@gmail.com> wrote:
>
> On Tue, Apr 4, 2023 at 2:36 AM Phillip Susi <phill@thesusis.net> wrote:
> >
> >
> > Hongyi Zhao <hongyi.zhao@gmail.com> writes:
> >
> > > Hi here,
> > >
> > > I want to revert a previous commit partially, as follows:
> > >
> > > werner@X10DAi:~$ git log |grep -A3 -B5 -m1 texstudio
> > > commit f18fbd1e16a1ca4215621768d17858c036086608
> > > Author: Hongyi Zhao <hongyi.zhao@gmail.com>
> > > Date:   Sun Aug 1 20:01:02 2021 +0800
> > >
> > >     deleted:    Public/CTAN/IDE/phonon/compile-install-phonon
> > >     deleted:    Public/CTAN/IDE/texstudio-org/texstudio.git.sh
> > >     modified:   Public/repo/github.com/Dushistov/sdcv.git.sh
> > >     deleted:    Public/repo/github.com/goldendict/stardict-relative/bigdict
> > >
> > > More specifically, I just want to revert the following ones:
> > >
> > >     deleted:    Public/CTAN/IDE/phonon/compile-install-phonon
> > >     deleted:    Public/CTAN/IDE/texstudio-org/texstudio.git.sh
> > >
> > > Is this possible?
> >
> > If you are comfortable with git-gui and gitk, then I would say just
> > revert it, then click ammend the previous commit in git-gui, and click
> > to unstage the changes you DON'T want to revert, then commit.  If you
> > want to do it from the command line, then git-revert, then git checkout
> > HEAD~1 -- ( the other 4 file names here ) will get back the other 4
> > files then you can git commit --amend.  Alternatively you can skip
> > git-revert and instead git checkout f18fbd1e16~1 -- (the two files that
> > you DO want to revert), then git commit.
>
> Thanks for your tips. I've also figured out the similar solution based
> on the comment here [1], as shown below:
>
> $ git show f18fbd1e16a1ca4215621768d17858c036086608 --
> Public/CTAN/IDE/phonon/compile-install-phonon
> Public/CTAN/IDE/texstudio-org/texstudio.git.sh | git apply --reverse
> --3way
>
> Because the commit I want to revert is done a long time ago, which is
> not the parent of the commit I'm currently on, so I can't use the `~1`
> which indicates that I want to go back one commit from my current
> position.

Sorry for my inappropriate description above. In fact, it's a more
concise method which also will do the trick, aka, as follows:

$ git checkout f18fbd1e16~1 --
Public/CTAN/IDE/phonon/compile-install-phonon
Public/CTAN/IDE/texstudio-org/texstudio.git.sh

> [1] https://stackoverflow.com/questions/5669358/can-i-do-a-partial-revert-in-git
>
> Best,
> Zhao

Re: git revert with partial commit.

[Hongyi Zhao]

On Tue, Apr 4, 2023 at 8:37 AM Hongyi Zhao <hongyi.zhao@gmail.com> wrote:
>
> On Tue, Apr 4, 2023 at 8:20 AM Hongyi Zhao <hongyi.zhao@gmail.com> wrote:
> >
> > On Tue, Apr 4, 2023 at 2:36 AM Phillip Susi <phill@thesusis.net> wrote:
> > >
> > >
> > > Hongyi Zhao <hongyi.zhao@gmail.com> writes:
> > >
> > > > Hi here,
> > > >
> > > > I want to revert a previous commit partially, as follows:
> > > >
> > > > werner@X10DAi:~$ git log |grep -A3 -B5 -m1 texstudio
> > > > commit f18fbd1e16a1ca4215621768d17858c036086608
> > > > Author: Hongyi Zhao <hongyi.zhao@gmail.com>
> > > > Date:   Sun Aug 1 20:01:02 2021 +0800
> > > >
> > > >     deleted:    Public/CTAN/IDE/phonon/compile-install-phonon
> > > >     deleted:    Public/CTAN/IDE/texstudio-org/texstudio.git.sh
> > > >     modified:   Public/repo/github.com/Dushistov/sdcv.git.sh
> > > >     deleted:    Public/repo/github.com/goldendict/stardict-relative/bigdict
> > > >
> > > > More specifically, I just want to revert the following ones:
> > > >
> > > >     deleted:    Public/CTAN/IDE/phonon/compile-install-phonon
> > > >     deleted:    Public/CTAN/IDE/texstudio-org/texstudio.git.sh
> > > >
> > > > Is this possible?
> > >
> > > If you are comfortable with git-gui and gitk, then I would say just
> > > revert it, then click ammend the previous commit in git-gui, and click
> > > to unstage the changes you DON'T want to revert, then commit.  If you
> > > want to do it from the command line, then git-revert, then git checkout
> > > HEAD~1 -- ( the other 4 file names here ) will get back the other 4
> > > files then you can git commit --amend.  Alternatively you can skip
> > > git-revert and instead git checkout f18fbd1e16~1 -- (the two files that
> > > you DO want to revert), then git commit.
> >
> > Thanks for your tips. I've also figured out the similar solution based
> > on the comment here [1], as shown below:
> >
> > $ git show f18fbd1e16a1ca4215621768d17858c036086608 --
> > Public/CTAN/IDE/phonon/compile-install-phonon
> > Public/CTAN/IDE/texstudio-org/texstudio.git.sh | git apply --reverse
> > --3way
> >
> > Because the commit I want to revert is done a long time ago, which is
> > not the parent of the commit I'm currently on, so I can't use the `~1`
> > which indicates that I want to go back one commit from my current
> > position.
>
> Sorry for my inappropriate description above. In fact, it's a more
> concise method which also will do the trick, aka, as follows:
>
> $ git checkout f18fbd1e16~1 --
> Public/CTAN/IDE/phonon/compile-install-phonon
> Public/CTAN/IDE/texstudio-org/texstudio.git.sh

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'


> > [1] https://stackoverflow.com/questions/5669358/can-i-do-a-partial-revert-in-git
> >
> > Best,
> > Zhao

Re: git revert with partial commit.

[Chris Torek]

On Tue, Apr 4, 2023 at 9:00 AM Hongyi Zhao <hongyi.zhao@gmail.com> 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

Re: git revert with partial commit.

[Sergey Organov]

Chris Torek <chris.torek@gmail.com> writes:

> On Tue, Apr 4, 2023 at 9:00 AM Hongyi Zhao <hongyi.zhao@gmail.com> 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'

[...]

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

So, why Git can't help us achieving it by supporting paths limiting in
(all) merge operations? There seems to be no absolute obstacles, just a
luck of support.

Thanks,
-- Sergey

Re: git revert with partial commit.

[Junio C Hamano]

Sergey Organov <sorganov@gmail.com> writes:

>> 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.
>
> So, why Git can't help us achieving it by supporting paths limiting in
> (all) merge operations? There seems to be no absolute obstacles, just a
> luck of support.

I think there is no fundamental reason to forbid an optional
pathspec to "cherry-pick" and "revert", given that a commit that
results from either "git cherry-pick" or "git revert" is called a
"cherry-pick" or a "revert" merely by convention and there is no
tool-level support to treat them any specially at merge or rebase
time [*1*].  It would make it harder to design tool-level support
for full cherry-picks or reverts, but that is a problem for future
generation, not ours ;-)  Allowing pathspec to "merge" and recording
the result as a merge of two (or more) parents is an absolute no-no
but that is not what we are discussing.

But in practice, the part that takes the most brain work in a revert
or cherry-pick that is not an outright "the effect of that commit as
its entirety is now gone" is not the mechanical (partial)
reapplication, but coming up with a good split of the original (or
the reverse of the original) and a good explanation.  Especially
given that it would be just the matter of running these commands
with "--no-commit", selectively resetting the paths that the user
does not want to touch, before spending some quality time describing
what the user did in the resulting commit, it is very understandable
if teaching pathspec to these commands has been outside anybody's
priority list so far.

But I do not think Chris meant to say "you should not expect such a
feature"; what we heard was a reasonable explanation of how the
current world works, and I do not see a reason to react strongly to
such a statement as if you were unreasonably forbidden from doing
something sensible.


[Footnote]

*1* If there were, it would totally be a different story.  For
example, merging a branch that has a revert of a commit X to a
branch that has the original commit X _may_ want to avoid replaying
the revert from the side branch in the result depending on the
circumstances, but it will be even less clear what to do if such a
"special cased" revert were a partial one).

Re: git revert with partial commit.

[Sergey Organov]

Junio C Hamano <gitster@pobox.com> writes:

> Sergey Organov <sorganov@gmail.com> writes:
>
>>> 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.
>>
>> So, why Git can't help us achieving it by supporting paths limiting in
>> (all) merge operations? There seems to be no absolute obstacles, just a
>> luck of support.
>
> I think there is no fundamental reason to forbid an optional
> pathspec to "cherry-pick" and "revert", given that a commit that
> results from either "git cherry-pick" or "git revert" is called a
> "cherry-pick" or a "revert" merely by convention and there is no
> tool-level support to treat them any specially at merge or rebase
> time [*1*].  It would make it harder to design tool-level support
> for full cherry-picks or reverts, but that is a problem for future
> generation, not ours ;-)  Allowing pathspec to "merge" and recording
> the result as a merge of two (or more) parents is an absolute no-no
> but that is not what we are discussing.

If I got this right, you believe that "git merge" should never have
support for "partial merges", whereas it makes sense for cherry-pick and
revert? If so, I disagree. There is no reason for Git to strictly
prevent me from using the feature specifically in "git merge" (once it's
otherwise implemented), provided I do mean it and didn't do it by
mistake.

Please notice that I can do it right now already (and I did a few
times), only with a more pain than necessary, and I don't see why this
pain is to be preserved (provided we do have the feature implemented in
the future). Besides, "git merge" is only a helper, and it'd be an
improvement if it'll be capable to help in more cases.

[...]

> But I do not think Chris meant to say "you should not expect such a
> feature"; what we heard was a reasonable explanation of how the
> current world works, and I do not see a reason to react strongly to
> such a statement as if you were unreasonably forbidden from doing
> something sensible.

Nice, so I figure I may allow myself to still keep a weak hope for the
feature, and thus stop being forbidden, even if not unreasonably, from
doing something sensible. ;-)

Thanks,
-- Sergey Organov

Re: git revert with partial commit.

[Junio C Hamano]

Sergey Organov <sorganov@gmail.com> writes:

> If I got this right, you believe that "git merge" should never have
> support for "partial merges",...

Correct, and that is not just a belief, but it needs stepping back
two steps to understand why.  Unfortunately I do not have time for
that today, so maybe some other occasion.

Re: git revert with partial commit.

[Felipe Contreras]

On Tue, Apr 4, 2023 at 3:08 PM Sergey Organov <sorganov@gmail.com> wrote:
>
> Junio C Hamano <gitster@pobox.com> writes:
>
> > Sergey Organov <sorganov@gmail.com> writes:
> >
> >>> 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.
> >>
> >> So, why Git can't help us achieving it by supporting paths limiting in
> >> (all) merge operations? There seems to be no absolute obstacles, just a
> >> luck of support.
> >
> > I think there is no fundamental reason to forbid an optional
> > pathspec to "cherry-pick" and "revert", given that a commit that
> > results from either "git cherry-pick" or "git revert" is called a
> > "cherry-pick" or a "revert" merely by convention and there is no
> > tool-level support to treat them any specially at merge or rebase
> > time [*1*].  It would make it harder to design tool-level support
> > for full cherry-picks or reverts, but that is a problem for future
> > generation, not ours ;-)  Allowing pathspec to "merge" and recording
> > the result as a merge of two (or more) parents is an absolute no-no
> > but that is not what we are discussing.
>
> If I got this right, you believe that "git merge" should never have
> support for "partial merges", whereas it makes sense for cherry-pick and
> revert? If so, I disagree. There is no reason for Git to strictly
> prevent me from using the feature specifically in "git merge" (once it's
> otherwise implemented), provided I do mean it and didn't do it by
> mistake.
>
> Please notice that I can do it right now already (and I did a few
> times), only with a more pain than necessary, and I don't see why this
> pain is to be preserved (provided we do have the feature implemented in
> the future). Besides, "git merge" is only a helper, and it'd be an
> improvement if it'll be capable to help in more cases.

This sounds awfully familiar to Mercurial's reluctance to support
rewriting history. It wasn't the tool's place to prescribe what the
users should or shouldn't do.

If the user wants to do it, the tool should help him do it, not
pontificate about what is heretic.

The user is still going to do it, like with a rebase plugin on
Mercurial, or with `git filter-branch` and then merge the result. All
the tool is achieving is being annoying by not helping the user.

> > But I do not think Chris meant to say "you should not expect such a
> > feature"; what we heard was a reasonable explanation of how the
> > current world works, and I do not see a reason to react strongly to
> > such a statement as if you were unreasonably forbidden from doing
> > something sensible.
>
> Nice, so I figure I may allow myself to still keep a weak hope for the
> feature, and thus stop being forbidden, even if not unreasonably, from
> doing something sensible. ;-)

I wouldn't. Features agreed by everyone decades ago never got merged,
even features already agreed by the maintainer.

Cheers.

-- 
Felipe Contreras

Re: git revert with partial commit.

[Sergey Organov]

Felipe Contreras <felipe.contreras@gmail.com> writes:

> On Tue, Apr 4, 2023 at 3:08 PM Sergey Organov <sorganov@gmail.com> wrote:
>>
>> Junio C Hamano <gitster@pobox.com> writes:
>>
>> > Sergey Organov <sorganov@gmail.com> writes:
>> >
>> >>> 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.
>> >>
>> >> So, why Git can't help us achieving it by supporting paths limiting in
>> >> (all) merge operations? There seems to be no absolute obstacles, just a
>> >> luck of support.
>> >
>> > I think there is no fundamental reason to forbid an optional
>> > pathspec to "cherry-pick" and "revert", given that a commit that
>> > results from either "git cherry-pick" or "git revert" is called a
>> > "cherry-pick" or a "revert" merely by convention and there is no
>> > tool-level support to treat them any specially at merge or rebase
>> > time [*1*].  It would make it harder to design tool-level support
>> > for full cherry-picks or reverts, but that is a problem for future
>> > generation, not ours ;-)  Allowing pathspec to "merge" and recording
>> > the result as a merge of two (or more) parents is an absolute no-no
>> > but that is not what we are discussing.
>>
>> If I got this right, you believe that "git merge" should never have
>> support for "partial merges", whereas it makes sense for cherry-pick and
>> revert? If so, I disagree. There is no reason for Git to strictly
>> prevent me from using the feature specifically in "git merge" (once it's
>> otherwise implemented), provided I do mean it and didn't do it by
>> mistake.
>>
>> Please notice that I can do it right now already (and I did a few
>> times), only with a more pain than necessary, and I don't see why this
>> pain is to be preserved (provided we do have the feature implemented in
>> the future). Besides, "git merge" is only a helper, and it'd be an
>> improvement if it'll be capable to help in more cases.
>
> This sounds awfully familiar to Mercurial's reluctance to support
> rewriting history. It wasn't the tool's place to prescribe what the
> users should or shouldn't do.
>
> If the user wants to do it, the tool should help him do it, not
> pontificate about what is heretic.
>
> The user is still going to do it, like with a rebase plugin on
> Mercurial, or with `git filter-branch` and then merge the result. All
> the tool is achieving is being annoying by not helping the user.

Yep, and I'm worried by such trends in Git as well. Looks like growing
influence of software development culture where the user is not
considered to be intelligent enough to make proper decisions by himself,
and needs to be thoroughly guided by the tool (designers) all the time.

Thanks,
-- Sergey Organov

Re: git revert with partial commit.

[Phillip Susi]

Hongyi Zhao <hongyi.zhao@gmail.com> writes:

> Because the commit I want to revert is done a long time ago, which is
> not the parent of the commit I'm currently on, so I can't use the `~1`
> which indicates that I want to go back one commit from my current
> position.

You *can* use HEAD~1.  After the git revert, a new commit has been
created, and so HEAD~1 refers to the state of things before running git
revert.

Re: git revert with partial commit.

[Felipe Contreras]

On Wed, Apr 5, 2023 at 1:39 AM Sergey Organov <sorganov@gmail.com> wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:

> > If the user wants to do it, the tool should help him do it, not
> > pontificate about what is heretic.
> >
> > The user is still going to do it, like with a rebase plugin on
> > Mercurial, or with `git filter-branch` and then merge the result. All
> > the tool is achieving is being annoying by not helping the user.
>
> Yep, and I'm worried by such trends in Git as well. Looks like growing
> influence of software development culture where the user is not
> considered to be intelligent enough to make proper decisions by himself,
> and needs to be thoroughly guided by the tool (designers) all the time.

Which ironically goes against the philosophy of the original author of Git:

> No project is more important than the users of the project. -- Linus Torvalds

-- 
Felipe Contreras

Re: git revert with partial commit.

[Sergey Organov]

Felipe Contreras <felipe.contreras@gmail.com> writes:

> On Wed, Apr 5, 2023 at 1:39 AM Sergey Organov <sorganov@gmail.com>
> wrote:
>> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> > If the user wants to do it, the tool should help him do it, not
>> > pontificate about what is heretic.
>> > The user is still going to do it, like with a rebase plugin on
>> > Mercurial, or with `git filter-branch` and then merge the result.
>> > All the tool is achieving is being annoying by not helping the
>> > user.
>> Yep, and I'm worried by such trends in Git as well. Looks like
>> growing influence of software development culture where the user is
>> not considered to be intelligent enough to make proper decisions by
>> himself, and needs to be thoroughly guided by the tool (designers)
>> all the time.
>
> Which ironically goes against the philosophy of the original author of
> Git:
>
>> No project is more important than the users of the project.
>> -- Linus Torvalds

I rather bother about too much care for the users in the aforementioned
cases, similar to the way overly cautious mother cares about her
children, all this being absolutely well-intentioned.

The problem with such care is that it's inefficient to drive nails in
with a hand hammer in a soft wrapping, though it's admittedly less
dangerous for ones fingers.

Overall, when using a tool, I prefer to feel myself a grown-up human
being responsible for my own actions, rather than a child under intense
guidance and excessive protection. I'm thankful for proper safety
measures, but I want potentially unsafe action to be performed
nevertheless when I actually mean it, instead of lengthy display of
rhetorics about why I should not have had even attempted it in the first
place.

-- 
Sergey Organov