[haiku-commits] Re: BRANCH looncraz-github.setviewuicolor [8c0d56c205c7] in src: apps/haikudepot/ui servers/app kits/interface apps/haikudepot/ui_generic kits/shared
- From: Paweł Dziepak <pdziepak@xxxxxxxxxxx>
- To: haiku-commits@xxxxxxxxxxxxx
- Date: Fri, 2 Oct 2015 18:59:54 +0100
On 2 October 2015 at 17:32, Stephan Aßmus <superstippi@xxxxxx> wrote:
Hi,
Am 02.10.2015 um 18:07 schrieb looncraz:
On 10/2/2015 10:45, Urias McCullough wrote:
On Fri, Oct 2, 2015 at 8:44 AM, looncraz <looncraz@xxxxxxxxxxx> wrote:
Not sure why, though, when this is all done, a squashed commit makes
for the
best way to merge the code into Haiku, provided it is accepted.
That seems like a subjective opinion.
Many devs (myself for one) may prefer to retain the individual commit
history as it more accurately shows the thought process and
incremental work that went into development of a feature.
- Urias
Funny, I've always found it to be damaging when trying to cleanly merge
new code.
But I'll submit however y'all please. I'm about as opinionated as a
rock when it comes to how people run their own projects :p
I for one would prefer to review a single patch against head, i.e. the end
result. Especially since I couldn't review the commits so far in depth and
I don't want to make comments on something that got changed anyway. Whether
it makes more sense to commit as small commits or as one squash commit, I
have not much of an opinion on.
Reviewing the end result – yes. End result in a form of a single large
patch – no.
I agree that it is just a waste of reviewer's time trying to read something
like:
commit 1: my change
commit 2: fix build
commit 3: fix bug introduced in commit 1
Patches like that should be squashed into a single one before the final
merge, as they only pollute history and confuse readers.
However, squashing everything into a single big patch is also bad. It is
not easy to read and understand such end result, the history is lost
(including the explanation why the change was needed that should be in the
commit message) and it makes git bisect useless. Generally, everyone should
think twice before using word "and" in a commit message, maybe it should be
more than one commit.
So I general I think the best solution is to merge a series of patches each
one good on its own, without need for further fixes, and each doing one
thing (and, if it is not obvious, with commit message explaining why Haiku
cannot continue to exist without this patch). Something similar to Linux
workflow.
Such series of patches also shouldn't be very long. Big feature branches
that are virtually untested by anyone except their original author and
touch (and break) many parts of the code. There is no point in waiting for
everything to be ready because if the changes are serious it is almost
certain that some bugs will be found when the patches get tested by the
general audience after the merge, so follow-up fixes may be unavoidable. If
instead of merging one big feature branch a number of patch series is
merged (over a period of time) the testing happens earlier, the author
knows about any bugs earlier (which may be very important if they are not
just simple mistakes but more involved problems that may influence the
remaining work that needs to be done), less problems with merge conflicts
and it is easier for someone else to take over the project if the original
author mysteriously disappears (trying to do something with old, bit-rotten
branch with massive number of conflicts can be quite demotivating).
Paweł
PS This mail actually contradicts itself, shorter posts are more likely to
be read ;)
Other related posts:
