Wishlist: do git fetch and abort if the current branch is out of date

[mgedmin]

I just released z3c.coverage 2.0.1 with one missing fix because I forgot to git pull before running fullrelease.

It would be nice if zest.releaser did a git fetch and compared HEAD with the origin (e.g. git log --oneline ..origin), and then asked me if I wanted to continue and miss those changes (defaulting to N).

[reinout]

I can see the need you describe. However, I wonder about some corner cases:

• In some cases you want to make a release of some older revision. I guess a "git fetch" won't hurt then.
• The behaviour should be similar for svn/bzr/hg and an "svn up" can hurt harder than a "git fetch".
• Is "origin" reliably always called "origin"?

OTOH, zest.releaser wants to push the changes afterwards, so the branch effectively MUST be up to date.

I guess my worries are mostly no problems in practice. "svn up" is the one I'm worried most about. @mauritsvanrees?

[mauritsvanrees]

With svn this is unneeded: when running prerelease and trying to commit it, you see the error immediately.

This would only be needed for git and friends, because there you can easily commit your hard work locally and totally forget to check if someone else has done work upstream too.

git fetch just fetches any extra commits and does not update the working directory, so that sounds safe. BTW, we should probably do git fetch --all to get all remotes. Whether the remotes are called origin or something else does not matter.

For bzr it should probably be bzr missing --theirs-only.

For mercurial, hg pull only gets the changes, without updating the working directory, so that seems safe too.

The most tricky with all these things is probably that we need to parse the output (possibly translated) to see if we need to warn the user. But in case of doubt we can always simply ask, with a default answer of 'No'.