Eli Zaretskii writes:
>> We generally rebase before pushing, to keep the git history as linear as
>> reasonably possible.
>
> May I suggest to have this in HACKING, including the (probably
> necessary) "pull --rebase" that should go with it?
Sure, that makes sense. Would you like to propose a p
> From: Mark H Weaver
> Cc: l...@gnu.org, guile-devel@gnu.org
> Date: Sat, 22 Feb 2014 23:40:20 -0500
>
> Eli Zaretskii writes:
>
> >> It's safe to fork a multithreaded program without using pthread_atfork
> >> if only async-signal-safe functions are called before the exec.
> >
> > You may kno
> From: Mark H Weaver
> Cc: l...@gnu.org, guile-devel@gnu.org
> Date: Sun, 23 Feb 2014 00:50:16 -0500
>
> Eli Zaretskii writes:
>
> >> Definitions for these on MinGW are available in Gnulib's 'sys_wait'
> >> module. I'll import it soon.
> >
> > Please don't: that gnulib module is dead wrong f
> From: Mark H Weaver
> Cc: l...@gnu.org, guile-devel@gnu.org
> Date: Sun, 23 Feb 2014 09:21:12 -0500
>
> Eli Zaretskii writes:
>
> >> We generally rebase before pushing, to keep the git history as linear as
> >> reasonably possible.
> >
> > May I suggest to have this in HACKING, including the
Eli Zaretskii writes:
>> From: Mark H Weaver
>> Cc: l...@gnu.org, guile-devel@gnu.org
>> Date: Sat, 22 Feb 2014 23:40:20 -0500
>>
>> Eli Zaretskii writes:
>>
>> >> It's safe to fork a multithreaded program without using pthread_atfork
>> >> if only async-signal-safe functions are called befo
