* Re: core.gitproxy and non-git protocols
From: Jakub Narebski @ 2007-08-04 0:34 UTC (permalink / raw)
To: git
In-Reply-To: <20070802053151.GH20052@spearce.org>
Shawn O. Pearce wrote:
> David Symonds <dsymonds@gmail.com> wrote:
>> It'd be great if (a) the documentation could be fixed, or (b) the
>> proxy-picking code could be at least extended to ssh:// protocols, and
>> preferrably extended to defining custom protocols.
>
> Did you try setting GIT_SSH envvar to point to a script that does
> what you need? I do this in one particular case...
GIT_SSH environmental variable is *not described* anywhere in the
documentation. Would you be so kind?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.5.3-rc4
From: Ismail Dönmez @ 2007-08-04 0:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vzm18jg7p.fsf@assigned-by-dhcp.cox.net>
On Saturday 04 August 2007 03:28:26 you wrote:
> I tagged 1.5.3-rc4 and it will soon be mirrored out. This is
> the last rc before the real thing, which I am hoping to happen
> by mid August. Until then, I won't look at anything but
> regression fixes and documentation updates. Please test this
> one well.
Can't build manpages, same error as
http://lists-archives.org/git/625107-having-problems-with-building-the-manpages.html :
xmlto -m callouts.xsl man git-add.xml
runtime error: file
file:///usr/share/sgml/docbook/xsl-stylesheets-1.73.0/manpages/other.xsl line
129 element call-template
The called template 'read-character-map' was not found.
Regards,
ismail
--
Perfect is the enemy of good
^ permalink raw reply
* [RFC (take 3)] Git User's Survey 2007
From: Jakub Narebski @ 2007-08-04 0:50 UTC (permalink / raw)
To: git
In-Reply-To: <200707250358.58637.jnareb@gmail.com>
It's been more than a year since last Git User's Survey. It would be
interesting to find what changed since then. Therefore the idea to
have another survey.
First there is a question about the form of survey. Should we use web
based survey, as the survey before (http://www.survey.net.nz), sending
emails with link to this survey, or perhaps do email based survey,
with email Reply-To: address put for this survey alone?
Second, what questions should be put in the survey, and in the case of
single choice and multiple choice questions what possible answers
should be? Below are slightly extended questions from the last
survey. Please comment on it.
Third, where to send survey to? I was thinking about git mailing list,
LKML, and mailing list for git projects found on GitProjects page on
GIT wiki. Do you want to add some address? Or should info about GIT
User's Survey 2007 be sent also to one of on-line magazines like
LinuxToday, or asked to put on some blog?
Those lists include:
wine-users, xmms2-devel, xcb (freedesktop), cairo, u-boot-users,
git mailing list, lklm (thanks to Paolo Ciarrocchi)
LWN, NewsForge, Slashdot, OSNews,
Those lists might include:
CRUX Linux, Source Mage Linux, DirectFB, GNU LilyPond, OLPC,
Thousands Parsec, X.Org, Mesa3D, Beryl -> Compiz Fusion,
Other possibilities:
OpenOffice.org, Mozilla (MozillaZine), SeaMonkey,
KDE (dot.kde.net), GNOME, Blue GNU
References:
http://marc.info/?l=git&m=115116592330648&w=2
http://marc.info/?l=git&m=115364303813936&w=2
http://git.or.cz/gitwiki/GitSurvey
----
Hi all,
We would like to ask you a few questions about your use of the GIT
version control system. This survey is mainly to understand who is
using GIT, how and why.
The results will be published to the GIT wiki and discussed on the git
mailing list.
We'll close the survey in three weeks starting from today, <date>.
Please devote a few minutes of your time to fill this simple
questionnaire, it will help a lot the git community to understand your
needs, what you like of git, and of course what you don't like of it.
The survey can be found here:
http://www.survey.net.nz/survey.php? <number>
----
About you
1. What country are you in?
2. What is your preferred non-programming language?
3. How old are you?
4. Which programming languages you are proficient with?
(The choices include programming languages used by git)
(zero or more: multiple choice)
- C, shell, Perl, Python, Tcl/Tk
Getting started with GIT
1. How did you hear about GIT?
2. Did you find GIT easy to learn?
- very easy/easy/reasonably/hard/very hard
3. What helped you most in learning to use it?
4. What did you find hardest?
5. When did you start using git? From which version?
* (date, or version, or both)
Other SCMs
1. What other SCM did you use?
2. What other SCM do you use currently?
3. What other SCM do you use as a main SCM for your project
instead of git, if any?
4. Why did you choose this SCM?
* example: better MS Windows support
5. What would you require from git to enable you to change,
if you use other SCM for your project?
6. Did you import your repository from foreign SCM?
7. What tool did you use for import?
8. Do your git repository interact with other SCM?
9. What tool did/do you use?
How you use GIT
1. Do you use GIT for work, unpaid projects, or both?
work/unpaid projects/both/none(*)
(*)I use git to interact with some project I'm interested in
2. How do you obtain GIT? Source tarball, binary package, or
pull the main repository?
- binary package/source tarball/pull from main repository
3. What hardware platforms do you use GIT on?
* examples: i386, x86_64, ARM, PowerPC, Alpha, g5, ...
4. What OS (please include the version) do you use GIT on?
* examples: Linux, MS Windows (Cygwin/MinGW/gitbox),
IRIX, HP-UX, Solaris, FreeBSD, ...
(please give kernel version and distribution for Linux)
5. How many people do you collaborate with using GIT?
6. How big are the repositories that you work on? (e.g. how many
files, how much disk space, how deep is the history?)
* number of files in repository: "git ls-tree -r HEAD | wc -l"
* largest file under version control
* pack size of freshly cloned fully packed repository
* number of commits in straight line, number of commits in branch
("git rev-list --first-parent HEAD | wc -l",
"git rev-list HEAD | wc -l")
7. How many different projects do you manage using GIT?
8. Which porcelains do you use?
(zero or more: multiple choice)
- core-git, cogito, StGIT, pg, guilt, other
9. Which git GUI do you use
(zero or more: multiple choice)
- gitk, git-gui, qgit, gitview, giggle, tig, instaweb,
(h)gct, qct, KGit, other
10. Which (main) git web interface do you use for your projects?
- gitweb/cgit/wit (Ruby)/git-php/other
11. How do you publish/propagate your changes?
(zero or more: multiple choice)
- push, pull request, format-patch + email, bundle, other
12. Does git.git repository include code produced by you?
- yes/no
Internationalization
1. Is translating GIT required for wider adoption?
- yes/no/somewhat
2. What do you need translated?
* examples: git-gui, qgit, messages, manpages, user's manual
3. For what language do you need translation for?
What you think of GIT
1. Overall, how happy are you with GIT?
- unhappy/not so happy/happy/very happy/completely ecstatic
2. How does GIT compare to other SCM tools you have used?
- worse/equal (or comparable)/better
3. What do you like about using GIT?
4. What would you most like to see improved about GIT?
(features, bugs, plug-ins, documentation, ...)
5. If you want to see GIT more widely used, what do you
think we could do to make this happen?
Changes in GIT (since year ago, or since you started using it)
1. Did you participate in previous Git User's Survey?
- yes/no
2. What improvements you wanted got implemented?
3. What improvements you wanted didn't get implemented?
4. How do you compare current version iwth version from year ago?
- current version is: better/worse/no changes
5. Which of the new features do you use?
(zero or more: multiple choice)
- git-gui, bundle, eol conversion, gitattributes,
submodules, worktree, release notes, user's manual,
reflog, stash, shallow clone, detached HEAD, fast-import,
mergetool, interactive rebase, commit template, blame improvements,
other (not mentioned here)
6. If you selected "other", what are those features?
Documentation
1. Do you use the GIT wiki?
- yes/no
2. Do you find GIT wiki useful?
- yes/no/somewhat
3. Do you contribute to GIT wiki?
- yes/no/only corrections or spam removal
4. Do you find GIT's on-line help (homepage, documentation) useful?
- yes/no/somewhat
5. Do you find help distributed with GIT useful
(manpages, manual, tutorial, HOWTO, release notes)?
- yes/no/somewhat
6. Do you contribute to GIT documentation?
- yes/no
7. What could be improved on the GIT homepage?
8. What topics would you like to have on GIT wiki?
9. What could be improved in GIT documentation?
Getting help, staying in touch
1. Have you tried to get GIT help from other people?
- yes/no
2. If yes, did you get these problems resolved quickly
and to your liking?
- yes/no
3. Do you subscribe to the mailing list?
- yes/no
4. Do you read the mailing list? What method do you use?
- subscribed/news interface/RSS interface/archives/
/post + reply-to request/digests/I don't read it
5. If yes, do you find it useful?
- yes/no (optional)
6. Do you find traffic levels on GIT mailing list OK.
- yes/no? (optional)
7. Do you use the IRC channel (#git on irc.freenode.net)?
- yes/no
8. If yes, do you find IRC channel useful?
- yes/no (optional)
Open forum
1. What other comments or suggestions do you have that are not
covered by the questions above?
^ permalink raw reply
* Re: [PATCH] gitweb: Fix handling of $file_name in feed generation
From: Robert Fitzsimons @ 2007-08-04 0:27 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Steven Walter, git, Robert Fitzsimons, Junio Hamano
In-Reply-To: <200708031950.43126.jnareb@gmail.com>
> Subject: [PATCH] gitweb: Fix handling of $file_name in feed generation
>
> The commit b6093a5c, by Robert Fitzsimons:
> "gitweb: Change atom, rss actions to use parse_commits."
> forgot to pass $file_name parameter to parse_commits subroutine.
>
> If git_feed is provided a file name, it ought to show only the history
> affecting that file or a directory. The title was being set
> correctly, but all commits from history were being shown.
>
> Signed-off-by: Steven Walter <stevenrwalter@gmail.com>
> Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Silly me. Jakub's change is the correct fix for the bug.
Robert
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.5.3-rc4
From: Junio C Hamano @ 2007-08-04 1:30 UTC (permalink / raw)
To: Ismail Dönmez; +Cc: git
In-Reply-To: <200708040341.36147.ismail@pardus.org.tr>
Ismail Dönmez <ismail@pardus.org.tr> writes:
> Can't build manpages, same error as ...
Sigh...
The asciidoc toolchain used by us (either AsciiDoc 7 nor 8) does
not seem to work well with docbook-xsl 1.72 and 1.73, it seems.
If you can investigate where the breakage is to come up with
patches to make it format with newer docbook-xsl, without
breaking 1.71 (which k.org uses to make the preformatted
documentation in html and man branches), it would be very much
welcomed and appreciated.
I however have a slight suspition that the patch might end up to
be against either asciidoc or docbook-xsl package, not our
documentation...
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.5.3-rc4
From: Ismail Dönmez @ 2007-08-04 1:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vsl70jdcr.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 870 bytes --]
On Saturday 04 August 2007 04:30:12 Junio C Hamano wrote:
> Ismail Dönmez <ismail@pardus.org.tr> writes:
> > Can't build manpages, same error as ...
>
> Sigh...
>
> The asciidoc toolchain used by us (either AsciiDoc 7 nor 8) does
> not seem to work well with docbook-xsl 1.72 and 1.73, it seems.
>
> If you can investigate where the breakage is to come up with
> patches to make it format with newer docbook-xsl, without
> breaking 1.71 (which k.org uses to make the preformatted
> documentation in html and man branches), it would be very much
> welcomed and appreciated.
>
> I however have a slight suspition that the patch might end up to
> be against either asciidoc or docbook-xsl package, not our
> documentation...
Attached patch from Fedora against docbook-xsl 1.73 fixes the issue.
Regards,
ismail
--
Perfect is the enemy of good
[-- Attachment #2: docbook-xsl-manpages-charmap.patch --]
[-- Type: text/x-diff, Size: 504 bytes --]
--- docbook-xsl-1.73.0/manpages/docbook.xsl.manpages-charmap 2007-07-23 16:24:23.000000000 +0100
+++ docbook-xsl-1.73.0/manpages/docbook.xsl 2007-07-23 16:25:16.000000000 +0100
@@ -37,6 +37,7 @@
<xsl:include href="lists.xsl"/>
<xsl:include href="endnotes.xsl"/>
<xsl:include href="table.xsl"/>
+ <xsl:include href="../common/charmap.xsl"/>
<!-- * we rename the following just to avoid using params with "man" -->
<!-- * prefixes in the table.xsl stylesheet (because that stylesheet -->
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.5.3-rc4
From: Junio C Hamano @ 2007-08-04 3:13 UTC (permalink / raw)
To: Ismail Dönmez; +Cc: git
In-Reply-To: <200708040448.56611.ismail@pardus.org.tr>
Ismail Dönmez <ismail@pardus.org.tr> writes:
> Attached patch from Fedora against docbook-xsl 1.73 fixes the issue.
Thanks. I'll mention this in the INSTALL document somewhere.
Perhaps the patch should go to docbook-xsl maintainers.
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.5.3-rc4
From: Steven Grimm @ 2007-08-04 3:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ismail Dönmez, git
In-Reply-To: <7vsl70jdcr.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> The asciidoc toolchain used by us (either AsciiDoc 7 nor 8) does
> not seem to work well with docbook-xsl 1.72 and 1.73, it seems.
>
How attached are we to asciidoc? Every time I do a clean build and sit
there twiddling my thumbs waiting for xmlto to do its thing, I think to
myself, "If this were a dedicated Perl script to do the syntax
transformations directly to man and html formats, it would blast through
all the .txt files in a second or two total." It seems outlandish to me
that it takes longer to build the (relatively small) documentation than
it does to build the actual code. Plus we constantly run into this sort
of problem.
Do we want to keep using asciidoc (e.g., so people can easily export to
other asciidoc-supported formats), or is a dedicated renderer something
we'd consider switching to? I have a flight from China back to the US
coming in a couple weeks; this could be a perfect little project to keep
me occupied between in-flight movies. It doesn't look like the syntax
transformations are very hard, and it'd be easy enough to verify
correctness by just comparing against the existing asciidoc output.
Am I correct in observing that "*roff -man" and HTML are the only two
output formats we care about, or do people use other formats in their
private branches?
-Steve
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.5.3-rc4
From: Junio C Hamano @ 2007-08-04 4:38 UTC (permalink / raw)
To: Steven Grimm; +Cc: Ismail Dönmez, git
In-Reply-To: <46B3F762.1050306@midwinter.com>
Steven Grimm <koreth@midwinter.com> writes:
> How attached are we to asciidoc? Every time I do a clean build and sit
> there twiddling my thumbs waiting for xmlto to do its thing, I think
> to myself, "If this were a dedicated Perl script to do the syntax
> transformations directly to man and html formats, it would blast
> through all the .txt files in a second or two total." It seems
> outlandish to me that it takes longer to build the (relatively small)
> documentation than it does to build the actual code. Plus we
> constantly run into this sort of problem.
I cannot say that I am really happy with the current situation.
In my unscientific tests, it appears that we are spending about
50% of the time in asciidoc and 50% in xmlto for man backend
(total about 5 seconds for producing git.7 on my private box).
For xhtml11 backend, git.html takes about 2.3 seconds (for
xhtml11 backend, the output is written directly by asciidoc).
> Do we want to keep using asciidoc (e.g., so people can easily export
> to other asciidoc-supported formats), or is a dedicated renderer
> something we'd consider switching to? I have a flight from China back
> to the US coming in a couple weeks; this could be a perfect little
> project to keep me occupied between in-flight movies. It doesn't look
> like the syntax transformations are very hard, and it'd be easy enough
> to verify correctness by just comparing against the existing asciidoc
> output.
>
> Am I correct in observing that "*roff -man" and HTML are the only two
> output formats we care about, or do people use other formats in their
> private branches?
I obviously do not speak for others, but the only format I care
about personally is the *.txt one. We picked asciidoc primarily
because the source language was readable.
Unfortunately, AsciiDoc 8 requires authors to quote more
"special characters" we would rather be able to use as literals
(most importantly, plus sign '+') than AsciiDoc 7, and I am
afraid the trend to hijack more non alphabet letters as
"special" may continue.
If I read you correctly, what you are proposing to offer is a
clone of asciidoc, perhaps AsciiDoc 7, with only xhtml11 and man
backends. It is a subset in the sense that you will do only two
backends, but otherwise is a clone in the sense that you are
going to implement the input language we use (one thing I
personally care about while probably other people do not is the
conditional compilation "ifdef::stalenotes[]" in git.txt).
There is an obvious maintenance cost and risk with such a fork.
* You would need to duplicate the AsciiDoc 7 manual and
maintain it as well; otherwise, when later versions of
AsciiDoc comes, people who update our documentation will
refer to asciidoc website to learn the syntax, and find out
that your dialect does not match what is described there.
This already is the case, as our documentation source is
written for AsciiDoc 7 and we use asciidoc7compatible support
when running with AsciiDoc 8.
* How much can we really rely on your fork to be kept
maintained? When we need newer mark-up that is not offered
by AsciiDoc 7 clone, is it our plan to model that after
AsciiDoc X (X > 7), or we just come up with an extension of
our own?
* What would happen when xhtml11 goes out of fashion and we
would want to switch to newer formats?
* What to do with the user manual, which formats to docbook
"book" output?
I have a mild suspicion that a clone/fork of AsciiDoc is not a
way to go.
It might be more worthwhile to research what other "Text-ish
lightweight mark-up" systems are availble, and if there is one
that is more efficient and can go to at least html and man,
one-time convert our documentation source to that format using
your Perl magic. The minimum requirements are:
* The source is readable without too much mark-up distraction;
* Can go to roff -man;
* Can go to html.
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.5.3-rc4
From: Daniel Barkalow @ 2007-08-04 4:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Steven Grimm, Ismail Dönmez, git
In-Reply-To: <7vfy2zj4nj.fsf@assigned-by-dhcp.cox.net>
On Fri, 3 Aug 2007, Junio C Hamano wrote:
> If I read you correctly, what you are proposing to offer is a
> clone of asciidoc, perhaps AsciiDoc 7, with only xhtml11 and man
> backends. It is a subset in the sense that you will do only two
> backends, but otherwise is a clone in the sense that you are
> going to implement the input language we use (one thing I
> personally care about while probably other people do not is the
> conditional compilation "ifdef::stalenotes[]" in git.txt).
It's worth noting that we're a substantial portion of the asciidoc user
base, at least based on asciidoc's "Projects using AsciiDoc" page. We
could probably be influential in the asciidoc development if we tried
(maybe starting with a config file mechanism for controlling what
characters are markup instead of literal, so that we'll be able to make
documents which will work the same with all versions of asciidoc).
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH] unpack-trees.c: assume submodules are clean during check-out
From: Junio C Hamano @ 2007-08-04 5:13 UTC (permalink / raw)
To: skimo, Sven Verdoolaege; +Cc: git, Eran Tromer
In-Reply-To: <20070801140532.GC31114MdfPADPa@greensroom.kotnet.org>
Sven Verdoolaege <skimo@kotnet.org> writes:
> If you have a submodule checked out and you go back (or forward)
> to a revision of the supermodule that contains a different
> revision of the submodule and then switch to another revision,
> it will complain that the submodule is not uptodate, because
> git simply didn't update the submodule in the first move.
>
> Now, you may say that I simply need to run 'git submodule update'
> after every such move, but this is very inconvenient, especially
> if you're doing a bisect or a rebase.
>
> How do other people deal with this problem?
>
> How about just replacing the body of ce_compare_gitlink
> with "return 0" until git actually (optionally) updates
> the submodules during an update of the supermodule?
Let me understand the problem first. If your first checkout
does not check out the submodule, switching between revisions
that has different commit of the submodule there would not fail,
but once you checkout the submodule, switching without updating
the submodule would be Ok (because by design updating the
submodule is optional) but then further switching out of that
state will fail because submodule in the supermodule tree and
checked-out submodule repository are now out of sync. Is that
the problem?
In any case, I doubt ce_compare_gitlink() is the right layer to
work this around -- it is not about "can we switch" but is about
"is it different". It is at too low a level.
The current policy is to consider it is perfectly normal that
checked-out submodule is out-of-sync wrt the supermodule index,
if I am reading you right. I think it is a good policy, at
least until we introduce a superproject repository configuration
option that says "in this repository, I do care about this
submodule and at any time I move around in the superproject,
recursively check out the submodule to match". The most extreme
case of this policy is that the superproject index knows about
the submodule but the subdirectory does not even have to be
checked out, which is what we have now.
Where does the "No you are not up-to-date, I wouldn't let you
switch" come from? Is that verify_uptodate() called from
merged_entry() called from twoway_merge()? I think the right
approach to deal with this is to teach verify_uptodate() about
the policy. The function is about "make sure the filesystem
entity that corresponds to this cache entry is up to date, lest
we lose the local modifications". As we explicitly allow
submodule checkout to drift from the supermodule index entry,
the check should say "Ok, for submodules, not matching is the
norm" for now. Later when we have the ability to mark "I care
about this submodule to be always in sync with the superproject"
(thereby implementing automatic recursive checkout and perhaps
diff, among other things), we should check if the submodule in
question is marked as such and perform the current test.
How about doing something like this instead?
unpack-trees.c | 9 +++++++++
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/unpack-trees.c b/unpack-trees.c
index 3b32718..dfd985b 100644
--- a/unpack-trees.c
+++ b/unpack-trees.c
@@ -407,6 +407,15 @@ static void verify_uptodate(struct cache_entry *ce,
unsigned changed = ce_match_stat(ce, &st, 1);
if (!changed)
return;
+ /*
+ * NEEDSWORK: the current default policy is to allow
+ * submodule to be out of sync wrt the supermodule
+ * index. This needs to be tightened later for
+ * submodules that are marked to be automatically
+ * checked out.
+ */
+ if (S_ISGITLINK(ntohl(ce->ce_mode)))
+ return;
errno = 0;
}
if (errno == ENOENT)
^ permalink raw reply related
* Re: [ANNOUNCE] GIT 1.5.3-rc4
From: Junio C Hamano @ 2007-08-04 5:23 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Steven Grimm, Ismail Dönmez, git
In-Reply-To: <Pine.LNX.4.64.0708040046400.23671@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> writes:
> It's worth noting that we're a substantial portion of the asciidoc user
> base, at least based on asciidoc's "Projects using AsciiDoc" page. We
> could probably be influential in the asciidoc development if we tried
> (maybe starting with a config file mechanism for controlling what
> characters are markup instead of literal, so that we'll be able to make
> documents which will work the same with all versions of asciidoc).
Tempting, but...
* The breakage that triggered this thread was not about asciidoc
but about docbook-xsl. AsciiDoc project cannot do much about
it.
* The slowness while formatting our manual pages are 50% from
xmlto toolchain and even if AsciiDoc were were to be sped up
20x, we will still spend 4-5 minutes to format ~140 manual
pages.
^ permalink raw reply
* Re: Some ideas for StGIT
From: Pavel Roskin @ 2007-08-04 5:41 UTC (permalink / raw)
To: Andy Parkins; +Cc: git, Catalin Marinas
In-Reply-To: <200708031914.04344.andyparkins@gmail.com>
Hello, Andy!
On Fri, 2007-08-03 at 19:14 +0100, Andy Parkins wrote:
> On Friday 2007, August 03, Pavel Roskin wrote:
>
> > I don't suggest that StGIT gives up on the git-based storage, but this
> > mode of operation could be implemented in two ways.
>
> git's shiny new git rebase -i has removed, for me, those times when I needed
> stgit. Perhaps those who've move from git to quilt would try again when
> 1.5.3 is out with the magic that is "rebase -i".
I don't understand how one option can replace StGIT. I assume you were
trying to avoid StGIT already, and "git-rebase -i" was just the last
missing piece.
It would be great if you could tell me how your approach would deal with
the issue of editable patches I mentioned already. In case I was
unclear, here's the quote from one of the developers:
[quote]
Sometimes, I just make patches in quilt, then I do "quilt
refresh", "quilt pop -a", "cd patches" and modify the patches
and series file manually, e.g. by moving one patch from one file
into the other. The "cd ..", "quilt push -a" and off I am. That
the "database" of quilt is in a known format and I can hack on
it with an editor is a plus for me :-)
[end of quote]
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: [RFC (take 3)] Git User's Survey 2007
From: Shawn O. Pearce @ 2007-08-04 5:41 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200708040250.55180.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> wrote:
> It's been more than a year since last Git User's Survey. It would be
> interesting to find what changed since then. Therefore the idea to
> have another survey.
This is actually a pretty good draft. I'd say its about ready to
go. A couple of minor comments:
> How you use GIT
>
> 1. Do you use GIT for work, unpaid projects, or both?
> work/unpaid projects/both/none(*)
> (*)I use git to interact with some project I'm interested in
I don't understand the (*) point here. What's the middle ground
between work and unpaid projects? Paid projects that aren't work?
Isn't that the definition of work? Very confused...
> 7. How many different projects do you manage using GIT?
> 8. Which porcelains do you use?
> (zero or more: multiple choice)
> - core-git, cogito, StGIT, pg, guilt, other
I really hope nobody chooses pg. I haven't supported it in a very
long time. Might be a good idea to keep it in this survey just to
make sure its 0, then omit it from the next survey. :-)
> Changes in GIT (since year ago, or since you started using it)
...
> 5. Which of the new features do you use?
> (zero or more: multiple choice)
> - git-gui, bundle, eol conversion, gitattributes,
> submodules, worktree, release notes, user's manual,
> reflog, stash, shallow clone, detached HEAD, fast-import,
> mergetool, interactive rebase, commit template, blame improvements,
> other (not mentioned here)
Wow.
This community has accomplished a lot since the last survey.
That list covers most of the major items over the past year, if
not all of them. But I'd never really seen it all written out
in such a concise list; there's so much blood, sweat and tears
in those topics from everyone on (and off) this mailing list.
Reading it now is bringing back a lot of memories for me.
Sorry, I just had a very emotional reaction to seeing how much we
have managed to accomplish in so little time. Thank you to everyone
who has made this list possible!
> Getting help, staying in touch
>
> 1. Have you tried to get GIT help from other people?
> - yes/no
> 2. If yes, did you get these problems resolved quickly
> and to your liking?
> - yes/no
Possible new item:
Would commerical (paid) support from a support vendor be of
interest to you/your organization?
Just kicking the idea out there. Some of us have talked about
this on and off from time to time, I wonder what our user community
thinks of it. I think Sam Vilain was suggesting he sell Git support
to my day-job company, so my coworkers could call him and ask him
questions, and he could ask me those same questions on #git, then
mail me a 6-pack of beer[*1*] for my troubles. :)
[*1*] And sadly I don't drink beer...
--
Shawn.
^ permalink raw reply
* Re: core.gitproxy and non-git protocols
From: Shawn O. Pearce @ 2007-08-04 5:43 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <f90his$3tg$2@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> wrote:
> Shawn O. Pearce wrote:
> >
> > Did you try setting GIT_SSH envvar to point to a script that does
> > what you need? I do this in one particular case...
>
> GIT_SSH environmental variable is *not described* anywhere in the
> documentation. Would you be so kind?
Whow. It really isn't documented.
OK, I'll send a documentation patch in a few minutes.
--
Shawn.
^ permalink raw reply
* Re: Some ideas for StGIT
From: Shawn O. Pearce @ 2007-08-04 5:51 UTC (permalink / raw)
To: Pavel Roskin; +Cc: Andy Parkins, git, Catalin Marinas
In-Reply-To: <1186206085.28481.33.camel@dv>
Pavel Roskin <proski@gnu.org> wrote:
>
> On Fri, 2007-08-03 at 19:14 +0100, Andy Parkins wrote:
> > On Friday 2007, August 03, Pavel Roskin wrote:
> >
> > > I don't suggest that StGIT gives up on the git-based storage, but this
> > > mode of operation could be implemented in two ways.
> >
> > git's shiny new git rebase -i has removed, for me, those times when I needed
> > stgit. Perhaps those who've move from git to quilt would try again when
> > 1.5.3 is out with the magic that is "rebase -i".
I agree with Andy. Aside from the performance issues that I
am currently having with a 55 patch series, "rebase -i" (and its
predecessor script from Dscho) have been a major part of my toolkit,
to the point that I really don't need something like StGIT on
my system.
(Regarding the performance, cherry-picking 55 patches is
slow, especially when many of them would apply trivially with
git-diff|git-apply --index. Be nice to improve that in 1.5.4.)
> I don't understand how one option can replace StGIT. I assume you were
> trying to avoid StGIT already, and "git-rebase -i" was just the last
> missing piece.
Oh, I'm sure there's features in StGIT that are useful that aren't
available via "rebase -i". But to be honest, "rebase -i" is good
enough. It just ain't fast enough. Editing a patch that is 50
back in the series *sucks*.
> It would be great if you could tell me how your approach would deal with
> the issue of editable patches I mentioned already. In case I was
> unclear, here's the quote from one of the developers:
>
> [quote]
> Sometimes, I just make patches in quilt, then I do "quilt
> refresh", "quilt pop -a", "cd patches" and modify the patches
> and series file manually, e.g. by moving one patch from one file
> into the other. The "cd ..", "quilt push -a" and off I am. That
> the "database" of quilt is in a known format and I can hack on
> it with an editor is a plus for me :-)
> [end of quote]
Uh, the "database" of "rebase -i" is just a chain of commits in a
git repository. These are a well known format and can be easily
edited with "rebase -i". This is a real plus for me as the series
can be edited directly in my favorite vi clone, then applied to my
working directory. ;-)
--
Shawn.
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.5.3-rc4
From: Daniel Barkalow @ 2007-08-04 5:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Steven Grimm, Ismail Dönmez, git
In-Reply-To: <7v1wejj2j8.fsf@assigned-by-dhcp.cox.net>
On Fri, 3 Aug 2007, Junio C Hamano wrote:
> Daniel Barkalow <barkalow@iabervon.org> writes:
>
> > It's worth noting that we're a substantial portion of the asciidoc user
> > base, at least based on asciidoc's "Projects using AsciiDoc" page. We
> > could probably be influential in the asciidoc development if we tried
> > (maybe starting with a config file mechanism for controlling what
> > characters are markup instead of literal, so that we'll be able to make
> > documents which will work the same with all versions of asciidoc).
>
> Tempting, but...
>
> * The breakage that triggered this thread was not about asciidoc
> but about docbook-xsl. AsciiDoc project cannot do much about
> it.
>
> * The slowness while formatting our manual pages are 50% from
> xmlto toolchain and even if AsciiDoc were were to be sped up
> 20x, we will still spend 4-5 minutes to format ~140 manual
> pages.
For the latter, asciidoc ought to be able to generate manpages. Not sure
what to do about docbook (for the user manual); it seems generally prone
to compatibility problems. Perhaps we should go through latex instead,
since that's extremely stable these days, or go straight to html.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* [PATCH] Document GIT_SSH environment variable alongside other variables
From: Shawn O. Pearce @ 2007-08-04 6:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jakub Narebski
The GIT_SSH environment variable has survived for quite a while
without being documented, but has been mentioned on list and on
my day-job repositories can only be accessed via magic supplied
through the wonderous hack that is GIT_SSH.
Advertising it alongside other "low level magic" such as GIT_PAGER
and GIT_MERGE_VERBOSITY will certainly help others who need to
spread their own pixie dust to make things work.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
Documentation/git.txt | 16 ++++++++++++++++
1 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/Documentation/git.txt b/Documentation/git.txt
index 4c4d174..18f8b6a 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -421,6 +421,22 @@ other
to an empty string or to the value "cat", git will not launch
a pager.
+'GIT_SSH'::
+ If this environment variable is set then gitlink:git-fetch[1]
+ and gitlink:git-push[1] will use this command instead
+ of `ssh` when they need to connect to a remote system.
+ The 'GIT_SSH' command will be given exactly two arguments:
+ the 'username@host' (or just 'host') from the URL and the
+ shell command to execute on that remote system.
++
+To pass options to the program that you want to list in GIT_SSH
+you will need to wrap the program and options into a shell script,
+then set GIT_SSH to refer to the shell script.
++
+Usually it is easier to configure any desired options through your
+personal `.ssh/config` file. Please consult your ssh documentation
+for further details.
+
'GIT_FLUSH'::
If this environment variable is set to "1", then commands such
as git-blame (in incremental mode), git-rev-list, git-log,
--
1.5.3.rc3.941.gaac97
^ permalink raw reply related
* Re: [ANNOUNCE] GIT 1.5.3-rc4
From: Steven Grimm @ 2007-08-04 6:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ismail Dönmez, git
In-Reply-To: <7vfy2zj4nj.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> If I read you correctly, what you are proposing to offer is a
> clone of asciidoc, perhaps AsciiDoc 7, with only xhtml11 and man
> backends. It is a subset in the sense that you will do only two
> backends, but otherwise is a clone in the sense that you are
> going to implement the input language we use (one thing I
> personally care about while probably other people do not is the
> conditional compilation "ifdef::stalenotes[]" in git.txt).
>
Yes and no. I am not offering to clone *all* of AsciiDoc, just whatever
subset is necessary to format the git documentation. (Of course, having
looked at this very little so far, perhaps that really is all of
AsciiDoc -- but it's certainly not all of xmlto.)
> * You would need to duplicate the AsciiDoc 7 manual and
> maintain it as well; otherwise, when later versions of
> AsciiDoc comes, people who update our documentation will
> refer to asciidoc website to learn the syntax, and find out
> that your dialect does not match what is described there.
>
Actually, I disagree with this. If we were to fork our own document
formatter (or rather "implement" -- "fork" implies starting with the
existing code base) we would explicitly say its input was expected to be
in the "git documentation human-readable text format" rather than "git's
implementation of the AsciiDoc format." Then we could freely tweak
whatever parts of AsciiDoc we're not happy with, and precise
compatibility would be a total non-issue.
> * How much can we really rely on your fork to be kept
> maintained? When we need newer mark-up that is not offered
> by AsciiDoc 7 clone, is it our plan to model that after
> AsciiDoc X (X > 7), or we just come up with an extension of
> our own?
>
My thought would be to come up with our own syntax; that's a logical
result of me not considering this anything but "a formatter whose input
looks suspiciously like AsciiDoc".
While I agree that that's extra work, it also seems to be the case that
(a) git hasn't actually needed new markup very often, and (b) we've
spent far more time dealing with AsciiDoc version-to-version
incompatibilities than it would likely take to implement whatever new
markup we needed.
> * What would happen when xhtml11 goes out of fashion and we
> would want to switch to newer formats?
>
If I do this I'll try to structure the code in such a way that new
formats could be added without huge pain. Will it be as flexible and
configurable as xmlto? Absolutely not, which is kind of the point of the
exercise. Adding a substantially different output format might require
logic changes to the formatter depending on the details, given that the
optimization here will be for speed rather than extreme flexibility.
On the other hand, I don't think that's a short-term enough concern to
be worth worrying too much about; it'll be a long, long time before
XHTML is completely replaced by anything else, just because of its
gargantuan installed base of existing documents. And it's not like we
can't decide to switch to another formatter down the road if we want to.
(Once we all have 64-core machines on our desktops, "make -j64" will
cause AsciiDoc/xmlto to be sufficiently fast!)
> * What to do with the user manual, which formats to docbook
> "book" output?
>
Ah, that's a sticking point, and an answer to my "are there other output
formats?" question. I never pay attention to that file when I'm doing
builds -- forgot it even existed. I'll ask one question first: is that
Docbook output actually necessary, or would people be happy enough just
having the user manual in XHTML?
Assuming we really need a Docbook manual, it's tempting to say, "keep
using AsciiDoc" but then my assertion that we aren't really using
AsciiDoc's input format kind of flies out the window. I wonder if it's
possible to go from one of my proposed script's *output* formats to
Docbook format -- is there software to take well-formed XHTML and turn
it into that format? (Possibly that software is called "xmlto"...) I
think the transformation from .txt to .html is likely to be pretty
lossless, so it should be theoretically possible, anyway.
> It might be more worthwhile to research what other "Text-ish
> lightweight mark-up" systems are availble, and if there is one
> that is more efficient and can go to at least html and man,
> one-time convert our documentation source to that format using
> your Perl magic. The minimum requirements are:
>
> * The source is readable without too much mark-up distraction;
>
> * Can go to roff -man;
>
> * Can go to html.
>
I will look around and see what I can find. You're quite right, better
to use already-existing code than reinvent the wheel.
-Steve
^ permalink raw reply
* Re: [PATCH] user-manual: mention git gui citool (commit, amend)
From: Shawn O. Pearce @ 2007-08-04 6:20 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: Steffen Prohaska, git
In-Reply-To: <20070803125846.GC28323@fieldses.org>
"J. Bruce Fields" <bfields@fieldses.org> wrote:
> On Thu, Aug 02, 2007 at 11:04:59PM -0400, Shawn O. Pearce wrote:
> > Online help? In git-gui? :-)
> >
> > We don't have an online help system yet.
>
> Fair enough.
>
> Though I'd like to keep the main body of the manual focused on the major
> command line tools, I'd have no objection to a separate chapter (or
> appendix?) devoted to git-gui; then you could point directly at that.
> Would that make sense?
Yea, that makes a lot of sense. git-gui isn't a full replacement
for the command line anyway, so I would never suggest a wholesale
rewrite of the user manual to slant the entire thing towards git-gui.
Doing so would only point out the many shortcomings in git-gui. :)
I haven't explored any in-Tk rendering options yet, been too busy
with other projects. Ideally I'd like to just render the asciidoc
markup directly, but I don't think anyone has done an asciidoc
viewer for Tk. I can't imagine it would be that difficult to get
some sort of parser working though...
But at this point in git (and git-gui's) life I think it would
be very worthwhile to devote an entire (new) chapter to git-gui,
maybe as part of git 1.5.4/git-gui 0.9.0. I think we're far too
late in the 1.5.3 cycle to do it now. I personally won't have the
time to even try to rough draft something anytime soon, let alone
let others copy-edit me before Juino releases 1.5.3. :)
Being bundled with core git has brought git-gui a sizeable and
growing userbase, and more and more users are discovering it
each day. We're now seeing it be translated into many different
languages, and it is a somewhat core part of the MSYS port as many
Windows users prefer to click in GUIs over type in cmd.exe terminal
windows (can't say I blame them, cmd.exe is aweful!).
In other words I think git-gui should get roughly as much attention
from the user manual as git-add/rm/mv/commit/checkout/branch get,
as it offers the same feature set. But it shouldn't distract from
the command line part of the manual.
Maybe we should write parts of the manual in a "choose your own
adventure style" and use different chapters for different paths.
I think users can easily decide between the command line "i like to
type" vs. the gui "i like to click" paths and focus their attention
to the material they are most interested in. :-)
--
Shawn.
^ permalink raw reply
* Re: [PATCH] user-manual: mention git gui citool (commit, amend)
From: Shawn O. Pearce @ 2007-08-04 6:33 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: Steffen Prohaska, git
In-Reply-To: <20070803125601.GA28323@fieldses.org>
"J. Bruce Fields" <bfields@fieldses.org> wrote:
> On Thu, Aug 02, 2007 at 11:01:01PM -0400, Shawn O. Pearce wrote:
> > So I'd really love to do better. But frankly I'm at a loss here
> > and just don't know what sort of change to make.
>
> The one thing that struck me when I fired up git-gui was that it wasn't
> obvious to me which things I should try clicking on.
Yea, that I have noticed with other newbies. I have recently had
the chance to observe a few new users work with git-gui for the
first time and I have noticed that they just don't quite know what
to poke at and experiment with. Unlike with many other applications
where its more obvious what's there for the poking...
> For example: the buttons, drop-down menus, and check-boxes all cry out
> to be played with. But the filenames in the lists at the top are less
> obvious, and it might never have occurred to me on my own to right-click
> on the diff hunks at the bottom. That just looks like passive colorized
> text to me.
It doesn't just look like colored text to me anymore. Which is a
huge problem for me as an interface designer. I know what's there.
BTW, the reason why there's a context menu in the diff viewer?
I right clicked in there one day and nothing happened. The fact
that nothing happen surprised the hell out of me. Even though I
had written all of that code myself. So I went off and added
that context menu.
Later I realized I wanted to just stage that hunk. I could click
on it all I want, but the $@!*@(!@* computer didn't do what I really
wanted it to. So stage hunk was born and added to the context menu.
That experience is actually true of much of the git-gui UI. Things
happen there only because I've actually tried to do something,
only to shock myself when I find out it doesn't work! I promptly
write the patch and contribute it. :)
> I don't know what sort of user-interface conventions say "play with
> me!", though. Random ideas:
>
> - maybe the cursor should change shape over the diff hunks (or
> just the headers?)
That's actually a pretty cool idea. I might play with it just to
see how I feel about the cursor changing and if it gives me any
ideas about what might happen under it. Though as I write this
email I'm thinking that if the cursor changed shape when it was
over the diff hunk header I'd try to left-click the hunk header to
get a reaction from the computer.
> - maybe buttons, hunk headers, file names, etc., should all be
> in the same color?
> - maybe the hunk headers could benefit from a little more
> decoration? I don't know how to do that without just making
> the display look more cluttered, though.
> - maybe left-clicking on diff hunks should do something too?
I just had a thought of putting an actual button icon in the first
column of the hunk header lines. If it looks enough like a button
icon thingy, users might just click on it. And when they do we
can present that diff pane context menu, and look, they can stage
their hunks! ;-)
Just a thought. Utterly random too. Musta been that alpha particle
slamming into a neuron.
Thanks for the ideas. Its certainly given me some things to
experiment with in the next week or so when I can find the time.
--
Shawn.
^ permalink raw reply
* Re: Some ideas for StGIT
From: Theodore Tso @ 2007-08-04 6:38 UTC (permalink / raw)
To: Pavel Roskin; +Cc: Catalin Marinas, git
In-Reply-To: <1186163410.26110.55.camel@dv>
On Fri, Aug 03, 2007 at 01:50:10PM -0400, Pavel Roskin wrote:
> Hello!
>
> I was recently disappointed to learn that one of the Linux drivers
> (bcm43xx_mac80211, to be precise) switched from git to quilt. I asked
> whether StGIT was considered, a discussion followed, and I think the key
> points need to be shared with StGIT developers. I'll add some of my
> ideas to the mix.
You might also ask them if they considered "guilt", which uses
text-based patches. It's a lot easier to use, and if they really want
quilt-like functionality, "guilt" will provide it.
My main reason for avoiding StGIT is the fact that at least in the
past, I've found it very fragile when I forget and use "git checkout"
instead of "stg branch" to switch between branches. The fact that
sometimes you have to use the StGit variant of basic git commands has
always struck me as confusing, and then recovering when things get
screwed can be exciting. Usually it's when I start having to cut and
paste SHA1 hashes and running diffs to recreate my patch series after
things get screwed is usually about the time when I wonder why I tried
using StGIT again. (Don't get me wrong; I'm sure I did something
really stupid, and wrong, that caused things to get screwed up. My
complaint is that when I do something stupid, StGIT isn't robust and
is painful to recover from.)
That's why I like guilt; it doesn't require that you use alternate stg
commands for manipulating branches, and since it maintains an external
set of text patches, recovering is much easier; worst case I can just
do a "git reset --hard" and then follow it up with a guilt push -a.
And because it's so stupid simple, it's much rarer that something goes
seriously wrong that requires me to use a recovery procedure in the
first place.
Editing patch headers are also a lot easier with guilt; you can just
go ahead and edit them all, and then you can fresh them in git by
doing a "guilt pop -a; guilt push -a". Since it's not using a
git-based storage, it doesn't have to rewrite the whole patch stack
when you modify a single patch header; you can edit a whole bunch of
text headers and then refresh the git commit series just once.
Of course, that's just my preference; others may find StGIT more
convenient, or folks may find the new rebase -i to be better yet.
YMMV.
- Ted
^ permalink raw reply
* Re: [PATCH] git-gui: Added support for OS X right click
From: Shawn O. Pearce @ 2007-08-04 6:55 UTC (permalink / raw)
To: Väinö Järvelä; +Cc: git
In-Reply-To: <C4431971-A1F1-463E-B238-D351FCBB57F8@pp.inet.fi>
V??in?? J??rvel?? <v@pp.inet.fi> wrote:
> OS X sends Button-2 on a "real" right click, such as with a three
> button mouse, or by using the two-finger trackpad click.
Thanks, this will be in 0.8.1. I'm pushing it out shortly.
I had a devil of a time applying your patch though. git-am
choked because the patch was whitespace damaged, and then after
hand-correction and resuming it horribly munged your name's encoding
in the commit. I think there's a bug in there in git-am; I'll
have to try to track it down. I managed to get the patch applied
correctly by editing the mbox file directly, so that git-am did
not need to stop and ask me to resolve the patch.
It seems that Apple's Mail.app just doesn't like to send patches
without destroying them. If you do wind up sending another patch
in the future it may just be easier if you attach the mbox that
format-patch creates, instead of trying to inline it in the
message body.
--
Shawn.
^ permalink raw reply
* [PATCH] git-clone: use cpio's --quiet flag
From: Jeff King @ 2007-08-04 7:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Without this flag, cpio prints the number of blocks copied,
leading to the somewhat confusing git-clone output:
$ git-clone foo bar
Initialized empty Git repository in ...
0 blocks
Signed-off-by: Jeff King <peff@peff.net>
---
This is obviously on top of the jc/clone topic in next.
git-clone.sh | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/git-clone.sh b/git-clone.sh
index 4c9b1c9..ccfc316 100755
--- a/git-clone.sh
+++ b/git-clone.sh
@@ -281,7 +281,8 @@ yes)
fi
fi &&
cd "$repo" &&
- find objects -depth -print | cpio -pumd$l "$GIT_DIR/" || exit 1
+ find objects -depth -print | cpio --quiet -pumd$l "$GIT_DIR/" \
+ || exit 1
fi
git-ls-remote "$repo" >"$GIT_DIR/CLONE_HEAD" || exit 1
;;
--
1.5.3.rc3.942.g536b2
^ permalink raw reply related
* Re: Shell script cleanups/style changes?
From: Florian Weimer @ 2007-08-04 7:10 UTC (permalink / raw)
To: git
In-Reply-To: <20070802214103.GT29424@schiele.dyndns.org>
* Robert Schiele:
>> Sure. What about the git-rebase line using $(($end - $msgnum)) ?
>
> Bad on Solaris:
>
> $ uname -a
> SunOS solaris10-x64 5.10 Generic i86pc i386 i86pc
> $ end=1
> $ msgnum=5
> $ echo $(($end - $msgnum))
> syntax error: `(' unexpected
> $
Is this with /usr/xpg4/bin/sh or /bin/sh? The latter is not POSIX and
should not be used by GIT, IMHO, otherwise there will be endless
issues in less-well-tested code paths. Is rewriting the shebang lines
to use the POSIX shell an option for GIT?
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox