Change assignee address to fix Bugzilla bug #829

[imagejan]

I guess there should be a better solution than hard-coding the default assignee address, but that fixed Bug #829 ( http://fiji.sc/bugzilla/show_bug.cgi?id=829 ) for me.

[ctrueden]

Does it work if you leave off the assignee altogether? I.e., if you comment out:

"&assigned_to="+e(bugzillaAssignee)+

Will the bug get submitted OK, to the usual default assignee for the component?

If so, we might want to do that instead, to avoid the hardcoding as you say. @dscho, are you on board with that? Or would you rather that imagej-builds always be CCed by default, regardless of the default assignee per component?

[dscho]

If we could avoid hard-coding any assignee, I would really love that!

[imagejan]

The bug submitter indeed works when the assigned_to field only contains the ccString. The default assignee (imagej-builds@imagej.net) appears to get set automatically at the server side.
My second commit comments out the hard-coded assignee address.

[dscho]

@imagejan thanks!

May I ask for one more thing, though? I know I could easily do it myself, but you might find the technique worthwhile also for other projects:

With ImageJ2, and more and more also with the Fiji projects, we want to make full use of the pull request model where topic branches are developed until they are merged into master. Until they are merged, they are subject to frequent rewriting, including reworking existing commits. For example, when some change was introduced in the topic branch that was reverted in a later commit, we prefer to rewrite the commit history of that topic branch so that the undesired change is not even there anymore.

In this particular case, the change to a different default assignee is undesired, and we should "squash" the two commits together. This is easily done using Git's interactive rebase. I wish I had more foresight when I got bullied into changing the script's name from the original edit patch series (which I find much more intuitive a title). Basically, it presents you with a list of commits to re-apply; you can rearrange the order, stop after applying a specific commit in order to adjust it (by editing the files, then calling git commit --amend), even removing unwanted commits. And you can squash two commits.

So I would suggest to call

git rebase -i HEAD~2

which will give you a list in your favorite editor:

pick 0e4e00d Change assignee address to fix Bugzilla bug #829
pick b646efc Bug Submitter: avoid hard-coding the default assignee

By changing the second pick into squash and then saving and quitting the editor, you tell Git to combine the two commits into one. You are then offered to edit the commit message to your liking in the editor.

After that the commits are no longer the same, of course: commits themselves are immutable, all we can change are the pointers into that commit graph when we commit and switch branches and merge or pull. That means that you have to force push:

git push origin +HEAD

This will automatically update this pull request, too.

[dscho]

Oh, one more request: I get to see enough commented-out code all the time to be tired of it. Like, really tired. It strikes me as utterly pointless to have code that is more than just likely to become stale, when all it would be good for (a record of what was there) is addressed perfectly well by the Git history.

Would you terribly mind removing the parts in question instead of commenting them out? Thanks!

[imagejan]

@dscho Thanks a lot for the tutorial!

Not being a native vi user, I prefer using SourceTree (by Atlassian) for most of my git exercises, since it provides a really nice GUI to git. I didn't find how to rebase interactively with SourceTree though, so I followed your advice on the command line.

Worked perfectly, thanks. :)