Hi Christian,
On Thu, Apr 07, 2016 at 04:06:59PM -0400, Christian Couder wrote:
> On Wed, Apr 6, 2016 at 12:37 PM, Willy Tarreau wrote:
> > On Wed, Apr 06, 2016 at 07:57:01AM -0700, Junio C Hamano wrote:
> >> This seems to have been lost, perhaps because the top part that was
> >> quite long didn
On Wed, Apr 6, 2016 at 12:37 PM, Willy Tarreau wrote:
> On Wed, Apr 06, 2016 at 07:57:01AM -0700, Junio C Hamano wrote:
>> This seems to have been lost, perhaps because the top part that was
>> quite long didn't look like a patch submission message or something.
>
> Don't worry, we all know it's t
On Wed, Apr 06, 2016 at 07:57:01AM -0700, Junio C Hamano wrote:
> This seems to have been lost, perhaps because the top part that was
> quite long didn't look like a patch submission message or something.
Don't worry, we all know it's the submitter's responsibility to retransmit,
I apply the same
This seems to have been lost, perhaps because the top part that was
quite long didn't look like a patch submission message or something.
Git 1.7.12 is a quite ancient release and I wouldn't be surprised if
we made the behaviour change during the period leading to v2.6 on
purpose, but nothing immed
Hi,
after I upgraded my machine, I switched from git 1.7.12.2 to 2.6.4
and experienced an annoying regression when dealing with stable
kernel backports.
I'm using a "dorelease" script which relies on git-cherry-pick's
ability to properly detect duplicate s-o-b to ensure that all merged
commits ar
5 matches
Mail list logo