| 1 |
Hi all, |
| 2 |
|
| 3 |
On Sun, 8 May 2016 01:52:22 +0200 Patrice Clement wrote: |
| 4 |
> Hi gents |
| 5 |
> |
| 6 |
> After yet another discussion about git in the #gentoo-dev channel tonight, the |
| 7 |
> topic of merge commits came up for the umpteenth time. |
| 8 |
> |
| 9 |
> We all seem to agree merge commits are really bad design, add clutter to the |
| 10 |
> log graph after a while and should be banned altogether from reaching the |
| 11 |
> central repository. |
| 12 |
|
| 13 |
No, not all of us. |
| 14 |
|
| 15 |
> As of now, no policy is in place yet to keep developers from pushing merge |
| 16 |
> commits. |
| 17 |
> |
| 18 |
> What is the correct course of action? I would very much like it to be worded in |
| 19 |
> a document (GLEP and/or Wiki page) so that confusion is avoided and we all are |
| 20 |
> on the same page on this topic. |
| 21 |
|
| 22 |
Sometimes merge commits are desired. But they should be used |
| 23 |
wisely. Of course if used randomly and without thought they may |
| 24 |
become disaster. |
| 25 |
|
| 26 |
I see nothing wrong if developer makes series of large non-trivial |
| 27 |
changes in a separate branch and then merges this branch with |
| 28 |
current head after good testing. Another case is when some user |
| 29 |
submits a long branch of patches and developer merges it from |
| 30 |
external repository (with proper testing of course). |
| 31 |
|
| 32 |
If one have problems reading logs with merge commits, use gitk |
| 33 |
or similar tools. I had the same hate relationship towards |
| 34 |
non-linear workflow after switching from cvs and svn to git, but |
| 35 |
with time comes the understanding that git workflow is the right |
| 36 |
way to go, it just takes time to get accustomed to it. |
| 37 |
|
| 38 |
Best regards, |
| 39 |
Andrew Savchenko |
Archives