* Re: [PATCH v5 15/15] fast-export: don't handle uninteresting refs
From: Felipe Contreras @ 2012-11-26 12:16 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jeff King, Jonathan Nieder, git, Johannes Schindelin, Max Horn,
Sverre Rabbelier, Brandon Casey, Brandon Casey, Ilari Liusvaara,
Pete Wyckoff, Ben Walton, Matthieu Moy, Julian Phillips
In-Reply-To: <7v7gp9udsl.fsf@alter.siamese.dyndns.org>
On Mon, Nov 26, 2012 at 6:35 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> On Wed, Nov 21, 2012 at 8:48 PM, Jeff King <peff@peff.net> wrote:
>> ...
>> I would like to understand that that even means. What behavior is
>> currently broken?
>
> I do not know if this is the same as what Peff was referring to, but
> I found this message in the discussion thread during my absense.
>
> From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
> Subject: Re: [PATCH v3 4/4] fast-export: make sure refs are updated properly
> Date: Fri, 2 Nov 2012 16:17:14 +0100 (CET)
> Message-ID: <alpine.DEB.1.00.1211021612320.7256@s15462909.onlinehome-server.info>
>
> (which is $gmane/208946) that says:
>
> Note that
>
> $ git branch foo master~1
> $ git fast-export foo master~1..master
>
> still does not update the "foo" ref, but a partial fix is better
> than no fix.
First of all, do we agree that this patch does not change the
situation for this command? If so, I don't see why that would be
relevant while discussing this patch series.
Second, this is what I get:
% git log --decorate --oneline foo master~1..master
8c7a786 (tag: v1.8.0, master) Git 1.8.0
Notice that 'foo' is not there? It's not there because we explicitly
stated that we didn't want it there.
And what do you expect that command to do with 'foo'? To throw a
'reset refs/heads/foo'? To what commit? There is no mark for that
commit. 'reset :0'? That doesn't help anybody. No, that command is not
broken, it works as expected.
Notice the situation would be different with 'git fast-export
--import-marks=marks foo master~1..master', because if there's a mark
for foo, *now* we can do something about it. This particular patch
series doesn't, but the next one does.
Cheers.
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH] fast-export: Allow pruned-references in mark file
From: Felipe Contreras @ 2012-11-26 11:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Antoine Pelisse, git
In-Reply-To: <7vd2z1xb6c.fsf@alter.siamese.dyndns.org>
On Mon, Nov 26, 2012 at 5:03 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Antoine Pelisse <apelisse@gmail.com> writes:
>
>> fast-export can fail because of some pruned-reference when importing a
>> mark file.
>>
>> The problem happens in the following scenario:
>>
>> $ git fast-export --export-marks=MARKS master
>> (rewrite master)
>> $ git prune
>> $ git fast-export --import-marks=MARKS master
>>
>> This might fail if some references have been removed by prune
>> because some marks will refer to non-existing commits.
>>
>> Let's warn when we have a mark for a commit we don't know.
>> Also, increment the last_idnum before, so we don't override
>> the mark.
>
> Is this a safe and sane thing to do, and if so why? Could you
> describe that in the log message here?
Why would fast-export try to export something that was pruned? Doesn't
that mean it wasn't reachable?
Essentially, if 'git rev-list $foo' can't possibly export this pruned
object, why would 'git fast-export $foo' would?
Cheers.
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH v3 0/7] New remote-bzr remote helper
From: Felipe Contreras @ 2012-11-26 11:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jeff King, Johannes Schindelin
In-Reply-To: <7v4nkdxawx.fsf@alter.siamese.dyndns.org>
On Mon, Nov 26, 2012 at 5:09 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> On Sun, Nov 11, 2012 at 3:19 PM, Felipe Contreras
>> <felipe.contreras@gmail.com> wrote:
>>> This is a re-roll of the previous series to add support to fetch and push
>>> special modes, and refactor some related code.
>>
>> It seems this one got forgotten, I only see v2 in pu.
>
> Oops; I think that was fell through the cracks during the maintainer
> hand-off. As the previous one has already been cooking in 'next'
> for a week or so, I would appreciate if you send incremental updates
> to fix or enhance what is in there.
Yes, that's what I have planned for the next patches, as I already did
for remote-hg, but the changes in remote-bzr were a bit bigger.
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH] Fix bash completion when `egrep` is aliased to `egrep --color=always`
From: Frans Klaver @ 2012-11-26 11:30 UTC (permalink / raw)
To: Adam Tkac; +Cc: Marc Khouzam, git
In-Reply-To: <20121126112352.GA4481@redhat.com>
On Mon, Nov 26, 2012 at 12:23 PM, Adam Tkac <atkac@redhat.com> wrote:
> Good idea, thanks. Improved patch is attached.
It is custom on this list to mail the patches, rather than attaching
them, so people can review your changes in-line. You can read more
about it in in git/Documentation/SubmittingPatches.
Cheers,
Frans
^ permalink raw reply
* Re: [PATCH] Fix bash completion when `egrep` is aliased to `egrep --color=always`
From: Adam Tkac @ 2012-11-26 11:23 UTC (permalink / raw)
To: Marc Khouzam; +Cc: git
In-Reply-To: <CAFj1UpG6H3bpoa7xbqpH6Hyb6pwqE_CCgP6iT36D-ELvtVi4wA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 597 bytes --]
On Thu, Nov 22, 2012 at 02:55:21PM -0500, Marc Khouzam wrote:
> On Thu, Nov 22, 2012 at 10:41 AM, Adam Tkac <atkac@redhat.com> wrote:
> > Hello all,
> >
> > attached patch fixes bash completion when `egrep` is aliased to `egrep --color=always`.
>
> To avoid any aliases, it may be better to use
> \egrep
Good idea, thanks. Improved patch is attached.
Regards, Adam
>
> This could be worthwhile for all utilities used by the script.
>
> Just a thought.
>
> Marc
>
>
> >
> > Comments are welcomed.
> >
> > Regards, Adam
> >
> > --
> > Adam Tkac, Red Hat, Inc.
--
Adam Tkac, Red Hat, Inc.
[-- Attachment #2: 0001-If-egrep-is-aliased-temporary-disable-it-in-bash.com.patch --]
[-- Type: text/plain, Size: 979 bytes --]
>From 255192296cd175fddcac2647447a66a0ca55b855 Mon Sep 17 00:00:00 2001
From: Adam Tkac <atkac@redhat.com>
Date: Thu, 22 Nov 2012 16:34:58 +0100
Subject: [PATCH] If `egrep` is aliased, temporary disable it in
bash.completion
Originally reported as https://bugzilla.redhat.com/show_bug.cgi?id=863780
Signed-off-by: Adam Tkac <atkac@redhat.com>
Signed-off-by: Holger Arnold <holgerar@gmail.com>
---
contrib/completion/git-completion.bash | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 0960acc..79073c2 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -565,7 +565,7 @@ __git_complete_strategy ()
__git_list_all_commands ()
{
local i IFS=" "$'\n'
- for i in $(git help -a|egrep '^ [a-zA-Z0-9]')
+ for i in $(git help -a| \egrep '^ [a-zA-Z0-9]')
do
case $i in
*--*) : helper pattern;;
--
1.8.0
^ permalink raw reply related
* Re: Python extension commands in git - request for policy change
From: Andreas Ericsson @ 2012-11-26 11:05 UTC (permalink / raw)
To: esr; +Cc: Felipe Contreras, git
In-Reply-To: <20121125224443.GC6937@thyrsus.com>
On 11/25/2012 11:44 PM, Eric S. Raymond wrote:
> Felipe Contreras <felipe.contreras@gmail.com>:
>> According to the results of the last survey, our users do care about
>> performance, so I don't think there's anything excessive about it. Are
>> there any hidden costs in maintenance problems? I don't think so.
>
> Then you're either pretending or very naive. Three decades of
> experience as a C programmer tells me that C code at any volume is a
> *serious* maintainance problem relative to almost any language with
> GC. Prudent architects confine it is much as possible.
>
Prudent architects also avoid rewrites as much as possible, since it's
inevitable that bugs will be introduced that have been fixed in the
"official" version.
Personally, I think if you'd left your suggestion on "It would be great
to have guidelines for python scripts. I propose 2.6 as the minimum
required python verison" and left it at that, there would have been
very little disagreement. The suggestion that things should be rewritten
in python for some spurious long-term savings seems mostly designed to
refuel everyone's favourite flamethrower, and you know as well as I do
that it just won't happen unless there's at least a chance of some
substantial technical benefits from doing so.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.
^ permalink raw reply
* Re: Requirements for integrating a new git subcommand
From: Peter Krefting @ 2012-11-26 11:01 UTC (permalink / raw)
To: Eric S. Raymond; +Cc: git
In-Reply-To: <20121123153541.GA20097@thyrsus.com>
Eric S. Raymond:
> and (b) include the removal of import-directories.perl in my
> integration patch.
Yes, please.
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* Re: Multiple threads of compression
From: Thorsten Glaser @ 2012-11-26 9:59 UTC (permalink / raw)
To: Brandon Casey; +Cc: git@vger.kernel.org
In-Reply-To: <CA+sFfMerMWnJwiBz0=MxO0gn8B2M8g12mt5VzZaRj591oMPVow@mail.gmail.com>
Brandon Casey dixit:
>The number of threads that pack uses can be configured in the global
>or system gitconfig file by setting pack.threads.
[…]
>The other setting you should probably look at is pack.windowMemory
>which should help you control the amount of memory git uses while
>packing. Also look at core.packedGitWindowSize and
>core.packedGitLimit if your repository is really large.
OK, thanks a lot!
I can’t really say much about the repositories beforehand
because it’s a generic code hosting platform, several instances
of which we run at my employer’s place (I also run one privately
now), and which is also run by e.g. Debian. But I’ll try to figure
out some somewhat sensible defaults.
>Running 'git gc' with --aggressive should be as safe as running it
>without --aggressive.
OK, thanks.
>But, you should think about whether you really need to run it more
>than once, or at all. When you use --aggressive, git will perform the
[…]
Great explanation!
I think that I’d want to run it once, after the repository has
been begun to be used (probably not correct English but you know
what I want to say), but have to figure out a way to do so… but
I’ll just leave out the --aggressive from the cronjob then.
Much appreciated,
//mirabilos
--
Sometimes they [people] care too much: pretty printers [and syntax highligh-
ting, d.A.] mechanically produce pretty output that accentuates irrelevant
detail in the program, which is as sensible as putting all the prepositions
in English text in bold font. -- Rob Pike in "Notes on Programming in C"
^ permalink raw reply
* Re: [PATCH] diff: Fixes shortstat number of files
From: Antoine Pelisse @ 2012-11-26 9:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Linus Torvalds
In-Reply-To: <7vhaodxctq.fsf@alter.siamese.dyndns.org>
Indeed stat seems to be broken on master by commit 74faaa16 from Linus Torvalds
There are three separated issues here:
- unmerged files are marked as "interesting" in stat and probably
shouldn't, with some patch like this:
data->is_interesting = p->status != 0;
if (!one || !two) {
data->is_unmerged = 1;
+ data->is_interesting = 0;
return;
}
By the way, I don't get the point of this code then:
else if (data->files[i]->is_unmerged) {
fprintf(options->file, "%s", line_prefix);
show_name(options->file, prefix, name, len);
fprintf(options->file, " Unmerged\n");
continue;
}
and
if (file->is_unmerged) {
/* "Unmerged" is 8 characters */
bin_width = bin_width < 8 ? 8 : bin_width;
continue;
}
Are we ever supposed to print that ? I feel like it could be removed.
- Unmerged files are not filtered out in shortstat, thus counted
twice (addressed by the patch)
- no file has ever been filtered out of numstat, and probably should
the way it's done in stat. That is with something like this:
if (!data->files[i]->is_interesting &&
(added + deleted == 0)) {
continue;
}
Cheers,
Antoine Pelisse
---------- Forwarded message ----------
From: Junio C Hamano <gitster@pobox.com>
Date: Mon, Nov 26, 2012 at 4:28 AM
Subject: Re: [PATCH] diff: Fixes shortstat number of files
To: Antoine Pelisse <apelisse@gmail.com>
Cc: git@vger.kernel.org
Antoine Pelisse <apelisse@gmail.com> writes:
> Subject: Re: [PATCH] diff: Fixes shortstat number of files
Please replace "Fixes" with "Fix at least (because our log messages
are written as if a patch is giving an order to the codebase, iow,
in imperative mood), but we would prefer to see a concrete
description on what is fixed, when we can. And in this case, I
think we can, perhaps:
diff: do not count unmerged paths twice in --shortstat/--numstat
or something.
> There is a discrepancy between the last line of `git diff --stat`
> and `git diff --shortstat` in case of a merge.
> The unmerged files are actually counted twice, thus doubling the
> value of "file changed".
I think the current 'master' and upward is broken with respect to
this; I am consistently getting two entries for unmerged paths
across --stat, --shortstat and --numstat options (iow, not just
shortstat and numstat but the '--stat' seems to be broken as well).
Thanks.
^ permalink raw reply
* Re: Python extension commands in git - request for policy change
From: Krzysztof Mazur @ 2012-11-26 8:32 UTC (permalink / raw)
To: Sitaram Chamarty; +Cc: esr, git
In-Reply-To: <CAMK1S_g2jpa+VqnuzhNaBNkC5bJHwbEy1iP-=sG29FFKmjTjpw@mail.gmail.com>
On Mon, Nov 26, 2012 at 10:40:00AM +0530, Sitaram Chamarty wrote:
> On Mon, Nov 26, 2012 at 4:17 AM, Eric S. Raymond <esr@thyrsus.com> wrote:
> > Krzysztof Mazur <krzysiek@podlesie.net>:
> >> What about embedded systems? git is also useful there. C and shell is
> >> everywhere, python is not.
> >
> > Supposing this is true (and I question it with regard to shell) if you
> > tell me how you live without gitk and the Perl pieces I'll play that
> > right back at you as your answer.
>
> gitk is unlikely to be used on an embedded system, the perl pieces more so.
Currently even perl is used only for few very high level commands that
are not really needed there. I think that python is ok for pieces
that use perl now, but I think that it shouldn't be used for
basic porcelain commands. I also don't think that we should prefer
python over other languages and especially I don't think that some
existing code should be rewritten to python.
Even if python is really better, I think that the natural migration is
much better.
>
> I have never understood why people complain about readability in perl.
> Just because it uses the ascii charset a bit more? You expect a
> mathematician or indeed any scientist to use special symbols to mean
> special things, why not programmers?
>
Because some perl programmers really create write-only code, but the
maintainer can just reject that code. It's not the language that
create non-readable code, but the programmer. I think that the perl
code in git is readable, at least is parts I've seen.
Krzysiek
^ permalink raw reply
* Re: [PATCH] Third try at documenting command integration requirements.
From: Perry Hutchison @ 2012-11-26 8:07 UTC (permalink / raw)
To: esr; +Cc: git
In-Reply-To: <20121126053557.E56434065F@snark.thyrsus.com>
esr@thyrsus.com (Eric S. Raymond) wrote:
> This document contains no new policies or proposals; it attempts
> to document established practices and interface requirements.
...
> +4. If your command has any dependency on a a particular version of
^^^
typo. (granted this is an extreme nit)
^ permalink raw reply
* Re: [PATCH 00/11] alternative unify appending of sob
From: Nguyen Thai Ngoc Duy @ 2012-11-26 7:56 UTC (permalink / raw)
To: Brandon Casey; +Cc: git, gitster, Brandon Casey
In-Reply-To: <1353894359-6733-1-git-send-email-drafnel@gmail.com>
On Mon, Nov 26, 2012 at 8:45 AM, Brandon Casey <drafnel@gmail.com> wrote:
> From: Brandon Casey <bcasey@nvidia.com>
>
> I hate to have the battle of the patches, but I kinda prefer the
> append_signoff code in sequencer.c over the code in log-tree.c as a
> foundation to build on.
>
> So, this series is similar to Duy's "unification" series, but it goes in the
> opposite direction and builds on top of sequencer.c and additionally adds the
> elements from my original series to treat the "(cherry picked from..." line
> added by 'cherry-pick -x' in the same way that other footer elements are
> treated (after addressing Junio's comments about rfc2822 continuation lines
> and duplicate s-o-b's).
>
> I've integrated Duy's series with a few minor tweaks. I added a couple
> of additional tests to t4014 and corrected one of the tests which had
> incorrect behavior. I think his sign-off's should still be valid, so I
> kept them in. Sorry that I've been slow, and now the two of us are stepping
> on each other's toes, but Duy please take a look and let me know if there's
> anything you dislike.
I'm still not sure whether format-patch should follow cherry-pick's
rule in appending sob. If it does, it probably makes more sense to fix
the sequencer.c code then delete log-tree.c (not fixes on log-tree.c
then delete it). I see that your changes pass all the new tests I
added in format-patch so sequencer.c is probably good enough,
log-tree.c changes are probably not needed. Feel free take over the
series :-)
--
Duy
^ permalink raw reply
* [RFC] pack-objects: compression level for non-blobs
From: David Michael Barr @ 2012-11-26 6:25 UTC (permalink / raw)
To: Git Mailing List; +Cc: David Michael Barr
Add config pack.graphcompression similar to pack.compression.
Applies to non-blob objects and if unspecified falls back to pack.compression.
We may identify objects compressed with level 0 by their leading bytes.
Use this to force recompression when the source and target levels mismatch.
Limit its application to when the config pack.graphcompression is set.
Signed-off-by: David Michael Barr <b@rr-dav.id.au>
---
builtin/pack-objects.c | 49 +++++++++++++++++++++++++++++++++++++++++++++----
1 file changed, 45 insertions(+), 4 deletions(-)
I started working on this just before taking a vacation,
so it's been a little while coming.
The intent is to allow selective recompression of pack data.
For small objects/deltas the overhead of deflate is significant.
This may improve read performance for the object graph.
I ran some unscientific experiments with the chromium repository.
With pack.graphcompression = 0, there was a 2.7% increase in pack size.
I saw a 35% improvement with cold caches and 43% otherwise on git log --raw.
diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c
index f069462..9518daf 100644
--- a/builtin/pack-objects.c
+++ b/builtin/pack-objects.c
@@ -40,6 +40,7 @@ struct object_entry {
unsigned long z_delta_size; /* delta data size (compressed) */
unsigned int hash; /* name hint hash */
enum object_type type;
+ enum object_type actual_type;
enum object_type in_pack_type; /* could be delta */
unsigned char in_pack_header_size;
unsigned char preferred_base; /* we do not pack this, but is available
@@ -81,6 +82,8 @@ static int num_preferred_base;
static struct progress *progress_state;
static int pack_compression_level = Z_DEFAULT_COMPRESSION;
static int pack_compression_seen;
+static int pack_graph_compression_level = Z_DEFAULT_COMPRESSION;
+static int pack_graph_compression_seen;
static unsigned long delta_cache_size = 0;
static unsigned long max_delta_cache_size = 256 * 1024 * 1024;
@@ -125,14 +128,14 @@ static void *get_delta(struct object_entry *entry)
return delta_buf;
}
-static unsigned long do_compress(void **pptr, unsigned long size)
+static unsigned long do_compress(void **pptr, unsigned long size, int level)
{
git_zstream stream;
void *in, *out;
unsigned long maxsize;
memset(&stream, 0, sizeof(stream));
- git_deflate_init(&stream, pack_compression_level);
+ git_deflate_init(&stream, level);
maxsize = git_deflate_bound(&stream, size);
in = *pptr;
@@ -191,6 +194,18 @@ static unsigned long write_large_blob_data(struct git_istream *st, struct sha1fi
return olen;
}
+static int check_pack_compressed(struct packed_git *p,
+ struct pack_window **w_curs,
+ off_t offset)
+{
+ unsigned long avail;
+ int compressed = 0;
+ unsigned char *in = use_pack(p, w_curs, offset, &avail);
+ if (avail >= 3)
+ compressed = !!(in[2] & 0x6);
+ return compressed;
+}
+
/*
* we are going to reuse the existing object data as is. make
* sure it is not corrupt.
@@ -240,6 +255,8 @@ static void copy_pack_data(struct sha1file *f,
}
}
+#define compression_level(type) ((type) && (type) != OBJ_BLOB ? pack_graph_compression_level : pack_compression_level)
+
/* Return 0 if we will bust the pack-size limit */
static unsigned long write_no_reuse_object(struct sha1file *f, struct object_entry *entry,
unsigned long limit, int usable_delta)
@@ -286,7 +303,7 @@ static unsigned long write_no_reuse_object(struct sha1file *f, struct object_ent
else if (entry->z_delta_size)
datalen = entry->z_delta_size;
else
- datalen = do_compress(&buf, size);
+ datalen = do_compress(&buf, size, compression_level(entry->actual_type));
/*
* The object header is a byte of 'type' followed by zero or
@@ -379,6 +396,13 @@ static unsigned long write_reuse_object(struct sha1file *f, struct object_entry
offset += entry->in_pack_header_size;
datalen -= entry->in_pack_header_size;
+ if (!pack_to_stdout &&
+ pack_graph_compression_seen &&
+ check_pack_compressed(p, &w_curs, offset) != !!compression_level(entry->actual_type)) {
+ unuse_pack(&w_curs);
+ return write_no_reuse_object(f, entry, limit, usable_delta);
+ }
+
if (!pack_to_stdout && p->index_version == 1 &&
check_pack_inflate(p, &w_curs, offset, datalen, entry->size)) {
error("corrupt packed object for %s", sha1_to_hex(entry->idx.sha1));
@@ -955,6 +979,8 @@ static int add_object_entry(const unsigned char *sha1, enum object_type type,
memset(entry, 0, sizeof(*entry));
hashcpy(entry->idx.sha1, sha1);
entry->hash = hash;
+ if (pack_graph_compression_seen)
+ entry->actual_type = sha1_object_info(sha1, NULL);
if (type)
entry->type = type;
if (exclude)
@@ -1758,7 +1784,8 @@ static void find_deltas(struct object_entry **list, unsigned *list_size,
*/
if (entry->delta_data && !pack_to_stdout) {
entry->z_delta_size = do_compress(&entry->delta_data,
- entry->delta_size);
+ entry->delta_size,
+ compression_level(entry->actual_type));
cache_lock();
delta_cache_size -= entry->delta_size;
delta_cache_size += entry->z_delta_size;
@@ -2159,6 +2186,16 @@ static int git_pack_config(const char *k, const char *v, void *cb)
pack_idx_opts.version);
return 0;
}
+ if (!strcmp(k, "pack.graphcompression")) {
+ int level = git_config_int(k, v);
+ if (level == -1)
+ level = Z_DEFAULT_COMPRESSION;
+ else if (level < 0 || level > Z_BEST_COMPRESSION)
+ die("bad pack graph compression level %d", level);
+ pack_graph_compression_level = level;
+ pack_graph_compression_seen = 1;
+ return 0;
+ }
return git_default_config(k, v, cb);
}
@@ -2519,6 +2556,10 @@ int cmd_pack_objects(int argc, const char **argv, const char *prefix)
argc = parse_options(argc, argv, prefix, pack_objects_options,
pack_usage, 0);
+ /* Fall back after option parsing to catch --compression */
+ if (!pack_graph_compression_seen)
+ pack_graph_compression_level = pack_compression_level;
+
if (argc) {
base_name = argv[0];
argc--;
--
1.8.0
^ permalink raw reply related
* [PATCH] Third try at documenting command integration requirements.
From: Eric S. Raymond @ 2012-11-26 5:35 UTC (permalink / raw)
To: git
This document contains no new policies or proposals; it attempts
to document established practices and interface requirements.
Signed-off-by: Eric S. Raymond <esr@thyrsus.com>
---
Documentation/technical/api-command.txt | 91 +++++++++++++++++++++++++++++++
1 file changed, 91 insertions(+)
create mode 100644 Documentation/technical/api-command.txt
diff --git a/Documentation/technical/api-command.txt b/Documentation/technical/api-command.txt
new file mode 100644
index 0000000..c1c1afb
--- /dev/null
+++ b/Documentation/technical/api-command.txt
@@ -0,0 +1,91 @@
+= Integrating new subcommands =
+
+This is how-to documentation for people who want to add extension
+commands to git. It should be read alongside api-builtin.txt.
+
+== Runtime environment ==
+
+git subcommands are standalone executables that live in the git
+execution directory, normally /usr/lib/git-core. The git executable itself
+is a thin wrapper that sets GIT_DIR and passes command-line arguments
+to the subcommand.
+
+(If "git foo" is not found in the git exec path, the wrapper
+will look in the rest of your $PATH for it. Thus, it's possible
+to write local git extensions that don't live in system space.)
+
+== Implementation languages ==
+
+Most subcommands are written in C or shell. A few are written in
+Perl. A tiny minority are written in Python.
+
+While we strongly encourage coding in portable C for portability, these
+specific scripting languages are also acceptable. We won't accept more
+without a very strong technical case, as we don't want to broaden the
+git suite's required dependencies.
+
+Python is fine for import utilities, surgical tools, remote helpers
+and other code at the edges of the git suite - but it should not yet
+be used for core functions. This may change in the future; the problem
+is that we need better Python integration in the git Windows installer
+before we can be confident people in that environment won't
+experience an unacceptably large loss of capability.
+
+C commands are normally written as single modules, named after the
+command, that link a collection of functions called libgit. Thus,
+your command 'git-foo' would normally be implemented as a single
+"git-foo.c"; this organization makes it easy for people reading the
+code to find things.
+
+See the CodingGuidelines document for other guidance on what we consider
+good practice in C and shell, and api-builtin.txt for the support
+functions available to built-in commands written in C.
+
+== What every extension command needs ==
+
+You must have a man page, written in asciidoc (this is what git help
+followed by your subcommand name will display). Be aware that there is
+a local asciidoc configuration and macros which you should use. It's
+often helpful to start by cloning an existing page and replacing the
+text content.
+
+You must have a test, written to report in TAP (Test Anything Protocol).
+Tests are executables (usually shell scripts) that live in the 't'
+subdirectory of the tree. Each test name begins with 't' and a sequence
+number that controls where in the test sequence it will be executed;
+conventionally the rest of the name stem is that of the command
+being tested.
+
+Read the file t/README to learn more about the conventions to be used
+in writing tests, and the test support library.
+
+== Integrating a command ==
+
+Here are the things you need to do when you want to merge a new
+subcommand into the git tree.
+
+0. Don't forget to sign off your patch!
+
+1. Append your command name to one of the variables BUILTIN_OBJS,
+EXTRA_PROGRAMS, SCRIPT_SH, SCRIPT_PERL or SCRIPT_PYTHON.
+
+2. Drop its test in the t directory.
+
+3. If your command is implemented in an interpreted language with a
+p-code intermediate form, make sure .gitignore in the main directory
+includes a pattern entry that ignores such files. Python .pyc and
+.pyo files will already be covered.
+
+4. If your command has any dependency on a a particular version of
+your language, document it in the INSTALL file.
+
+5. There is a file command-list.txt in the distribution main directory
+that categorizes commands by type, so they can be listed in appropriate
+subsections in the documentation's summary command list. Add an entry
+for yours. To understand the categories, look at git-cmmands.txt
+in the main directory.
+
+6. When your patch is merged, remind the maintainer to add something
+about it in the RelNotes file.
+
+That's all there is to it.
--
1.7.9.5
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
Whether the authorities be invaders or merely local tyrants, the
effect of such [gun control] laws is to place the individual at the
mercy of the state, unable to resist.
-- Robert Anson Heinlein, 1949
^ permalink raw reply related
* Re: [PATCH v5 15/15] fast-export: don't handle uninteresting refs
From: Junio C Hamano @ 2012-11-26 5:35 UTC (permalink / raw)
To: Felipe Contreras
Cc: Jeff King, Jonathan Nieder, git, Johannes Schindelin, Max Horn,
Sverre Rabbelier, Brandon Casey, Brandon Casey, Ilari Liusvaara,
Pete Wyckoff, Ben Walton, Matthieu Moy, Julian Phillips
In-Reply-To: <CAMP44s2B2_htR8LFbHk99WaNUcaYJCxVJPdRdj5VQ0k+fB9NOg@mail.gmail.com>
Felipe Contreras <felipe.contreras@gmail.com> writes:
> On Wed, Nov 21, 2012 at 8:48 PM, Jeff King <peff@peff.net> wrote:
> ...
> I would like to understand that that even means. What behavior is
> currently broken?
I do not know if this is the same as what Peff was referring to, but
I found this message in the discussion thread during my absense.
From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Subject: Re: [PATCH v3 4/4] fast-export: make sure refs are updated properly
Date: Fri, 2 Nov 2012 16:17:14 +0100 (CET)
Message-ID: <alpine.DEB.1.00.1211021612320.7256@s15462909.onlinehome-server.info>
(which is $gmane/208946) that says:
Note that
$ git branch foo master~1
$ git fast-export foo master~1..master
still does not update the "foo" ref, but a partial fix is better
than no fix.
^ permalink raw reply
* Re: [PATCH] Add documentation on how to integrate commands.
From: Eric S. Raymond @ 2012-11-26 5:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vy5hpvukk.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com>:
> As the first sentence in this paragraph does not make it clear
> enough that you are defining a new term "git execution directory",
> "execution directory" here may be misleading and can easily be
> mistaken as if we look something in the directory where the user
> runs "git" in. We usually call it "exec path".
Fixed.
> Actually, we tend to avoid Python dependency for anything important
> and allow it only on fringes; people who lack Python environment are
> not missing much, and we would want to keep it that way until the
> situation on the Windows front changes.
Added:
Python is fine for import utilities, surgical tools, remote helpers
and other code at the edges of the git suite - but it should not yet
be used for core functions. This may change in the future; the problem
is that we need better Python integration in the git Windows installer
before we can be confident people in that environment won't
experience an unacceptably large loss of capability.
I will also take this as a part-resolution of the related policy thread.
Issue perhaps to be revisited when the Windows port gets the Python support
to a good state.
I will submit for separate consideration a patch proposing the following
new guidelines:
1. Python code SHOULD NOT require an interpreter version newer than 2.6.
2. Python code SHOULD check the interpreter version and exit gracefully
with an explanation if it detects that its dependency cannot be satisfied.
> I would prefer to see this sentence not call libgit.a a "library".
> We primarily use libgit.a to let linker pick necessary object files
> without us having to list object files for non-builtin command
> implementations and it is not designed to be used by other people.
Fixed. I now refer to it as a "collection of functions".
> And when sending a patch in, do not forget to sign off your patches
> ;-)
Added. I will submit a third time with a signoff. :-)
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
^ permalink raw reply
* Re: Python extension commands in git - request for policy change
From: Sitaram Chamarty @ 2012-11-26 5:10 UTC (permalink / raw)
To: esr; +Cc: Krzysztof Mazur, git
In-Reply-To: <20121125224728.GD6937@thyrsus.com>
On Mon, Nov 26, 2012 at 4:17 AM, Eric S. Raymond <esr@thyrsus.com> wrote:
> Krzysztof Mazur <krzysiek@podlesie.net>:
>> What about embedded systems? git is also useful there. C and shell is
>> everywhere, python is not.
>
> Supposing this is true (and I question it with regard to shell) if you
> tell me how you live without gitk and the Perl pieces I'll play that
> right back at you as your answer.
gitk is unlikely to be used on an embedded system, the perl pieces more so.
I have never understood why people complain about readability in perl.
Just because it uses the ascii charset a bit more? You expect a
mathematician or indeed any scientist to use special symbols to mean
special things, why not programmers?
Perhaps people should be forced to use COBOL for a few years (like I
did, a long while ago) to appreciate brevity.
^ permalink raw reply
* Re: Can I zip a git repo without losing anything?
From: Andrew Ardill @ 2012-11-26 5:06 UTC (permalink / raw)
To: Carl Smith; +Cc: git@vger.kernel.org
In-Reply-To: <CAP-uhDcQg0BuEdHDTa6qVqLCeB-LE1GZtEqHgY_j1--XodsDKw@mail.gmail.com>
On 26 November 2012 15:55, Carl Smith <carl.input@gmail.com> wrote:
> Hi all
>
> This is my first post to this list, so thank you for all your work.
>
> After suggesting using zip files to move our projects around, I was
> told that you can not zip a git repo without loosing all the history.
> This didn't make sense to me, but two people told me the same thing,
> so I wasn't sure. I think they may have been confusing the zipped file
> you can download from GitHub with a zipped git repo.
Hi Carl,
The basics of it are as follows, a little simplified to hopefully make it clear
Git uses a working directory that contains the files which you are
working on. These get converted into a snapshot when you commit, and
these commits form the history of your project. These snapshots along
with everything else that git needs to work are stored in the git
directory, often called ".git".
When you zip the files you are working on you are creating a manual
snapshot of your project. If you zip the git directory you are
compressing the entire git repository and this has enough information
to recreate your entire history. If you zip both of them you get your
history as well as any changes that have not been committed yet. When
a server holds a copy of your repository it will not include a working
directory at all, but instead just the git directory. In this
situation the git directory will often be called the same name as the
project.
The zip from GitHub does indeed only contain the working directory,
and so doesn't include the history.
Hope that helps!
Regards,
Andrew Ardill
Regards,
Andrew Ardill
^ permalink raw reply
* Can I zip a git repo without losing anything?
From: Carl Smith @ 2012-11-26 4:55 UTC (permalink / raw)
To: git
Hi all
This is my first post to this list, so thank you for all your work.
After suggesting using zip files to move our projects around, I was
told that you can not zip a git repo without loosing all the history.
This didn't make sense to me, but two people told me the same thing,
so I wasn't sure. I think they may have been confusing the zipped file
you can download from GitHub with a zipped git repo.
If someone could put me straight on this, I'd really appreciate it.
Thanks
Carl
^ permalink raw reply
* [ANNOUNCE] Git v1.8.0.1
From: Junio C Hamano @ 2012-11-26 4:54 UTC (permalink / raw)
To: git; +Cc: Linux Kernel
The latest maintenance release Git v1.8.0.1 is now available at
the usual places.
The release tarballs are found at:
http://code.google.com/p/git-core/downloads/list
and their SHA-1 checksums are:
4e7492f7558f3ba2a450c43efa7de3b0b1adc6c1 git-1.8.0.1.tar.gz
6c0e64d53a8543447f595e3bac4966ba9257e783 git-htmldocs-1.8.0.1.tar.gz
cb26eea4ebe53b41cbc5c5f430499f7d76605414 git-manpages-1.8.0.1.tar.gz
Also the following public repositories all have a copy of the v1.8.0.1
tag and the maint branch that the tag points at:
url = git://repo.or.cz/alt-git.git
url = https://code.google.com/p/git-core/
url = git://git.sourceforge.jp/gitroot/git-core/git.git
url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core
url = https://github.com/gitster/git
Git v1.8.0.1 Release Notes
==========================
Fixes since v1.8.0
------------------
* The configuration parser had an unnecessary hardcoded limit on
variable names that was not checked consistently.
* The "say" function in the test scaffolding incorrectly allowed
"echo" to interpret "\a" as if it were a C-string asking for a
BEL output.
* "git mergetool" feeds /dev/null as a common ancestor when dealing
with an add/add conflict, but p4merge backend cannot handle
it. Work it around by passing a temporary empty file.
* "git log -F -E --grep='<ere>'" failed to use the given <ere>
pattern as extended regular expression, and instead looked for the
string literally.
* "git grep -e pattern <tree>" asked the attribute system to read
"<tree>:.gitattributes" file in the working tree, which was
nonsense.
* A symbolic ref refs/heads/SYM was not correctly removed with "git
branch -d SYM"; the command removed the ref pointed by SYM
instead.
* Earlier we fixed documentation to hyphenate "remote-tracking branch"
to clarify that these are not a remote entity, but unhyphenated
spelling snuck in to a few places since then.
* "git pull --rebase" run while the HEAD is detached tried to find
the upstream branch of the detached HEAD (which by definition
does not exist) and emitted unnecessary error messages.
* The refs/replace hierarchy was not mentioned in the
repository-layout docs.
* Sometimes curl_multi_timeout() function suggested a wrong timeout
value when there is no file descriptors to wait on and the http
transport ended up sleeping for minutes in select(2) system call.
A workaround has been added for this.
* Various rfc2047 quoting issues around a non-ASCII name on the
From: line in the output from format-patch have been corrected.
* "git diff -G<pattern>" did not honor textconv filter when looking
for changes.
* Bash completion script (in contrib/) did not correctly complete a
lazy "git checkout $name_of_remote_tracking_branch_that_is_unique"
command line.
* RSS feed from "gitweb" had a xss hole in its title output.
* "git config --path $key" segfaulted on "[section] key" (a boolean
"true" spelled without "=", not "[section] key = true").
* "git checkout -b foo" while on an unborn branch did not say
"Switched to a new branch 'foo'" like other cases.
Also contains other minor fixes and documentation updates.
----------------------------------------------------------------
Changes since v1.8.0 are as follows:
Andreas Schwab (1):
commit: fixup misplacement of --no-post-rewrite description
Ben Walton (1):
Remove the hard coded length limit on variable names in config files
Carlos Martín Nieto (1):
config: don't segfault when given --path with a missing value
David Aguilar (1):
mergetools/p4merge: Handle "/dev/null"
Jan H. Schönherr (7):
utf8: fix off-by-one wrapping of text
format-patch: do not wrap non-rfc2047 headers too early
format-patch: do not wrap rfc2047 encoded headers too late
format-patch: introduce helper function last_line_length()
format-patch: make rfc2047 encoding more strict
format-patch: fix rfc2047 address encoding with respect to rfc822 specials
format-patch tests: check quoting/encoding in To: and Cc: headers
Jeff King (3):
diff_grep: use textconv buffers for add/deleted files
gitweb: escape html in rss title
checkout: print a message when switching unborn branches
Junio C Hamano (9):
builtin/grep.c: make configuration callback more reusable
grep: move the configuration parsing logic to grep.[ch]
grep: move pattern-type bits support to top-level grep.[ch]
revisions: initialize revs->grep_filter using grep_init()
log --grep: use the same helper to set -E/-F options as "git grep"
test-lib: Fix say_color () not to interpret \a\b\c in the message
Start preparing for 1.8.0.1
Further preparation for 1.8.0.1
Git 1.8.0.1
Marc Khouzam (1):
Completion must sort before using uniq
Matthieu Moy (2):
Documentation: remote tracking branch -> remote-tracking branch
Document 'git commit --no-edit' explicitly
Michael J Gruber (1):
push/pull: adjust missing upstream help text to changed interface
Nguyễn Thái Ngọc Duy (1):
grep: stop looking at random places for .gitattributes
Phil Hord (1):
git-pull: Avoid merge-base on detached head
Philip Oakley (1):
Doc repository-layout: Show refs/replace
René Scharfe (6):
refs: lock symref that is to be deleted, not its target
branch: factor out check_branch_commit()
branch: factor out delete_branch_config()
branch: delete symref branch, not its target
branch: skip commit checks when deleting symref branches
branch: show targets of deleted symrefs, not sha1s
Romain Francoise (1):
mailmap: avoid out-of-bounds memory access
Stefan Zager (1):
Fix potential hang in https handshake
^ permalink raw reply
* Re: [PATCH 0/2] second try
From: Junio C Hamano @ 2012-11-26 4:50 UTC (permalink / raw)
To: Sven Strickroth; +Cc: git, Jeff King, Jakub Narebski, Eric Wong
In-Reply-To: <50B11AF5.2090701@tu-clausthal.de>
Sven Strickroth <sven.strickroth@tu-clausthal.de> writes:
> Am 11.11.2012 17:40 schrieb Sven Strickroth:
>> Am 06.10.2012 20:28 schrieb Junio C Hamano:
>>> It is either that it was simply forgotten, or after I wrote the part
>>> you quoted early in January there were discussions later that showed
>>> the patch was not desirable for some reason. I do not recall which.
>>
>> I noticed no threads about possible problems, so I try again.
>
> On November 11th I submitted the updated patches again, however, without
> any reaction or comments.
I think between Peff and me it fell in the cracks during the
hand-off; I do not know about the others, probably people did not
find it interesting perhaps?
I'll add Eric Wong (git-svn submaintainer) to Cc.
^ permalink raw reply
* Re: Requirements for integrating a new git subcommand
From: Eric S. Raymond @ 2012-11-26 4:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vmwy5xe9n.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com>:
> "Eric S. Raymond" <esr@thyrsus.com> writes:
>
> > While the weave operation can build a commit graph with any structure
> > desired, an important restriction of the inverse (unraveling)
> > operation is that it operates on *master branches only*. The unravel
> > operation discards non-master-branch content, emitting a warning
> > to standard error when it has to do so.
>
> Imagine that I have a simple four-commit diamond:
>
> I---A
> \ \
> B---M
>
> where Amy and Bob forked the initial commit made by Ian and created
> one commit each, and their branches were merged into one 'master'
> branch by a merge commit made by Mac. How many state snapshots will
> I see when I ask you to unravel this? Three, or four?
You will see four tree states. I have managed to remove the
master-branch-only restriction.
> As to the procedural stuff, I think others have sufficiently
> answered already. If I may add something, a new stuff typically
> start its life in contrib/ before it proves to be useful.
Thank you, I have submitted a documentation patch which folds
in the on-list discussion.
As a separate point...are you requesting that I submit my integration
patch to drop git-weave in contrib? If so, I will of course comply.
But I will point out that git-weave is not a half-thought out
experiment; it is fully documented and has a functional test. The
case for its usefulness is bolstered by one previous contrib script,
which the author has agreed to retire in favor of git-weave.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
^ permalink raw reply
* Re: [PATCH] Add documentation on how to integrate commands.
From: Junio C Hamano @ 2012-11-26 4:47 UTC (permalink / raw)
To: Eric S. Raymond; +Cc: git
In-Reply-To: <20121124122333.BAD7B4065F@snark.thyrsus.com>
esr@thyrsus.com (Eric S. Raymond) writes:
> ---
Sign off?
> Documentation/CommandIntegration | 69 ++++++++++++++++++++++++++++++++++++++
> 1 file changed, 69 insertions(+)
> create mode 100644 Documentation/CommandIntegration
>
> diff --git a/Documentation/CommandIntegration b/Documentation/CommandIntegration
> new file mode 100644
> index 0000000..be248f7
> --- /dev/null
> +++ b/Documentation/CommandIntegration
> @@ -0,0 +1,69 @@
> += Integrating new subcommands =
> +
> +This is how-to documentation for people who want to add extension
> +commands to git.
> +
> +== Runtime environment ==
> +
> +git subcommands are standalone executables that live in the git
> +execution directory, normally /usr/lib/git-core. The git executable itself
> +is a thin wrapper that sets GIT_DIR and passes command-line arguments
> +to the subcommand.
> +
> +(If "git foo" is not found in the git execution directory, the wrapper
> +will look in the rest of your $PATH for it. Thus, it's possible
As the first sentence in this paragraph does not make it clear
enough that you are defining a new term "git execution directory",
"execution directory" here may be misleading and can easily be
mistaken as if we look something in the directory where the user
runs "git" in. We usually call it "exec path".
> +== Implementation languages ==
> +
> +Most subcommands are written in C or shell. A few are written in
> +Perl. A tiny minority are written in Python.
> +
> +While we strongly encourage coding in portable C for portability, these
> +specific scripting languages are also acceptable. We won't accept more
> +without a very strong technical case, as we don't want to broaden the
> +git suite's required dependencies.
Actually, we tend to avoid Python dependency for anything important
and allow it only on fringes; people who lack Python environment are
not missing much, and we would want to keep it that way until the
situation on the Windows front changes.
> +C commands are normally written as single modules, named after the
> +command, that link a core library called libgit. Thus, your command
I would prefer to see this sentence not call libgit.a a "library".
We primarily use libgit.a to let linker pick necessary object files
without us having to list object files for non-builtin command
implementations and it is not designed to be used by other people.
> +== Integrating a command ==
> +
> +Here are the things you need to do when you want to merge a new
> +subcommand into the git tree.
> +
> +1. Append your command name to one of the variables BUILTIN_OBJS,
> +EXTRA_PROGRAMS, SCRIPT_SH, SCRIPT_PERL or SCRIPT_PYTHON.
> +
> +2. Drop its test in the t directory.
> +
> +That's all there is to it.
And when sending a patch in, do not forget to sign off your patches
;-)
^ permalink raw reply
* Re: [PATCH v3 0/7] New remote-bzr remote helper
From: Junio C Hamano @ 2012-11-26 4:09 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git, Jeff King, Johannes Schindelin
In-Reply-To: <CAMP44s2F9C4cr6v===M3AWHieaiUk1adigcU8txpZPL0wN81Ow@mail.gmail.com>
Felipe Contreras <felipe.contreras@gmail.com> writes:
> On Sun, Nov 11, 2012 at 3:19 PM, Felipe Contreras
> <felipe.contreras@gmail.com> wrote:
>> This is a re-roll of the previous series to add support to fetch and push
>> special modes, and refactor some related code.
>
> It seems this one got forgotten, I only see v2 in pu.
Oops; I think that was fell through the cracks during the maintainer
hand-off. As the previous one has already been cooking in 'next'
for a week or so, I would appreciate if you send incremental updates
to fix or enhance what is in there.
Thanks.
^ permalink raw reply
* Re: [PATCH] fast-export: Allow pruned-references in mark file
From: Junio C Hamano @ 2012-11-26 4:03 UTC (permalink / raw)
To: Antoine Pelisse; +Cc: git
In-Reply-To: <1353750432-17373-1-git-send-email-apelisse@gmail.com>
Antoine Pelisse <apelisse@gmail.com> writes:
> fast-export can fail because of some pruned-reference when importing a
> mark file.
>
> The problem happens in the following scenario:
>
> $ git fast-export --export-marks=MARKS master
> (rewrite master)
> $ git prune
> $ git fast-export --import-marks=MARKS master
>
> This might fail if some references have been removed by prune
> because some marks will refer to non-existing commits.
>
> Let's warn when we have a mark for a commit we don't know.
> Also, increment the last_idnum before, so we don't override
> the mark.
Is this a safe and sane thing to do, and if so why? Could you
describe that in the log message here?
> Signed-off-by: Antoine Pelisse <apelisse@gmail.com>
> ---
> builtin/fast-export.c | 11 +++++++----
> 1 file changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/builtin/fast-export.c b/builtin/fast-export.c
> index 12220ad..141b245 100644
> --- a/builtin/fast-export.c
> +++ b/builtin/fast-export.c
> @@ -607,16 +607,19 @@ static void import_marks(char *input_file)
> || *mark_end != ' ' || get_sha1(mark_end + 1, sha1))
> die("corrupt mark line: %s", line);
>
> + if (last_idnum < mark)
> + last_idnum = mark;
> +
> object = parse_object(sha1);
> - if (!object)
> - die ("Could not read blob %s", sha1_to_hex(sha1));
> + if (!object) {
> + warning("Could not read blob %s", sha1_to_hex(sha1));
> + continue;
> + }
>
> if (object->flags & SHOWN)
> error("Object %s already has a mark", sha1_to_hex(sha1));
>
> mark_object(object, mark);
> - if (last_idnum < mark)
> - last_idnum = mark;
>
> object->flags |= SHOWN;
> }
^ 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