Re: [PATCH v2 2/2] fsmonitor.allowRemote now overrides default behavior

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 11, 2022, 16:53 UTC
Message-ID: <xmqqtu6ig1s5.fsf@gitster.g>
In-Reply-To: <7a071c9e6be68b58306582dbac5952a5b1bcbc6a.1660233432.git.gitgitgadget@gmail.com>

"Eric DeCosta via GitGitGadget" <gitgitgadget@gmail.com> writes:

Show 10 quoted lines

> From: Eric DeCosta <edecosta@mathworks.com>
>
> Reworked the logic around fsmonitor.allowRemote such that if
> allowRemote is set it will determine if monitoring the remote
> worktree is allowed.
>
> Get remote protocoal information; if this fails report an error else
> print it if tracing is enabled.
>
> Fixed fomratting issues.

The end result (i.e. HEAD^{tree} of the branch you developed these two patches on) may be good (I haven't checked), but it is not how we fix problems in an earlier attempt in this project by keeping the faulty commit(s) on the bottom and piling "oops, that was wrong, and here is a fix-up" commit(s) on top.

Once you are happy with the end result, use "rebase -i" to clean-up the history leading to that end result. The goal is to pretend as if you were a perfect human, more perfect than your actual self, who came up with an ideal patch without making mistakes that need to be corrected with "fix-up" commits. In this particular case, you'd most likely want to end up with a single commit, so squashing them together and fixing up the log message might be all you need to do. When you work on a more elaborate topic, you may also want to split or reorder original commits to present a logical progression towards the end result. "rebase -i" is a good tool to help you do so.

I am not a user of GitGitGadget myself, but if I recall correctly, you should be able to force-push the result of such a clean-up to update the pull-request, to trigger a new iteration to be sent to the list.

Thanks.