pull changes from remote bevor pushing

[mojoaxel]

If the remote repository has changed since the last fetch github refuses the push with a "non-fast-forward" message. It would be nice to have the option to pull/merge the remote bevor pushing. If auto merge is not possible bumping should be aborted.

(I'm not sure if I'll find the time to implement this but I thought it might not hurt to report it here) By the way: @vojtajina Thanks!

[eddiemonge]

I disagree with doing this. As a maintainer, your local branch should already be up to date. Pulling and merging automatically right before pushing is scary and can often go wrong. What happens if there are conflicts? What happens if someone else has already tagged and released the same change? There are just too many things going on for this to work imo.

[mojoaxel]

I disagree with doing this. As a maintainer, your local branch should already be up to date. Pulling and merging automatically right before pushing is scary and can often go wrong.

Thanks for your feedback. Of course you are right! But in daily use I noticed that I had to pull right in front of every bump just to make sure no other contributor changed something seconds ago. I frequently forget pulling and than have a local tag that is not up to date with remote. A big mess that needs manual cleanup. I think grunt-bump is all about making a version-bump easier. I totally would agree, if pulling should be disabled by default, but it really improves my live and I think I'm not the only one.

What happens if there are conflicts?

If the pull results in conflicts or pullAutoCommit is turned off, grunt-bump can not commit the new version and stops with the usual "please merge first" or "please resolve conflicts" or a similar message.

What happens if someone else has already tagged and released the same change?

If the version-number was already increased (in package.json) there is no problem because the version bump is done after the pull. If a tag has been already created with the NEW version number, than this would be a problem in every case and has nothing to do with the pull.

There are just too many things going on for this to work imo.

A lot of things can go wrong using grunt-bump in general! I don't think that doing a pull is changing that significantly. But of course i'm very willing to improve the plugin if you guys can think of some edge-cases.

[eddiemonge]

the other thing is pulling creates merge commits unless you are doing a rebase or squashing that message.

in general though, I'm not a fan of doing things that have side effects like pulling.

contributor changed something seconds ago Does this happen often? If so, maybe the problem is in your process. If something just went in, do you want to push that in that tag? Maybe switching to a development/master branch would be better. Could be a team process rather than a tooling issue.

[mojoaxel]

the other thing is pulling creates merge commits unless you are doing a rebase or squashing that message.

This is true. This is why I introduced the pullAutoCommit option. If you don't want automatic generated merge commits you can disable it. Than the merge fails and you have to resolve the changes by hand. Than you can squash them, discard them or commit them using a custom message. (Rebasing would also be a nice alternative! But I would consider this a new feature.)

in general though, I'm not a fan of doing things that have side effects like pulling.

I understand that this is not for everybody. What about disabling it by default but give users like me a chance to enable it (if they know what they are doing)?

[mojoaxel]

@eddiemonge How do we solve this difference of opinion? (I also have access rights to this repository but are not willing to merge anything without some approval!)

What does others say?

[eddiemonge]

If there was better testing i'd be more comfortable pulling this although I don't really know how to test something like this since outside things introduce changes.

I still think this adds too much complexity. Another alternative is to use a different plugin (or even make a quick custom one) that does this and run it before bump

[eddiemonge]

Yet another options is to do bumps in PRs. This is a process change and gets rid of the

make sure no other contributor changed something seconds ago

problem. This just adds too many scary things and I still feel like it should be handled elsewhere

[mojoaxel]

Yet another options is to do bumps in PRs.

That's nice idea! But this would relay on GitHub. This could be a nice optional behavior but not default!

This just adds too many scary things and I still feel like it should be handled elsewhere

I'm still not sure what "scary things" could happen (see above).

[eddiemonge]

I still think a different plugin would be better. Something like a grunt-prepull type of plugin. There could be all sorts of additional options needed that could be better handled there instead of adding a lot more here. Things like rebasing, autocommits, fail on any changes, etc. It wouldn't be a hard plugin to do

[mojoaxel]

I still think a different plugin would be better.

ok