On 6/30/2021 11:58 AM, John Ericson wrote:> Douglas,
>
> Thanks. Those are good hidden gems with git, for sure!
>
> Correct me if I am wrong, but since I am using
git-send-email/git-format-patch the diff ones don't apply to me, right?
Those would be for e.g. David and reviewers in general, not patch submitters?
Yes, David Newall <openssh at davidnewall.com> was complaining he could
not tell if the
changes were just indenting or other formatting changes. So the use of diff
options
would help him a lot.
>
> Thus, the additional options for /creating/ the patches you are proposing
are:
>
> * Combine patch, rely on reviewer to use the provided diff options
> * Split patch, create a file like
https://github.com/llvm/llvm-project/blob/main/.git-blame-ignore-revs
<https://github.com/llvm/llvm-project/blob/main/.git-blame-ignore-revs>
for reviewers to use
> with git blame.
I have not submitted any OpenSSH patches in a long time. I am saying there are
ways
for the OpenSSH maintainers to address indentation changes.
But I am not sure why you had to change the indentations in your submission the
first place.
>
> ?
>
> John
>
> On Wed, Jun 30, 2021, at 8:37 AM, Douglas E Engert wrote:
>> Three other options:
>> ? With diff use one of theses options: -E --ignore-tab-expansion, -Z
--ignore-trailing-space,
>> ? -b --ignore-space-change,? -w --ignore-all-space, and/or? -B
--ignore-blank-lines
>>
>> With git-blame use the -w option.
>>
>> With git do all format changes in separate commits, then add commit(s)
to .ignoreRevsFile
>> so these format only commits do not show up in git blame. Best used
when doing? mass formatting
>> changes to the source, then inforce formatting standards when doing new
commits.
>>
>>
>> On 6/30/2021 5:14 AM, David Newall wrote:
>> > Hi John,
>> >
>> > On 30/6/21 2:57 pm, John Cotton Ericson wrote:
>> >> The nature of the change is putting a decent chunk of existing
autoconf m4 within
>> >> a newly-introduced if-then-else. That means either the
indention will become wrong,
>> >> or there will be some churn/noise reindenting the old code.
>> >>
>> >> I chose to reindent first, making on odd 2x indent, and then
add the new code and
>> >> if-then-else, also fixing the indent.
>> >
>> > The problem is that a diff for a version from before your patch
comparing with a version
>> > after will be noisy.? That's what I want you to avoid.
>> >
>> >> A third option would be to simply do the first of those to
patches, making the minimal
>> >> change and then leaving the indentation incorrect.
>> >
>> > That's what I think you should do.? Adding a comment at the
if-then-else saying why the
>> > indent is wrong might help avoid flammage about wrongly indented
code.
>> >
>> > Regards,
>> >
>> > David
>> > _______________________________________________
>> > openssh-unix-dev mailing list
>> > openssh-unix-dev at mindrot.org <mailto:openssh-unix-dev at
mindrot.org>
>> > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
<https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev>
>>
>> --
>>
>> ? Douglas E. Engert? <DEEngert at gmail.com <mailto:DEEngert at
gmail.com>>
>>
>> _______________________________________________
>> openssh-unix-dev mailing list
>> openssh-unix-dev at mindrot.org <mailto:openssh-unix-dev at
mindrot.org>
>> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
<https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev>
>>
>
--
Douglas E. Engert <DEEngert at gmail.com>