Fix to problem with untracked files stopping release #40

[paulmdavies]

Added more thorough check for repo dirtiness when release is called.

Now distinguishes between unstaged changes and untracked files. Untracked files can be ignored by setting
ignoreUntrackedFiles := true in the project settings, allowing the user to release even if they have untracked files. This setting defaults to false, for compatibility with existing code.

[paulmdavies]

I agree that modified files should be committed separately. This patch does not change that. However, there are three ways in which a repository can be dirty:

• Untracked files
• Modified tracked files not staged for commit
• Staged but uncommitted modifications (see note below)

We need to distinguish between these cases, as we want to allow the user to permit the presence of untracked files when releasing, but not modified tracked files, or staged but uncommitted changes.
The changes I have made make release always fail in the case where there are modified files, which is as it should be. However, it warns them that those modified files are the reason for the failure. These files are not added, that is the user's responsibility.
In the case of untracked files, the release process fails unless the user has specified the ignoreUntrackedFiles setting, in which case their release proceeds as normal.

N.B. I have realised, however, that I've neglected the case where to user has staged but uncommitted modified files. I'll put in a case for that tomorrow, and then resubmit the pull request.

[gseitz]

👍 Sounds reasonable. Thanks for the effort. Much appreciated!

[laughedelic]

👍 are you going to include it in the next release of the plugin?

[avdv]

👍 Thanks @paulmdavies

[tjadams]

👍 sounds like a good change

[alexbohr]

Would really love to have this option added, would make this plug-in a better option to git-flow if I didn't have to worry about untracked files for every release.
Thanks

[paulmdavies]

@alexbohr it was added. Just specify the ignoreUntrackedFiles key in your sbt configuration.

[alexbohr]

Thanks @paulmdavies ... but what version is it released in? Looks like this pull-request is still open and hasn't been merged in yet.

[pjolep]

Is this going to be merged soon?

[avdv]

bump. what's the matter? why isn't this merged already?

[mphuff]

+1 Where is the merge on this? Would love to have this available :)

[avdv]

Since master and this PR diverged quite some time ago, I have rebased the commits onto master, cleaned up the code a bit (to avoid compiler warnings) and implemented the hasUntrackedFiles and hasModifiedFiles for the Subversion.

Have a look here:

https://github.com/avdv/sbt-release/tree/fix-issue-40

WDYT, should I PR this?

If you feel adventurous, you can use:

resolvers += "jitpack" at "https://jitpack.io"
addSbtPlugin("com.github.avdv" % "sbt-release" % "jitpack-SNAPSHOT")

in your plugins.sbt to use this version.

[paulmdavies]

I think, @avdv, I'd keep it as your version. I'd thought not more than a coupleof days ago about forking it myself - @gseitz doesn't seem to care for this project any more, so let's have a fork with this merge which is what the people want :-)

[avdv]

Yeah, apparently gseitz doesn't care for this project any more. But, since this plugin is community maintained I'm hoping to get this integrated instead of maintaining a separate fork.

@jroper, you seem to feel responsible for this plugin. What do you think?

[jroper]

Responsible? Hmm... lazy but benevolent person with the necessary access to merge and release is a better description for me. If a change is simple for me to review (or has been reviewed by others that I trust), I'll merge it and cut a new release, but only if I have enough time and enough people ask :)

Fix the conflicts (or create a new PR) and I'll merge.

[avdv]

Fix the conflicts (or create a new PR) and I'll merge.

Cool, here you are: #144