Am 17.12.2013 um 16:08 schrieb Ingo Weinhold <ingo_weinhold@xxxxxx>:
If one currently has uncommitted changes, one would also need to stash them. If
one doesn't really want to rebase them to the current master yet, one would
have to create a separate branch first. It's not that much work, but at least
some reason to postpone applying a patch.
That sounds like a flawed workflow. Git has cheap branches and easy
history-rewriting, and it has that for a reason. So instead of having a lot of
uncommitted diffs on master, the right way would be to create a private
(meaning: not uploaded) feature branch and commit even incomplete stuff and
then before merging it back to master edit it using git rebase -i. This allows
quickly switching between branches without having to stash etc. This also
solves the problem of having to rebase local changes just to apply something to
master. I sense a lot of SVN workflow still being used here ;).
The testing part could be solved by a queue branch: A bot periodically builds
the queue branch and if that works, someone can cherry-pick the changes from
the queue branch after 48h. The diffs are cherry-picked so that the history
mess of that queue branch does not get into master. So a patch could go
instantly into the queue branch and if it is rejected, a simple git revert on
the queue branch would revoke that patch. The master branch can be merged into
the queue branch regularly so that patches in the queue branch are based on a
current master. This creates quite a patch + revert mess in the history, but
a.) this is useful history and b.) as patches are only cherry-picked, this
history mess does not get into master. Every patch that has not been reverted
after 48h can then be considered ready for master. Of course, if the build bot
fails, it should be bisected (which would only need 2 or 3 steps as the queue
should not get too big within one day ;)) and the culprit be re