* Re: git replace woes: dirty stat with clean workdir
From: Christian Couder @ 2009-11-10 23:33 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Git Mailing List
In-Reply-To: <4AF992F8.8010309@drmicha.warpmail.net>
Hi,
On mardi 10 novembre 2009, Michael J Gruber wrote:
> Hi there,
>
> when cooking up a "warning example" for git replace (don't draw
> premature conclusions when there are replaced objects) I came across the
> following problem: git status seems to compare the work dir with the
> tree of HEAD, not the replacing tree. Even deleting the index does not
> help.
Yeah, you are right. I must say that I never tested replacing trees before.
> [ The example also shows that we need a way to specify
> --no-replace-objects for gitk. Would easier if gitk really where git
> something. ]
Yeah, I think --no-replace-objects might not work well for shell scripts or
even commands that call other commands using run_command(). Perhaps we need
an environment variable GIT_NO_REPLACE_OBJECTS to be set by commands that
are passed --no-replace-objects and checked by all the commands. I will
have a look at that.
Thanks,
Christian.
^ permalink raw reply
* Re: Git drawbacks?
From: Dmitry Potapov @ 2009-11-10 23:43 UTC (permalink / raw)
To: Dmitry Smirnov; +Cc: git
In-Reply-To: <loom.20091110T154312-665@post.gmane.org>
On Tue, Nov 10, 2009 at 02:54:43PM +0000, Dmitry Smirnov wrote:
> Dmitry Potapov <dpotapov <at> gmail.com> writes:
>
> > And then if you really want
> > to have good and clean history, you need more than just a branch. You
> > should be able to amend your previous commits while you work on some
> > feature. With Git, it is trivial, you just run 'git rebase -i' and may
> > edit some previous commits, correct comments, squash fix-ups, etc...
> > How can you model that? By creating another branch and moving patches
> > to it by hands... Well, it is not very productive time spending, and
> > the cost of branch becomes even more prominent.
>
> This is a cool feature, but it contradicts to my understanding of VCS.
Yes, it may *appear* to contradict one of basic axioms of any VCS --
history is immutable, but here is the rule -- you never ever rebase or
change in any other way the public history of the official repository.
So once your commits hit the master branch, you should never try to
change them. This may be enforced through Git hooks.
However, when we speak about history of commits in your private feature
branch then no one cares about how you have arrived to these series of
patches more than in what order you have edited your files. What really
matters is the end result -- our patches are clean and easy to review.
Now, what is 'public' history or what is not. If no one has seen your
commits then it is clearly not public. If your commits are integrated
to the main development branch ('master') then they are clearly public.
However, many Git users have an international branch (often called as
proposed updates or 'pu' for short). The 'pu' branch is regularly
rewound, so no one should based their work on it. It is more for review
and additional testing of things that may not ready yet. When your
branch is merged to 'pu', it considered to be a fair play to re-write
your patches. However, you should do that in the way that will not
cause problems for people who review your changes.
Finally, when you re-write some branch using interactive rebase or
something else. Your old changes do not disappear immediately from your
repository. Git has 'reflog', which keeps _all_ commits in your local
repository for 30 days (or whatever time your choose). So, if you did
something wrong during rebase, you can always go back to the original
version, though you will hardly ever need that feature unless you do
something really stupid...
> BTW, as I undestood it, it is just a feature that can be implemented
> in any VCS (if you have access to its internals).
At least, not so simple. Have you heard about Mercurial? It is another
DVCS, which in many aspects similar to Git, but the underlying backend
is very different. I do not follow it very closely, but for a long time
it did not have 'rebase' and users were advised to use Mercurial Queues
instead, which is patch management system on top of Mercurial. While Git
has its own implementations of patch management systems on top of Git
such as StGit and recently TopGit, I do not think they come even close
when it comes to easy to use in everyday work, especially if you do not
want to be bothered with thinking about patch management.
Much power of Git and its flexibility comes from clean separation of the
underlying storage format and repository history. This makes 'rebase'
almost trivial in Git (unless you have merges in rebased history and you
try to preserve them), while with many other VCSes, those changes will
require significant changes to the underlying storage, which may be
difficult to implement safely and efficiently. The price that Git has to
pay for its flexibility is the need to run the garbage collection to
purge loose objects and compact all objects in one compressed pack...
Dmitry
^ permalink raw reply
* Re: gitk : french translation
From: Nicolas Sebrecht @ 2009-11-11 0:10 UTC (permalink / raw)
To: Emmanuel Trillaud
Cc: Maximilien Noal, Matthieu Moy, Nicolas Pitre, Nicolas Sebrecht,
Thomas Moulard, Guy Brand, Git Mailing List
In-Reply-To: <9f50533b0911100945l2c3b7399w1d72771fd2cf8df@mail.gmail.com>
The 10/11/09, Emmanuel Trillaud wrote:
> +"Last-Translator: YOUR NAME <E-MAIL@ADDRESS>\n"
> +"Language-Team: FRENCH\n"
Please, fill in these fields.
> +#: gitk:337
> +msgid "No files selected: --merge specified but no files are unmerged."
> +msgstr "Aucun fichier sélectionné : --merge précisé, mais tous les
> fichiers sont fusionnés."
Line wraping error; configure your mail user agent to not wrap lines,
please.
> +#FIXME : améliorer la traduction de 'file limite'
If you add some FIXME (which is good), you also should mark the
translation as "fuzzy" like this:
> +#: gitk:340
#, fuzzy
> +msgid ""
> +"No files selected: --merge specified but no unmerged files are within file "
> +"limit."
> +msgstr "Aucun fichier sélectionné : --merge précisé mais aucun
> fichier non fusionné n'est dans la limite des fichiers."
<...>
> +#: gitk:1437
> +msgid "Can't parse git log output:"
> +msgstr "Impossible de lire le résultat de git log :"
s/le résultat/la sortie/
> +#: gitk:1793 gitk:1817 gitk:3916 gitk:8786 gitk:10322 gitk:10498
> +msgid "OK"
> +msgstr "OK"
This one should not be required.
> +#: gitk:1934
> +msgid "New view..."
> +msgstr "Nouvelle vue ..."
s/vue /vue/
> +#: gitk:2099 gitk:2101
> +msgid "Exact"
> +msgstr "Exact"
This one should not be required.
> +#: gitk:2215
> +msgid "Patch"
> +msgstr "Patch"
Ditto.
> +#: gitk:2366 gitk:8604
> +msgid "Create new branch"
> +msgstr "Créer nouvelle branche"
"Créer une nouvelle branche"
> +#: gitk:2368
> +msgid "Reset HEAD branch to here"
> +msgstr "Réinitialiser la branch HEAD vers cet état"
"branche" (missing "e").
> +#: gitk:2656
> +msgid ""
> +"\n"
> +"Gitk - a commit viewer for git\n"
> +"\n"
> +"Copyright © 2005-2008 Paul Mackerras\n"
> +"\n"
> +"Use and redistribute under the terms of the GNU General Public License"
> +msgstr ""
> +"\n"
> +"Gitk - visualisateur de commit pour git\n"
> +"\n"
> +"Copyright © 2005-2008 Paul Mackerras\n"
> +"\n"
> +"Utilisation et redistribution soumis aux termes de la GNU General
> Public License"
"soumises"
> +#: gitk:2693
> +msgid "<Left>, z, j\tGo back in history list"
> +msgstr "<Gauche>, z, j\tAvancer dans l'historique"
s/Avancer/Reculer/
> +#: gitk:2694
> +msgid "<Right>, x, l\tGo forward in history list"
> +msgstr "<Droite>, x, l\tRemonter dans l'historique"
s/Remonter/Avancer/
> +#: gitk:2713
> +msgid "/\t\tFocus the search box"
> +msgstr "/"
No idea?
> +#: gitk:3401
> +msgid "No such commit"
> +msgstr "commit inexistant"
s/commit/Commit/
> +#: gitk:3415
> +msgid "git gui blame: command failed:"
> +msgstr "git gui blame : échec de la commande"
Missing ending " :".
> +#: gitk:3446
> +#, tcl-format
> +msgid "Couldn't read merge head: %s"
> +msgstr "Impossible de lire le head de la fusion: %s"
s/fusion/fusion /
> +#: gitk:3479
> +#, tcl-format
> +msgid "Couldn't start git blame: %s"
> +msgstr "impossible de démarrer git blame : %s"
s/impossible/Impossible/
> +#: gitk:3679
> +msgid "References (space separated list):"
> +msgstr "Références (liste d'éléments séparer par des espaces) :"
s/séparer/séparés/
> +#: gitk:3684
> +msgid "All remote-tracking branches"
> +msgstr "Toutes les branches de suivie distante"
"Toutes les branches de suivi distantes"
> +#: gitk:3687
> +msgid "Committer:"
> +msgstr "Committer :"
"Commiter"
> +#: gitk:3690
> +msgid "Changes to Files:"
> +msgstr "Changements des fichiers"
Missing ":".
> +#: gitk:3695
> +msgid "Since:"
> +msgstr "Depuis :"
"De :"
> +# FIXME : traduction de "skip"
"éviter"?
> +#: gitk:3697
> +msgid "Limit and/or skip a number of revisions (positive integer):"
> +msgstr "Limiter et/ou sauter un certain nombre (entier positif) de révision :"
^
"Limiter et/ou éviter un certain nombre (entier positif) de révisions :"
> +#: gitk:3699
> +msgid "Number to skip:"
> +msgstr "Nombre à sauter :"
"éviter"?
> +#FIXME : traduction de "branch sides"
> +#: gitk:3702
#, fuzzy
> +msgid "Mark branch sides"
> +msgstr "Marquer le flanc des branches"
What about "côté"?
> +#: gitk:3837
> +msgid "-- criteria for selecting revisions"
> +msgstr "-- critère pour la séléction des révisions"
"sélection"
> +#: gitk:3955
> +msgid "Error in commit selection arguments:"
> +msgstr "Erreur dans les arguments de sélection des commits"
Missing ":".
> +#: gitk:4456 gitk:6303 gitk:8065 gitk:8080
> +msgid "Date"
> +msgstr "Date"
Should not be required.
> +#: gitk:4456 gitk:6303
> +msgid "CDate"
> +msgstr "CDate"
Ditto.
> +#: gitk:4605 gitk:4610
> +msgid "Descendant"
> +msgstr "Descendant"
Ditto.
> +#FIXME : plutôt traduire par "pas un descendant"
> +#: gitk:4606
#, fuzzy
> +msgid "Not descendant"
> +msgstr "Non descendant"
<...>
> +#FIXME : plutôt traduire par "pas un ancêtre"
> +#: gitk:4614
#, fuzzy
> +msgid "Not ancestor"
> +msgstr "Non ancêtre"
<...>
> +#: gitk:4904
> +msgid "Local changes checked in to index but not committed"
> +msgstr "Modifications locales enregistrées dans l'index mais non comittées"
"commitées"
> +#: gitk:4940
> +msgid "Local uncommitted changes, not checked in to index"
> +msgstr "Modifications locales non enregistrées dans l'index et non committées"
Ditto.
> +#: gitk:6822 gitk:6828 gitk:8058
> +msgid "Parent"
> +msgstr "Parent"
Should not be required.
> +#: gitk:7926
> +#, tcl-format
> +msgid "Revision %s is not in the current view"
> +msgstr "Révision %s n'est pas dans la vue courante"
s/Révision/ La révision/
> +#: gitk:8127
> +msgid "Detached head: can't reset"
> +msgstr "Head détachée: impossible de réinitialiser"
"détaché" instead of "détachée" is better FMPOV.
> +#: gitk:8236 gitk:8242
> +msgid "Skipping merge commit "
> +msgstr "Sauter le commit de la fusion "
"Éviter le commit de fusion "
> +#: gitk:8262 gitk:8265 gitk:8273 gitk:8283 gitk:8292
> +msgid "Commit "
> +msgstr "Commit "
Should not be required.
> +#: gitk:8274
> +msgid ""
> +" differs from\n"
> +" "
> +msgstr ""
> +"diffère de\n"
Miss the space at the begining?
> +#: gitk:8483
> +msgid "Error creating tag:"
> +msgstr "Erreur à la création du tag"
Missing ":".
> +#: gitk:8705
> +#, tcl-format
> +msgid "Commit %s is already included in branch %s -- really re-apply it?"
> +msgstr "Commit %s est déjà inclus dans la branche %s -- faut-il
> vraiment le ré-appliquer?"
Peut-être :
"ré-appliquer malgré tout ?"
> +#: gitk:8719
> +#, tcl-format
> +msgid ""
> +"Cherry-pick failed because of local changes to file '%s'.\n"
> +"Please commit, reset or stash your changes and try again."
> +msgstr "La cueillette a échouée à cause de modifications locale au
> fichier '%s'.\n"
s/locale/locales/
> +"Veuillez committer, reset ou stash vos changements et essayer de nouveau."
s/committer/commiter/
s/reset/réinitialiser/ (for consistency with this whole translation)
s/stash/stasher/
> +#: gitk:8741
> +msgid "No changes committed"
> +msgstr "Aucun changement committer"
"Aucun changement commité"
> +# FIXME: faut-il traduire working tree par répertoire de travail ou
> arbre de travail?
> +# FIXME : traduction de Soft/Hard/Mixed
> +#: gitk:8777
> +msgid "Soft: Leave working tree and index untouched"
> +msgstr "Douce: Laisse l'arbre de travail et l'index dans leur état courant"
"Léger : laisse les fichiers du work tree et l'index intacts"
> +#: gitk:8780
> +msgid "Mixed: Leave working tree untouched, reset index"
> +msgstr "Hybride: Laisse l'arbre de travail dans son état courant,
> réinitialise l'index"
"Hybride : ne touche pas aux fichiers du work tree, réinitialise l'index"
> +#: gitk:8783
> +msgid ""
> +"Hard: Reset working tree and index\n"
> +"(discard ALL local changes)"
> +msgstr ""
> +"Dur: Réinitialise l'arbre de travail et l'index\n"
"Réinitialise le work tree et l'index"
> +"(abandonne TOUS les changements locaux)"
<...>
> +#: gitk:8857
#, fuzzy
> +msgid "Checking out"
> +msgstr "Récupération"
<...>
> +#: gitk:9257
> +msgid ""
> +"Error reading commit topology information; branch and preceding/following "
> +"tag information will be incomplete."
> +msgstr ""
> +"Erreur à la lecture des informations sur la topology des commits. "
s/topology/topologie/
s/./ ;/
> +"Les informations sur les branches et les tags précédents/suivant "
s/L/l/
> +"seront incomplètes."
> +
> +#: gitk:10243
> +msgid "Tag"
> +msgstr "Tag"
Should not be required.
> +#: gitk:10243
> +msgid "Id"
> +msgstr "Id"
Ditto.
> +#: gitk:10308
> +msgid "B"
> +msgstr "B"
Ditto.
> +#: gitk:10311
> +msgid "I"
> +msgstr "I"
Ditto.
> +#FIXME : Traduction standard de "pane"?
> +#: gitk:10416
#, fuzzy
> +#, tcl-format
> +msgid "Maximum graph width (% of pane)"
> +msgstr "Longueur maximum du graphe (% du panneau)"
<...>
> +#: gitk:10441
> +msgid "Support per-file encodings"
> +msgstr "Support pour un encodage de caractère par fichier"
s/de caractère/ des caractères/
> +#: gitk:10449
> +msgid "Choose..."
> +msgstr "Choisir ..."
No space.
> +#: gitk:10475
> +msgid "Diff: hunk header"
> +msgstr "Différences : entête de l'extrait"
"diff : entête du hunk"
> +#: gitk:10477
> +msgid "diff hunk header"
> +msgstr "différences : entête de l'extrait"
Ditto.
> +#: gitk:10973
> +msgid ""
> +"Sorry, gitk cannot run with this version of Tcl/Tk.\n"
> +" Gitk requires at least Tcl/Tk 8.4."
> +msgstr ""
> +"Désolé, gitk ne peut être exécuté par cette version de Tcl/Tk.\n"
> +" Gitk requiert Tcl/Tk version 8.4 ou supérieur."
s/par/avec/
--
Nicolas Sebrecht
^ permalink raw reply
* Re: gitk : french translation
From: Emmanuel Trillaud @ 2009-11-11 1:10 UTC (permalink / raw)
To: Nicolas Sebrecht
Cc: Maximilien Noal, Matthieu Moy, Nicolas Pitre, Thomas Moulard,
Guy Brand, Git Mailing List
In-Reply-To: <20091110204742.GA27518@vidovic>
2009/11/10 Nicolas Sebrecht <nicolas.s.dev@gmx.fr>:
>> commiter : auteur du commit : commiteur
>
> Why not "commiteur" for gitk too?
It's ok for me.
>> Check out : Récupérer : charger
>> to cherry-pick : Ceuillir
>> Diff : Différence : Diff
>
> See comment at the end.
>
>> Soft (Reset) : Douce :
>
> Léger ?
Souds better. I will make the change, except if someone has a better
proposal.
>> I prefer to translate "Diff" by "Différences" _especially_ when we are
>> talking about the action of making a "diff"
>
> You don't explain _why_. We had 3 points in favour of the "diff" term in
> french in this thread (keep Git's commands consistency, rough
> translation and english word more used even by french people as for
> "patch"). I have another argument to use "diff" now: keep consistency
> with 'git gui'.
I see now that I have no good reasons to prefer "Différences".
>> translation of "cherry-pick". For this one we could use "<translation>
>> (<english-word>) ..." as suggest previously.
>
> I'm fine here.
Thanks for your comments.
Emmanuel Trillaud
^ permalink raw reply
* Re: [PATCH 20/24] http-fetch: add missing initialization of argv0_path
From: Jonathan Nieder @ 2009-11-11 1:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Sixt
In-Reply-To: <7vpr7q6sw8.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> Why do you have inclusion of "exec_cmd.h" in [19/24]? As far as I can
> tell, nothing you do in that patch depends on it.
No good reason. Thanks for cleaning up my mess.
Jonathan
^ permalink raw reply
* Re: [PATCH 18/24] merge: do not setup worktree twice
From: Jonathan Nieder @ 2009-11-11 1:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vws1y6sxg.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> Jonathan Nieder <jrnieder@gmail.com> writes:
>
>> Builtins do not need to run setup_worktree() for themselves, since
>> the builtin machinery runs it for them.
>>
>> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
>> ---
>> This matter since '-h' cannot suppress _this_ setup_work_tree()
>> through the builtin machinery.
>
> I think this should directly go to 'maint'. I ejected it from the
> series.
Thanks. I think something like this should go on top on maint, then
reverted in master.
Sorry for the trouble,
Jonathan
-- %< --
Subject: check-ref-format does not know --print yet
Don’t advertise the --print option of the future in the current
usage string.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
builtin-check-ref-format.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin-check-ref-format.c b/builtin-check-ref-format.c
index 96382e3..a5ba4ea 100644
--- a/builtin-check-ref-format.c
+++ b/builtin-check-ref-format.c
@@ -8,7 +8,7 @@
#include "strbuf.h"
static const char builtin_check_ref_format_usage[] =
-"git check-ref-format [--print] <refname>\n"
+"git check-ref-format <refname>\n"
" or: git check-ref-format --branch <branchname-shorthand>";
int cmd_check_ref_format(int argc, const char **argv, const char *prefix)
--
1.6.5.2
^ permalink raw reply related
* [PATCH] gitk: Add ability to define an alternate temporary directory
From: David Aguilar @ 2009-11-11 1:49 UTC (permalink / raw)
To: paulus; +Cc: git, David Aguilar
gitk fails to show diffs when browsing a repository for which
we have read-only access. This is due to gitk's assumption
that the current directory is always writable.
This teaches gitk to honor the GITK_TMPDIR environment
variable. This allows users to override the default location
used for writing temporary files.
Signed-off-by: David Aguilar <davvid@gmail.com>
---
gitk | 10 +++++++---
1 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/gitk b/gitk
index db5ec54..9139ace 100755
--- a/gitk
+++ b/gitk
@@ -3170,11 +3170,15 @@ proc flist_hl {only} {
}
proc gitknewtmpdir {} {
- global diffnum gitktmpdir gitdir
+ global diffnum env gitktmpdir gitdir
if {![info exists gitktmpdir]} {
- set gitktmpdir [file join [file dirname $gitdir] \
- [format ".gitk-tmp.%s" [pid]]]
+ if {[info exists env(GITK_TMPDIR)]} {
+ set tmpdir $env(GITK_TMPDIR)
+ } else {
+ set tmpdir [file dirname $gitdir]
+ }
+ set gitktmpdir [file join $tmpdir [format ".gitk-tmp.%s" [pid]]]
if {[catch {file mkdir $gitktmpdir} err]} {
error_popup "[mc "Error creating temporary directory %s:" $gitktmpdir] $err"
unset gitktmpdir
--
1.6.5.2.180.gc5b3e
^ permalink raw reply related
* [PATCH] gitk: Document the $GITK_TMPDIR variable
From: David Aguilar @ 2009-11-11 1:49 UTC (permalink / raw)
To: paulus; +Cc: git, David Aguilar
In-Reply-To: <1257904149-44381-1-git-send-email-davvid@gmail.com>
Signed-off-by: David Aguilar <davvid@gmail.com>
---
Documentation/gitk.txt | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/Documentation/gitk.txt b/Documentation/gitk.txt
index cf465cb..7e184f3 100644
--- a/Documentation/gitk.txt
+++ b/Documentation/gitk.txt
@@ -100,6 +100,11 @@ Files
Gitk creates the .gitk file in your $HOME directory to store preferences
such as display options, font, and colors.
+Environment Variables
+---------------------
+Gitk honors the $GITK_TMPDIR environment when creating temporary
+files and directories.
+
SEE ALSO
--------
'qgit(1)'::
--
1.6.5.2.180.gc5b3e
^ permalink raw reply related
* Re: [PATCH] gitk: Add ability to define an alternate temporary directory
From: Sam Vilain @ 2009-11-11 3:59 UTC (permalink / raw)
To: David Aguilar; +Cc: paulus, git
In-Reply-To: <1257904149-44381-1-git-send-email-davvid@gmail.com>
David Aguilar wrote:
> gitk fails to show diffs when browsing a repository for which
> we have read-only access. This is due to gitk's assumption
> that the current directory is always writable.
>
> This teaches gitk to honor the GITK_TMPDIR environment
> variable. This allows users to override the default location
> used for writing temporary files.
>
Is there a good reason not to use the common TMPDIR or TMP environment
variables for this?
Sam
^ permalink raw reply
* Re: git-svn not fetching all revisions
From: Sam Vilain @ 2009-11-11 4:00 UTC (permalink / raw)
To: Marcus Better; +Cc: git
In-Reply-To: <4AF9AC1A.5000100@better.se>
Marcus Better wrote:
> The problem is that the trunk was replaced by a branch at some point.
> When I do "git svn clone -s svn://host/repo/project" it only fetches the
> "old" trunk up to the time of the switch, and then stops. Newer
> revisions of the "new" trunk are not fetched and cannot be seen with
> "find-rev".
Yeah. Try doing it in parts - fetch the two stages of the history
explicitly using the revision range arguments to 'git svn fetch' - and
then graft the histories together and fix up with git filter-branch. A
bit of a hassle, but unfortunately there's not much other option...
Sam
^ permalink raw reply
* Re: git-svn problem with v1.6.5
From: Sam Vilain @ 2009-11-11 4:02 UTC (permalink / raw)
To: pascal; +Cc: git list
In-Reply-To: <4AF9E7FE.3060701@obry.net>
Pascal Obry wrote:
> Hello,
>
> A git-svn mirror is created using Git v1.6.4. When I copy this mirror
> into another machine which is using v1.6.5 I get the following error:
>
> $ git svn rebase
> fatal: Invalid revision range
> d2cf08bb67e4b7da33a250127aab784f1f2f58d3..refs/remotes/svn/trunk
> rev-list --pretty=raw --no-color --reverse
> d2cf08bb67e4b7da33a250127aab784f1f2f58d3..refs/remotes/svn/trunk --:
> command returned error: 128
>
> Using v1.6.4 instead I have no problem. Any idea to track this problem down?
>
Did you copy the entire directory across using rsync/tar/etc or 'git
clone' ? You'll need to make sure that the 'refs/remotes/*' refs look
exactly the same on the clone as they did on the original import repository.
Sam
^ permalink raw reply
* Re: [PATCH] gitk: Add ability to define an alternate temporary directory
From: David Aguilar @ 2009-11-11 4:07 UTC (permalink / raw)
To: Sam Vilain; +Cc: paulus, git
In-Reply-To: <4AFA368F.207@vilain.net>
On Wed, Nov 11, 2009 at 04:59:11PM +1300, Sam Vilain wrote:
> David Aguilar wrote:
> > gitk fails to show diffs when browsing a repository for which
> > we have read-only access. This is due to gitk's assumption
> > that the current directory is always writable.
> >
> > This teaches gitk to honor the GITK_TMPDIR environment
> > variable. This allows users to override the default location
> > used for writing temporary files.
> >
>
> Is there a good reason not to use the common TMPDIR or TMP environment
> variables for this?
I, personally, would not be opposed to that.
The only reason I chose a different variable was that I didn't
want to change the existing behavior (backwards-compat hat on).
Since TMPDIR and TMP are common then we'd be changing the
behavior.
That said, if there's a consensus that the path doesn't matter
much than we could change the behavior. I was just trying to be
careful.
--
David
^ permalink raw reply
* Re: Bug: "git svn clone" does not honor svn.authorsfile setting
From: Sam Vilain @ 2009-11-11 4:26 UTC (permalink / raw)
To: Curt Sampson, git
In-Reply-To: <20091110130913.GR19475@poetic.cynic.net>
Curt Sampson wrote:
> When using "git svn fetch" or "git svn clone", the --authors-file
> command line parameter does what it claims in the docs. Additionally,
> for "git svn fetch", an svn.authorsfile configuration parameter in
> ~/.gitconfig is used, if no command line argument is specified. However,
> svn.authorsfile is ignored by "git svn clone", though the documentation
> claims that clone "runs init and fetch."
>
> I have confirmed this bug is present in git versions 1.6.0.4 and 1.6.5.1.
>
Does moving the line:
command_oneline('config', 'svn.authorsfile', $_authors) if $_authors;
Immediately prior to the "fetch_all" line before it fix the problem? It
looks strange for it to set it afterwards...
Sam
^ permalink raw reply
* [PATCH] bash: add the merge option --ff-only
From: Björn Gustavsson @ 2009-11-11 4:49 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
Signed-off-by: Björn Gustavsson <bgustavsson@gmail.com>
---
contrib/completion/git-completion.bash | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index e3ddecc..a0917d1 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1224,7 +1224,7 @@ _git_log ()
__git_merge_options="
--no-commit --no-stat --log --no-log --squash --strategy
- --commit --stat --no-squash --ff --no-ff
+ --commit --stat --no-squash --ff --no-ff --ff-only
"
_git_merge ()
--
1.6.5.1.69.g36942
^ permalink raw reply related
* t5541-http-push hanging
From: Brian Gernhardt @ 2009-11-11 6:28 UTC (permalink / raw)
To: Git List
My build script for git has been hanging at t5541.2 and I haven't had the tuits to discover why. Here's what I've gotten so far, in case anyone can figure it out faster:
$ ./t5541-http-push.sh -v
Initialized empty Git repository in /Users/brian/dev/git/t/trash directory.t5541-http-push/.git/
* expecting success:
cd "$ROOT_PATH" &&
mkdir test_repo &&
cd test_repo &&
git init &&
: >path1 &&
git add path1 &&
test_tick &&
git commit -m initial &&
cd - &&
git clone --bare test_repo test_repo.git &&
cd test_repo.git &&
git config http.receivepack true &&
ORIG_HEAD=$(git rev-parse --verify HEAD) &&
cd - &&
mv test_repo.git "$HTTPD_DOCUMENT_ROOT_PATH"
Initialized empty Git repository in /Users/brian/dev/git/t/trash directory.t5541-http-push/test_repo/.git/
[master (root-commit) 0c973ae] initial
0 files changed, 0 insertions(+), 0 deletions(-)
create mode 100644 path1
/Users/brian/dev/git/t/trash directory.t5541-http-push
Initialized empty Git repository in /Users/brian/dev/git/t/trash directory.t5541-http-push/test_repo.git/
/Users/brian/dev/git/t/trash directory.t5541-http-push
* ok 1: setup remote repository
* expecting success:
cd "$ROOT_PATH" &&
git clone $HTTPD_URL/smart/test_repo.git test_repo_clone
Initialized empty Git repository in /Users/brian/dev/git/t/trash directory.t5541-http-push/test_repo_clone/.git/
error: RPC failed; result=22, HTTP code = 500
^CFATAL: Unexpected exit with code 130
brian@hermes t (master)$ cd trash\ directory.t5541-http-push/httpd/
brian@hermes httpd (master)$ cat error.log
[Wed Nov 11 06:19:39 2009] [notice] Apache/2.2.13 (Unix) configured -- resuming normal operations
[Wed Nov 11 06:19:39 2009] [error] [client 127.0.0.1] git-http-backend(59490) malloc: *** error for object 0x100200340: incorrect checksum for freed object - object was probably modified after being freed.
[Wed Nov 11 06:19:39 2009] [error] [client 127.0.0.1] *** set a breakpoint in malloc_error_break to debug
[Wed Nov 11 06:19:40 2009] [error] [client 127.0.0.1] Premature end of script headers: git-http-backend
[Wed Nov 11 06:24:23 2009] [notice] caught SIGTERM, shutting down
^ permalink raw reply
* Re: git-svn problem with v1.6.5
From: Pascal Obry @ 2009-11-11 8:11 UTC (permalink / raw)
To: Sam Vilain; +Cc: git list
In-Reply-To: <4AFA3751.7000709@vilain.net>
Sam,
> Did you copy the entire directory across using rsync/tar/etc or 'git
> clone' ?
I did a rsync of the .git directory so I expect all refs to be there.
Pascal.
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net - http://v2p.fr.eu.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver keys.gnupg.net --recv-key F949BD3B
^ permalink raw reply
* Re: [PATCH v4 1/2] filter-branch: stop special-casing $filter_subdir argument
From: Johannes Sixt @ 2009-11-11 8:30 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, Junio C Hamano
In-Reply-To: <0280836a32983c848bbb0e3b441be256d3c8f4fa.1257885121.git.trast@student.ethz.ch>
Thomas Rast schrieb:
> Johannes Sixt wrote:
>> # we need "--" only if there are no path arguments in $@
>> nonrevs=$(git rev-parse --no-revs "$@") || exit
>> dashdash=${nonrevs+"--"}
>>
>> (including the comment; you can drop the dquotes in the dashdash
>> assignment if you think the result is still readable.)
>
> Ok. I was briefly scared that this was bash-specific syntax, but dash
> seems happy so I'll trust your advice.
You shouldn't. I'm wrong ;-)
In the snippet above, dashdash will always be set to "--" because a mere
'+' in the variable expansion only tests whether the variable ('nonrevs')
is unset, but it is always set. Even ${nonrevs:+"--"} is wrong, and your
earlier 'test -z' invocation was the correct way to set dashdash.
But...
I did some testing, and now I have to wonder about the use-case that you
present in the commit message:
> Furthermore, the case for --subdirectory-filter supplies its own --,
> so the user cannot provide one himself, so the following was
> impossible:
>
> git filter-branch --subdirectory-filter subdir -- --all -- subdir/file
If you try in git.git itself:
$ git rev-list --simplify-merges --all -- \
Documentation/git-commit.txt | wc -l
84
$ git rev-list --simplify-merges --all -- \
Documentation/git-commit.txt Documentation | wc -l
4624
I thought that the intention to give an extra path argument is to reduce
the number of commits that remain in the rewritten history. But by giving
--subdirectory-filter, the path filter actually loosened, and many more
commits are rewritten.
Since your intention to write this patch is actually to implement
--remap-to-ancestor, I suggest that we defer the question whether the
above use-case makes sense, and only rewrite this particular paragraph in
the commit message to point out the real bug:
-----
Furthermore, --subdirectory-filter supplies its own '--', and if the user
provided one himself, such as in
git filter-branch --subdirectory-filter subdir -- --all -- subdir/file
an extra '--' was used as path filter in the call to git-rev-list that
determines the commits that shall be rewritten.
-----
I'll submit a replacement patch.
-- Hannes
^ permalink raw reply
* Consensus on "Git"
From: David Symonds @ 2009-11-11 8:32 UTC (permalink / raw)
To: git
Hi folks,
Is there consensus on "Git" being the standard capitalisation, versus
"GIT"? I only really see "git" and "Git" on the mailing list and in
most external documentation and websites (e.g. git-scm.com and
github.com), but git's source tells a different picture:
$ cat *.[ch] | egrep -o '\bG[Ii][Tt]\b' | sort | uniq -c
36 GIT
7 Git
$ cat Documentation/* 2> /dev/null | egrep -o '\bG[Ii][Tt]\b' | sort | uniq -c
284 GIT
155 Git
Dave.
^ permalink raw reply
* Re: [PATCH] Define $PERL_PATH in test-lib.sh
From: Philippe Bruhat (BooK) @ 2009-11-11 8:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Sixt, git
In-Reply-To: <7v7hty6so9.fsf@alter.siamese.dyndns.org>
On Tue, Nov 10, 2009 at 12:17:26PM -0800, Junio C Hamano wrote:
> "Philippe Bruhat (BooK)" <book@cpan.org> writes:
>
> > On Tue, Nov 10, 2009 at 01:26:53PM +0100, Johannes Sixt wrote:
> >> >
> >> > +test -z "$NO_PERL" && test -z "$PERL_PATH" && export PERL_PATH=/usr/bin/perl
> >>
> >> Wouldn't
> >>
> >> ... && export PERL_PATH=perl
> >>
> >> be a safer fall-back?
> >
> > /usr/bin/perl is the value used in the top-level Makefile.
> > I used this for consistency.
>
> Hmm, but that means two separate definitions in ./Makefile and
> t/test-lib.sh must be kept in sync forever, and there is not even a
> comment next to the line that requires such care in your patch to help
> people who might want to change these lines in the future.
Is there a way to obtain whatever value was computed in the Makefile,
or should I just add a comment in all-caps saying "keep this in sync
with the default value in the top level Makefile"? (and a more detailed
commit message)
--
Philippe Bruhat (BooK)
Freedom is not an individual effort. Yours comes only when you grant others
theirs. (Moral from Groo The Wanderer #5 (Epic))
^ permalink raw reply
* Re: [PATCH] Define $PERL_PATH in test-lib.sh
From: Jeff King @ 2009-11-11 8:43 UTC (permalink / raw)
To: Philippe Bruhat (BooK); +Cc: Junio C Hamano, Johannes Sixt, git
In-Reply-To: <20091111084014.GE8896@plop>
On Wed, Nov 11, 2009 at 09:40:14AM +0100, Philippe Bruhat (BooK) wrote:
> > Hmm, but that means two separate definitions in ./Makefile and
> > t/test-lib.sh must be kept in sync forever, and there is not even a
> > comment next to the line that requires such care in your patch to help
> > people who might want to change these lines in the future.
>
> Is there a way to obtain whatever value was computed in the Makefile,
> or should I just add a comment in all-caps saying "keep this in sync
> with the default value in the top level Makefile"? (and a more detailed
> commit message)
Yes. Did you miss the second half of my other message?
http://article.gmane.org/gmane.comp.version-control.git/132561
-Peff
^ permalink raw reply
* Re: P4 Sync problem
From: Tor Arvid Lund @ 2009-11-11 8:43 UTC (permalink / raw)
To: Dmitry Smirnov; +Cc: git
In-Reply-To: <loom.20091110T145046-137@post.gmane.org>
On Tue, Nov 10, 2009 at 2:56 PM, Dmitry Smirnov <divis1969@gmail.com> wrote:
> Hi,
>
> I'm trying to import Perfoce client into Git repository.
> I had configured git-p4.clent=MYCLIENT and git-p4.useclientspec=true.
>
> When runnign git p4 sync --verbose I got the follwing:
>
> c:\p4\views\Git\p4client>git p4 sync --verbose
<snip>
> Traceback (most recent call last):
> File "/usr/sbin/git-core//git-p4", line 1929, in ?
> main()
> File "/usr/sbin/git-core//git-p4", line 1924, in main
> if not cmd.run(args):
> File "/usr/sbin/git-core//git-p4", line 1676, in run
> changes = p4ChangesForPaths(self.depotPaths, self.changeRange)
> File "/usr/sbin/git-core//git-p4", line 442, in p4ChangesForPaths
> assert depotPaths
> AssertionError
Hi. So - I think the problem is that git-p4 doesn't understand what it
is you want to sync. The git-p4.useclientspec flag was created for the
purpose where your perforce depot may look like this:
//depot/project1
//depot/project1/source_code
//depot/project1/documentation
//depot/project1/some_large_collection_of_binaries
Then - if I set up my client spec like:
//depot/...
-//depot/project1/some_large_collection_of_binaries
... and do
git p4 sync //depot/project1@all
... it should get all project1 files except the
"some_large_collection_of_binaries" subdirectory (provided that you
have set the git-p4.client and git-p4.useclientspec).
-Tor Arvid-
^ permalink raw reply
* [PATCH v5 1/2] filter-branch: stop special-casing $filter_subdir argument
From: Johannes Sixt @ 2009-11-11 8:53 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, Junio C Hamano
In-Reply-To: <4AFA7624.5040400@viscovery.net>
From: Thomas Rast <trast@student.ethz.ch>
Handling $filter_subdir in the usual way requires a separate case at
every use, because the variable is empty when unused.
Furthermore, --subdirectory-filter supplies its own '--', and if the user
provided one himself, such as in
git filter-branch --subdirectory-filter subdir -- --all -- subdir/file
an extra '--' was used as path filter in the call to git-rev-list that
determines the commits that shall be rewritten.
To keep the argument handling sane, we filter $@ to contain only the
non-revision arguments, and store all revisions in $ref_args. The
$ref_args are easy to handle since only the SHA1s are needed; the
actual branch names have already been stored in $tempdir/heads at this
point.
An extra separating -- is only required if the user did not provide
any non-revision arguments, as the latter disambiguate the
$filter_subdir following after them (or fail earlier because they are
ambiguous themselves).
Thanks to Johannes Sixt for suggesting this solution.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
---
Johannes Sixt schrieb:
> I'll submit a replacement patch.
Here it is. The interdiff to your version is merely
--- a/git-filter-branch.sh
+++ b/git-filter-branch.sh
@@ -266,7 +266,7 @@
# we need "--" only if there are no path arguments in $@
nonrevs=$(git rev-parse --no-revs "$@") || exit
-dashdash=${nonrevs+"--"}
+test -z "$nonrevs" && dashdash=-- || dashdash=
rev_args=$(git rev-parse --revs-only "$@")
case "$filter_subdir" in
and I changed the commit message in the way I announced it.
-- Hannes
git-filter-branch.sh | 22 +++++++++++++++-------
1 files changed, 15 insertions(+), 7 deletions(-)
diff --git a/git-filter-branch.sh b/git-filter-branch.sh
index a480d6f..ed3db7d 100755
--- a/git-filter-branch.sh
+++ b/git-filter-branch.sh
@@ -257,15 +257,24 @@ git read-tree || die "Could not seed the index"
# map old->new commit ids for rewriting parents
mkdir ../map || die "Could not create map/ directory"
+# we need "--" only if there are no path arguments in $@
+nonrevs=$(git rev-parse --no-revs "$@") || exit
+test -z "$nonrevs" && dashdash=-- || dashdash=
+rev_args=$(git rev-parse --revs-only "$@")
+
case "$filter_subdir" in
"")
- git rev-list --reverse --topo-order --default HEAD \
- --parents --simplify-merges "$@"
+ eval set -- "$(git rev-parse --sq --no-revs "$@")"
;;
*)
- git rev-list --reverse --topo-order --default HEAD \
- --parents --simplify-merges "$@" -- "$filter_subdir"
-esac > ../revs || die "Could not get the commits"
+ eval set -- "$(git rev-parse --sq --no-revs "$@" $dashdash \
+ "$filter_subdir")"
+ ;;
+esac
+
+git rev-list --reverse --topo-order --default HEAD \
+ --parents --simplify-merges $rev_args "$@" > ../revs ||
+ die "Could not get the commits"
commits=$(wc -l <../revs | tr -d " ")
test $commits -eq 0 && die "Found nothing to rewrite"
@@ -356,8 +365,7 @@ then
do
sha1=$(git rev-parse "$ref"^0)
test -f "$workdir"/../map/$sha1 && continue
- ancestor=$(git rev-list --simplify-merges -1 \
- $ref -- "$filter_subdir")
+ ancestor=$(git rev-list --simplify-merges -1 "$ref" "$@")
test "$ancestor" && echo $(map $ancestor) >> "$workdir"/../map/$sha1
done < "$tempdir"/heads
fi
--
1.6.5.rc2.47.g49402
^ permalink raw reply related
* [PATCH v5 2/2] filter-branch: nearest-ancestor rewriting outside subdir filter
From: Johannes Sixt @ 2009-11-11 8:55 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, Junio C Hamano
In-Reply-To: <4AFA7B9A.4090005@viscovery.net>
From: Thomas Rast <trast@student.ethz.ch>
Date: Tue, 10 Nov 2009 22:04:51 +0100
Since a0e4639 (filter-branch: fix ref rewriting with
--subdirectory-filter, 2008-08-12) git-filter-branch has done
nearest-ancestor rewriting when using a --subdirectory-filter.
However, that rewriting strategy is also a useful building block in
other tasks. For example, if you want to split out a subset of files
from your history, you would typically call
git filter-branch -- <refs> -- <files>
But this fails for all refs that do not point directly to a commit
that affects <files>, because their referenced commit will not be
rewritten and the ref remains untouched.
The code was already there for the --subdirectory-filter case, so just
introduce an option that enables it independently.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
---
Only resent for Junio's convenience. It is identical to your v4, but
with my SOB added.
-- Hannes
Documentation/git-filter-branch.txt | 13 ++++++++++++-
git-filter-branch.sh | 18 +++++++++++++-----
t/t7003-filter-branch.sh | 18 ++++++++++++++++++
3 files changed, 43 insertions(+), 6 deletions(-)
diff --git a/Documentation/git-filter-branch.txt b/Documentation/git-filter-branch.txt
index 2b40bab..394a77a 100644
--- a/Documentation/git-filter-branch.txt
+++ b/Documentation/git-filter-branch.txt
@@ -159,7 +159,18 @@ to other tags will be rewritten to point to the underlying commit.
--subdirectory-filter <directory>::
Only look at the history which touches the given subdirectory.
The result will contain that directory (and only that) as its
- project root.
+ project root. Implies --remap-to-ancestor.
+
+--remap-to-ancestor::
+ Rewrite refs to the nearest rewritten ancestor instead of
+ ignoring them.
++
+Normally, positive refs on the command line are only changed if the
+commit they point to was rewritten. However, you can limit the extent
+of this rewriting by using linkgit:rev-list[1] arguments, e.g., path
+limiters. Refs pointing to such excluded commits would then normally
+be ignored. With this option, they are instead rewritten to point at
+the nearest ancestor that was not excluded.
--prune-empty::
Some kind of filters will generate empty commits, that left the tree
diff --git a/git-filter-branch.sh b/git-filter-branch.sh
index ed3db7d..6b8b6a4 100755
--- a/git-filter-branch.sh
+++ b/git-filter-branch.sh
@@ -125,6 +125,7 @@ filter_subdir=
orig_namespace=refs/original/
force=
prune_empty=
+remap_to_ancestor=
while :
do
case "$1" in
@@ -137,6 +138,11 @@ do
force=t
continue
;;
+ --remap-to-ancestor)
+ shift
+ remap_to_ancestor=t
+ continue
+ ;;
--prune-empty)
shift
prune_empty=t
@@ -182,6 +188,7 @@ do
;;
--subdirectory-filter)
filter_subdir="$OPTARG"
+ remap_to_ancestor=t
;;
--original)
orig_namespace=$(expr "$OPTARG/" : '\(.*[^/]\)/*$')/
@@ -354,12 +361,13 @@ while read commit parents; do
die "could not write rewritten commit"
done <../revs
-# In case of a subdirectory filter, it is possible that a specified head
-# is not in the set of rewritten commits, because it was pruned by the
-# revision walker. Fix it by mapping these heads to the unique nearest
-# ancestor that survived the pruning.
+# If we are filtering for paths, as in the case of a subdirectory
+# filter, it is possible that a specified head is not in the set of
+# rewritten commits, because it was pruned by the revision walker.
+# Ancestor remapping fixes this by mapping these heads to the unique
+# nearest ancestor that survived the pruning.
-if test "$filter_subdir"
+if test "$remap_to_ancestor" = t
then
while read ref
do
diff --git a/t/t7003-filter-branch.sh b/t/t7003-filter-branch.sh
index 329c851..9503875 100755
--- a/t/t7003-filter-branch.sh
+++ b/t/t7003-filter-branch.sh
@@ -288,4 +288,22 @@ test_expect_success 'Prune empty commits' '
test_cmp expect actual
'
+test_expect_success '--remap-to-ancestor with filename filters' '
+ git checkout master &&
+ git reset --hard A &&
+ test_commit add-foo foo 1 &&
+ git branch moved-foo &&
+ test_commit add-bar bar a &&
+ git branch invariant &&
+ orig_invariant=$(git rev-parse invariant) &&
+ git branch moved-bar &&
+ test_commit change-foo foo 2 &&
+ git filter-branch -f --remap-to-ancestor \
+ moved-foo moved-bar A..master \
+ -- -- foo &&
+ test $(git rev-parse moved-foo) = $(git rev-parse moved-bar) &&
+ test $(git rev-parse moved-foo) = $(git rev-parse master^) &&
+ test $orig_invariant = $(git rev-parse invariant)
+'
+
test_done
--
1.6.5.rc2.47.g49402
^ permalink raw reply related
* Re: [PATCH v5 1/2] filter-branch: stop special-casing $filter_subdir argument
From: Johannes Sixt @ 2009-11-11 8:58 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, Junio C Hamano
In-Reply-To: <4AFA7B9A.4090005@viscovery.net>
Johannes Sixt schrieb:
> --- a/git-filter-branch.sh
> +++ b/git-filter-branch.sh
> @@ -266,7 +266,7 @@
>
> # we need "--" only if there are no path arguments in $@
> nonrevs=$(git rev-parse --no-revs "$@") || exit
> -dashdash=${nonrevs+"--"}
> +test -z "$nonrevs" && dashdash=-- || dashdash=
> rev_args=$(git rev-parse --revs-only "$@")
>
> case "$filter_subdir" in
Arrgh! I should have indented these lines so that they
do not count as patch text.
Sorry.
-- Hannes
^ permalink raw reply
* Re: Consensus on "Git"
From: Sverre Rabbelier @ 2009-11-11 9:02 UTC (permalink / raw)
To: David Symonds; +Cc: git
In-Reply-To: <ee77f5c20911110032r65a60653sfeef34e3de07d17e@mail.gmail.com>
Heya,
On Wed, Nov 11, 2009 at 09:32, David Symonds <dsymonds@gmail.com> wrote:
> Is there consensus on "Git" being the standard capitalisation, versus
> "GIT"? I only really see "git" and "Git" on the mailing list and in
> most external documentation and websites (e.g. git-scm.com and
> github.com), but git's source tells a different picture:
Definitely "Git" or "git", the source code ones are probably from
variable names, something like "GIT_INSTALL_DIR" and whatnot.
--
Cheers,
Sverre Rabbelier
^ 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