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 some
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 of
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
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
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 can
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" prot
