yorik wrote:When I screw things too much with git I sometimes do the following to start over:
1. Save your changes in a diff file with git diff mybranch..master > mychanges.patch
2. Delete your dirty branch, make a new clean one from a fresh, up-to-date master
3. Switch to that branch and apply your changes with patch -d1 < mychanges.patch
4. If there are changed files produced by diff that shouldn't be changed, git checkout them
Then you have a rebased branch with only your changes there, ready to be committed.
How would you write an automated "merge officer" scan? It must identify any two developers repetitively skipping the 4th step by lack of time/discipline. I need a solution for my ongoing CI enhancements
Here is an example of this problem:
Two musicians, one from Germany, the other from the USA. They write a song that simply traverses the c major scale. They commit note after note. In Germany we write "cdefgahc". Notice the "h"! In the USA musicians write "cdefgabc". Notice the "b"!
The song might internationally evolve as follows:
Code: Select all
USA : (cdef) (bc)---------(de)-----(fga)------(bc)
\ / \ \ \ \
master : ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( )
\ / / / /
Both get lazy from (ga) onwards. The master would have the effective states
Code: Select all
Other musicians, who care maybe only about the first octave and try to stay synchronized, might get pretty annoyed and confused about these frequent, repetitive overwrites of
I think we must somehow query git over several commits by the same developer to identify that he repeatedly overwrites the master with his unsynchronized way of writing things. I expect that such identification would usually come at least in pairs of developers running into such a loop, and then the "merge officer" must reject them immediately, maybe even rewind a bit. Any snippets or seen a similar automation (static analysis) already?