[git-users] Re: Should 'git revert' provide an option to ignore the patch context?

2017-06-22 Thread Igor Djordjevic 
On Thursday, June 22, 2017 at 1:00:05 PM UTC+2, Harry wrote:
>
> I found your response very helpful, Buga, especially the last part where 
> you apply the patch in reverse without the unified diff context.
>
> Thanks and regards,
> /HS
>

No problem, I`m glad it helped, I learned something new as well :)

Regards,
Buga

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[git-users] Re: Should 'git revert' provide an option to ignore the patch context?

2017-06-22 Thread Harry 
I found your response very helpful, Buga, especially the last part where 
you apply the patch in reverse without the unified diff context.

Thanks and regards,
/HS

On Sunday, June 18, 2017 at 5:26:46 PM UTC+5:30, Igor Djordjevic wrote:
>
> Hi Harry,
>
> On Wednesday, June 14, 2017 at 6:12:28 PM UTC+2, Harry wrote:
>>
>> I had posted my question earlier on StackOverflow, here: 
>> 
>> https://stackoverflow.com/questions/44543219/git-revert-unable-to-undo-an-individual-commit-even-in-a-simple-case
>>
>
> I`d say you got a pretty straight answer there already, but let`s try to 
> address the questions you`ve raised here as well.
>
>
> *1. *Would having a new option (such as *--ignore-patch-context *) while 
>> doing *git revert* make sense?
>>
>
> While being possible, whether it would make sense is arguable, as using 
> context-free patches is already discouraged as unsafe in general (see 
> *git-apply 
> --unidiff-zero*[1] 
> ).
>
> But, as it`s already implemented for `git-apply`, it might make sense to 
> have it for `git-revert` as well, being noted as discouraged in the same 
> manner...? And I guess nobody needed it much so far, thus it`s not 
> implemented yet?
>
> That said, you`re free to bring the discussion to the main *Git mailing 
> list*[2]  (that`s where the development happens), and try 
> the patch yourself :) Please note that only plain-text e-mails are 
> accepted, no HTML.
>
>
> This option when used would carry out the *revert* mechanically/blindly 
>> and leave the result in an uncommitted state (with maybe a warning on the 
>> console), allowing the user to verify things for syntax and semantics 
>> before committing.  
>>
>
> Now, might be you`re not seeing it that way, but this is _exactly_ what 
> Git is doing - it carries out the revert mechanically/blindly and leaves 
> the result in uncommited state (with merge conflict warning on the 
> console), allowing the user to verify things for syntax and semantics 
> before _resolving merge conflicts_ and commiting.
>
> The only difference is that instead of your proposed _changing_ of the 
> merge result by trying a lucky guess on what should the final state be 
> (disregarding context, which is certainly not a blind/mechanical thing to 
> do), making it harder for user to comprehend what actually happened, it 
> _really_ does its thing blindly (respecting the context), taking both sides 
> of the change (before/after) and leaving them as-is for the user to make 
> sense of it.
>
> For "simple case" you`re discussing here (simple for human, that is, still 
> not for a machine), it`s trivial for a user to make sense of the merge 
> conflicts and resolve them correctly (and easily/quickly), and you even 
> have various GUI tools to help if raw conflict markers confuse you.
>
>
> All this said, let me tell you that what you want is actually already 
> possible with Git... ;) Well, might be not as directly as you hoped for, 
> but instead of your:
>
> (*1*) $ git revert master^^
>
> ... step, what you could try doing is this:
>
> (*2*) $ git show master^^ >bug.patch
> (*3*) $ git apply --reverse --unidiff-zero bug.patch
>
> Command on line (*2*) creates a "bug.patch" file holding the diff/patch 
> that "bug" commit introduced. Command on line (*3*) applies this patch, 
> but in reverse (note the `--reverse` parameter), so instead of adding the 
> "Bug" line it removes it, and `--unidiff-zero` parameter tells it to 
> disregard context lines - which is exactly what you`re looking for... :) 
> Now you can review the change, and commit it.
>
> For a safety measure, please note again that usage of context-free patches 
> is discouraged, being more error-prone.
>
>
> 2. Is there any documentation where such details of the operations (such 
>> as *revert*, *merge, *...) are described?
>>
>
> Not sure if this is what you have in mind, but there`s Git *reference 
> manual*[3]  (holding more info on *git-revert*
> [4]  and *git-merge*[5] 
>  as well).
>
> [1] https://git-scm.com/docs/git-apply#git-apply---unidiff-zero
> [2] g...@vger.kernel.org 
> [3] https://git-scm.com/docs
> [4] https://git-scm.com/docs/git-revert
> [5] https://git-scm.com/docs/git-merge
>
> Regards,
> Buga
>

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[git-users] Re: Should 'git revert' provide an option to ignore the patch context?

2017-06-18 Thread Igor Djordjevic 
Hi Harry,

On Wednesday, June 14, 2017 at 6:12:28 PM UTC+2, Harry wrote:
>
> I had posted my question earlier on StackOverflow, here: 
> 
> https://stackoverflow.com/questions/44543219/git-revert-unable-to-undo-an-individual-commit-even-in-a-simple-case
>

I`d say you got a pretty straight answer there already, but let`s try to 
address the questions you`ve raised here as well.


*1. *Would having a new option (such as *--ignore-patch-context *) while 
> doing *git revert* make sense?
>

While being possible, whether it would make sense is arguable, as using 
context-free patches is already discouraged as unsafe in general (see 
*git-apply 
--unidiff-zero*[1] 
).

But, as it`s already implemented for `git-apply`, it might make sense to 
have it for `git-revert` as well, being noted as discouraged in the same 
manner...? And I guess nobody needed it much so far, thus it`s not 
implemented yet?

That said, you`re free to bring the discussion to the main *Git mailing 
list*[2]  (that`s where the development happens), and 
try the patch yourself :) Please note that only plain-text e-mails are 
accepted, no HTML.


This option when used would carry out the *revert* mechanically/blindly and 
> leave the result in an uncommitted state (with maybe a warning on the 
> console), allowing the user to verify things for syntax and semantics 
> before committing.  
>

Now, might be you`re not seeing it that way, but this is _exactly_ what Git 
is doing - it carries out the revert mechanically/blindly and leaves the 
result in uncommited state (with merge conflict warning on the console), 
allowing the user to verify things for syntax and semantics before 
_resolving merge conflicts_ and commiting.

The only difference is that instead of your proposed _changing_ of the 
merge result by trying a lucky guess on what should the final state be 
(disregarding context, which is certainly not a blind/mechanical thing to 
do), making it harder for user to comprehend what actually happened, it 
_really_ does its thing blindly (respecting the context), taking both sides 
of the change (before/after) and leaving them as-is for the user to make 
sense of it.

For "simple case" you`re discussing here (simple for human, that is, still 
not for a machine), it`s trivial for a user to make sense of the merge 
conflicts and resolve them correctly (and easily/quickly), and you even 
have various GUI tools to help if raw conflict markers confuse you.


All this said, let me tell you that what you want is actually already 
possible with Git... ;) Well, might be not as directly as you hoped for, 
but instead of your:

(*1*) $ git revert master^^

... step, what you could try doing is this:

(*2*) $ git show master^^ >bug.patch
(*3*) $ git apply --reverse --unidiff-zero bug.patch

Command on line (*2*) creates a "bug.patch" file holding the diff/patch 
that "bug" commit introduced. Command on line (*3*) applies this patch, but 
in reverse (note the `--reverse` parameter), so instead of adding the "Bug" 
line it removes it, and `--unidiff-zero` parameter tells it to disregard 
context lines - which is exactly what you`re looking for... :) Now you can 
review the change, and commit it.

For a safety measure, please note again that usage of context-free patches 
is discouraged, being more error-prone.


2. Is there any documentation where such details of the operations (such as 
> *revert*, *merge, *...) are described?
>

Not sure if this is what you have in mind, but there`s Git *reference 
manual*[3]  (holding more info on *git-revert*[4] 
 and *git-merge*[5] 
 as well).

[1] https://git-scm.com/docs/git-apply#git-apply---unidiff-zero
[2] g...@vger.kernel.org
[3] https://git-scm.com/docs
[4] https://git-scm.com/docs/git-revert
[5] https://git-scm.com/docs/git-merge

Regards,
Buga

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.