|looking for a good workflow for fly-by changes [message #717589]
||Sun, 21 August 2011 10:53
| Henrik Lindberg
Registered: July 2009
I am looking for a good workflow for the following case.
Say I am working on fixing a bug on a issue-42 branch. As I am doing
this, I detect javadoc comments, and dead code that should have been
fixed in code that I am looking at.
I could log an issue and come back to it later. But it is more work to
log this than the work to fix it. Result is most likely yet another
low-priority work item that just lengthens the backlog and triage time.
I could just change it and let it be part of my merge of issue-42. This
is less satisfactory, as this change has nothing to do with issue-42.
(One way around this is to commit, but then rebase interactively and
omit commits that are unrelated (and then deal with those later) - but
this is somewhat messy, and seems to much overhead for fixing a spelling
If Egit had good rebase --interactive I just need to commit the cleanup
with a message that allows me to recognize those commits. Right now,
since I have to switch to command line, this seems too much work for a
c) Fix cleanup on master
I could switch back to the master branch, fix it there, commit, push.
I then need to rebase my issue-42 branch (so I see the changes as I
d) Fix cleanup in separate branch
I could create a separate branch for cleanup fixes like these. I still
need to rebase my issue-42 branch to the cleanup , but I can deal with
merging all cleanup commits into master as one operation.
In all cases where I have to switch branch, and I am working with a
delta that involves manifest changes, I incur a quite heavy build, which
is not ideal. This also makes me reluctant to fix the spelling error.
Is there some other convenient way of dealing with fly-by changes? What
do you do in these situations?