On Wed, Mar 10, 2010 at 05:26:52PM -0800, Will Light wrote:
> Git is still an array of small specialized tools, they just don't all
> get dumped in /usr/bin the way they used to. On my system they get
> put in /usr/lib/git-core.
>
> -w
>
Makes perfect sense.
--
I am a man who does not exist fo
On Wed, Mar 10, 2010 at 1:28 PM, Uriel wrote:
> Actually it is sad that git moved from 'small specialized tools'
> towards a more centralized/monolithic model. But nobody will miss the
> dependency on perl...
Git is still an array of small specialized tools, they just don't all
get dumped in /usr
On Wed, Mar 10, 2010 at 8:56 PM, Stephane Sezer wrote:
> On Wed, 10 Mar 2010 12:37:54 +0100
> Alexander Surma wrote:
>
>> And for the bloat: Git is sometimes percieved as somewhat more bloated
>> (>100 little tools instead of 1 like hg) - that depends on the point
>> of view.
>
> Is this still tr
fixed. :)
2010/3/10 anonymous :
> Revision 175 of surf removed lines 158-162:
>
> /* cookie persistance */
> s = webkit_get_default_session();
> cookies = soup_cookie_jar_new();
> soup_session_add_feature(s, SOUP_SESSION_FEATURE(cookies));
> g_signal_connect(cookies, "changed", G_CALLBACK(changeco
Better fix:
diff -r 688bf1f96927 surf.c
--- a/surf.cMon Mar 08 10:06:32 2010 +0100
+++ b/surf.cWed Mar 10 23:24:05 2010 +0300
@@ -675,7 +675,6 @@
void
setup(void) {
- SoupSession *s;
char *proxy;
char *new_proxy;
SoupURI *puri;
@@ -703,7 +702,7 @@
Revision 175 of surf removed lines 158-162:
/* cookie persistance */
s = webkit_get_default_session();
cookies = soup_cookie_jar_new();
soup_session_add_feature(s, SOUP_SESSION_FEATURE(cookies));
g_signal_connect(cookies, "changed", G_CALLBACK(changecookie), NULL);
Then variable `s` is used again
On Wed, 10 Mar 2010 12:37:54 +0100
Alexander Surma wrote:
> And for the bloat: Git is sometimes percieved as somewhat more bloated
> (>100 little tools instead of 1 like hg) - that depends on the point
> of view.
Is this still true ?
--
Stephane Sezer
>>> There's always git, the core of which is written in C, but some
>>> scripts are perl.
>>
>> perl support is disabled in my git build. But perl removal is
>> somewhat trickier than python because of the GNU autotools. The
>> real todo list for perl is
>> GNU autotools removal or/and basic GNU ma
On 3/10/10, Sylvain BERTRAND wrote:
>> There's always git, the core of which is written in C, but some
>> scripts are perl.
>
> perl support is disabled in my git build. But perl removal is somewhat
> trickier than python because of the GNU autotools. The real todo list for
> perl is
> GNU autotoo
> There's always git, the core of which is written in C, but some
> scripts are perl.
perl support is disabled in my git build. But perl removal is somewhat
trickier than python because of the GNU autotools. The real todo list for perl
is
GNU autotools removal or/and basic GNU makefile. I tried t
On 10 March 2010 11:31, Sylvain Bertrand wrote:
> In war against bloat, python removal is on the todo list.
> Is there any chance to use something different than hg for source
> versioning and branching?
I think the most significant parts of mercurial are written in C, and
all other parts in pyth
There's always git, the core of which is written in C, but some
scripts are perl.
And for the bloat: Git is sometimes percieved as somewhat more bloated
(>100 little tools instead of 1 like hg) - that depends on the point
of view.
Surma
On Wed, Mar 10, 2010 at 12:31 PM, Sylvain Bertrand
wrote:
>
In war against bloat, python removal is on the todo list.
Is there any chance to use something different than hg for source
versioning and branching?
--
code in C, protect your code with GNU (A)(L)GPL, keep your rights, use GNU/Linux
13 matches
Mail list logo
