On Wed, Jun 29, 2016 at 3:23 PM, Eric Pruitt wrote:
> On Wed, Jun 29, 2016 at 01:54:13PM -0800, Britton Kerin wrote:
>> I'm not going to try to fix patches I don't use myself, it's possible
>> to screw up and testing is a hassle since it involves the wm.
>
> I wonder what the odds are of a patch a
Late reply to this, but I favor the git branch approach as you suggest. It is
already a dependency, so why not use it for its intended purpose?
The great thing about a branch is that it is easy to use the version the patch
is for, and update as desired. The tools to manage the use cases around
On Fri, 1 Jul 2016 14:49:34 -0700
Ben Woolley wrote:
Hey Ben,
> Late reply to this, but I favor the git branch approach as you suggest.
> It is already a dependency, so why not use it for its intended purpose?
>
> The great thing about a branch is that it is easy to use the version the
> patch
On 07/01/2016 08:39 PM, FRIGN wrote:
> On Fri, 1 Jul 2016 14:49:34 -0700
> Ben Woolley wrote:
>
> [...]
>> Remember, git was originally created to solve the problem of concurrently
>> managing many large patch sets from distributed sources. Isn't that the
>> problem here?
>
> it's always the s
On Fri, 1 Jul 2016 21:05:09 -0700
Leo Gaspard wrote:
Hey Leo,
> Actually, I'd think if you give people push access to their patch branch
> it may be easier for them than having to export a patch and update the
> wiki: they already rebase the patches for themselves, they would just
> have to git