* Re: [PATCH] Allow update hooks to update refs on their own
From: Daniel Barkalow @ 2007-11-28 3:25 UTC (permalink / raw)
To: Steven Grimm; +Cc: Junio C Hamano, git
In-Reply-To: <49EB8C6F-8100-48C1-BB2D-A8F6023BACAD@midwinter.com>
On Tue, 27 Nov 2007, Steven Grimm wrote:
> On Nov 27, 2007, at 5:19 PM, Junio C Hamano wrote:
>
> >How does this interact with the "pretend to have fetched back
> >immediately" supported by modern git-push?
>
>
> That continues to fire, but it updates the local tracking ref to point to the
> SHA1 that was pushed, which isn't the actual remote ref. So you have to do a
> real fetch to get the local tracking ref pointed to the right place. In other
> words, that feature doesn't do any good in this context, but it doesn't really
> hurt anything either.
>
> It would of course be better if git-push could notice that it needs to do an
> actual fetch. I think it'd be sufficient to transmit the final remote ref SHA1
> back to git-push, and if it doesn't match what was pushed, that's a sign that
> a fetch is needed. But that change wouldn't be mutually exclusive with this
> patch, I believe.
Couldn't you do this with a status message? ("ok <refname> changed by
hook" or something.)
I disagree that the feature doesn't do any good; it records that the state
of the remote is at least as new as the local state, so you can tell
without a network connection that you don't have any local changes you
haven't sent off.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH] Allow update hooks to update refs on their own
From: Junio C Hamano @ 2007-11-28 3:49 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Steven Grimm, git
In-Reply-To: <Pine.LNX.4.64.0711272143470.5349@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> writes:
> On Tue, 27 Nov 2007, Steven Grimm wrote:
>
>> On Nov 27, 2007, at 5:19 PM, Junio C Hamano wrote:
>>
>> >How does this interact with the "pretend to have fetched back
>> >immediately" supported by modern git-push?
>>
>>
>> That continues to fire, but it updates the local tracking ref to point to the
>> SHA1 that was pushed, which isn't the actual remote ref. So you have to do a
>> real fetch to get the local tracking ref pointed to the right place. In other
>> words, that feature doesn't do any good in this context, but it doesn't really
>> hurt anything either.
>>
>> It would of course be better if git-push could notice that it needs to do an
>> actual fetch. I think it'd be sufficient to transmit the final remote ref SHA1
>> back to git-push, and if it doesn't match what was pushed, that's a sign that
>> a fetch is needed. But that change wouldn't be mutually exclusive with this
>> patch, I believe.
>
> Couldn't you do this with a status message? ("ok <refname> changed by
> hook" or something.)
>
> I disagree that the feature doesn't do any good; it records that the state
> of the remote is at least as new as the local state, so you can tell
> without a network connection that you don't have any local changes you
> haven't sent off.
Yeah, and I am wondering why update hook needs to be changed for this.
Didn't we introduce post-receive exactly for this sort of thing?
^ permalink raw reply
* Re: Rollback of git commands
From: Sean @ 2007-11-28 3:55 UTC (permalink / raw)
To: Jon Smirl; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <9e4733910711271733r6f280618pbb14095aebba3309@mail.gmail.com>
On Tue, November 27, 2007 8:33 pm, Jon Smirl said:
Hi Jon,
> I'm only looking for a command that would rollback the effect of
> changes to the object store (you don't have to remove the objects).
> Losing complex staging would be ok since it can be recreated.
>
> Let's take my recent problem as an example. I typed 'git rebase
> linus/master' instead of 'stg rebase linus/master'. Then I typed 'stg
> repair'. The repair failed and left me in a mess. Both of these are
> easy to rollback except for the fact that stg has stored a bunch of
> state in .git/*.
>
> After doing the commands I located my last commit before the rebase
> and edited master back to it. But my system was still messed up since
> moving master got me out of sync with the state stg stored in .git/*.
> The 'stg repair' command had changed the stored state.
From your description is seems that Git proper was able to handle the
situation just fine. It sounds instead like you're describing a problem
with Stg where it became confused without a way to restore _its_ meta
data. There's not much Git itself can do to help in this situation
unless Stg stores all of its meta-data as standard Git objects, rather
than just using the .git directory.
Sean
^ permalink raw reply
* Re: Rollback of git commands
From: Geert Bosch @ 2007-11-28 4:07 UTC (permalink / raw)
To: Jon Smirl; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <9e4733910711271749q1b96bfe9i60e43619c89234b9@mail.gmail.com>
On Nov 27, 2007, at 20:49, Jon Smirl wrote:
> Rollback is too strong of name for this. Checkpoints would be better.
> The idea is to record the total system state at convenient moments and
> then allow moving back to the checkpointed state. The object store
> supports this, but the rest of the state in .git/* isn't being
> recorded.
I have always wondered why refs and tags are not
in the regular object store. In a way, there
should be just one root pointer (SHA1) pointing
to a tree with refs, etc.
As for the problem of "lots of loose objects", each
command could write a single pack file. By directly
writing deltas instead of complete new tree objects,
storage requirements should be modest. Also, just
writing a single new pack file is very efficient
for I/O purposes.
To prevent too many pack files, a merge policy
could allow a new pack to include (and thus obsolete)
a number of similarly sized or smaller packs.
After the new file has been successfully written, the
old files are no longer necessary and can be
moved to a "trashes" area to be expired.
-Geert
^ permalink raw reply
* Re: Rollback of git commands
From: Jon Smirl @ 2007-11-28 4:37 UTC (permalink / raw)
To: Sean; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <BAYC1-PASMTP02DBA3FB25E09FE45F0BF2AE770@CEZ.ICE>
On 11/27/07, Sean <seanlkml@sympatico.ca> wrote:
> On Tue, November 27, 2007 8:33 pm, Jon Smirl said:
>
> Hi Jon,
>
> > I'm only looking for a command that would rollback the effect of
> > changes to the object store (you don't have to remove the objects).
> > Losing complex staging would be ok since it can be recreated.
> >
> > Let's take my recent problem as an example. I typed 'git rebase
> > linus/master' instead of 'stg rebase linus/master'. Then I typed 'stg
> > repair'. The repair failed and left me in a mess. Both of these are
> > easy to rollback except for the fact that stg has stored a bunch of
> > state in .git/*.
> >
> > After doing the commands I located my last commit before the rebase
> > and edited master back to it. But my system was still messed up since
> > moving master got me out of sync with the state stg stored in .git/*.
> > The 'stg repair' command had changed the stored state.
>
> From your description is seems that Git proper was able to handle the
> situation just fine. It sounds instead like you're describing a problem
> with Stg where it became confused without a way to restore _its_ meta
> data. There's not much Git itself can do to help in this situation
> unless Stg stores all of its meta-data as standard Git objects, rather
> than just using the .git directory.
Patch management is an important part of the work flow. I would hope
that git implements patch management as a core feature in future
versions. stgit/guilt/quilt are valuable since they blazed the trail
and figured out what commands are useful. As time passes these
features can become more highly integrated into core git.
Of course you've never screwed up a repository using git commands,
right? I've messed up plenty. A good way to mess up a repo is to get
the data in .git/* out of sync with what is in the repo. I'm getting
good enough with git that I can fix most mess up with a few edits, but
it took me two years to get to that point. Rolling back to a check
point is way easier. User error and a command failing are both equally
valid ways to mess up a repo.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [PATCH] Replace misleading message during interactive rebasing
From: Junio C Hamano @ 2007-11-28 4:37 UTC (permalink / raw)
To: Johannes Sixt
Cc: Wincent Colaiuta, git, tsuna, Johannes.Schindelin, mcostalba
In-Reply-To: <474BD5CA.7050407@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
> Wincent Colaiuta schrieb:
>> + export _GIT_CHERRY_PICK_HELP="run 'git rebase --continue'"
>
> Isn't this a bashism?
Being an old-fashioned shell programmer myself, "export VAR=VAL" does
raise my eyebrows. It is in POSIX but are there shells that we do
support (dash, bash, ksh -- /bin/sh on Solaris does not count) that
want their exports old-fashioned way?
^ permalink raw reply
* Re: Rollback of git commands
From: Sean @ 2007-11-28 4:40 UTC (permalink / raw)
To: Jon Smirl; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <9e4733910711272037r2ce3ed01y31ec8531f5803efe@mail.gmail.com>
On Tue, November 27, 2007 11:37 pm, Jon Smirl said:
> Patch management is an important part of the work flow. I would hope
> that git implements patch management as a core feature in future
> versions. stgit/guilt/quilt are valuable since they blazed the trail
> and figured out what commands are useful. As time passes these
> features can become more highly integrated into core git.
Think this is a separate topic from where we started though.
> Of course you've never screwed up a repository using git commands,
> right? I've messed up plenty. A good way to mess up a repo is to get
> the data in .git/* out of sync with what is in the repo. I'm getting
> good enough with git that I can fix most mess up with a few edits, but
> it took me two years to get to that point. Rolling back to a check
> point is way easier. User error and a command failing are both equally
> valid ways to mess up a repo.
What are you looking for that reflogs don't already handle?
Cheers,
Sean
^ permalink raw reply
* Re: Rollback of git commands
From: Jon Smirl @ 2007-11-28 4:53 UTC (permalink / raw)
To: Sean; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <BAYC1-PASMTP101A96ADE42981D2708652AE770@CEZ.ICE>
On 11/27/07, Sean <seanlkml@sympatico.ca> wrote:
> On Tue, November 27, 2007 11:37 pm, Jon Smirl said:
>
> > Patch management is an important part of the work flow. I would hope
> > that git implements patch management as a core feature in future
> > versions. stgit/guilt/quilt are valuable since they blazed the trail
> > and figured out what commands are useful. As time passes these
> > features can become more highly integrated into core git.
>
> Think this is a separate topic from where we started though.
>
> > Of course you've never screwed up a repository using git commands,
> > right? I've messed up plenty. A good way to mess up a repo is to get
> > the data in .git/* out of sync with what is in the repo. I'm getting
> > good enough with git that I can fix most mess up with a few edits, but
> > it took me two years to get to that point. Rolling back to a check
> > point is way easier. User error and a command failing are both equally
> > valid ways to mess up a repo.
>
> What are you looking for that reflogs don't already handle?
A UI that doesn't need a year of using git before you know what to do with it.
Delta tracking of changes made in .git/* that aren't currently being tracked.
reflogs is a piece of the complete solution.
A higher level of integration for stgit would probably make it more
bullet proof.
>
> Cheers,
> Sean
>
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [PATCH] Allow update hooks to update refs on their own
From: Steven Grimm @ 2007-11-28 2:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v4pf7b20b.fsf@gitster.siamese.dyndns.org>
On Nov 27, 2007, at 5:19 PM, Junio C Hamano wrote:
> How does this interact with the "pretend to have fetched back
> immediately" supported by modern git-push?
That continues to fire, but it updates the local tracking ref to point
to the SHA1 that was pushed, which isn't the actual remote ref. So you
have to do a real fetch to get the local tracking ref pointed to the
right place. In other words, that feature doesn't do any good in this
context, but it doesn't really hurt anything either.
It would of course be better if git-push could notice that it needs to
do an actual fetch. I think it'd be sufficient to transmit the final
remote ref SHA1 back to git-push, and if it doesn't match what was
pushed, that's a sign that a fetch is needed. But that change wouldn't
be mutually exclusive with this patch, I believe.
-Steve
^ permalink raw reply
* Re: Rollback of git commands
From: Junio C Hamano @ 2007-11-28 4:57 UTC (permalink / raw)
To: Sean; +Cc: Jon Smirl, Git Mailing List
In-Reply-To: <BAYC1-PASMTP02DBA3FB25E09FE45F0BF2AE770@CEZ.ICE>
"Sean" <seanlkml@sympatico.ca> writes:
>> After doing the commands I located my last commit before the rebase
>> and edited master back to it. But my system was still messed up since
>> moving master got me out of sync with the state stg stored in .git/*.
>> The 'stg repair' command had changed the stored state.
>
> From your description is seems that Git proper was able to handle the
> situation just fine. It sounds instead like you're describing a problem
> with Stg where it became confused without a way to restore _its_ meta
> data. There's not much Git itself can do to help in this situation
> unless Stg stores all of its meta-data as standard Git objects, rather
> than just using the .git directory.
Essentially, he does not want to use "git rebase" and have a way to
disable the command on a branch that stg is actively munging. And that
is something git proper can help with the user, which is why I earlier
referred him to pre-rebase hook.
As you suggested, however, git proper should not know the internals of
Porcelains, so I'd rather not to have that logic deep in git-rebase
itself. But the pre-rebase hook shoud be the appropriate place for the
user to actually populate with stg specific logic ("is stg set to
actively munge this branch") and activate it for his repository.
^ permalink raw reply
* Re: [PATCH] Allow update hooks to update refs on their own
From: Steven Grimm @ 2007-11-28 5:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Daniel Barkalow, git
In-Reply-To: <7vzlwz9ghg.fsf@gitster.siamese.dyndns.org>
On Nov 27, 2007, at 7:49 PM, Junio C Hamano wrote:
> Yeah, and I am wondering why update hook needs to be changed for this.
> Didn't we introduce post-receive exactly for this sort of thing?
I didn't think the post-receive hook could reject a revision. I need
to be able to do that here, e.g., if the user's change fails to commit
because it's rejected by an svn commit hook. (Hooks upon hooks upon
hooks...) If I do the svn commit in post-receive it's not clear how
the user would repush the change after fixing it -- their fix would
show up as a delta on top of a revision that I can't commit on its own
to svn, so I would somehow have to know to do a squash merge and there
would no longer be a one-to-one correspondence between git and svn
revisions. That's not a total showstopper (I'm rewriting history
anyway) but it sure seems like it'll be confusing and error-prone.
Also, running in post-receive will subject me to race conditions that
aren't present in the update hook case; if I make my update hook
script do its own locking and update the refs on its own, I'm
guaranteed no other push will come along and update my ref out from
under me. In post-receive there is no such guarantee and I may end up
sending two pushes' worth of commits to svn when I think I'm only
sending one.
If I'm misunderstanding the flow of control, please feel free to
correct me. It just seemed like update was the only good place to do
what I needed to do.
-Steve
^ permalink raw reply
* Re: stgit: lost all my patches again
From: Karl Hasselström @ 2007-11-28 6:32 UTC (permalink / raw)
To: Jon Smirl; +Cc: Catalin Marinas, Git Mailing List
In-Reply-To: <9e4733910711271859w7b7dc141q93e3c9f67693a54@mail.gmail.com>
On 2007-11-27 21:59:00 -0500, Jon Smirl wrote:
> Karl, Catalin, can stgit install a pre-rebase hook and disable 'git
> rebase' when stg is active on the branch? This would keep me from
> destroying my patch stack when my fingers get ahead of me. Might be
> good to disable anything else that can cause damage too.
Mmmm. We'd have to define "damage"; "stg repair" can take care of
quite a lot of things nowadays. Committing new stuff on top of a patch
series is no problem, for example, and "git reset --hard HEAD^ && stg
repair" is equivalent to "stg pop". I can see how "git rebase" would
still be a nuisance, though.
Patch? :-)
Presumably, we'd want the hook to be a Python script, so as to
* not make it more difficult to port StGit to Windows someday;
* make it possible for the hook to call StGit functions; and
* not force the project's contributors to learn more shell scripting
than they have to. :-)
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* [PATCH] git-config --get-color: get configured color
From: Junio C Hamano @ 2007-11-28 7:20 UTC (permalink / raw)
To: Jeff King, Dan Zwell; +Cc: git, Jakub Narebski
In-Reply-To: <7vabp4u40y.fsf@gitster.siamese.dyndns.org>
This new option allows scripts to grab color setting from the user
configuration, translated to ANSI color escape sequence.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Junio C Hamano <gitster@pobox.com> writes:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>> Integer variables can have optional 'k', 'm' or 'g' suffix.
>> config_int() method will return simple decimal number, taking
>> care of those suffixes.
>
> Good. I forgot about --int option to "git config" already.
>
> Maybe in a similar way, we might want to add --color to "git
> config" to return ANSI sequence, so that Git::config_color() can
> work without even loading Term::ANSIColor?
Documentation/git-config.txt | 16 ++++++++++++
builtin-config.c | 55 +++++++++++++++++++++++++++++++++++++++--
2 files changed, 68 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-config.txt b/Documentation/git-config.txt
index a592b61..ed3076f 100644
--- a/Documentation/git-config.txt
+++ b/Documentation/git-config.txt
@@ -20,6 +20,7 @@ SYNOPSIS
'git-config' [<file-option>] --rename-section old_name new_name
'git-config' [<file-option>] --remove-section name
'git-config' [<file-option>] [-z|--null] -l | --list
+'git-config' [<file-option>] --get-color name [default]
DESCRIPTION
-----------
@@ -134,6 +135,12 @@ See also <<FILES>>.
output without getting confused e.g. by values that
contain line breaks.
+--get-color name default::
+
+ Find the color configured for `name` (e.g. `color.diff.new`) and
+ output it as the ANSI color escape sequence to the standard
+ output. The optional `default` parameter is used if the
+ configuration for `name` is missing.
[[FILES]]
FILES
@@ -292,6 +299,15 @@ To add a new proxy, without altering any of the existing ones, use
% git config core.gitproxy '"proxy-command" for example.com'
------------
+An example to use customized color from the configuration in your
+script:
+
+------------
+#!/bin/sh
+WS=$(git config --get-color color.diff.whitespace "blue reverse")
+RESET==$(git config --get-color "" "reset")
+echo "${WS}your whitespace color or blue reverse${RESET}"
+------------
include::config.txt[]
diff --git a/builtin-config.c b/builtin-config.c
index f672c9c..4c9ded3 100644
--- a/builtin-config.c
+++ b/builtin-config.c
@@ -1,8 +1,9 @@
#include "builtin.h"
#include "cache.h"
+#include "color.h"
static const char git_config_set_usage[] =
-"git-config [ --global | --system | [ -f | --file ] config-file ] [ --bool | --int ] [ -z | --null ] [--get | --get-all | --get-regexp | --replace-all | --add | --unset | --unset-all] name [value [value_regex]] | --rename-section old_name new_name | --remove-section name | --list";
+"git-config [ --global | --system | [ -f | --file ] config-file ] [ --bool | --int ] [ -z | --null ] [--get | --get-all | --get-regexp | --replace-all | --add | --unset | --unset-all] name [value [value_regex]] | --rename-section old_name new_name | --remove-section name | --list | --get-color var [default]";
static char *key;
static regex_t *key_regexp;
@@ -161,6 +162,53 @@ char *normalize_value(const char *key, const char *value)
return normalized;
}
+static int get_color_found;
+static const char *get_color_slot;
+static char parsed_color[COLOR_MAXLEN];
+
+static int git_get_color_config(const char *var, const char *value)
+{
+ if (!strcmp(var, get_color_slot)) {
+ color_parse(value, var, parsed_color);
+ get_color_found = 1;
+ }
+ return 0;
+}
+
+static int get_color(int argc, const char **argv)
+{
+ /*
+ * grab the color setting for the given slot from the configuration,
+ * or parse the default value if missing, and return ANSI color
+ * escape sequence.
+ *
+ * e.g.
+ * git config --get-color color.diff.whitespace "blue reverse"
+ */
+ const char *def_color = NULL;
+
+ switch (argc) {
+ default:
+ usage(git_config_set_usage);
+ case 2:
+ def_color = argv[1];
+ /* fallthru */
+ case 1:
+ get_color_slot = argv[0];
+ break;
+ }
+
+ get_color_found = 0;
+ parsed_color[0] = '\0';
+ git_config(git_get_color_config);
+
+ if (!get_color_found && def_color)
+ color_parse(def_color, "command line", parsed_color);
+
+ fputs(parsed_color, stdout);
+ return 0;
+}
+
int cmd_config(int argc, const char **argv, const char *prefix)
{
int nongit = 0;
@@ -234,8 +282,9 @@ int cmd_config(int argc, const char **argv, const char *prefix)
return 1;
}
return 0;
- }
- else
+ } else if (!strcmp(argv[1], "--get-color")) {
+ return get_color(argc-2, argv+2);
+ } else
break;
argc--;
argv++;
--
1.5.3.6.2039.g0495
^ permalink raw reply related
* [PATCH/RFC] "color.diff = true" is not "always" anymore.
From: Junio C Hamano @ 2007-11-28 7:26 UTC (permalink / raw)
To: git list
In-Reply-To: <7vr6icej23.fsf@gitster.siamese.dyndns.org>
Too many people got burned by setting color.diff and color.status to
true when they really should have set it to "auto".
This makes only "always" to do the unconditional colorization, and
change the meaning of "true" to the same as "auto": colorize only when
we are talking to a terminal.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
* This is definitely a backward incompatible change, but I think it is
only in a good way. Are there people who have "color.* = true" and
do mean it? If we do this, they need to change their configuration
and use "always", but I suspect there is no sane workflow that wants
the color escape code in files (e.g. "git log >file") or pipes
(e.g. "git diff | grep foo") by default, in which case this won't
hurt anybody and would help countless normal people who were bitten
by the mistaken meaning originally chosen for "true".
color.c | 32 +++++++++++++++++++-------------
1 files changed, 19 insertions(+), 13 deletions(-)
diff --git a/color.c b/color.c
index 124ba33..97cfbda 100644
--- a/color.c
+++ b/color.c
@@ -118,21 +118,27 @@ bad:
int git_config_colorbool(const char *var, const char *value)
{
- if (!value)
- return 1;
- if (!strcasecmp(value, "auto")) {
- if (isatty(1) || (pager_in_use && pager_use_color)) {
- char *term = getenv("TERM");
- if (term && strcmp(term, "dumb"))
- return 1;
- }
- return 0;
+ if (value) {
+ if (!strcasecmp(value, "never"))
+ return 0;
+ if (!strcasecmp(value, "always"))
+ return 1;
+ if (!strcasecmp(value, "auto"))
+ goto auto_color;
}
- if (!strcasecmp(value, "never"))
+
+ /* Missing or explicit false to turn off colorization */
+ if (!git_config_bool(var, value))
return 0;
- if (!strcasecmp(value, "always"))
- return 1;
- return git_config_bool(var, value);
+
+ /* any normal truth value defaults to 'auto' */
+ auto_color:
+ if (isatty(1) || (pager_in_use && pager_use_color)) {
+ char *term = getenv("TERM");
+ if (term && strcmp(term, "dumb"))
+ return 1;
+ }
+ return 0;
}
static int color_vfprintf(FILE *fp, const char *color, const char *fmt,
--
1.5.3.6.2039.g0495
^ permalink raw reply related
* ok for git to delete temporary packs on write error?
From: David Tweed @ 2007-11-28 7:42 UTC (permalink / raw)
To: Git Mailing List
Hi, I'd like to check if there's any reason in the overall design of
git which would make deleting tmp_pack's that have suffered
write errors a bad idea? (Before I look further into this I may be missing
a good reason why they shouldn't be auto-deleted.)
My encounter with this comes from using an almost full
usbstick which I discovered when I was poking around
for other reasons several partial packs from occasions
(separated by weeks) where gc failed. On each failure
I'd removed stuff from the drive to clear space and done
a successful gc but hadn't thought to
check below .git for removable stuff so they'd just accumulated.
Below is a output of a test session:
$ git version
git version 1.5.3.6
$ git gc --aggressive --prune
Generating pack...
Done counting 22216 objects.
Deltifying 22216 objects...
100% (22216/22216) done
Writing 22216 objects...
fatal: sha1 file '/media/usbdiskc/v.git/objects/tmp_pack_QCYYAi' write
error (No space left on device)
error: failed to run repack
$ ls -l /media/usbdiskc/v.git/objects/
total 3944
drwxr-xr-x 2 sis05dst sis05dst 2048 2007-11-28 07:25 info
drwxr-xr-x 2 sis05dst sis05dst 2048 2007-11-28 07:25 pack
-rwxr-xr-x 1 sis05dst sis05dst 4034560 2007-11-28 07:25 tmp_pack_QCYYAi
-rw------- 1 sis05dst sis05dst 0 2007-04-18 23:02 tmp_pack_RYLguI
--
cheers, dave tweed__________________________
david.tweed@gmail.com
Rm 124, School of Systems Engineering, University of Reading.
"we had no idea that when we added templates we were adding a Turing-
complete compile-time language." -- C++ standardisation committee
^ permalink raw reply
* Re: [PATCH] git-config --get-color: get configured color
From: Dan Zwell @ 2007-11-28 7:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, git, Jakub Narebski
In-Reply-To: <7vir3mal9u.fsf_-_@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> +--get-color name default::
> +
> + Find the color configured for `name` (e.g. `color.diff.new`) and
> + output it as the ANSI color escape sequence to the standard
> + output. The optional `default` parameter is used if the
> + configuration for `name` is missing.
Perhaps you could mention here that the second parameter is a normal
string, not an ansi code? Just adding 'for example, "blue"' would
probably help.
> +RESET==$(git config --get-color "" "reset")
This is a typo, no?
+RESET=$(git config --get-color "" "reset")
Dan
^ permalink raw reply
* Re: Rebase/cherry-picking idea
From: Junio C Hamano @ 2007-11-28 8:06 UTC (permalink / raw)
To: Wincent Colaiuta
Cc: Johannes Schindelin, Johannes Sixt, Benoit Sigoure,
Git Mailing List
In-Reply-To: <97F6E8DE-4022-4458-B6A9-C644A6EDC1E3@wincent.com>
> Once I get a clear idea of what kind of change is likely to actually
> get accepted I'll submit a proper patch.
Too often, people disappear with a patch that is basically good but has
room for improvements this way. I really do not have time nor bandwidth
to keep bugging them for updates, and often end up cleaning up on my own
instead.
This is such a patch, and without acks or comments, it is also very
likely to be lost.
-- >8 --
revert/cherry-pick: Allow overriding the help text by the calling Porcelain
A Porcelain command that uses cherry-pick or revert may make a commit
out of resolved index itself, in which case telling the user to commit
the result is not appropriate at all. This allows GIT_CHERRY_PICK_HELP
environment variable to be set by the calling Porcelain in order to
override the built-in help text.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
* I suspect that "git rebase --continue" can do "git add -u" itself,
just like recent "git rebase --skip" would do "git reset --hard".
The overriding help text in this patch can lose its second line that
tells the user to use "git add <paths>" if we decide to do so.
builtin-revert.c | 33 +++++++++++++++++++++++----------
git-rebase--interactive.sh | 5 +++++
2 files changed, 28 insertions(+), 10 deletions(-)
diff --git a/builtin-revert.c b/builtin-revert.c
index a0586f9..4f86178 100644
--- a/builtin-revert.c
+++ b/builtin-revert.c
@@ -224,6 +224,27 @@ static int merge_recursive(const char *base_sha1,
return run_command_v_opt(argv, RUN_COMMAND_NO_STDIN | RUN_GIT_CMD);
}
+static char *help_msg(const unsigned char *sha1)
+{
+ static char helpbuf[1024];
+ char *msg = getenv("GIT_CHERRY_PICK_HELP");
+
+ if (msg)
+ return msg;
+
+ strcpy(helpbuf, " After resolving the conflicts,\n"
+ "mark the corrected paths with 'git add <paths>' "
+ "and commit the result.");
+
+ if (action == CHERRY_PICK) {
+ sprintf(helpbuf + strlen(helpbuf),
+ "\nWhen commiting, use the option "
+ "'-c %s' to retain authorship and message.",
+ find_unique_abbrev(sha1, DEFAULT_ABBREV));
+ }
+ return helpbuf;
+}
+
static int revert_or_cherry_pick(int argc, const char **argv)
{
unsigned char head[20];
@@ -352,16 +373,8 @@ static int revert_or_cherry_pick(int argc, const char **argv)
}
if (close(msg_fd) || commit_lock_file(&msg_file) < 0)
die ("Error wrapping up %s", defmsg);
- fprintf(stderr, "Automatic %s failed. "
- "After resolving the conflicts,\n"
- "mark the corrected paths with 'git add <paths>' "
- "and commit the result.\n", me);
- if (action == CHERRY_PICK) {
- fprintf(stderr, "When commiting, use the option "
- "'-c %s' to retain authorship and message.\n",
- find_unique_abbrev(commit->object.sha1,
- DEFAULT_ABBREV));
- }
+ fprintf(stderr, "Automatic %s failed.%s\n",
+ me, help_msg(commit->object.sha1));
exit(1);
}
if (close(msg_fd) || commit_lock_file(&msg_file) < 0)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index bf44b6a..33a5d4b 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -30,6 +30,11 @@ test -d "$REWRITTEN" && PRESERVE_MERGES=t
test -f "$DOTEST"/strategy && STRATEGY="$(cat "$DOTEST"/strategy)"
test -f "$DOTEST"/verbose && VERBOSE=t
+GIT_CHERRY_PICK_HELP=" After resolving the conflicts,
+mark the corrected paths with 'git add <paths>', and
+run 'git rebase --continue'"
+export GIT_CHERRY_PICK_HELP
+
warn () {
echo "$*" >&2
}
^ permalink raw reply related
* Re: What's cooking in git.git (topics)
From: Andreas Ericsson @ 2007-11-28 8:12 UTC (permalink / raw)
To: J. Bruce Fields
Cc: Johannes Schindelin, Nicolas Pitre,
らいしななこ, Jakub Narebski,
git
In-Reply-To: <20071127170749.GA19136@fieldses.org>
J. Bruce Fields wrote:
> On Tue, Nov 27, 2007 at 04:54:18PM +0000, Johannes Schindelin wrote:
>> Hi,
>>
>> On Tue, 27 Nov 2007, J. Bruce Fields wrote:
>>
>>> If we really want a fetch+rebase script, OK, but call it something other
>>> than pull.
>> Why? pull = fetch + merge only because that was the originally envisioned
>> way to pull remote changes into your local working tree. However, I do
>> not see why we should be married to pull being a fetch and a merge for
>> eternity.
>
> Two responses:
>
> First, OK, if you want to say "pull" means "fetch something and then
> incorporate it somehow into your current branch", that doesn't bother me
> quite as much as saying that "pull" always means "fetch + merge", and
> that "rebase" is really just a special kind of merge. It's clearly not
> a merge.
>
I beg to differ. The end result is identical to a merge (assuming one
never does "git rebase skip", which otoh could be thought of as one way
of resolving a merge conflict). It's just history that doesn't turn out
the same. git has always been about content, so from that pov, a rebase
is exactly the same as a merge.
> Second: "fetch+rebase" will really have very different properties from
> "fetch+pull".
"fetch+merge", no?
> It may be possible to make the former behave a little
> like the latter in some common cases, but it's going to complicated.
True. I don't think octopus rebase needs to be supported, for example.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] Move all dashed form git commands to libexecdir
From: Jan Hudec @ 2007-11-28 8:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Nguyễn Thái Ngoc Duy, git
In-Reply-To: <7v8x4jb295.fsf@gitster.siamese.dyndns.org>
On Tue, Nov 27, 2007 at 17:13:58 -0800, Junio C Hamano wrote:
> Jan Hudec <bulb@ucw.cz> writes:
> > On Tue, Nov 27, 2007 at 16:18:01 +0000, Johannes Schindelin wrote:
> >> On Tue, 27 Nov 2007, Nguyễn Thái Ngoc Duy wrote:
> >>
> >> > Both configure and make-only ways should work now
> >>
> >> I thought your plan was to put the non-porcelain into the libexecdir only?
> >
> > I had the impression that deprecating the dash notation for /all/ use was
> > approved some time ago. Though I don't want to search through the list
> > archives this late in the night to check it.
>
> [...]
>
> In case somebody is thinking about 36e5e70e0f40 (Start deprecating
> "git-command" in favor of "git command"), that is a somewhat different
> issue. What Linus suggested is not installing git-foo link for built-in
> commands _anywhere_ on the filesystem. Not just "out of user's PATH".
> That is not deprecating dash form but removing the support for it. We
> need to give ample time for users to adjust to such a change.
Yes, that is what I said I recall seeing. Installing out of user's PATH is
a step towards not installing at all and the change suggests it has been
already accepted as a general direction for future. Or not?
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
^ permalink raw reply
* Re: [PATCH] Replace misleading message during interactive rebasing
From: Wincent Colaiuta @ 2007-11-28 8:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Sixt, git, tsuna, Johannes.Schindelin, mcostalba
In-Reply-To: <7vve7n9eaa.fsf@gitster.siamese.dyndns.org>
El 28/11/2007, a las 5:37, Junio C Hamano escribió:
> Johannes Sixt <j.sixt@viscovery.net> writes:
>
>> Wincent Colaiuta schrieb:
>>> + export _GIT_CHERRY_PICK_HELP="run 'git rebase --continue'"
>>
>> Isn't this a bashism?
>
> Being an old-fashioned shell programmer myself, "export VAR=VAL" does
> raise my eyebrows. It is in POSIX but are there shells that we do
> support (dash, bash, ksh -- /bin/sh on Solaris does not count) that
> want their exports old-fashioned way?
As I noted earlier in thread, the idiom is used elsewhere in Git
already. Below is a list of the instances I found where shell scripts
use the idiom. There are also other instances (documentation, test
scripts, even a tcl file) where the idiom is used. As far as its
suitability I only have directory experience with Bash, and it's
always worked in all versions that I've tried in the 2.x and 3.x
range. The other shells, I don't know.
In any case, below I'll paste in a revised patch that doesn't use the
export FOO=... idiom. I can also submit another patch changing the
other usages of the idiom elsewhere in the tree, but I'd need guidance
on how far you'd want to go (only the Git commands? also the tests?
don't worry about the docs? etc).
El 27/11/2007, a las 9:49, Wincent Colaiuta escribió:
> I wondered that myself before submitting the patch, but then saw
> that the same pattern was used at other places as well:
>
> git-clone.sh:
>
> W=$(cd "$GIT_WORK_TREE" && pwd) && export GIT_WORK_TREE="$W"
>
> git-filter-branch.sh:
>
> export GIT_INDEX_FILE="$(pwd)/../index"
> export GIT_COMMIT=$commit
> export GIT_COMMIT="$sha1"
>
> git-quiltimport.sh:
>
> export GIT_AUTHOR_NAME=$(sed -ne 's/Author: //p' "$tmp_info")
> export GIT_AUTHOR_EMAIL=$(sed -ne 's/Email: //p' "$tmp_info")
> export GIT_AUTHOR_DATE=$(sed -ne 's/Date: //p' "$tmp_info")
> export SUBJECT=$(sed -ne 's/Subject: //p' "$tmp_info")
>
> So if this is a problem, those sites will need to be changed as well.
>
> Cheers,
> Wincent
Here's the revised patch:
--------8<---------
From cd11e1355011796fe16d0eb7116fae4070f2a30d Mon Sep 17 00:00:00 2001
From: Wincent Colaiuta <win@wincent.com>
Date: Mon, 26 Nov 2007 13:35:46 +0100
Subject: [PATCH] Replace misleading message during interactive rebasing
git-rebase--interactive uses git-cherry-pick under the covers to reorder
commits, which in turn means that in the event of a conflict a message
will be shown advising the user to commit the results and use the -c
switch to retain authorship after fixing the conflict.
The message is misleading because what the user really needs to do is
run "git rebase --continue"; the committing is handled by git-rebase
and the authorship of the commit message is retained automatically.
We solve this problem by using an environment variable to communicate
to git-cherry-pick that rebasing is underway and replace the misleading
error message with a more helpful one.
Signed-off-by: Wincent Colaiuta <win@wincent.com>
---
builtin-revert.c | 8 +++++---
git-rebase--interactive.sh | 4 ++++
2 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/builtin-revert.c b/builtin-revert.c
index a0586f9..5a57574 100644
--- a/builtin-revert.c
+++ b/builtin-revert.c
@@ -229,7 +229,7 @@ static int revert_or_cherry_pick(int argc, const
char **argv)
unsigned char head[20];
struct commit *base, *next, *parent;
int i;
- char *oneline, *reencoded_message = NULL;
+ char *oneline, *reencoded_message = NULL, *help_message;
const char *message, *encoding;
const char *defmsg = xstrdup(git_path("MERGE_MSG"));
@@ -352,11 +352,13 @@ static int revert_or_cherry_pick(int argc, const
char **argv)
}
if (close(msg_fd) || commit_lock_file(&msg_file) < 0)
die ("Error wrapping up %s", defmsg);
+ help_message = getenv("_GIT_CHERRY_PICK_HELP");
fprintf(stderr, "Automatic %s failed. "
"After resolving the conflicts,\n"
"mark the corrected paths with 'git add <paths>' "
- "and commit the result.\n", me);
- if (action == CHERRY_PICK) {
+ "and %s.\n", me,
+ help_message ? help_message : "commit the result");
+ if (action == CHERRY_PICK && !help_message) {
fprintf(stderr, "When commiting, use the option "
"'-c %s' to retain authorship and message.\n",
find_unique_abbrev(commit->object.sha1,
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index bf44b6a..3552c89 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -117,6 +117,8 @@ pick_one () {
sha1=$(git rev-parse --short $sha1)
output warn Fast forward to $sha1
else
+ _GIT_CHERRY_PICK_HELP="run 'git rebase --continue'"
+ export _GIT_CHERRY_PICK_HELP &&
output git cherry-pick "$@"
fi
}
@@ -187,6 +189,8 @@ pick_one_preserving_merges () {
fi
;;
*)
+ _GIT_CHERRY_PICK_HELP="run 'git rebase --continue'"
+ export _GIT_CHERRY_PICK_HELP &&
output git cherry-pick "$@" ||
die_with_patch $sha1 "Could not pick $sha1"
;;
--
1.5.3.6.953.gdffc
^ permalink raw reply related
* Re: [PATCH] Move all dashed form git commands to libexecdir
From: Nguyen Thai Ngoc Duy @ 2007-11-28 8:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jan Hudec, Johannes Schindelin, git
In-Reply-To: <7v8x4jb295.fsf@gitster.siamese.dyndns.org>
On Nov 28, 2007 8:13 AM, Junio C Hamano <gitster@pobox.com> wrote:
> In case somebody is thinking about 36e5e70e0f40 (Start deprecating
> "git-command" in favor of "git command"), that is a somewhat different
> issue. What Linus suggested is not installing git-foo link for built-in
> commands _anywhere_ on the filesystem. Not just "out of user's PATH".
> That is not deprecating dash form but removing the support for it. We
> need to give ample time for users to adjust to such a change.
A little note on this one. I've been using git without builtin links
for a while with my git-box port. There are still some builtin fixups
needed. And because execv_git_cmd() always uses dash form, so it's
impossible to use vanilla git without builtin links.
--
Duy
^ permalink raw reply
* Re: [PATCH] Make Git accept absolute path names for files within the work tree
From: Junio C Hamano @ 2007-11-28 8:43 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
In-Reply-To: <1196205847-22968-1-git-send-email-robin.rosenberg@dewire.com>
Robin Rosenberg <robin.rosenberg@dewire.com> writes:
> This patch makes it possible to drag files and directories from
> a graphical browser and drop them onto a shell and feed them
> to common git operations without editing away the path to the
> root of the work tree.
>
> Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
> ---
> setup.c | 19 +++++++++++++++++
> t/t3904-abspatharg.sh | 55 +++++++++++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 74 insertions(+), 0 deletions(-)
> create mode 100755 t/t3904-abspatharg.sh
>
> diff --git a/setup.c b/setup.c
> index f512ea0..ffc30bf 100644
> --- a/setup.c
> +++ b/setup.c
> @@ -7,6 +7,25 @@ static int inside_work_tree = -1;
> const char *prefix_path(const char *prefix, int len, const char *path)
> {
> const char *orig = path;
> + const char *work_tree = get_git_work_tree();
> + if (is_absolute_path(path) && work_tree) {
> + int n = strlen(work_tree);
> + if (!strncmp(path, work_tree, n) && (path[n] == '/' || !path[n])) {
> + if (path[n])
> + path += n + 1;
> + else
> + path += n;
> +
> + if (prefix && !strncmp(path, prefix, len - 1)) {
> + if (path[len - 1] == '/')
> + path += len;
> + else
> + if (!path[len - 1])
> + path += len - 1;
> + }
> + }
> + }
> +
This looks somewhat tighter than the previous one, but still made me
worried if the caller of prefix_path() has run the setup sequence enough
so that calling get_git_work_tree() is safe, so I ended up auditing the
callpath. At least, I do not want to see that unconditional call to
get_git_work_tree() when we do not need to do this "ah prefix got an
unusual absolute path" stuff.
* builtin-init-db.c uses prefix_path() to find where the template is
(this is mingw fallout change); in general, I do not think we would
want to trigger repository nor worktree discovery inside init-db,
although I suspect this particular callpath could be made Ok (because
it is taken only when template_dir is not absolute) if you do not
unconditionally call get_git_work_tree() in prefix_path().
* config.c uses prefix_path() to find the ETC_GITCONFIG that is not
absolute (again, mingw fallout). When git_config() is called, we
already should have discovered repository but worktree may not have
been found yet (config.worktree can be used to specify where it is,
so you have a chicken and egg problem). Again, this particular
callpath happens to be Ok because this is used only for non-absolute
path, but that is a bit subtle.
* get_pathspec() uses prefix_path() for obvious reasons, and the prefix
it gets must have been discovered by finding out where the worktree
is, so by definition that one is safe.
Everybody else you would get from "git grep prefix_path" are after the
proper setup, so they should all be safe.
> diff --git a/t/t3904-abspatharg.sh b/t/t3904-abspatharg.sh
> new file mode 100755
> index 0000000..cd4a52e
> --- /dev/null
> +++ b/t/t3904-abspatharg.sh
> @@ -0,0 +1,55 @@
> +#!/bin/sh
> +#
> +# Copyright (C) 2007 Robin Rosenberg
> +#
> +
> +test_description='Test absolute filename arguments to various git
> +commands. Absolute arguments pointing to a location within the git
> +work tree should behave the same as relative arguments. '
> +
> +. ./test-lib.sh
> +
> +test_expect_success 'add files using absolute path names' '
> +echo a >afile &&
> +echo b >bfile &&
> +git-add afile &&
> +git-add "$(pwd)/bfile" &&
This looks quite dense. With indent like other existing tests this
would become a bit easier to read.
> +test "afile bfile" = "$(echo $(git ls-files))"
Hmmm. Looks a bit ugly but Ok.
> +mkdir x &&
> +cd x &&
> +echo c >cfile &&
> +echo d >dfile &&
> +git-add cfile &&
> +git-add "$(pwd)" &&
> +cd .. &&
If this sequence fails in the middle, the next test will execute in a
wrong directory. Instead of "cd there && ... && cd .. &&", it is safer
to do "( cd there && ... ) &&".
> +test "afile bfile x/cfile x/dfile" = "$(echo $(git ls-files))" &&
> +git ls-files x >f1 &&
> +git ls-files "$(pwd)/x" >f2 &&
> +diff f1 f2
"diff -u" is much easier for people who ends up reading the output when
something goes wrong.
Cases that are still not covered:
try to add a file in the parent directory from a subdirectory,
using absolute path;
try to add a file in a directory that is too high (i.e. outside
the work tree), using absolute path;
The latter I think should fail. People tend to forget writing negative
tests when they are too excited with their shiny new features.
Perhaps adding something like:
try to add a sub-subdirectory using an absolute path, and make
sure paths in subdirectory are not added;
would also be prudent to catch future possible breakages (off by one
cutting the common directory prefix one level too deep or something),
but that is probably just me who tends to be paranoid.
Exactly the same comments apply to tests for other commands. Also I
think mv, rm, reset and checkout take pathnames.
^ permalink raw reply
* Re: Rebase/cherry-picking idea
From: Wincent Colaiuta @ 2007-11-28 8:52 UTC (permalink / raw)
To: Junio C Hamano
Cc: Johannes Schindelin, Johannes Sixt, Benoit Sigoure,
Git Mailing List
In-Reply-To: <7vir3m94ku.fsf@gitster.siamese.dyndns.org>
El 28/11/2007, a las 9:06, Junio C Hamano escribió:
>> Once I get a clear idea of what kind of change is likely to actually
>> get accepted I'll submit a proper patch.
>
> Too often, people disappear with a patch that is basically good but
> has
> room for improvements this way. I really do not have time nor
> bandwidth
> to keep bugging them for updates, and often end up cleaning up on my
> own
> instead.
The problem in this case was that my patch didn't receive any
meaningful feedback (ie. suggestions for improvement), only a lot of
bikeshed stuff about whether the environment variable should have an
underscore prefix or not, whether or not I should use "export FOO=..."
or not etc. So I didn't know what was necessary in order to get it
accepted.
> This is such a patch, and without acks or comments, it is also very
> likely to be lost.
Ok, please disregard the resend that I just posted a few minutes ago
(hadn't seen your new patch yet).
Cheers,
Wincent
^ permalink raw reply
* Re: [PATCH] Use --no-color option on git log commands.
From: Junio C Hamano @ 2007-11-28 4:45 UTC (permalink / raw)
To: Pascal Obry; +Cc: git list
In-Reply-To: <474C60FA.4040302@wanadoo.fr>
Pascal Obry <pascal.obry@wanadoo.fr> writes:
> Junio C Hamano a écrit :
>> The patch is good as belt-and-suspender, thanks.
>
> Ok.
>
>> But I suspect that we should make 'true' to mean 'auto' someday in
>> git_config_colorbool(). Crazy people can set 'always' if they really
>> wanted to, but most normal people would not want color unless the output
>> goes to the terminal, I would think.
>
> I definitely agree. I add it set to true, using auto instead I do not
> have the problem. Anyway I still think that it is good to apply my patch
> to completely avoid such issues.
Yes, that is what I said.
Except that the patch is severely whitespace damaged, and the message
lack a sign-off.
I fixed them up by hand, so no need to resend.
^ permalink raw reply
* Re: Rollback of git commands
From: Karl Hasselström @ 2007-11-28 9:22 UTC (permalink / raw)
To: Jon Smirl; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <9e4733910711271733r6f280618pbb14095aebba3309@mail.gmail.com>
On 2007-11-27 20:33:27 -0500, Jon Smirl wrote:
> Let's take my recent problem as an example. I typed 'git rebase
> linus/master' instead of 'stg rebase linus/master'. Then I typed
> 'stg repair'. The repair failed and left me in a mess. Both of these
> are easy to rollback except for the fact that stg has stored a bunch
> of state in .git/*.
>
> After doing the commands I located my last commit before the rebase
> and edited master back to it. But my system was still messed up
> since moving master got me out of sync with the state stg stored in
> .git/*. The 'stg repair' command had changed the stored state.
How exactly did repair mess up? Did it crash, produce a broken result,
an unreasonable but technically valid result, or just not the result
you wanted?
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ 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