Am 17.12.2013 um 16:08 schrieb Ingo Weinhold <ingo_weinhold@xxxxxx>: > Unfortunately applying a patch doesn't only take a few seconds -- at least > doing it the right way doesn't. It involves at least building the changed > sources (unless the patch only affects comments or a ReadMe) and better yet > also testing the changed code. Ideally doing that for both gcc versions > (though, understandably, people rarely do). > > 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 reverted. How does that idea sound? -- Jonathan