* Re: [PATCH] Makefile: introduce NO_PTHREADS
From: Mike Ralphson @ 2008-11-17 10:45 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, Git Mailing List, Linus Torvalds
In-Reply-To: <492148AD.1090604@viscovery.net>
2008/11/17 Johannes Sixt <j.sixt@viscovery.net>:
> Mike Ralphson schrieb:
>> 2008/11/15 Linus Torvalds <torvalds@linux-foundation.org>:
>>> On Sat, 15 Nov 2008, Junio C Hamano wrote:
>>>> This introduces make variable NO_PTHREADS for platforms that lack the
>>>> support for pthreads library or people who do not want to use it for
>>>> whatever reason. When defined, it makes the multi-threaded index
>>>> preloading into a no-op, and also disables threaded delta searching by
>>>> pack-objects.
>>> Ack. Makes sense.
>>
>> I'd be minded to make this the default on AIX to keep the prerequisite
>> list as small as possible, then people can opt-in for the performance
>> benefits if required.
>
> Is pthreads not a standard shipment on AIX? I would set NO_PTHREADS only
> if we know in advance that there are many installations without pthreads.
> (And I don't know what the situation is.)
I should have dug a bit further, it seems to be present on my 5.3
machines but I still need to determine whether it got installed by
default. Either way it must need some other link flags...
> BTW, this needs to be squashed in, because we don't have pthreads on Windows:
>
> diff --git a/Makefile b/Makefile
> index ffc9531..3a30b8c 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -769,6 +769,7 @@ ifneq (,$(findstring MINGW,$(uname_S)))
> NO_STRCASESTR = YesPlease
> NO_STRLCPY = YesPlease
> NO_MEMMEM = YesPlease
> + NO_PTHREADS = YesPlease
> NEEDS_LIBICONV = YesPlease
> OLD_ICONV = YesPlease
> NO_C99_FORMAT = YesPlease
>
Ta. Ok to add your S-o-B on a squashed patch?
Mike
^ permalink raw reply
* Re: [PATCH] gitweb: fix encode handling for site_{header,footer}
From: Jakub Narebski @ 2008-11-17 10:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Tatsuki Sugiura, git, Gerrit Pape, Recai Oktaş
In-Reply-To: <7v8wrizlxo.fsf@gitster.siamese.dyndns.org>
On Mon, 17 Nov 2008, Junio C Hamano wrote:
> Tatsuki Sugiura <sugi@nemui.org> writes:
>
> > All non-ASCII chars of site_{header,footer} will be broken
> > by perl IO layer without decoding to utf8.
> >
> > Here is a fix to just call to_utf8 for inputs from these files.
> >
> > Signed-off-by: Tatsuki Sugiura <sugi@nemui.org>
>
> Looks good, thanks.
Hmmm... it is good _partial_ solution. I wonder if gitweb doesn't
have the same problem with per-project README.html file...
> > ---
> > gitweb/gitweb.perl | 4 ++--
> > 1 files changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> > index 933e137..79ca5c2 100755
> > --- a/gitweb/gitweb.perl
> > +++ b/gitweb/gitweb.perl
> > @@ -2929,7 +2929,7 @@ EOF
> >
> > if (-f $site_header) {
> > open (my $fd, $site_header);
> > - print <$fd>;
> > + print map {to_utf8($_)} <$fd>;
> > close $fd;
> > }
> >
> > @@ -3018,7 +3018,7 @@ sub git_footer_html {
> >
> > if (-f $site_footer) {
> > open (my $fd, $site_footer);
> > - print <$fd>;
> > + print map {to_utf8($_)} <$fd>;
> > close $fd;
> > }
> >
> > --
> > 1.5.6.5
There was some patch by Recai Oktaş, or Gerrit Pape (or me)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 4c104d2..8b5fcc1 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -16,7 +16,7 @@ use Encode;
use Fcntl ':mode';
use File::Find qw();
use File::Basename qw(basename);
-binmode STDOUT, ':utf8';
+use open qw(:std :utf8);
BEGIN {
CGI->compile() if $ENV{'MOD_PERL'};
Then to_utf8() wouldn't be necessary. But I'd like for Perl experts to
check it first; for example this doesn't allow $fallback_encoding.
--
Jakub Narębski
Poland
^ permalink raw reply related
* Re: [PATCH] Teach/Fix pull/fetch -q/-v options
From: Tuncer Ayaz @ 2008-11-17 10:37 UTC (permalink / raw)
To: git; +Cc: gitster
In-Reply-To: <1226776980-9674-1-git-send-email-tuncer.ayaz@gmail.com>
Junio,
I think you need to have something like the following applied on top of
what's in pu to be able to use "pull -v -v -v" and be able to count the
occurrences via parse-options.c. What do you think?
--- git-pull.sh 2008-11-17 11:32:19.000000000 +0100
+++ git-pull.sh.b 2008-11-17 11:33:03.000000000 +0100
@@ -26,7 +26,7 @@
-q|--quiet)
verbosity=-q ;;
-v|--verbose)
- verbosity=-v ;;
+ verbosity="$verbosity -v" ;;
-n|--no-stat|--no-summary)
no_stat=-n ;;
--stat|--summary)
Signed-off-by: Tuncer Ayaz <tuncer.ayaz@gmail.com>
^ permalink raw reply
* Re: [PATCH] Makefile: introduce NO_PTHREADS
From: Johannes Sixt @ 2008-11-17 10:34 UTC (permalink / raw)
To: Mike Ralphson; +Cc: Junio C Hamano, Git Mailing List, Linus Torvalds
In-Reply-To: <e2b179460811170203v41e54ecclc3d6526bcc0fe928@mail.gmail.com>
Mike Ralphson schrieb:
> 2008/11/15 Linus Torvalds <torvalds@linux-foundation.org>:
>> On Sat, 15 Nov 2008, Junio C Hamano wrote:
>>> This introduces make variable NO_PTHREADS for platforms that lack the
>>> support for pthreads library or people who do not want to use it for
>>> whatever reason. When defined, it makes the multi-threaded index
>>> preloading into a no-op, and also disables threaded delta searching by
>>> pack-objects.
>> Ack. Makes sense.
>
> I'd be minded to make this the default on AIX to keep the prerequisite
> list as small as possible, then people can opt-in for the performance
> benefits if required.
Is pthreads not a standard shipment on AIX? I would set NO_PTHREADS only
if we know in advance that there are many installations without pthreads.
(And I don't know what the situation is.)
BTW, this needs to be squashed in, because we don't have pthreads on Windows:
diff --git a/Makefile b/Makefile
index ffc9531..3a30b8c 100644
--- a/Makefile
+++ b/Makefile
@@ -769,6 +769,7 @@ ifneq (,$(findstring MINGW,$(uname_S)))
NO_STRCASESTR = YesPlease
NO_STRLCPY = YesPlease
NO_MEMMEM = YesPlease
+ NO_PTHREADS = YesPlease
NEEDS_LIBICONV = YesPlease
OLD_ICONV = YesPlease
NO_C99_FORMAT = YesPlease
-- Hannes
^ permalink raw reply related
* Re: [PATCH] request-pull: make usage string match manpage
From: Junio C Hamano @ 2008-11-17 10:28 UTC (permalink / raw)
To: Stefan Naewe; +Cc: git
In-Reply-To: <1226912239-7248-1-git-send-email-stefan.naewe@atlas-elektronik.com>
Thanks.
^ permalink raw reply
* Re: [PATCH] gitweb: fix encode handling for site_{header,footer}
From: Junio C Hamano @ 2008-11-17 10:28 UTC (permalink / raw)
To: Tatsuki Sugiura; +Cc: git, Jakub Narebski
In-Reply-To: <87vdumbxgc.wl@vaj-k-334-sugi.local.valinux.co.jp>
Tatsuki Sugiura <sugi@nemui.org> writes:
> All non-ASCII chars of site_{header,footer} will be broken
> by perl IO layer without decoding to utf8.
>
> Here is a fix to just call to_utf8 for inputs from these files.
>
> Signed-off-by: Tatsuki Sugiura <sugi@nemui.org>
Looks good, thanks.
> ---
> gitweb/gitweb.perl | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index 933e137..79ca5c2 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -2929,7 +2929,7 @@ EOF
>
> if (-f $site_header) {
> open (my $fd, $site_header);
> - print <$fd>;
> + print map {to_utf8($_)} <$fd>;
> close $fd;
> }
>
> @@ -3018,7 +3018,7 @@ sub git_footer_html {
>
> if (-f $site_footer) {
> open (my $fd, $site_footer);
> - print <$fd>;
> + print map {to_utf8($_)} <$fd>;
> close $fd;
> }
>
> --
> 1.5.6.5
^ permalink raw reply
* Re: [PATCH] Makefile: introduce NO_PTHREADS
From: Junio C Hamano @ 2008-11-17 10:18 UTC (permalink / raw)
To: Mike Ralphson; +Cc: Johannes Sixt, Git Mailing List, Linus Torvalds
In-Reply-To: <e2b179460811170203v41e54ecclc3d6526bcc0fe928@mail.gmail.com>
"Mike Ralphson" <mike.ralphson@gmail.com> writes:
> 2008/11/15 Linus Torvalds <torvalds@linux-foundation.org>:
>>
>> On Sat, 15 Nov 2008, Junio C Hamano wrote:
>>>
>>> This introduces make variable NO_PTHREADS for platforms that lack the
>>> support for pthreads library or people who do not want to use it for
>>> whatever reason. When defined, it makes the multi-threaded index
>>> preloading into a no-op, and also disables threaded delta searching by
>>> pack-objects.
>>
>> Ack. Makes sense.
>
> I'd be minded to make this the default on AIX to keep the prerequisite
> list as small as possible, then people can opt-in for the performance
> benefits if required.
>
> I'll wait a little while to see if anyone else reports the same for
> other platforms and then submit a patch.
Thanks.
I expect to be slow this week til just before Thanksgiving, so the more
people we have to keep an eye on the areas they excel at, the better for
all of us and certainly it would help me a lot.
^ permalink raw reply
* Re: [PATCH 2/2] git-remote: add verbose mode
From: Junio C Hamano @ 2008-11-17 10:15 UTC (permalink / raw)
To: crquan; +Cc: git
In-Reply-To: <1226913150-26088-2-git-send-email-crquan@gmail.com>
crquan@gmail.com writes:
> From: Denis ChengRq <crquan@gmail.com>
>
> Signed-off-by: Cheng Renquan <crquan@gmail.com>
Your other one (I am assuming the other one is also from you) has "From:
Cheng Renquan <crquan@gmail.com>" and this is "From: Denis ChengRq
<crquan@gmail.com>". We'd prefer to keep the same person under a single
name in "git shortlog" list. Under which name do you want to be known?
Please describe in what sense this is "verbose", iow, what additional
information is added by this patch, in your proposed commit log message.
> @@ -40,10 +40,13 @@ static int opt_parse_track(const struct option *opt, const char *arg, int not)
> return 0;
> }
>
> -static int fetch_remote(const char *name)
> +static int fetch_remote(const char *name, const char *url)
> {
> const char *argv[] = { "fetch", name, NULL };
> - printf("Updating %s\n", name);
> + if (verbose)
> + printf("Updating %s (%s)\n", name, url);
Are you guaranteeing that url is not NULL at this point in the code?
If so how?
How does this "--verbose" command the users give "git remote" relate to
the "--verbose" option the underlying "git fetch" has? IOW, do you tell
"git fetch" to be verbose as well? If so, how? If not, why not?
^ permalink raw reply
* Re: [PATCH 1/2] remote short help message updated
From: Junio C Hamano @ 2008-11-17 10:15 UTC (permalink / raw)
To: crquan; +Cc: git
In-Reply-To: <1226913150-26088-1-git-send-email-crquan@gmail.com>
crquan@gmail.com writes:
> From: Cheng Renquan <crquan@gmail.com>
>
> Synced from git help remote.
>
> Signed-off-by: Cheng Renquan <crquan@gmail.com>
We strongly prefer writing commit log message in imperative mood, like:
[PATCH] git-remote: match usage string with the manual pages
The patch itself looks good. Thanks.
^ permalink raw reply
* Re: [PATCH] gitweb: fixes to gitweb feature check code
From: Junio C Hamano @ 2008-11-17 10:09 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Giuseppe Bilotta, git, Petr Baudis, Junio C Hamano
In-Reply-To: <200811171028.19807.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> Dnia poniedziałek 17. listopada 2008 07:10, Giuseppe Bilotta napisał:
>> On Mon, Nov 17, 2008 at 2:02 AM, Jakub Narebski <jnareb@gmail.com> wrote:
>
> [...]
>> > First, you forgot the signoff, but you have addressed that already.
>> >
>> >
>> > Second, I thought at first that it would be good for the patch to also
>> > simplify %feature hash, using "'default' => 1" instead of current bit
>> > convoluted "'default' => [1]", at the cost of bit more code for
>> > defensive programming. But now I think that if it is to be done,
>> > it should be put as separate patch.
>>
>> Is this an ACK? 8-D
>
> I'm sorry. Yes, it is.
Are you sure, even with those unnecessary changes from list context
assignments to scalar ones?
^ permalink raw reply
* Re: [PATCH] Makefile: introduce NO_PTHREADS
From: Mike Ralphson @ 2008-11-17 10:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Sixt, Git Mailing List, Linus Torvalds
In-Reply-To: <alpine.LFD.2.00.0811150915240.3468@nehalem.linux-foundation.org>
2008/11/15 Linus Torvalds <torvalds@linux-foundation.org>:
>
> On Sat, 15 Nov 2008, Junio C Hamano wrote:
>>
>> This introduces make variable NO_PTHREADS for platforms that lack the
>> support for pthreads library or people who do not want to use it for
>> whatever reason. When defined, it makes the multi-threaded index
>> preloading into a no-op, and also disables threaded delta searching by
>> pack-objects.
>
> Ack. Makes sense.
I'd be minded to make this the default on AIX to keep the prerequisite
list as small as possible, then people can opt-in for the performance
benefits if required.
I'll wait a little while to see if anyone else reports the same for
other platforms and then submit a patch.
Mike
^ permalink raw reply
* Re: [PATCH] gitweb: fixes to gitweb feature check code
From: Jakub Narebski @ 2008-11-17 9:28 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git, Petr Baudis, Junio C Hamano
In-Reply-To: <cb7bb73a0811162210iadb7511rc3474272c8e60c59@mail.gmail.com>
Dnia poniedziałek 17. listopada 2008 07:10, Giuseppe Bilotta napisał:
> On Mon, Nov 17, 2008 at 2:02 AM, Jakub Narebski <jnareb@gmail.com> wrote:
[...]
> > First, you forgot the signoff, but you have addressed that already.
> >
> >
> > Second, I thought at first that it would be good for the patch to also
> > simplify %feature hash, using "'default' => 1" instead of current bit
> > convoluted "'default' => [1]", at the cost of bit more code for
> > defensive programming. But now I think that if it is to be done,
> > it should be put as separate patch.
>
> Is this an ACK? 8-D
I'm sorry. Yes, it is.
Acked-by: Jakub Narebski <jnareb@gmail.com>
--
Jakub Narebski
Poland
^ permalink raw reply
* [PATCH 2/2] git-remote: add verbose mode
From: crquan @ 2008-11-17 9:12 UTC (permalink / raw)
To: git
In-Reply-To: <1226913150-26088-1-git-send-email-crquan@gmail.com>
From: Denis ChengRq <crquan@gmail.com>
Signed-off-by: Cheng Renquan <crquan@gmail.com>
---
builtin-remote.c | 19 +++++++++++++------
1 files changed, 13 insertions(+), 6 deletions(-)
diff --git a/builtin-remote.c b/builtin-remote.c
index d032f25..8a9f4b5 100644
--- a/builtin-remote.c
+++ b/builtin-remote.c
@@ -14,7 +14,7 @@ static const char * const builtin_remote_usage[] = {
"git remote rm <name>",
"git remote show [-n] <name>",
"git remote prune [-n | --dry-run] <name>",
- "git remote update [group]",
+ "git remote update [-v | --verbose] [group]",
NULL
};
@@ -40,10 +40,13 @@ static int opt_parse_track(const struct option *opt, const char *arg, int not)
return 0;
}
-static int fetch_remote(const char *name)
+static int fetch_remote(const char *name, const char *url)
{
const char *argv[] = { "fetch", name, NULL };
- printf("Updating %s\n", name);
+ if (verbose)
+ printf("Updating %s (%s)\n", name, url);
+ else
+ printf("Updating %s\n", name);
if (run_command_v_opt(argv, RUN_GIT_CMD))
return error("Could not fetch %s", name);
return 0;
@@ -117,7 +120,7 @@ static int add(int argc, const char **argv)
return 1;
}
- if (fetch && fetch_remote(name))
+ if (fetch && fetch_remote(name, url))
return 1;
if (master) {
@@ -769,8 +772,12 @@ static int prune(int argc, const char **argv)
static int get_one_remote_for_update(struct remote *remote, void *priv)
{
struct string_list *list = priv;
+
if (!remote->skip_default_update)
- string_list_append(xstrdup(remote->name), list);
+ string_list_append(remote->name, list)->util =
+ remote->url_nr > 0
+ ? (void *)remote->url[remote->url_nr-1] : NULL;
+
return 0;
}
@@ -818,7 +825,7 @@ static int update(int argc, const char **argv)
result = for_each_remote(get_one_remote_for_update, &list);
for (i = 0; i < list.nr; i++)
- result |= fetch_remote(list.items[i].string);
+ result |= fetch_remote(list.items[i].string, list.items[i].util);
/* all names were strdup()ed or strndup()ed */
list.strdup_strings = 1;
--
1.6.0.2
^ permalink raw reply related
* [PATCH 1/2] remote short help message updated
From: crquan @ 2008-11-17 9:12 UTC (permalink / raw)
To: git
From: Cheng Renquan <crquan@gmail.com>
Synced from git help remote.
Signed-off-by: Cheng Renquan <crquan@gmail.com>
---
builtin-remote.c | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/builtin-remote.c b/builtin-remote.c
index 71696b5..d032f25 100644
--- a/builtin-remote.c
+++ b/builtin-remote.c
@@ -8,12 +8,12 @@
#include "refs.h"
static const char * const builtin_remote_usage[] = {
- "git remote",
- "git remote add <name> <url>",
+ "git remote [-v | --verbose]",
+ "git remote add [-t <branch>] [-m <master>] [-f] [--mirror] <name> <url>",
"git remote rename <old> <new>",
"git remote rm <name>",
- "git remote show <name>",
- "git remote prune <name>",
+ "git remote show [-n] <name>",
+ "git remote prune [-n | --dry-run] <name>",
"git remote update [group]",
NULL
};
--
1.6.0.2
^ permalink raw reply related
* [PATCH] request-pull: make usage string match manpage
From: Stefan Naewe @ 2008-11-17 8:57 UTC (permalink / raw)
To: git; +Cc: Stefan Naewe
The usage string of 'git request-pull' differs from he manpage
which gives the correct 'synopsis'.
Signed-off-by: Stefan Naewe <stefan.naewe@atlas-elektronik.com>
---
git-request-pull.sh | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/git-request-pull.sh b/git-request-pull.sh
index 073a314..9088019 100755
--- a/git-request-pull.sh
+++ b/git-request-pull.sh
@@ -4,9 +4,9 @@
# This file is licensed under the GPL v2, or a later version
# at the discretion of Linus Torvalds.
-USAGE='<commit> <url> [<head>]'
-LONG_USAGE='Summarizes the changes since <commit> to the standard output,
-and includes <url> in the message generated.'
+USAGE='<start> <url> [<end>]'
+LONG_USAGE='Summarizes the changes between two commits to the standard output,
+and includes the given URL in the generated summary.'
SUBDIRECTORY_OK='Yes'
OPTIONS_SPEC=
. git-sh-setup
--
1.5.6.5
^ permalink raw reply related
* [PATCH] gitweb: fix encode handling for site_{header,footer}
From: Tatsuki Sugiura @ 2008-11-17 7:53 UTC (permalink / raw)
To: git
All non-ASCII chars of site_{header,footer} will be broken
by perl IO layer without decoding to utf8.
Here is a fix to just call to_utf8 for inputs from these files.
Signed-off-by: Tatsuki Sugiura <sugi@nemui.org>
---
gitweb/gitweb.perl | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 933e137..79ca5c2 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -2929,7 +2929,7 @@ EOF
if (-f $site_header) {
open (my $fd, $site_header);
- print <$fd>;
+ print map {to_utf8($_)} <$fd>;
close $fd;
}
@@ -3018,7 +3018,7 @@ sub git_footer_html {
if (-f $site_footer) {
open (my $fd, $site_footer);
- print <$fd>;
+ print map {to_utf8($_)} <$fd>;
close $fd;
}
--
1.5.6.5
^ permalink raw reply related
* Re: git to libgit2 code relicensing
From: Andreas Ericsson @ 2008-11-17 7:24 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Christian Couder, Git Mailing List
In-Reply-To: <alpine.DEB.1.00.0811162159280.30769@pacific.mpi-cbg.de>
Johannes Schindelin wrote:
> Hi,
>
> On Sun, 16 Nov 2008, Andreas Ericsson wrote:
>
>> With the current list of ok's 73.09% of the code in git.git seems to be
>> relicenseable for the purpose of libgit2. That will provide quite a
>> kickstart.
>
> I doubt it. Most of that code was written with the execute-once
> mentality. And with the we-have-posix mentality.
>
"Copy-rewrite", naturally. Being able to lift much of the data-munging code
is a great benefit. It's basically just the revision traversal (which is
heavy on state-dependant code) that I haven't quite figured out how to do
yet, but I believe Shawn's idea of using revision pools is most likely the
way to go. Each application has to make sure a pool isn't modified by more
than one thread, but each application can have as many pools as it likes.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: publish since current state?
From: Andreas Ericsson @ 2008-11-17 7:21 UTC (permalink / raw)
To: Gennady Kushnir; +Cc: git
In-Reply-To: <96ed5eac0811161242o4c800e37u7c96872a9a4351ef@mail.gmail.com>
Gennady Kushnir wrote:
> Hello list.
> I'm going to publish my work into online public repository.
> I have several months of previous history in my local git repo. And I
> don't want to make it all public.
> Is it possible to publish just a shallow copy of my repository storing
> my current tree?
Yes. Look for 'grafts' in the documentation. You'll have to create a
new repository containing only the most recent code first, and then
create the grafts-file in that repository and copy the object database
from the old repository into the new one.
> I'd also like to keep my local history private but push new commits
> from it into that online repo.
>
The grafts solution will work like that, assuming you don't publish
your grafts-file.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: GIT and SCC
From: Andreas Ericsson @ 2008-11-17 7:05 UTC (permalink / raw)
To: Jan Hudec
Cc: Theodore Tso, Martin Terreni, Mike Ralphson, Shawn O. Pearce, git
In-Reply-To: <20081116215134.GA4719@efreet.light.src>
Jan Hudec wrote:
> On Wed, Nov 05, 2008 at 14:38:25 -0500, Theodore Tso wrote:
>> On Wed, Nov 05, 2008 at 09:23:55PM +0200, Martin Terreni wrote:
>>> http://en.wikipedia.org/wiki/SCC_compliant
>>>
>>> It is probably not much, but this is what I could find in a minute. many
>>> VC system have a SCC complaint API (apart of the native). This protocol
>>> was created by M$ is used by many systems so they are not bound to a
>>> specific VC tool.
>> It's a closed-source, undocumented API that you can only get access to
>> by signing a Microsoft NDA. From the WinMerge API:
>>
>> SCC API is closed API (no public documentation available) some
>> IDE's (e.g. Visual Studio) use. There apparently have couple
>> of reverse-engineered free implementations for SCC API. Status
>> of those are unknown.
>>
>> WARNING: Be very sure you are not submitting any code behing
>> NDA for WinMerge. WinMerge is Open Source so it is not legal
>> to do. And what is worse it would prevent anybody reading that
>> code working with SCC (and perhaps also VCS) support.
>>
>
> I don't really know what this interface is about, but:
> - For VS6 and newer, source control plugin can be implemented by creating
> a dll exporting particular set of controls. This is documented in help
> files that come with VS2005 SDK which is freely downloadable from M$ web,
> so I don't think that would be under NDA.
> - For VS2003 and newer (ie. the .NET based versions), plugins can be
> implemented for almost anything, including source control, by creating
> .net assembly exporting classes that implement some particular interfaces.
> These interfaces are documented in the abovementioned SDK, so again no NDA
> needed.
> I actually started writing such plugin some months back, but since I can only
> work on it at $work (don't have Windooze at ~, not to mention VS2005 license
> -- the SDK is free to download, but requires full, non-express, studio) and
> since it does not look like I could get them use Git at $work anytime soon,
> I didn't work on it too much. Still I could share the basic skeleton and
> the knowledge I have if somebody wanted to move that somewhere.
>
I'm interested. Please email me off-list. I'll pass it on to the monodevelop
people and see what happens. Hopefully they can reuse the same interface so
that mono plugins all of a sudden work everywhere.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] gitweb: fixes to gitweb feature check code
From: Giuseppe Bilotta @ 2008-11-17 6:10 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Petr Baudis, Junio C Hamano
In-Reply-To: <200811170202.27893.jnareb@gmail.com>
On Mon, Nov 17, 2008 at 2:02 AM, Jakub Narebski <jnareb@gmail.com> wrote:
> On Sat, 15 Nov 2008, Giuseppe Bilotta wrote:
>
>> The gitweb_check_feature routine was being used for two different
>> purposes: retrieving the actual feature value (such as the list of
>> snapshot formats or the list of additional actions), and to check if a
>> feature was enabled.
>>
>> For the latter use, since all features return an array, it led to either
>> clumsy code or subtle bugs, with disabled features appearing enabled
>> because (0) evaluates to 1.
>>
>> We fix these bugs, and simplify the code, by separating feature (list)
>> value retrieval (gitweb_get_feature) from boolean feature check (i.e.
>> retrieving the first/only item in the feature value list). Usage of
>> gitweb_check_feature across gitweb is replaced by the appropriate call
>> wherever needed.
>> ---
>
> First, you forgot the signoff, but you have addressed that already.
>
>
> Second, I thought at first that it would be good for the patch to also
> simplify %feature hash, using "'default' => 1" instead of current bit
> convoluted "'default' => [1]", at the cost of bit more code for
> defensive programming. But now I think that if it is to be done,
> it should be put as separate patch.
Is this an ACK? 8-D
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* Re: purging unwanted history
From: Geoff Russell @ 2008-11-17 3:03 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: git
In-Reply-To: <20081117022714.GC3911@atjola.homenet>
On Mon, Nov 17, 2008 at 12:57 PM, Björn Steinbrink <B.Steinbrink@gmx.de> wrote:
> On 2008.11.17 03:24:12 +0100, Björn Steinbrink wrote:
>> On 2008.11.17 10:56:23 +1030, Geoff Russell wrote:
>> > I have a repository with 5 years worth of history, I only want to keep
>> > 1 year, so I want to purge the first 4 years. As it happens, the
>> > repository only has a single branch which should simplify the problem.
>>
>> Use filter-branch to drop the parents on the first commit you want to
>> keep, and then drop the old cruft.
>>
>> Let's say $drop is the hash of the latest commit you want to drop. To
>> keep things sane and simple, make sure the first commit you want to
>> keep, ie. the child of $drop, is not a merge commit. Then you can use:
>>
>> git filter-branch --parent-filter "sed -e 's/-p $drop//'" \
>> --tag-name-filter cat -- \
>> --all ^$drop
>>
>> The above rewrites the parents of all commits that come "after" $drop.
>>
>> Check the results with gitk.
>>
>>
>> Then, to clean out all the old cruft.
>>
>> First, the backup references from filter-branch:
>>
>> git for-each-ref --format='%(refname)' refs/original | \
>> while read ref
>> do
>> git update-ref -d "$ref"
>> done
>>
>> Then clean your reflogs:
>> git reflog expire --expire=0 --all
>>
>> And finally, repack and drop all the old unreachable objects:
>> git repack -ad
>> git prune # For objects that repack -ad might have left around
>>
>> At that point, everything leading up to and including $drop should be
>> gone.
>
> Hm, on second thought, if you have tags referencing some of the old
> history, they'll still be around, I think. Just delete those before you
> start the rewriting.
>
> And of course do the above with a copy of your repo. Just in case.
>
> Björn
>
Great, I've just tested this and it is exactly what I want. I'm still
getting my head around
why, but understanding will arrive with a little more thought.
Many thanks,
Geoff
--
6 Fifth Ave,
St Morris, S.A. 5068
Australia
Ph: 041 8805 184 / 08 8332 5069
^ permalink raw reply
* Re: purging unwanted history
From: Björn Steinbrink @ 2008-11-17 2:27 UTC (permalink / raw)
To: Geoff Russell; +Cc: git
In-Reply-To: <20081117022412.GB3911@atjola.homenet>
On 2008.11.17 03:24:12 +0100, Björn Steinbrink wrote:
> On 2008.11.17 10:56:23 +1030, Geoff Russell wrote:
> > I have a repository with 5 years worth of history, I only want to keep
> > 1 year, so I want to purge the first 4 years. As it happens, the
> > repository only has a single branch which should simplify the problem.
>
> Use filter-branch to drop the parents on the first commit you want to
> keep, and then drop the old cruft.
>
> Let's say $drop is the hash of the latest commit you want to drop. To
> keep things sane and simple, make sure the first commit you want to
> keep, ie. the child of $drop, is not a merge commit. Then you can use:
>
> git filter-branch --parent-filter "sed -e 's/-p $drop//'" \
> --tag-name-filter cat -- \
> --all ^$drop
>
> The above rewrites the parents of all commits that come "after" $drop.
>
> Check the results with gitk.
>
>
> Then, to clean out all the old cruft.
>
> First, the backup references from filter-branch:
>
> git for-each-ref --format='%(refname)' refs/original | \
> while read ref
> do
> git update-ref -d "$ref"
> done
>
> Then clean your reflogs:
> git reflog expire --expire=0 --all
>
> And finally, repack and drop all the old unreachable objects:
> git repack -ad
> git prune # For objects that repack -ad might have left around
>
> At that point, everything leading up to and including $drop should be
> gone.
Hm, on second thought, if you have tags referencing some of the old
history, they'll still be around, I think. Just delete those before you
start the rewriting.
And of course do the above with a copy of your repo. Just in case.
Björn
^ permalink raw reply
* Re: purging unwanted history
From: Björn Steinbrink @ 2008-11-17 2:24 UTC (permalink / raw)
To: Geoff Russell; +Cc: git
In-Reply-To: <93c3eada0811161626h69929cd7va3fa4007a2341bae@mail.gmail.com>
On 2008.11.17 10:56:23 +1030, Geoff Russell wrote:
> I have a repository with 5 years worth of history, I only want to keep
> 1 year, so I want to purge the first 4 years. As it happens, the
> repository only has a single branch which should simplify the problem.
Use filter-branch to drop the parents on the first commit you want to
keep, and then drop the old cruft.
Let's say $drop is the hash of the latest commit you want to drop. To
keep things sane and simple, make sure the first commit you want to
keep, ie. the child of $drop, is not a merge commit. Then you can use:
git filter-branch --parent-filter "sed -e 's/-p $drop//'" \
--tag-name-filter cat -- \
--all ^$drop
The above rewrites the parents of all commits that come "after" $drop.
Check the results with gitk.
Then, to clean out all the old cruft.
First, the backup references from filter-branch:
git for-each-ref --format='%(refname)' refs/original | \
while read ref
do
git update-ref -d "$ref"
done
Then clean your reflogs:
git reflog expire --expire=0 --all
And finally, repack and drop all the old unreachable objects:
git repack -ad
git prune # For objects that repack -ad might have left around
At that point, everything leading up to and including $drop should be
gone.
HTH
Björn
^ permalink raw reply
* Re: Re: git rev-list ordering
From: Johannes Schindelin @ 2008-11-17 1:35 UTC (permalink / raw)
To: Ian Hilt; +Cc: sverre, Git Mailing List
In-Reply-To: <alpine.LFD.2.00.0811162001550.28544@sys-0.hiltweb.site>
Hi,
On Sun, 16 Nov 2008, Ian Hilt wrote:
> On Sun, 16 Nov 2008, Johannes Schindelin wrote:
>
> > On Sat, 15 Nov 2008, Ian Hilt wrote:
> >
> > > On Sat, 15 Nov 2008, Sverre Rabbelier wrote:
> > > > The --reverse is applied after the --max-count, so you are seeing
> > > > the reverse of one commit ;). For comparison, have a look at:
> > > >
> > > > $ git rev-list --reverse --max-count=2
> > >
> > > Ah, I see. So if you didn't want the sorting to take a long time
> > > for many commits, you would limit the output to n commits, then sort
> > > the output. Is this the logic behind this design?
> >
> > Yes. It is by design, since the guy who wrote the initial --reverse
> > support cannot think of an interesting situation where you need to
> > list the oldest n commits.
>
> I see. Well, the situation in which I found this to be needed was while
> trying to figure out how to find the next commit on branch X while on a
> detached head from that branch without counting how many commits back I
> was. In other words,
>
> $ git checkout X~4
> $ # now I want X~3 without using a number or carets
> $ git checkout $(git rev-list --reverse ..X | head -1)
> -- or --
> $ git checkout $(git rev-list ..X | tail -1)
This could break down horribly when there was branching going on.
However, in case you are certain there is only one child of X~4, I'd
suggest doing this:
$ git checkout $(git rev-list --parents --all ^HEAD |
sed -n "s/ .*$(git rev-parse HEAD).*$//p")
IOW I would list all revisions with parents, and filter out all which do
not have the current one as parent.
Hth,
Dscho
^ permalink raw reply
* Re: git-bugzilla
From: Jakub Narebski @ 2008-11-17 1:23 UTC (permalink / raw)
To: Steve Frécinaux; +Cc: git
In-Reply-To: <492089EA.60205@gmail.com>
Steve Frécinaux <nudrema@gmail.com> writes:
> Here is a chunk of code I wrote a few time ago, to post patches to
> bugzilla, modelled mostly after git-format-patch/git-send-email.
>
> You can find it there:
> http://code.istique.net/?p=git-bugzilla.git
>
> It is written in perl and requires WWW::Mechanize.
[...]
Added to http://git.or.cz/gitwiki/InterfacesFrontendsAndTools
Thanks.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox