[PATCH 1/2] Indent code before next channge

[Douglas E Engert]

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>