Felipe Contreras <felipe.contreras@xxxxxxxxx> writes: > 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. 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
