Le 18/01/2020 à 18:49, Segher Boessenkool a écrit :
On Wed, Jan 15, 2020 at 04:37:49PM +, Iain Sandoe wrote:
I’m guessing that public development branches will probably gravitate to the
no non-FF mode, if they are to be used by people other than the primary author
.. although that does
Le 29/12/2019 à 17:32, Richard Earnshaw a écrit :
We agreed that for changes in our current workflow practices we'd defer
that until *after* we'd switched to git; so this is getting off topic.
On the other hand, we do need to sort out what we do with existing merge
history, as that forms part
Le 29/12/2019 à 14:31, Segher Boessenkool a écrit :
On Sun, Dec 29, 2019 at 12:46:50PM +0100, Julien '_FrnchFrgg_' RIVAUD wrote:
At worst, no commit is testable in the
branch except the last, and git will say that the bug was introduced in
the branch, which is not worse that what you'd get
Le 29/12/2019 à 14:26, Segher Boessenkool a écrit :
Hi!
On Sun, Dec 29, 2019 at 12:42:07PM +0100, Julien '_FrnchFrgg_' RIVAUD wrote:
I'm not arguing that you should go that route, it seems a bit extreme to
me. But outright refusing merges on the basis they are painful is (if
you can accept
Le 29/12/2019 à 12:02, Richard Biener a écrit :
On December 29, 2019 11:41:00 AM GMT+01:00, Segher Boessenkool
wrote:
On Sun, Dec 29, 2019 at 02:40:45AM +0100, Julien FrnchFrgg Rivaud
wrote:
Oh, I'm not talking about historical merges. I'm saying we
shouldn't do
future merges, where we
Le 29/12/2019 à 11:41, Segher Boessenkool a écrit :
On Sun, Dec 29, 2019 at 02:40:45AM +0100, Julien FrnchFrgg Rivaud wrote:
Oh, I'm not talking about historical merges. I'm saying we shouldn't do
future merges, where we can help that. It disagrees with our documented
"submitting patches"
