On Tue, Apr 4, 2023 at 3:08 PM Sergey Organov <sorganov@xxxxxxxxx> wrote: > > Junio C Hamano <gitster@xxxxxxxxx> writes: > > > Sergey Organov <sorganov@xxxxxxxxx> 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
