On close of splashscreen interrupt verifyDB #5557

With the splashscreen being able to be closed it is possible to shutdown during the lengthy verifyDB method. (Takes about a minute on my machine). This change allows us to shutdown much sooner.

Re: development process, the usual way of working is to merge changes into master then backport as necessary to releases.

For next time: Please do pulls against master unless it is something that only applies to 0.10 e.g. release notes.

Merged via 70477a0bdf6eb6d123ce256f064bbd3bc356c82a (master) 94b362dbd64ca39c642400cbae45743ef597a9b7 (0.10)

with "backport" I guess you mean cherry-pick. Maybe you want to look up the proper git way of doing it which is to commit on the oldest branch (0.10 in this case) and merge that into master on a regular basis. If you ever want to do signing and/or cryptographic repository checks for tampering you can't use cherry-picks.

Interesting, I wasn't aware of that 'proper' way. I see it has certain advantages, but IMHO it is harder to follow nonlinear sets of changes.

By the way, all merge commits are already signed after review by the merger (and #5149 would add a script to validate that they actually are) these days.

Thanks for the suggestion but I'm well aware of other approaches and prefer the current way. This makes sure that all changes are in master first, so there is never confusion about whether master us up to date.

In the cherry-picked commit a back-reference is made to the original commit(s) and pull requests, so this doesn't prevent auditing of any kind.

This makes sure that all changes are in master first, so there is never confusion about whether master us up to date.

The merge approach doesn't have any such confusion either. So this argument doesn't really go either way. I'm pretty sure its easy to set up the Travis CI to do this automatically for you.

In the cherry-pick strategy I have seen many projects (opensource or at my work) run into problems. For instance because its hard to keep track of which things are backported already. You can forget commits that need to be on the stable branch. There is also no way to mark a bugfix as "meant for stable" in the pull request.

Next to that a cherry-pick is a manual operation that can introduce errors and, worse, it allows for tampering. A 2 line fix is easy to proof-read, but a larger bugfix can easily be changed and end up with an exploit in the release branch. The original submitter would never find out.

Which comes back to signing your commits; as Bitcoin grows the need to be certain about code origin grows. Now you made two commits in my name where you were able to change anything if you wanted to. Which essentially means there is no trust model. Well, we have to trust you :)

Signing a commit would be much better trust model, and I would argue that bitcoin core will grow in importance (accountability wise) faster than the Linux kernel did. Which does have a signing policy as you know.

All I wrote here is the more verbose version of explaining why cherry-pick is not something you should do, you can probably find many more if you go to the kernel ML or other big open source projects.

In the cherry-picked commit a back-reference is made to the original commit(s) and pull requests, so this doesn't prevent auditing of any kind.

As explained above; there is no way to do automatic auditing because you manually committed those changes. There is no guarantee it is even the same patch, and it doesn't have to be. You even changed the commit message so any hash-based checking is impossible too. All you can do is manually compare the two commits in the two branches to see if they are mostly the same.

All you can do is manually compare the two commits in the two branches to see if they are mostly the same.

And you have to do that anyway, because merge commits can also introduce changes (though this may indeed be easier to automatically validate).

And you have to do that anyway, because merge commits can also introduce changes

A merge commit contains only the changes, so its pretty trivial to check. It should be empty in almost all cases :-)

Commits in git do not contain changes. They store references to the parent commit(s), and to the resulting tree. Diffs are always computed on the fly locally by comparing with the previous tree.

Checking whether a git merge is 'clean' means you have to recompute the merge based on the claimed parent commits, and comparing the resulting tree (which means you need to know the merge algorithm etc.). I heard a Git developer say (a few months ago) that there was no functionality to automatically verify this.

You must have heard a git developer say that there is no guaranteed perfect way to do this; since git the executable does very well in the majority of cases. Just do a 'git show' on a merge commit and you'll see. Its empty in most cases because in most cases the merge is trivial.

We are getting off track; if you don't believe that cherry-picks are a bad way to manage your git branches, then ask that git friend of yours what he thinks. Especially mention we don't use merge at all for release branches.

Bottom line is that anywhere that cherry-pick works without issues, your merge commit will be empty and automatic. So make your CI do it for you and you'll start to notice the benefit of using git. Google for "git branching strategy" and notice that all of them talk about using git merges. Bitcoin not using git merges for our non-topic branches means we are not using the one thing that really sets it apart from svn.

Here is a nice article; http://nvie.com/posts/a-successful-git-branching-model/