Re: git revert with partial commit.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

[...]

> 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



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux