Hi, I'm the author of the PR in question. My intention of using `git
rebase` was to make review easier by splitting the changes into two
individually meaningful commits. It's less work to just push the
individual commits, so I'm fine doing that as well of course.
Regarding the rebase / merge issue:
My git-fu is not that strong, but wouldn't merging master into the PR
branch make code review harder, because every change on the master
branch would now be part of the PR as well?
If that's true, I see no other way to keep the PR up to date than using
`git rebase`.
It was my original suggestion to John to just clone my fork and checkout
the PR branch, which is clearly a bad idea when that branch is rewriting
history. So that's on me.
Going forward, maybe it makes sense to have a section "Testing a PR" in
the guidelines that suggest a more robust setup (i.e. cloning
apache/netbeans and doing what Emilian Bold suggested)?
Best regards,
Thomas Zimmermann
On 2019/11/19 02:10:18, Tim Boudreau <n...@gmail.com> wrote:
> I really don't see the point of squashing commits. I know, everybody
would
> like to look like they write perfect, concise, error-free code the first
> time. But nobody does - and that seems to be the primary purpose. If you
> want to see the set of changes that implement a feature, it's not
that hard
> to come up with an incantation of git diff -r that will let you do that -
> and that kind of forensics as far less common - not something you should
> contort your development process and spend work on to optimize. So it
> seems to me, the main point of making commit history pretty is ego. Which
> is a silly thing to get excited about.
>
> -Tim
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
For additional commands, e-mail: dev-h...@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
