| 1 |
C. Bergström posted on Mon, 15 Sep 2014 02:49:48 +0700 as excerpted: |
| 2 |
|
| 3 |
> Pretty please do NOT allow "merge" commits.. they are the bane of evil |
| 4 |
> for the long term ability to have any sane work-flow. Trying browsing a |
| 5 |
> commit history after a big merge commit.. or following the parent.. |
| 6 |
|
| 7 |
You just called the inventor of git and the workflow it was designed to |
| 8 |
manage insane. If that's the case arguably quite a bit more insanity |
| 9 |
would be a good thing! =:^) |
| 10 |
|
| 11 |
Try git log --color --stat --graph on the mainline kernel in a terminal |
| 12 |
and read only the main merge-commit logs unless that merge is something |
| 13 |
of special interest you want more info on. It actually makes following a |
| 14 |
full kernel cycle, including the commit window, drilling down to sub- |
| 15 |
merges and individual commits only on 2-3 areas of interest while keeping |
| 16 |
a general awareness of developments in the rest of the kernel not only |
| 17 |
practical once again, but relatively easy. Without seeing merge-commits |
| 18 |
it was a LOT harder. I know as I've done it both ways, and while I can |
| 19 |
get around in git to some extent, my git skills are definitely nothing |
| 20 |
special! =:^) |
| 21 |
|
| 22 |
-- |
| 23 |
Duncan - List replies preferred. No HTML msgs. |
| 24 |
"Every nonfree program has a lord, a master -- |
| 25 |
and if you use the program, he is your master." Richard Stallman |
Archives