Le Tue, Nov 05, 2024 at 07:36:02PM +0100, Jeremie Courreges-Anglas a écrit :
> On Tue, Nov 05, 2024 at 07:05:46PM +0100, Landry Breuil wrote:
> > hi,
> >
> > hg is so painful and slow.. so here's a port for git-cinnabar, which
> > allows me to talk to mozilla mercurial servers, but working locally
On Tue, Nov 05, 2024 at 07:05:46PM +0100, Landry Breuil wrote:
> hi,
>
> hg is so painful and slow.. so here's a port for git-cinnabar, which
> allows me to talk to mozilla mercurial servers, but working locally with
> git.
>
> https://github.com/glandium/git-cinnabar/wiki/Mozilla:-A-git-workflow
hi,
hg is so painful and slow.. so here's a port for git-cinnabar, which
allows me to talk to mozilla mercurial servers, but working locally with
git.
https://github.com/glandium/git-cinnabar/wiki/Mozilla:-A-git-workflow-for-Gecko-development
i'm not sure i will be needing it for long given
http
OK.
Tests can be made to run easily, just s,bin/bash,bin/sh and
TDEP on devel/py-coverage, and it's probably worth doing.
On 2024/07/10 01:14, Anthony J. Bentley wrote:
> Hi,
>
> git filter-repo is a versatile tool for rewriting git repository history,
> which includes capabilities not found
Hi,
git filter-repo is a versatile tool for rewriting git repository history,
which includes capabilities not found anywhere else. It roughly falls into
the same space of tool as git filter-branch but without the capitulation-
inducing poor performance, with far more capabilities, and with a desig
On Sat, Mar 06, 2021 at 12:25:59PM -0800, Greg Steuck wrote:
> Greg Steuck writes:
> >> I'm happy to prepare an 8.10-compatible version now if that would help
> >> with the upgrade to 8.10.
> >
> > Thanks, that wouldn't hurt :)
>
> I gave it a whirl, what do you think:
Thanks. I just built the b
Greg Steuck writes:
>> I'm happy to prepare an 8.10-compatible version now if that would help
>> with the upgrade to 8.10.
>
> Thanks, that wouldn't hurt :)
I gave it a whirl, what do you think:
>From 3035c41344d31ef466004071acde2d0eddd3a2dc Mon Sep 17 00:00:00 2001
From: Greg Steuck
Date: Sat,
James Cook writes:
> On Thu, Mar 04, 2021 at 09:21:18PM -0800, Greg Steuck wrote:
> I guess the only issue is MODCABAL_MANIFEST might need to be
> re-generated? (I needed to do that when I rebased the port from your
> ghc 8.10 branch onto master with ghc 8.6.)
Yeah, that's the extent of the chan
Aaron Bieber writes:
> Builds fine for me! ("61m47.59s real36m53.69s user14m31.75s
> system" on my AMD Ryzen 9 3900X 12-Core Processor!)
>
> OK abieber@
Committed.
> We should decide on a name for a file to store the MOD{CABAL,GO,CARGO}
> dependency lists! These Makefiles are gonna be y
On Thu, Mar 04, 2021 at 09:21:18PM -0800, Greg Steuck wrote:
> Hi James,
>
> Thanks for gathering the data and analyzing it!
>
> I do not believe that speed of git-annex build should be a blocker to
> its inclusion into the tree. I'm just waiting for somebody to OK it
> before committing. Though
Greg Steuck writes:
> Hi James,
>
> Thanks for gathering the data and analyzing it!
>
> I do not believe that speed of git-annex build should be a blocker to
> its inclusion into the tree. I'm just waiting for somebody to OK it
> before committing. Though maybe it's best to do that after the ghc
> I propose we don't solve the problem until it's big enough to warrant
> our attention. I know I'm bad at predicting how things will develop a
> year from now. This is why I don't want to speculatively build more
> complexity.
Okay, makes sense!
> Thanks
> Greg
>
--
James
Hi James,
Thanks for gathering the data and analyzing it!
I do not believe that speed of git-annex build should be a blocker to
its inclusion into the tree. I'm just waiting for somebody to OK it
before committing. Though maybe it's best to do that after the ghc 8.10
upgrade, not sure?
James Coo
On 2021/03/03 23:53, James Cook wrote:
> I agree with Greg's comment in the other thread that the ideal
> solutions would be speeding up ghc or something like ccache. But I
> still wonder if there's a quick-and-dirty way to get a modest speedup
> without too much maintenance cost.
btw, ports bulk
> Full output attached.
Actually attached now.
--
James
815.882 1614811944.118 Building executable 'git-annex' for
git-annex-8.20210223..
280.208 161481.486 Building library for aeson-1.5.6.0..
230.755 1614808139.685 Building library for cryptonite-0.28..
225.882 1614810601.156 Building lib
> This seems to me like a reasonable port to have. My only concern is it
> takes 40 minutes to build with MAKE_JOBS=4 on a 4 core machine:
> cpu0: Intel(R) Core(TM) i7-10610U CPU @ 1.80GHz, 7097.97 MHz, 06-8e-0c
I don't have an easy solution to that, but here are some data and a
couple of thoughts
Thanks James for sending in the port!
James Cook writes:
> Now that Greg's new cabal infrastructure is checked in this should be
> ready. I've been using a previous version for a while, and briefly
> tested the attached version, which includes a few changes:
>
> * Update to latest release, and r
Greg Steuck wrote much of this --- see the earlier thread "Question
about lang/ghc module (trying to port git-annex)".
Now that Greg's new cabal infrastructure is checked in this should be
ready. I've been using a previous version for a while, and briefly
tested the attached version, which include
On Tue, Feb 11 2020, Paco Esteban wrote:
> On Sat, 25 Jan 2020, Paco Esteban wrote:
>
>> Hi ports@,
>>
>> Here's a new port for git-crypt, which is a tool for transparently
>> encrypt files on git repositories (so one can have sensitive information
>> on remote repositories). You can find more i
On Sat, 25 Jan 2020, Paco Esteban wrote:
> Hi ports@,
>
> Here's a new port for git-crypt, which is a tool for transparently
> encrypt files on git repositories (so one can have sensitive information
> on remote repositories). You can find more info here:
>
> https://www.agwa.name/projects/git-
Hi ports@,
Here's a new port for git-crypt, which is a tool for transparently
encrypt files on git repositories (so one can have sensitive information
on remote repositories). You can find more info here:
https://www.agwa.name/projects/git-crypt/
I decided not to include gnupg as a dependency.
Niall O'Higgins wrote:
I wanted to look at the source of a Linux development driver which was
in a private git tree, so I made this port. Other hackers might find
it useful, so I thought I'd share.
Tested on amd64, i386 and sparc64.
I'm interested too. I've done a port for my private use (to
On Sun, Mar 26, 2006 at 01:02:04AM +0100, Joachim Schipper wrote:
> On Sat, Mar 25, 2006 at 10:41:00PM +, Niall O'Higgins wrote:
> > I wanted to look at the source of a Linux development driver which was
> > in a private git tree, so I made this port. Other hackers might find
> > it useful, so
On Sat, Mar 25, 2006 at 10:41:00PM +, Niall O'Higgins wrote:
> I wanted to look at the source of a Linux development driver which was
> in a private git tree, so I made this port. Other hackers might find
> it useful, so I thought I'd share.
>
> Tested on amd64, i386 and sparc64.
>
> DESCR:
I wanted to look at the source of a Linux development driver which was
in a private git tree, so I made this port. Other hackers might find
it useful, so I thought I'd share.
Tested on amd64, i386 and sparc64.
DESCR:
git is a stupid (but extremely fast) directory content manager. It
doesn't d
25 matches
Mail list logo
