* Re: [PATCH] diffcore-rename: cache file deltas
From: Linus Torvalds @ 2007-10-03 1:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, git
In-Reply-To: <7vy7eu4eos.fsf@gitster.siamese.dyndns.org>
On Tue, 25 Sep 2007, Junio C Hamano wrote:
> >
> > - the name diff_free_filespec_data_large is horrible, but this is based
> > on the fact that diff_free_filespec_data actually does too much (it
> > frees the data _and_ some other auxiliary data). And renaming that
> > would entail changing many callsites.
>
> True. But we can rename it to diff_file_filespec_blob() and
> that would perfectly well describe what it does. Will do so
> when applying if it is Ok to you.
Well, that renaming apparently never happened, and it's still called
diff_free_filespec_data_large() now that it's in master.
That said, I think this patch should make it into the maintenance branch
too, renamed or not, since it's such a huge performance issue.
Linus
^ permalink raw reply
* Re: git-svn merge helper
From: Björn Steinbrink @ 2007-10-03 1:02 UTC (permalink / raw)
To: Steven Walter; +Cc: git
In-Reply-To: <20071003004252.GA28495@dervierte>
On 2007.10.02 20:42:52 -0400, Steven Walter wrote:
> On Wed, Oct 03, 2007 at 12:38:13AM +0200, Björn Steinbrink wrote:
> > > The other option is to have a "build" branch. By example:
> > >
> > > git checkout build
> > > git reset --hard master
> > > git merge mybranch
> > > make
> > >
> > > In that way, I have branch with the latest changes from head and the
> > > changes from mybranch together. The downside to this method is that you
> > > may have to repeated resolve merges. Despite the downsides, I find
> > > these two methods to work quite well.
> >
> > Thanks, but it makes no difference here, it stil results in a fast
> > forward. This is a small test case which exhibits the behaviour and
> > matches my current workflow with git-svn (except for the dcommits):
> >
> > git init
> > echo Hi > file1; git add file1; git commit -m file1
> > git checkout -b branch
> > echo Hi > file2; git add file2; git commit -m file2
> > git checkout master
> > echo Hi > file3; git add file3; git commit -m file3
> > git checkout branch
> > git merge master
> >
> > # Then I'd normally do the following which causes a fast forward
> > #git checkout master
> > #git merge branch
> >
> > # Now I tried this, which also results in a fast-forward:
> > git checkout -b merge
> > git reset --hard master
> > git merge branch
>
> I believe you misunderstood my suggestion. In using a "build" branch,
> you would not merge master into branch, as you did above. Instead, you
> would create a third, unpublished branch to hold the merge.
Almost though so.
> At the same time, I have a slightly better understanding of what it is
> you're trying to do. If you are trying to keep up an SVN-like workflow
> (namely pulling changes from trunk into a branch from time to time),
> then my solution probably isn't suitable for you. However, you might
> consider why you actually /need/ to do that, outside of SVN convention.
Due to the same reason for which the branch needs to be public at all,
there are other people who want to follow it and test it, while there
are external dependencies that currently change quite often. So I need
to get the relevant changes from trunk into my branch anyway, even with
svn conventions put aside (well, unless I force everyone else to merge
over and over again). And as sometimes others commit to that branch, too
(you just have to love that), keeping a separate branch for the final
merge isn't so nice either, as I'd need to constantly cherry-pick those
changes then and probably get even more conflicts along the way.
That said, Google finally liked some of the search terms that I threw at
it and revealed a thread [1] from march, where Linus was torn on whether
or not a --no-fast-forward option should be introduced. That sounds like
it would help here, any chance of getting such a thing?
Thanks,
Björn
[1]
http://lists-archives.org/git/419374-git-merge-and-merge-message.html
^ permalink raw reply
* [PATCH] git-diff: complain about >=8 consecutive spaces in initial indent
From: Junio C Hamano @ 2007-10-03 1:00 UTC (permalink / raw)
To: git; +Cc: J. Bruce Fields
In-Reply-To: <1189982942187-git-send-email-bfields@citi.umich.edu>
This teaches coloring code in "diff" to detect indent of 8 or
more places using SP, which can and should (in some projects
including the kernel and git itself) use HT instead.
---
* This is primarily meant as a "reminder" patch, and not for
inclusion. We earlier saw a patch to "git-apply" to rewrite
them to HT but rejected it, because some projects use "no HT,
all SP" policy (e.g. Python).
We probably should resurrect the earlier "git-apply" patch,
and teach it and this patch to selectively enable/disable
detection of different kinds of whitespace breakages.
diff.c | 11 +++++++++--
1 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/diff.c b/diff.c
index 0ee9ea1..647377b 100644
--- a/diff.c
+++ b/diff.c
@@ -531,8 +531,10 @@ static void emit_line_with_ws(int nparents,
int i;
int tail = len;
int need_highlight_leading_space = 0;
- /* The line is a newly added line. Does it have funny leading
- * whitespaces? In indent, SP should never precede a TAB.
+ /*
+ * The line is a newly added line. Does it have funny leading
+ * whitespaces? In indent, SP should never precede a TAB, and
+ * there shouldn't be more than 8 consecutive spaces.
*/
for (i = col0; i < len; i++) {
if (line[i] == '\t') {
@@ -545,6 +547,11 @@ static void emit_line_with_ws(int nparents,
else
break;
}
+ if (0 <= last_space_in_indent && last_tab_in_indent < 0 &&
+ 8 <= (i - col0)) {
+ last_tab_in_indent = i;
+ need_highlight_leading_space = 1;
+ }
fputs(set, stdout);
fwrite(line, col0, 1, stdout);
fputs(reset, stdout);
^ permalink raw reply related
* Re: metastore
From: Johannes Schindelin @ 2007-10-03 0:52 UTC (permalink / raw)
To: david
Cc: Julian Phillips, David H?rdeman, martin f krafft, git,
Daniel Barkalow, Thomas Harning Jr., Francis Moreau, Nicolas Vilz
In-Reply-To: <Pine.LNX.4.64.0710021743270.25489@asgard.lang.hm>
Hi,
On Tue, 2 Oct 2007, david@lang.hm wrote:
> in the discussion a few weeks ago I was told that there is a way to look
> at the contents of a file that hasn't been checked out yet (somehow it
> exists in a useable form 'in the index') but when I asked for
> information about how to do this I never got a response.
git show :<filename>
(Note the ":")
Hth,
Dscho
^ permalink raw reply
* Re: metastore
From: david @ 2007-10-03 0:52 UTC (permalink / raw)
To: Julian Phillips
Cc: David Härdeman, David Kastrup, martin f krafft, git,
Daniel Barkalow, Johannes Schindelin, Thomas Harning Jr.,
Francis Moreau, Nicolas Vilz
In-Reply-To: <Pine.LNX.4.64.0710030018240.4087@reaper.quantumfyre.co.uk>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 4935 bytes --]
On Wed, 3 Oct 2007, Julian Phillips wrote:
> Subject: Re: metastore
>
> On Tue, 2 Oct 2007, David Härdeman wrote:
>
>> On Tue, Oct 02, 2007 at 10:04:56PM +0200, David Kastrup wrote:
>>> David Härdeman <david@hardeman.nu> writes:
>>>
>>> > On Tue, Oct 02, 2007 at 08:53:01PM +0100, martin f krafft wrote:
>>> > > also sprach David Härdeman <david@hardeman.nu> [2007.09.19.2016
>>> +0100]:
>>> > > > But I agree, if any changes were made to git, I'd advocate adding
>>> > > > arbitrary attributes to files (much like xattrs) in name=value
>>> > > > pairs, then any extended metadata could be stored in those
>>> > > > attributes and external scripts/tools could use them in some way
>>> > > > that makes sense...and also make sure to only update them when it
>>> > > > makes sense.
>>> > > > > So where would those metdata be stored in your opinion?
>>> > > I'm not sufficiently versed in the internals of git to have an
>>> > informed opinion :)
>>>
>>> I think we have something like a length count for file names in index
>>> and/or tree. We could just put the (sorted) attributes after a NUL
>>> byte in the file name and include them in the count. It would also
>>> make those artificially longer file names work more or less when
>>> sorting them for deltification.
>>
>> Or perhaps the index format could be extended to include a new field for
>> value=name pairs instead of overloading the name field.
>>
>> But as I said, I have no idea how feasible it would be to change git to
>> support another arbitrary length field in the index/tree file.
>>
>>> However, this requires implementing _policies_: it must be possible to
>>> specify per repository exactly what will and what won't get tracked,
>>> or one will get conflicts that are not necessary or appropriate.
>>
>> I think the opposite approach would be better. Let git provide
>> set/get/delete attribute operations and leave it at that. Then external
>> programs can do what they want with that data and add/remove/modify tags as
>> necessary (and also include the smarts to not, e.g. remove the permissions
>> on all files if the git repo is checked out to a FAT fs).
>
> You need more than that. You need to be able to log, blame etc on the
> attributes. One of the big annoyances of Subversion properties is being
> unable to find out when or why a property value was changed.
>
> I still don't see why the attributes need to be stored in git directly -
> particularly if you are going to use an external program to actually apply
> any settings - why not store the attributes as normal file (or files) of some
> sort tracked by git? You could use any number of methods - e.g. use an
> sqlite database stored in the root of your tree, or a .<name>.props file
> alongside each path that you have properties for. You could even write a
> system that uses such a method and was then SCM agnostic, allowing you to
> keep your attribute tracking system if/when something better than git comes
> along - or simply share it with less-fortunate souls stuck in an inferior
> system.
one other big advantage of keeping things in a normal file, it's easier to
get the results accepted into git!
don't forget that the core git maintainers don't really see this as a
worthwhile effort, so the more intrusive the result is the less likely it
is to be accepted. It may end up that storing the attributes inside of git
_is_ the best thing to do, but it's gong to be a whole lot easier to get a
patch to implement this accepted if it's a migration from an existing,
heavily used, implementation then if it's from the 'outside' with people
saying "this is a neat thing, we think people would use it if it only had
this"
and even if an internal implementation does end up being the right thing,
the exact shape of the API is an item that will require a lot of debate
(and probably a few false starts) to get right. let's figure out the
real-world useage patterns first, and then work from there as appropriate.
shifting back onto implementaion details
in the discussion a few weeks ago I was told that there is a way to look
at the contents of a file that hasn't been checked out yet (somehow it
exists in a useable form 'in the index') but when I asked for information
about how to do this I never got a response.
the reason for needing this is that the routines writing the files need to
be able to access this information when they are dong so, but that file
may not be checked out.
for that matter, .gitattributes should have a similar problem (if
.gitattibutes for a directory hasn't been checked out yet how do you know
if you could do the line ending conversions on a file or not?). how is the
problem addressed there? (or is it the case that all the use so far has
really not used the per-directory files and everything is in the master
file, and that doesn't change enough to find these problems?
David Lang
^ permalink raw reply
* Re: git-svn merge helper
From: Steven Walter @ 2007-10-03 0:42 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: git
In-Reply-To: <20071002223813.GA3152@atjola.homenet>
On Wed, Oct 03, 2007 at 12:38:13AM +0200, Björn Steinbrink wrote:
> > The other option is to have a "build" branch. By example:
> >
> > git checkout build
> > git reset --hard master
> > git merge mybranch
> > make
> >
> > In that way, I have branch with the latest changes from head and the
> > changes from mybranch together. The downside to this method is that you
> > may have to repeated resolve merges. Despite the downsides, I find
> > these two methods to work quite well.
>
> Thanks, but it makes no difference here, it stil results in a fast
> forward. This is a small test case which exhibits the behaviour and
> matches my current workflow with git-svn (except for the dcommits):
>
> git init
> echo Hi > file1; git add file1; git commit -m file1
> git checkout -b branch
> echo Hi > file2; git add file2; git commit -m file2
> git checkout master
> echo Hi > file3; git add file3; git commit -m file3
> git checkout branch
> git merge master
>
> # Then I'd normally do the following which causes a fast forward
> #git checkout master
> #git merge branch
>
> # Now I tried this, which also results in a fast-forward:
> git checkout -b merge
> git reset --hard master
> git merge branch
I believe you misunderstood my suggestion. In using a "build" branch,
you would not merge master into branch, as you did above. Instead, you
would create a third, unpublished branch to hold the merge.
At the same time, I have a slightly better understanding of what it is
you're trying to do. If you are trying to keep up an SVN-like workflow
(namely pulling changes from trunk into a branch from time to time),
then my solution probably isn't suitable for you. However, you might
consider why you actually /need/ to do that, outside of SVN convention.
--
-Steven Walter <stevenrwalter@gmail.com>
"A human being should be able to change a diaper, plan an invasion,
butcher a hog, conn a ship, design a building, write a sonnet, balance
accounts, build a wall, set a bone, comfort the dying, take orders,
give orders, cooperate, act alone, solve equations, analyze a new
problem, pitch manure, program a computer, cook a tasty meal, fight
efficiently, die gallantly. Specialization is for insects."
-Robert Heinlein
^ permalink raw reply
* WIP: asciidoc replacement
From: Johannes Schindelin @ 2007-10-03 0:42 UTC (permalink / raw)
To: git, msysgit
Hi,
I do not want to depend on more than necessary in msysGit, and therefore I
started to write an asciidoc replacement.
So here it is: a perl script that does a good job on many .txt files in
Documentation/, although for some it deviates from "make man"'s output,
and for others it is outright broken. It is meant to be run in
Documentation/.
My intention is not to fix the script for all cases, but to make patches
to Documentation/*.txt themselves, so that they are more consistent (and
incidentally nicer to the script).
Now, I hear you already moan: "But Dscho, you know you suck at Perl!"
Yeah, I know, but maybe instead of bashing on me (pun intended), you may
want to enlighten me with tips how to make it nicer to read. (Yes, there
are no comments; yes, I will gladly add them where appropriate; yes, html
is just a stub.)
So here, without further ado, da script:
-- snip --
#!/usr/bin/perl
$conv = new man_page();
$conv->{manual} = 'Git Manual';
$conv->{git_version} = 'Git ' . `cat ../GIT-VERSION-FILE`;
$conv->{git_version} =~ s/GIT_VERSION = //;
$conv->{git_version} =~ s/-/\\-/;
$conv->{git_version} =~ s/\n//;
$conv->{date} = `date +%m/%d/%Y`;
$conv->{date} =~ s/\n//;
$par = '';
handle_file($ARGV[0]);
$conv->finish();
sub handle_text {
if ($par =~ /^\. /s) {
my @lines = split(/^\. /m, $par);
shift @lines;
$conv->enumeration(\@lines);
} elsif ($par =~ /^\* /s) {
my @lines = split(/^\* /m, $par);
shift @lines;
$conv->enumeration(\@lines, 'unnumbered');
} elsif ($par =~ /^\[verse\]/) {
$par =~ s/\[verse\] *\n?//;
$conv->verse($par);
} elsif ($par =~ /^(\t| +)/s) {
$par =~ s/^$1//mg;
$par =~ s/^\+$//mg;
$conv->indent($par);
} elsif ($par =~ /^([^\n]*)::\n((\t| +).*)$/s) {
my ($first, $rest, $indent) = ($1, $2, $3);
$rest =~ s/^\+$//mg;
while ($rest =~ /^(.*?\n\n)--+\n(.*?\n)--+\n\n(.*)$/s) {
my ($pre, $verb, $post) = ($1, $2, $3);
$pre =~ s/^(\t|$indent)//mg;
if ($first ne '') {
$conv->begin_item($first, $pre);
$first = '';
} else {
$conv->normal($pre);
}
$conv->verbatim($verb);
$rest = $post;
}
$rest =~ s/^(\t|$indent)//mg;
if ($first ne '') {
$conv->begin_item($first, $rest);
} else {
$conv->normal($rest);
}
$conv->end_item();
} elsif ($par =~ /^-+\n(.*\n)-+\n$/s) {
$conv->verbatim($1);
} else {
$conv->normal($par);
}
$par = '';
}
sub handle_file {
my $in;
open($in, '<' . $_[0]);
while (<$in>) {
if (/^=+$/) {
if ($par ne '' && length($_) >= length($par)) {
$conv->header($par);
$par = '';
next;
}
} elsif (/^-+$/) {
if ($par ne '' && length($_) >= length($par)) {
$conv->section($par);
$par = '';
next;
}
} elsif (/^~+$/) {
if ($par ne '' && length($_) >= length($par)) {
$conv->subsection($par);
$par = '';
next;
}
} elsif (/^\[\[(.*)\]\]$/) {
handle_text();
$conv->anchor($1);
next;
} elsif (/^$/) {
if ($par =~ /^-+\n.*[^-]\n$/s) {
# fallthru; is verbatim, but needs more.
} elsif ($par =~ /::\n$/s) {
# is item, but needs more.
next;
} else {
handle_text();
next;
}
} elsif (/^include::(.*)\[\]$/) {
handle_text();
handle_file($1);
next;
}
# convert "\--" to "--"
s/\\--/--/g;
# convert "\*" to "*"
s/\\\*/*/g;
# handle gitlink:
s/gitlink:([^\[ ]*)\[(\d+)\]/sprintf "%s",
$conv->get_link($1, $2)/ge;
# handle link:
s/link:([^\[ ]*)\[(.+)\]/sprintf "%s",
$conv->get_link($1, $2, 'external')/ge;
$par .= $_;
}
close($in);
handle_text();
}
package man_page;
sub new {
my ($class) = @_;
my $self = {
sep => '',
links => [],
# generator => 'Home grown git txt2man converter'
generator => 'DocBook XSL Stylesheets v1.71.1 <http://docbook.sf.net/>'
};
bless $self, $class;
return $self;
}
sub header {
my ($self, $text) = @_;
$text =~ s/-/\\-/g;
if ($self->{preamble_shown} == undef) {
$title = $text;
$title =~ s/\(\d+\)$//;
print '.\" Title: ' . $title
. '.\" Author: ' . "\n"
. '.\" Generator: ' . $self->{generator} . "\n"
. '.\" Date: ' . $self->{date} . "\n"
. '.\" Manual: ' . $self->{manual} . "\n"
. '.\" Source: ' . $self->{git_version} . "\n"
. '.\"' . "\n";
}
$text =~ tr/a-z/A-Z/;
my $suffix = "\"$self->{date}\" \"$self->{git_version}\""
. " \"$self->{manual}\"";
$text =~ s/^(.*)\((\d+)\)$/.TH "\1" "\2" $suffix/;
print $text;
if ($self->{preamble_shown} == undef) {
print '.\" disable hyphenation' . "\n"
. '.nh' . "\n"
. '.\" disable justification (adjust text to left'
. ' margin only)' . "\n"
. '.ad l' . "\n";
$self->{preamble_shown} = 1;
}
$self->{last_op} = 'header';
}
sub section {
my ($self, $text) = @_;
$text =~ tr/a-z/A-Z/;
$text =~ s/^(.*)$/.SH "\1"/;
print $text;
$self->{last_op} = 'section';
}
sub subsection {
my ($self, $text) = @_;
$text =~ s/^(.*)$/.SS "\1"/;
print $text;
$self->{last_op} = 'subsection';
}
sub get_link {
my ($self, $command, $section, $option) = @_;
if ($option eq 'external') {
my $links = $self->{links};
push(@$links, $command);
$command =~ s/\.html$//;
$command =~ s/-/ /g;
push(@$links, $command);
return '\fI' . $command . '\fR\&[1]';
} else {
return '\fB' . $command . '\fR(' . $section . ')';
}
}
sub common {
my ($self, $text, $option) = @_;
# escape backslashes, but not in "\n", "\&" or "\fB"
$text =~ s/\\(?!n|f[A-Z]|&)/\\\\/g;
# escape "-"
$text =~ s/-/\\-/g;
# handle ...
$text =~ s/(\.\.\.)/\\&\1/g;
# remove double space after full stop or comma
$text =~ s/([\.,]) /\1 /g;
if ($option ne 'no-markup') {
# make 'italic'
$text =~ s/'([^'\n]*)'/\\fI\1\\fR/g;
# ignore `
$text =~ s/`//g;
# make *bold*
$text =~ s/\*([^\*\n]*)\*/\\fB\1\\fR/g;
# handle <<sections>
$text =~ s/<<([^>]*)>>/the section called \\(lq\1\\(rq/g;
}
return $text;
}
sub normal {
my ($self, $text) = @_;
if ($text eq "") {
return;
}
$text = $self->common($text);
$text =~ s/ *\n(.)/ \1/g;
if ($self->{last_op} eq 'normal') {
print "\n";
}
print $text;
$self->{last_op} = 'normal';
}
sub verse {
my ($self, $text) = @_;
$text = $self->common($text);
$text =~ s/^\t/ /mg;
print ".sp\n.RS 4\n.nf\n" . $text . ".fi\n.RE\n";
$self->{last_op} = 'verse';
}
sub enumeration {
my ($self, $text, $option) = @_;
my $counter = 0;
foreach $line (@$text) {
$counter++;
print ".TP 4\n"
. ($option eq 'unnumbered' ? '\(bu' : $counter . '.')
. "\n"
. $self->common($line);
}
$self->{last_op} = 'enumeration';
}
sub begin_item {
my ($self, $item, $text) = @_;
$item = $self->common($item);
$text = $self->common($text);
$text =~ s/([^\n]) *\n([^\n])/\1 \2/g;
print ".PP\n" . $item . "\n.RS 4\n" . $text;
$self->{last_op} = 'item';
}
sub end_item {
my ($self) = @_;
print ".RE\n";
$self->{last_op} = 'end_item';
}
sub indent {
my ($self, $text) = @_;
$text = $self->common($text, 'no-markup');
$text =~ s/^\t/ /mg;
if ($self->{last_op} eq 'normal') {
print "\n";
}
print ".sp\n.RS 4\n.nf\n" . $text . ".fi\n.RE\n";
$self->{last_op} = 'indent';
}
sub verbatim {
my ($self, $text) = @_;
$text = $self->common($text, 'no-markup');
# convert tabs to spaces
$text =~ s/^\t/ /mg;
# remove trailing empty lines
$text =~ s/\n\n*$/\n/;
if ($self->{last_op} eq 'normal') {
print "\n";
}
print ".sp\n.RS 4\n.nf\n.ft C\n" . $text . ".ft\n\n.fi\n.RE\n";
$self->{last_op} = 'verbatim';
}
sub anchor {
my ($self, $text) = @_;
$self->{last_op} = 'anchor';
}
sub finish {
my ($self) = @_;
my $links = $self->{links};
if ($#$links >= 0) {
print '.SH "REFERENCES"' . "\n";
my $i = 1;
while ($#$links >= 0) {
my $ref = shift(@$links);
$ref =~ s/-/\\-/g;
my $label = shift(@$links);
printf (".IP \"% 2d.\" 4\n%s\n.RS 4\n\\%%%s\n.RE\n",
$i++, $label, $ref);
}
} else {
print "\n";
}
}
package html_page;
sub new {
my ($class) = @_;
my $self = {};
bless $self, $class;
return $self;
}
-- snap --
Ciao,
Dscho
P.S.: I need to catch some Zs, and do some real work, so do not be
surprised if I do not respond within the next 24 hours.
^ permalink raw reply
* Re: [PATCH] Change "refs/" references to symbolic constants
From: Junio C Hamano @ 2007-10-03 0:22 UTC (permalink / raw)
To: Jeff King; +Cc: Andy Parkins, git
In-Reply-To: <20071002204848.GA8284@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Perhaps a better quest would be to eliminate all of those counts
> entirely with code that is obviously correct. I think it is much more
> readable to replace:
>
> url = xmalloc(strlen(repo->base) + 64);
> sprintf(url, "%s/objects/pack/pack-%s.idx", repo->base, hex);
>
> with something like:
>
> strbuf_init(&url);
> strbuf_addf(&url, "%s/objects/pack/pack-%s.idx", repo->base, hex);
Ugh, this typically calls snprintf() twice doesn't it?
^ permalink raw reply
* Re: [PATCH] Mention 'cpio' dependency in INSTALL
From: Junio C Hamano @ 2007-10-03 0:14 UTC (permalink / raw)
To: Johan Herland; +Cc: git, Reece Dunn
In-Reply-To: <200710030142.30062.johan@herland.net>
Johan Herland <johan@herland.net> writes:
> reveals that cpio is not mentioned anywhere in the documentation,
> nor in the requirements section of the INSTALL file.
Thanks.
We use many other tools that are typically found in bog-standard
UNIX environments, like sed, echo, cat, sort, etc. and we do not
list them in the INSTALL file (nor we would want to). cpio used
to be in the "bog standard" category but perhaps Linux distros
do not install it by default, so it is worth listing it there.
Are there other commands we rely on that may not be universally
installed? I myself consider "cut" to be in the category, but
other than that I do not think of anything offhand.
^ permalink raw reply
* [PATCH] Mention 'cpio' dependency in INSTALL
From: Johan Herland @ 2007-10-02 23:42 UTC (permalink / raw)
To: git; +Cc: Reece Dunn, Junio C Hamano
In-Reply-To: <3f4fd2640710021409q104a4204r522391912d5b5c8c@mail.gmail.com>
Signed-off-by: Johan Herland <johan@herland.net>
---
On Tuesday 02 October 2007, Reece Dunn wrote:
> Do you know if cpio is listed anywhere in required dependencies?
Doing the following in the git repo:
$ grep -r cpio *
git-clone.sh: find objects -depth -print | cpio -pumd$l "$GIT_DIR/" || exit 1
git-merge.sh: cpio -0 -o >"$GIT_DIR/MERGE_SAVE"
git-merge.sh: cpio -iuv <"$GIT_DIR/MERGE_SAVE"
reveals that cpio is not mentioned anywhere in the documentation,
nor in the requirements section of the INSTALL file.
Have fun!
...Johan
INSTALL | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/INSTALL b/INSTALL
index 289b046..f1eb404 100644
--- a/INSTALL
+++ b/INSTALL
@@ -79,6 +79,9 @@ Issues of note:
- "perl" and POSIX-compliant shells are needed to use most of
the barebone Porcelainish scripts.
+ - "cpio" is used by git-merge for saving and restoring the index,
+ and by git-clone when doing a local (possibly hardlinked) clone.
+
- Some platform specific issues are dealt with Makefile rules,
but depending on your specific installation, you may not
have all the libraries/tools needed, or you may have
--
1.5.3.3.1144.gf10f2
^ permalink raw reply related
* [PATCH 4/4] Make git-pull complain and give advice when there is nothing to pull from
From: Federico Mena Quintero @ 2007-10-02 23:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <1191367817.3776.192.camel@cacharro.xalalinux.org>
Signed-off-by: Federico Mena Quintero <federico@gnu.org>
---
git-pull.sh | 22 ++++++++++++++++++----
1 files changed, 18 insertions(+), 4 deletions(-)
diff --git a/git-pull.sh b/git-pull.sh
index c3f05f5..74bfc16 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -97,10 +97,24 @@ case "$merge_head" in
esac
curr_branch=${curr_branch#refs/heads/}
- echo >&2 "Warning: No merge candidate found because value of config option
- \"branch.${curr_branch}.merge\" does not match any remote branch fetched."
- echo >&2 "No changes."
- exit 0
+ echo >&2 "You asked me to pull without telling me which branch you"
+ echo >&2 "want to merge with, and 'branch.${curr_branch}.merge' in"
+ echo >&2 "your configuration file does not tell me either. Please"
+ echo >&2 "name which branch you want to merge on the command line and"
+ echo >&2 "try again (e.g. 'git pull <repository> <refspec>')."
+ echo >&2 "See git-pull(1) for details on the refspec."
+ echo >&2
+ echo >&2 "If you often merge with the same branch, you may want to"
+ echo >&2 "configure the following variables in your configuration"
+ echo >&2 "file:"
+ echo >&2
+ echo >&2 " branch.${curr_branch}.remote = <nickname>"
+ echo >&2 " branch.${curr_branch}.merge = <remote-ref>"
+ echo >&2 " remote.<nickname>.url = <url>"
+ echo >&2 " remote.<nickname>.fetch = <refspec>"
+ echo >&2
+ echo >&2 "See git-config(1) for details."
+ exit 1
;;
?*' '?*)
if test -z "$orig_head"
--
1.5.2.4
^ permalink raw reply related
* Re: [PATCH 1/4] Add documentation for --track and --no-track to the git-branch docs.
From: Federico Mena Quintero @ 2007-10-02 23:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <1191368010.3776.198.camel@cacharro.xalalinux.org>
Arrrr... this should be "[PATCH 2/4]", of course. Sorry for the
confusion.
Federico
^ permalink raw reply
* [PATCH 3/4] Note that git-branch will not automatically checkout the new branch
From: Federico Mena Quintero @ 2007-10-02 23:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <1191367817.3776.192.camel@cacharro.xalalinux.org>
Signed-off-by: Federico Mena Quintero <federico@gnu.org>
---
Documentation/git-branch.txt | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt
index e9c12f9..53c1158 100644
--- a/Documentation/git-branch.txt
+++ b/Documentation/git-branch.txt
@@ -26,6 +26,10 @@ It will start out with a head equal to the one given as <start-point>.
If no <start-point> is given, the branch will be created with a head
equal to that of the currently checked out branch.
+Note that this will create the new branch, but it will not switch the
+working tree to it; use "git checkout <newbranch>" to switch to the
+new branch.
+
When a local branch is started off a remote branch, git can setup the
branch so that gitlink:git-pull[1] will appropriately merge from that
remote branch. If this behavior is desired, it is possible to make it
--
1.5.2.4
^ permalink raw reply related
* Re: metastore
From: Julian Phillips @ 2007-10-02 23:32 UTC (permalink / raw)
To: David Härdeman
Cc: David Kastrup, martin f krafft, git, Daniel Barkalow,
Johannes Schindelin, Thomas Harning Jr., Francis Moreau,
Nicolas Vilz
In-Reply-To: <20071002211518.GA10445@hardeman.nu>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 3128 bytes --]
On Tue, 2 Oct 2007, David Härdeman wrote:
> On Tue, Oct 02, 2007 at 10:04:56PM +0200, David Kastrup wrote:
>> David Härdeman <david@hardeman.nu> writes:
>>
>> > On Tue, Oct 02, 2007 at 08:53:01PM +0100, martin f krafft wrote:
>> > > also sprach David Härdeman <david@hardeman.nu> [2007.09.19.2016 +0100]:
>> > > > But I agree, if any changes were made to git, I'd advocate adding
>> > > > arbitrary attributes to files (much like xattrs) in name=value
>> > > > pairs, then any extended metadata could be stored in those
>> > > > attributes and external scripts/tools could use them in some way
>> > > > that makes sense...and also make sure to only update them when it
>> > > > makes sense.
>> > >
>> > > So where would those metdata be stored in your opinion?
>> >
>> > I'm not sufficiently versed in the internals of git to have an
>> > informed opinion :)
>>
>> I think we have something like a length count for file names in index
>> and/or tree. We could just put the (sorted) attributes after a NUL
>> byte in the file name and include them in the count. It would also
>> make those artificially longer file names work more or less when
>> sorting them for deltification.
>
> Or perhaps the index format could be extended to include a new field for
> value=name pairs instead of overloading the name field.
>
> But as I said, I have no idea how feasible it would be to change git to
> support another arbitrary length field in the index/tree file.
>
>> However, this requires implementing _policies_: it must be possible to
>> specify per repository exactly what will and what won't get tracked,
>> or one will get conflicts that are not necessary or appropriate.
>
> I think the opposite approach would be better. Let git provide set/get/delete
> attribute operations and leave it at that. Then external programs can do what
> they want with that data and add/remove/modify tags as necessary (and also
> include the smarts to not, e.g. remove the permissions on all files if the
> git repo is checked out to a FAT fs).
You need more than that. You need to be able to log, blame etc on the
attributes. One of the big annoyances of Subversion properties is being
unable to find out when or why a property value was changed.
I still don't see why the attributes need to be stored in git directly -
particularly if you are going to use an external program to actually apply
any settings - why not store the attributes as normal file (or files) of
some sort tracked by git? You could use any number of methods - e.g. use
an sqlite database stored in the root of your tree, or a .<name>.props
file alongside each path that you have properties for. You could even
write a system that uses such a method and was then SCM agnostic, allowing
you to keep your attribute tracking system if/when something better than
git comes along - or simply share it with less-fortunate souls stuck in an
inferior system.
--
Julian
---
A strong conviction that something must be done is the parent of many
bad measures.
-- Daniel Webster
^ permalink raw reply
* [PATCH 1/4] Add documentation for --track and --no-track to the git-branch docs.
From: Federico Mena Quintero @ 2007-10-02 23:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <1191367817.3776.192.camel@cacharro.xalalinux.org>
Signed-off-by: Federico Mena Quintero <federico@gnu.org>
---
Documentation/git-branch.txt | 15 +++++++++++++++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt
index 33bc31b..e9c12f9 100644
--- a/Documentation/git-branch.txt
+++ b/Documentation/git-branch.txt
@@ -91,6 +91,21 @@ OPTIONS
--no-abbrev::
Display the full sha1s in output listing rather than abbreviating them.
+--track::
+ Set up configuration so that git-pull will automatically
+ retrieve data from the remote branch. Use this if you always
+ pull from the same remote branch into the new branch, or if you
+ don't want to use "git pull <repository> <refspec>" explicitly. Set the
+ branch.autosetupmerge configuration variable to true if you
+ want git-checkout and git-branch to always behave as if
+ '--track' were given.
+
+--no-track::
+ When -b is given and a branch is created off a remote branch,
+ set up configuration so that git-pull will not retrieve data
+ from the remote branch, ignoring the branch.autosetupmerge
+ configuration variable.
+
<branchname>::
The name of the branch to create or delete.
The new branch name must pass all checks defined by
--
1.5.2.4
^ permalink raw reply related
* [PATCH 1/4] Say when --track is useful in the git-checkout docs.
From: Federico Mena Quintero @ 2007-10-02 23:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <1191367817.3776.192.camel@cacharro.xalalinux.org>
The documentation used to say what the option does, but it
didn't mention a use case.
Signed-off-by: Federico Mena Quintero <federico@gnu.org>
---
Documentation/git-checkout.txt | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt
index 734928b..dbd1a4a 100644
--- a/Documentation/git-checkout.txt
+++ b/Documentation/git-checkout.txt
@@ -50,7 +50,9 @@ OPTIONS
--track::
When -b is given and a branch is created off a remote branch,
set up configuration so that git-pull will automatically
- retrieve data from the remote branch. Set the
+ retrieve data from the remote branch. Use this if you always
+ pull from the same remote branch into the new branch, or if you
+ don't want to use "git pull <repository> <refspec>" explicitly. Set the
branch.autosetupmerge configuration variable to true if you
want git-checkout and git-branch to always behave as if
'--track' were given.
--
1.5.2.4
^ permalink raw reply related
* [PATCH 0/4] Another round of the --track patches
From: Federico Mena Quintero @ 2007-10-02 23:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v3axbvbto.fsf@gitster.siamese.dyndns.org>
On Tue, 2007-09-18 at 15:38 -0700, Junio C Hamano wrote:
> Federico Mena Quintero <federico@novell.com> writes:
> > - retrieve data from the remote branch. Set the
> > + retrieve data from the remote branch, otherwise you'll have to
> > + use "git pull <url>" explicitly. Set the
> > branch.autosetupmerge configuration variable to true if you
> > want git-checkout and git-branch to always behave as if
> > '--track' were given.
>
> Hmph.
>
> I'd rather make them consistent by dropping the not-so-correct
> "otherwise" phrase from all three copies. It is not "otherwise
> you'll have to", but "instead you can".
Sure, I've added better wording now.
> I am inclined to suggest rewording the message like this, and
> make this condition an error (i.e. "exit 1"):
[snip]
I like that message much better, and it's nice that it gives you the
snippet to put in your config file. This is in patch 4/4.
Thanks for the review; I hope this can make it in now ;)
Federico
^ permalink raw reply
* Re: git-svn merge helper
From: Björn Steinbrink @ 2007-10-02 22:38 UTC (permalink / raw)
To: Steven Walter; +Cc: git
In-Reply-To: <20071002220458.GA21038@dervierte>
On 2007.10.02 18:04:58 -0400, Steven Walter wrote:
> On Tue, Oct 02, 2007 at 11:14:00PM +0200, Björn Steinbrink wrote:
> > One common pattern in SVN is to have the feature branch following the
> > trunk. In git terms, that would mean that the feature branch is
> > continually rebased onto the HEAD of the HEAD AFAICT (although SVN of
> > course cannot represent that). The problem with that is, that git
> > doesn't create a merge commit in that case and git-svn gets confused
> > again.
> >
> > git checkout mybranch
> > git merge master # Creates a merge commit
> > git checkout master
> > git merge mybranch # Does just fast forward
> >
> > Is there anyway to force a merge commit or some other work around?
>
> When I want to do something like this, I go about it one of two ways.
> The first option is to simply rebase mybranch onto master. Since my
> feature branches are not usually published, there is no problem
> rewinding them. That may not be an option for you, however.
Unfortunately not, the branch in question is required to be in the SVN
repository.
> The other option is to have a "build" branch. By example:
>
> git checkout build
> git reset --hard master
> git merge mybranch
> make
>
> In that way, I have branch with the latest changes from head and the
> changes from mybranch together. The downside to this method is that you
> may have to repeated resolve merges. Despite the downsides, I find
> these two methods to work quite well.
Thanks, but it makes no difference here, it stil results in a fast
forward. This is a small test case which exhibits the behaviour and
matches my current workflow with git-svn (except for the dcommits):
git init
echo Hi > file1; git add file1; git commit -m file1
git checkout -b branch
echo Hi > file2; git add file2; git commit -m file2
git checkout master
echo Hi > file3; git add file3; git commit -m file3
git checkout branch
git merge master
# Then I'd normally do the following which causes a fast forward
#git checkout master
#git merge branch
# Now I tried this, which also results in a fast-forward:
git checkout -b merge
git reset --hard master
git merge branch
Anything I'm missing?
Thanks,
Björn
^ permalink raw reply
* [PATCH] for-each-ref: fix %(numparent) and %(parent)
From: Junio C Hamano @ 2007-10-02 22:12 UTC (permalink / raw)
To: git; +Cc: Andy Parkins
In-Reply-To: <200710021202.42452.andyparkins@gmail.com>
The string value of %(numparent) was not returned correctly.
Also %(parent) misbehaved for the root commits (returned garbage)
and merge commits (returned first parent, followed by a space).
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
* I noticed this while playing with Andy's patch to enhance the
date format string we saw recently on the list.
Andy does not have anything to do with the breakage; this
patch is against 'maint' to fix the bug that has always been
there from the very beginning of this code.
builtin-for-each-ref.c | 10 ++++++----
1 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/builtin-for-each-ref.c b/builtin-for-each-ref.c
index 0afa1c5..29f70aa 100644
--- a/builtin-for-each-ref.c
+++ b/builtin-for-each-ref.c
@@ -43,7 +43,7 @@ static struct {
{ "objectsize", FIELD_ULONG },
{ "objectname" },
{ "tree" },
- { "parent" }, /* NEEDSWORK: how to address 2nd and later parents? */
+ { "parent" },
{ "numparent", FIELD_ULONG },
{ "object" },
{ "type" },
@@ -262,24 +262,26 @@ static void grab_commit_values(struct atom_value *val, int deref, struct object
}
if (!strcmp(name, "numparent")) {
char *s = xmalloc(40);
+ v->ul = num_parents(commit);
sprintf(s, "%lu", v->ul);
v->s = s;
- v->ul = num_parents(commit);
}
else if (!strcmp(name, "parent")) {
int num = num_parents(commit);
int i;
struct commit_list *parents;
- char *s = xmalloc(42 * num);
+ char *s = xmalloc(41 * num + 1);
v->s = s;
for (i = 0, parents = commit->parents;
parents;
- parents = parents->next, i = i + 42) {
+ parents = parents->next, i = i + 41) {
struct commit *parent = parents->item;
strcpy(s+i, sha1_to_hex(parent->object.sha1));
if (parents->next)
s[i+40] = ' ';
}
+ if (!i)
+ *s = '\0';
}
}
}
--
1.5.3.3.1144.gf10f2
^ permalink raw reply related
* Re: merging .gitignore
From: Pierre Habouzit @ 2007-10-02 22:07 UTC (permalink / raw)
To: martin f krafft; +Cc: git, Andy Parkins, Johannes Schindelin
In-Reply-To: <20071002214919.GA21260@lapse.madduck.net>
[-- Attachment #1: Type: text/plain, Size: 966 bytes --]
On Tue, Oct 02, 2007 at 09:49:19PM +0000, martin f krafft wrote:
> also sprach Pierre Habouzit <madcoder@debian.org> [2007.10.02.2207 +0100]:
> > > > (a*)
> > > > / \
> > > > (ab*) (ac*)
> > > > \ /
> > > > ????
> > >
> > > (a*, ab*, ac*)
> >
> > Definitely not. a* -> ab* is making a?* unignored for any value of ?
> > except b. So adding a* is definitely invalid.
>
> In left, ab* is still ignored, in right ac* is still ignored, and in
> the integration branch, they're all ignored. We don't merge up in
> this model...
err maybe you didn't get my little picture
(a*)
/ \
v v
(ab*) (ac*)
\ /
v v
????
This is a perfectly sensible history. Or I miss sth on your end.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: git-svn merge helper
From: Steven Walter @ 2007-10-02 22:04 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: git
In-Reply-To: <20071002211400.GA992@atjola.homenet>
On Tue, Oct 02, 2007 at 11:14:00PM +0200, Björn Steinbrink wrote:
> One common pattern in SVN is to have the feature branch following the
> trunk. In git terms, that would mean that the feature branch is
> continually rebased onto the HEAD of the HEAD AFAICT (although SVN of
> course cannot represent that). The problem with that is, that git
> doesn't create a merge commit in that case and git-svn gets confused
> again.
>
> git checkout mybranch
> git merge master # Creates a merge commit
> git checkout master
> git merge mybranch # Does just fast forward
>
> Is there anyway to force a merge commit or some other work around?
When I want to do something like this, I go about it one of two ways.
The first option is to simply rebase mybranch onto master. Since my
feature branches are not usually published, there is no problem
rewinding them. That may not be an option for you, however.
The other option is to have a "build" branch. By example:
git checkout build
git reset --hard master
git merge mybranch
make
In that way, I have branch with the latest changes from head and the
changes from mybranch together. The downside to this method is that you
may have to repeated resolve merges. Despite the downsides, I find
these two methods to work quite well.
--
-Steven Walter <stevenrwalter@gmail.com>
"A human being should be able to change a diaper, plan an invasion,
butcher a hog, conn a ship, design a building, write a sonnet, balance
accounts, build a wall, set a bone, comfort the dying, take orders,
give orders, cooperate, act alone, solve equations, analyze a new
problem, pitch manure, program a computer, cook a tasty meal, fight
efficiently, die gallantly. Specialization is for insects."
-Robert Heinlein
^ permalink raw reply
* Re: [PATCH] Support tags in uncommit - use git_id instead of rev_parse
From: Pavel Roskin @ 2007-10-02 22:03 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <b0943d9e0710011500o1bd621a4q10dfe0468c8795e2@mail.gmail.com>
On Mon, 2007-10-01 at 23:00 +0100, Catalin Marinas wrote:
> On 30/09/2007, Pavel Roskin <proski@gnu.org> wrote:
> > Signed-off-by: Pavel Roskin <proski@gnu.org>
>
> With this patch, uncommit can take patch names (with modifiers) as the
> --to argument. When would this be needed?
Probably never.
> To allow tags, maybe just pass something like
> "git.rev_parse(options.to + '^{commit}')" or just modify git.rev_parse
> to do it (and git_id to avoid it).
I prefer to work with software that understands what I mean and tells me
that I cannot do it. It makes it easier to understand what is possible
and how the command is working.
Recognizing patch names in some commands but not others would be
annoying and inconsistent. Dumbing downs interactive software on
purpose is probably not worth the trouble.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: merging .gitignore
From: martin f krafft @ 2007-10-02 21:49 UTC (permalink / raw)
To: Pierre Habouzit, git, Andy Parkins, Johannes Schindelin
In-Reply-To: <20071002210748.GC19710@artemis.corp>
[-- Attachment #1: Type: text/plain, Size: 904 bytes --]
also sprach Pierre Habouzit <madcoder@debian.org> [2007.10.02.2207 +0100]:
> > > (a*)
> > > / \
> > > (ab*) (ac*)
> > > \ /
> > > ????
> >
> > (a*, ab*, ac*)
>
> Definitely not. a* -> ab* is making a?* unignored for any value of ?
> except b. So adding a* is definitely invalid.
In left, ab* is still ignored, in right ac* is still ignored, and in
the integration branch, they're all ignored. We don't merge up in
this model...
--
.''`. martin f. krafft <madduck@debian.org>
: :' : proud Debian developer, author, administrator, and user
`. `'` http://people.debian.org/~madduck - http://debiansystem.info
`- Debian - when you have better things to do than fixing systems
"if there's anything more important than my ego,
i want it caught and shot now."
-- zaphod beeblebrox
[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: metastore
From: martin f krafft @ 2007-10-02 21:44 UTC (permalink / raw)
To: git
Cc: David Härdeman, David Kastrup, Daniel Barkalow,
Johannes Schindelin, Thomas Harning Jr., Francis Moreau,
Nicolas Vilz
In-Reply-To: <20071002211518.GA10445@hardeman.nu>
[-- Attachment #1: Type: text/plain, Size: 482 bytes --]
also sprach David Härdeman <david@hardeman.nu> [2007.10.02.2215 +0100]:
> I think the opposite approach would be better. Let git provide
> set/get/delete attribute operations and leave it at that.
I like that idea.
--
martin; (greetings from the heart of the sun.)
\____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
"information superhighway"
is just an anagram for
"i'm on a huge wispy rhino fart".
spamtraps: madduck.bogus@madduck.net
[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: metastore
From: martin f krafft @ 2007-10-02 21:42 UTC (permalink / raw)
To: git
Cc: david, David Kastrup, David Härdeman, Daniel Barkalow,
Johannes Schindelin, Thomas Harning Jr., Francis Moreau,
Nicolas Vilz
In-Reply-To: <Pine.LNX.4.64.0710021351400.24697@asgard.lang.hm>
[-- Attachment #1: Type: text/plain, Size: 636 bytes --]
also sprach david@lang.hm <david@lang.hm> [2007.10.02.2154 +0100]:
>> How could there be a conflict if you can't make local changes
>> because you can't represent the attributes locally/natively?
>
> you merge two uptream branches that disagree about the attributes
You win. :)
--
martin; (greetings from the heart of the sun.)
\____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
"mein gott, selbst ein huhn kann debian installieren, wenn du genug
koerner auf die enter-taste legst."
-- thomas koehler in de.alt.sysadmin.recovery
spamtraps: madduck.bogus@madduck.net
[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ 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