* Re: git checkout -f: What am I missing?
From: Michael J Gruber @ 2010-01-15 15:28 UTC (permalink / raw)
To: Soham Mehta; +Cc: git
In-Reply-To: <4B4F899C.7070800@box.net>
Soham Mehta venit, vidit, dixit 14.01.2010 22:16:
> Hi,
>
> I have a situation with git that I'm trying to understand:
>
> Description:
> 1) GIT_DIR is set to /path/to/repo/.git
> 2) Repository is /not /a bare repo, and all files are nicely checked-out
> in /path/to/repo/
> 3) Somebody pushes to that repo using ssh (any branch, checked-out or not)
> 4) Default post-receive hook runs (it is the only one +x) which sends
> out an email
> (http://repo.or.cz/w/git.git/blob/HEAD:/contrib/hooks/post-receive-email)
> 5) After it is done sending the email, I put "git checkout -f", at the
> end in the same file, in case someone pushes to a checked-out branch
>
> Problem:
> It runs "checkout -f" as if inside .git directory, instead of on the
> parent. i.e. it gets all files from the parent and writes them inside
> .git. Parent is left untouched.
>
> Some more info:
> 0) We don't have GIT_DIR set in the environment. The hook does a
> rev-parse to find it.
> 1) echo of $GIT_DIR right before the checkout -f line gives a "." .
> 2) It works as expected if I do this: cd /path/to/repo && git
> --git-dir=/path/to/repo/.git/ checkout -f
>
> What I do know:
> 1) Pushing to a checked-out branch is not a git best-practice, and some
> git behavior is undefined in that case. We already have plans to go away
> from that.
> 2) Git tends to like full path names instead of relative ones
>
> Can someone help me understand this behavior?
Does the thread
http://permalink.gmane.org/gmane.comp.version-control.git/136267
help by any chance?
You've found the solution, "cd .. && unset GIT_DIR" does it.
Michael
^ permalink raw reply
* Re: Gitignore matching "git add" wildcard prevents operation
From: Nicolas Sebrecht @ 2010-01-15 15:39 UTC (permalink / raw)
To: Marko Poutiainen; +Cc: Jeff King, git, Nicolas Sebrecht
In-Reply-To: <4B4F87A0.2090301@sofistes.net>
The 14/01/10, Marko Poutiainen wrote:
>
> Well, it then the interface just isn't consistent,
But it is...
> Well, it then the interface just isn't consistent, because if that's the
> reason, then why does
>
> $git add .
>
> then work in this case? . is still just a type of wildcard, so it fail
> in a similar way, shouldn't it?
...because the dot isn't a wildcard. It's a path.
So, we expect 'git add' to recusively work and resolve ignored paths
from .gitignore and so.
--
Nicolas Sebrecht
^ permalink raw reply
* Re: Gitignore matching "git add" wildcard prevents operation
From: Nicolas Sebrecht @ 2010-01-15 15:34 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Marko Poutiainen, git, Nicolas Sebrecht
In-Reply-To: <20100114203928.GA26883@coredump.intra.peff.net>
The 14/01/10, Jeff King wrote:
> 1. Most programs don't take their own globs. Without knowing that git
> can do so, there is no reason to discover it in this instance. I
> can see searching the manpage for options, but not for a discussion
> of globbing behavior.
>
> 2. They would have to know that using a git-glob will magically change
> the error-checking behavior.
Not sure. This isn't a Git-particular issue.
Users may hit this with a lot of other unix tools (sed, grep, find,
etc). So, we can expect either
they already know the issue;
or
they are discovering it using Git.
Most of the tools I talk about do have a manual section about globbing.
Users could learn globs with Git too and expect the same behaviour
somewhere else.
--
Nicolas Sebrecht
^ permalink raw reply
* Re: Removal of post-upload-hook
From: Jeff King @ 2010-01-15 14:47 UTC (permalink / raw)
To: Robin H. Johnson; +Cc: Git Mailing List
In-Reply-To: <20100114210645.GE16921@orbis-terrarum.net>
On Thu, Jan 14, 2010 at 09:06:45PM +0000, Robin H. Johnson wrote:
> As a reasonable middle ground between the functionality and complete
> removal, can we find a way just to only execute the potentially
> dangerous hooks under known safe conditions or when explicitly requested
> by the user.
An alternative to ripping it out that was discussed is to check that
getuid() matches the owner of the hook.
That might be a nice improvement in security for the push hooks, as
well. But it does come at the cost of some inconvenience. How do you set
up hooks in a shared central repo that every user should trigger? You
need some way to say "these hooks really _are_ trusted, run them
anyway", but that mechanism cannot be in the configuration of the repo
itself for obvious reasons. I suppose if the owner is root? But that
leaves no way for non-root users to set up shared access.
Also, there is a similar issue with config. Right now, if I can convince
you to run "git log" in a repo whose config I own, I can make you run
arbitrary commands via textconv (and ditto for "git diff" and external
diff).
> Places where the hooks are safe:
> - the hooks are known trusted AND not writable by the user/group.
> (e.g. "chown -R root:root hooks/").
This can work, but has drawbacks. See above.
> - Systems where the users/groups do not have full shell access, just
> access to run Git itself. Eg gitosis, regular git+ssh:// w/ a
> restricted shell.
Yes, this would work, too, but how do you configure the "it's OK to run
random hooks" flag? Environment?
-Peff
^ permalink raw reply
* Re: [PATCH] git push --track
From: Johannes Schindelin @ 2010-01-15 14:09 UTC (permalink / raw)
To: Rudolf Polzer; +Cc: Nanako Shiraishi, git
In-Reply-To: <20100115134425.GA30986@rm.endoftheinternet.org>
Hi,
On Fri, 15 Jan 2010, Rudolf Polzer wrote:
> On Fri, Jan 15, 2010 at 07:27:41AM +0900, Nanako Shiraishi wrote:
> > 'git push --track' was suggested as a way to let users delay that decision.
> >
> > 'git branch --configure' to update the same information for an existing
> > branch was suggested as an alternative UI. An added benefit is that this
> > approach will allow the same option to be used when creating a branch.
> >
> > 'git pull --remember' that remembers the options used from the command line
> > was suggested as a solution in addition to 'git branch --reconfigure'. Users
> > can postpone the decision even more than 'git push --track', and it naturally
> > supports setting branch.topic.rebase with 'git pull --rebase --remember'. It
> > also has two additional benefits. 'push --track' configures what happens when
> > you 'pull' (counter-intuitive), but 'pull --remember' makes 'pull' to change
> > the setting used by 'pull' (much more natural). Also it does not add the
> > confusing word 'track' to the interface (for a more detailed discussion on
> > 'track', see http://article.gmane.org/gmane.comp.version-control.git/136785).
Thanks for the very nice summary!
> Still requires you to specify the remote and the branch name twice.
>
> So the workflow would be:
>
> git push origin localbranch:remotebranch
> ...
> git pull --remember origin remotebranch:localbranch
>
> instead of
>
> git push --track origin localbranch:remotebranch
> ...
> git pull
>
> The one thing I want to avoid, is specifying the "origin
> localbranch:remotebranch" stuff twice.
>
> Doesn't make git pull --remember a bad idea, it's good in many other
> cases. But in my specific use case, git push --track is the most useful
> one.
The thing is: done right, the three can share the major part of the code.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] git push --track
From: Rudolf Polzer @ 2010-01-15 14:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Ilari Liusvaara
In-Reply-To: <7vvdf33onp.fsf@alter.siamese.dyndns.org>
On Thu, Jan 14, 2010 at 09:47:22PM -0800, Junio C Hamano wrote:
> I have a feeling that it is more appropriate to have the additional code
> in transport_push(), which gets ls-remote information, runs match_refs()
> and finally calls transport->push_refs(). I think the extra branch
> configuration would fit better inside the if block immediately after all
> that happens, i.e.
>
> if (!(flags & TRANSPORT_PUSH_DRY_RUN)) {
> struct ref *ref;
> for (ref = remote_refs; ref; ref = ref->next)
> update_tracking_ref(transport->remote, ref, verbose);
> + if (flags & TRANSPORT_PUSH_RECONFIGURE_FORK)
> + configure_forked_branch(...);
> }
>
> in transport.c
I thought about this place when making my patch, but didn't put it there
because this function is not called in the rsync protocol (which defines
transport->push). So I instead did the logical step and went into the caller of
that function. Functionality-wise, it also isn't really a "transport" function
but part of pushing.
> > + if(!(flags & TRANSPORT_PUSH_DRY_RUN))
> > + if(!match_refs(local_refs, &remote_refs, refspec_nr, refspec, match_flags))
>
> Yuck; hiding the fact that you have an over-nested logic is not a way to
> fix it.
This was accidental.
But well. Why bother with this, if this feature was rejected before already
anyway.
Rudolf
^ permalink raw reply
* Re: [PATCH] git push --track
From: Rudolf Polzer @ 2010-01-15 13:44 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Johannes Schindelin, git
In-Reply-To: <20100115072741.6117@nanako3.lavabit.com>
On Fri, Jan 15, 2010 at 07:27:41AM +0900, Nanako Shiraishi wrote:
> 'git push --track' was suggested as a way to let users delay that decision.
>
> 'git branch --configure' to update the same information for an existing
> branch was suggested as an alternative UI. An added benefit is that this
> approach will allow the same option to be used when creating a branch.
>
> 'git pull --remember' that remembers the options used from the command line
> was suggested as a solution in addition to 'git branch --reconfigure'. Users
> can postpone the decision even more than 'git push --track', and it naturally
> supports setting branch.topic.rebase with 'git pull --rebase --remember'. It
> also has two additional benefits. 'push --track' configures what happens when
> you 'pull' (counter-intuitive), but 'pull --remember' makes 'pull' to change
> the setting used by 'pull' (much more natural). Also it does not add the
> confusing word 'track' to the interface (for a more detailed discussion on
> 'track', see http://article.gmane.org/gmane.comp.version-control.git/136785).
Still requires you to specify the remote and the branch name twice.
So the workflow would be:
git push origin localbranch:remotebranch
...
git pull --remember origin remotebranch:localbranch
instead of
git push --track origin localbranch:remotebranch
...
git pull
The one thing I want to avoid, is specifying the "origin
localbranch:remotebranch" stuff twice.
Doesn't make git pull --remember a bad idea, it's good in many other cases. But
in my specific use case, git push --track is the most useful one.
Rudolf
^ permalink raw reply
* Re: [PATCH 0/2] Improve Git performance on big trees
From: Nguyen Thai Ngoc Duy @ 2010-01-15 13:36 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git
In-Reply-To: <46a038f91001140721j5acb766cxfd777570d6edfca4@mail.gmail.com>
On 1/14/10, Martin Langhoff <martin.langhoff@gmail.com> wrote:
> 2010/1/14 Nguyễn Thái Ngọc Duy <pclouds@gmail.com>:
>
> > Almost 1 sec for "git rm foo" still seems too long though,
> > probably due to writing a 9MB index.
>
>
> One of the main issues there is that the Gentoo dir tree seems to be
> very flat. The kernel tree is huge, but much deeper, and does not have
> a huge top-level directory -- and git handles it fairly well.
Kernel tree is about one third the size of gentoo-x86 in terms of
worktree. It takes ~1 sec to do "git status" on kernel tree and 3 secs
on gentoo-x86, quite proportional. Except that 3 secs feel much longer
than 1 :-)
Directory structure may also affect performance though. Kernel tree
only has ~2k directories while gentoo-x86 has ~20k shallow dirs.
> Perhaps the Gentoo tree can be rearranged to be more nested? If your
> devs strongly prefer a flat view of it, that could be arranged with
> symlinks.
>
> Alternatively, each port can be in its own repo, and you can make a
> "top level repo" using git submodules -- this is what Fedora/RH is
> exploring at the moment.
There were discussions of these in the past. And to my experience,
these ideas won't go anywhere. The number of worktree files may drop
significantly after Git migration because I believe all ChangeLog
(~13k files on total ~80k) will be gone.
--
Duy
^ permalink raw reply
* Re: Filenames and prefixes in extended diffs
From: Nanako Shiraishi @ 2010-01-15 13:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfx69k0bu.fsf@alter.siamese.dyndns.org>
Quoting Junio C Hamano <gitster@pobox.com>
> The output from "git diff --no-index" is an exception to the above rule.
> It is primarily for people who have unmanaged contents and want to use
> features of the git diff engine that are not found in other people's diff
> implementations (e.g. wordwise colored diff),...
Is it possible to give --no-index option to "git grep", please?
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: [PATCH] Show submodules as modified when they contain a dirty work tree
From: Nanako Shiraishi @ 2010-01-15 13:32 UTC (permalink / raw)
To: Jens Lehmann
Cc: Junio C Hamano, Git Mailing List, Johannes Schindelin,
Shawn O. Pearce, Heiko Voigt, Lars Hjemli
In-Reply-To: <4B4E1817.1070202@web.de>
Quoting Jens Lehmann <Jens.Lehmann@web.de>
> diff --git a/t/t7506-status-submodule.sh b/t/t7506-status-submodule.sh
> index 3ca17ab..47e205b 100755
> --- a/t/t7506-status-submodule.sh
> +++ b/t/t7506-status-submodule.sh
> @@ -10,8 +10,12 @@ test_expect_success 'setup' '
> : >bar &&
> git add bar &&
> git commit -m " Add bar" &&
> + : >foo &&
> + git add foo &&
> + git commit -m " Add foo" &&
> cd .. &&
> - git add sub &&
> + echo output > .gitignore
> + git add sub .gitignore &&
> git commit -m "Add submodule sub"
> '
This is not a new problem you introduced, but if some commands
before 'cd ..' fails, the next test will run in 'sub'. Other
tests run operations inside () to avoid this problem.
> @@ -23,6 +27,31 @@ test_expect_success 'commit --dry-run -a clean' '
> git commit --dry-run -a |
> grep "nothing to commit"
> '
> +
> +echo "changed" > sub/foo
Have it inside the next test_expect_success.
> +test_expect_success 'status with modified file in submodule' '
> + git status | grep "modified: sub"
> +'
To catch failure from 'git status' this is better written like this.
git status >output &&
grep "modified: sub" output
> +test_expect_success 'status with modified file in submodule (porcelain)' '
> + git status --porcelain >output &&
> + diff output - <<-EOF
> + M sub
> +EOF
> +'
If you use -EOF you may want to align it with tab to make it
easier to read. The one in t7005-editor.sh is a good example
(t7401 is a bad example to imitate).
> +(cd sub && git checkout foo)
> +
> +echo "content" > sub/new-file
Move this part to the next test_expect_success to catch broken
checkout.
> +test_expect_success 'status with untracked file in submodule' '
> + git status | grep "modified: sub"
> +'
Same comment as before.
> +test_expect_success 'status with untracked file in submodule (porcelain)' '
> + git status --porcelain >output &&
> + diff output - <<-EOF
> + M sub
> +EOF
> +'
Same comment as before.
> +rm sub/new-file
> +
Do you need this? If so, move it inside the next
test_expect_success.
> test_expect_success 'rm submodule contents' '
> rm -rf sub/* sub/.git
> '
> --
> 1.6.6.203.g28a8ba.dirty
The following can be squashed to 4519d9cf092a173ac7b0a5570b0d5d602086ecf2
diff --git a/t/t7506-status-submodule.sh b/t/t7506-status-submodule.sh
index 47e205b..253c334 100755
--- a/t/t7506-status-submodule.sh
+++ b/t/t7506-status-submodule.sh
@@ -5,63 +5,87 @@ test_description='git status for submodule'
. ./test-lib.sh
test_expect_success 'setup' '
- test_create_repo sub
- cd sub &&
- : >bar &&
- git add bar &&
- git commit -m " Add bar" &&
- : >foo &&
- git add foo &&
- git commit -m " Add foo" &&
- cd .. &&
- echo output > .gitignore
+ test_create_repo sub &&
+ (
+ cd sub &&
+ : >bar &&
+ git add bar &&
+ git commit -m " Add bar" &&
+ : >foo &&
+ git add foo &&
+ git commit -m " Add foo"
+ ) &&
+ echo output > .gitignore &&
git add sub .gitignore &&
git commit -m "Add submodule sub"
'
test_expect_success 'status clean' '
- git status |
- grep "nothing to commit"
+ git status >output &&
+ grep "nothing to commit" output
'
+
test_expect_success 'commit --dry-run -a clean' '
- git commit --dry-run -a |
- grep "nothing to commit"
+ test_must_fail git commit --dry-run -a >output &&
+ grep "nothing to commit" output
'
-echo "changed" > sub/foo
test_expect_success 'status with modified file in submodule' '
- git status | grep "modified: sub"
+ (cd sub && git reset --hard) &&
+ echo "changed" >sub/foo &&
+ git status >output &&
+ grep "modified: sub" output
'
+
test_expect_success 'status with modified file in submodule (porcelain)' '
+ (cd sub && git reset --hard) &&
+ echo "changed" >sub/foo &&
+ git status --porcelain >output &&
+ diff output - <<-\EOF
+ M sub
+ EOF
+'
+
+test_expect_success 'status with added file in submodule' '
+ (cd sub && git reset --hard && echo >foo && git add foo) &&
+ git status >output &&
+ grep "modified: sub" output
+'
+
+test_expect_success 'status with added file in submodule (porcelain)' '
+ (cd sub && git reset --hard && echo >foo && git add foo) &&
git status --porcelain >output &&
- diff output - <<-EOF
- M sub
-EOF
+ diff output - <<-\EOF
+ M sub
+ EOF
'
-(cd sub && git checkout foo)
-echo "content" > sub/new-file
test_expect_success 'status with untracked file in submodule' '
- git status | grep "modified: sub"
+ (cd sub && git reset --hard) &&
+ echo "content" >sub/new-file &&
+ git status >output &&
+ grep "modified: sub" output
'
+
test_expect_success 'status with untracked file in submodule (porcelain)' '
git status --porcelain >output &&
- diff output - <<-EOF
- M sub
-EOF
+ diff output - <<-\EOF
+ M sub
+ EOF
'
-rm sub/new-file
test_expect_success 'rm submodule contents' '
rm -rf sub/* sub/.git
'
+
test_expect_success 'status clean (empty submodule dir)' '
- git status |
- grep "nothing to commit"
+ git status >output &&
+ grep "nothing to commit" output
'
+
test_expect_success 'status -a clean (empty submodule dir)' '
- git commit --dry-run -a |
- grep "nothing to commit"
+ test_must_fail git commit --dry-run -a >output &&
+ grep "nothing to commit" output
'
test_done
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply related
* Re: [PATCH] git push --track
From: Matthieu Moy @ 2010-01-15 13:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Rudolf Polzer, Tay Ray Chuan, git
In-Reply-To: <7vr5ps5jx1.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> The small nit is that "branch -f --track me origin/me" will happily
> overwrite "me", even when your "me" is not up to date with "origin/me",
> losing commits.
And another issue is:
$ git branch -f --track my-branch origin/my-branch
fatal: Cannot force update the current branch.
$ git branch --track my-branch origin/my-branch
fatal: A branch named 'my-branch' already exists.
Actually, I just can't find a natural set of commands doing:
1. create a branch (git checkout -b)
2. work on it
3. send it upstream (git push)
4. set the upstream as tracking (???)
with the current version of Git. I just do 4. with $EDITOR
.git/config ...
> Perhaps we could teach "branch --track me origin/me" (i.e. no "-f") not to
> barf even when "me" exists, as long as "me" is a subset of "origin/me",
> and treat it as a request to re-configure the upstream information for the
> existing branch "me" and at the same time fast-forward it to
> "origin/me"?
+1, and in addition, allow doing this on the checkout branch if it
doesn't actually change the reference (i.e. touch .git/config, not
.git/refs/...).
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: Removal of post-upload-hook
From: Arun Raghavan @ 2010-01-15 12:14 UTC (permalink / raw)
To: Ilari Liusvaara; +Cc: Jeff King, Shawn O. Pearce, git
In-Reply-To: <20100115115212.GA9221@Knoppix>
2010/1/15 Ilari Liusvaara <ilari.liusvaara@elisanet.fi>:
> On Fri, Jan 15, 2010 at 11:42:19AM +0530, Arun Raghavan wrote:
>>
>> Another thought - would it be acceptable to have a config option to
>> enable/disable these types of hooks, so that people who are not
>> affected by the problem or explicitly don't care can use them? Perhaps
>> a core.allowInsecureHooks ?
>
> That enable/disable would have to ignore per-repo configuration, which
> would make it behave differently from other options. Otherwise attacker
> could just flip the setting...
Alternatively, this could just be a build-time switch.
--
Arun Raghavan
http://arunraghavan.net/
(Ford_Prefect | Gentoo) & (arunsr | GNOME)
^ permalink raw reply
* Re: Removal of post-upload-hook
From: Ilari Liusvaara @ 2010-01-15 11:52 UTC (permalink / raw)
To: Arun Raghavan; +Cc: Jeff King, Shawn O. Pearce, git
In-Reply-To: <6f8b45101001142212i4151c625k54b450cd5978f158@mail.gmail.com>
On Fri, Jan 15, 2010 at 11:42:19AM +0530, Arun Raghavan wrote:
>
> Another thought - would it be acceptable to have a config option to
> enable/disable these types of hooks, so that people who are not
> affected by the problem or explicitly don't care can use them? Perhaps
> a core.allowInsecureHooks ?
That enable/disable would have to ignore per-repo configuration, which
would make it behave differently from other options. Otherwise attacker
could just flip the setting...
-Ilari
^ permalink raw reply
* Re: [PATCH 2/2] Fix variable initialization in insert_packed_refs().
From: Richard Weinberger @ 2010-01-15 11:02 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git, gitster
In-Reply-To: <4B501A9D.6060703@viscovery.net>
Am Freitag 15 Januar 2010 08:34:53 schrieb Johannes Sixt:
> If you look around in the code, you'll find more *cough* initializations
> *cough* like this. They are written this way for a reason: they avoid
> unwarranted compiler warnings "'foo' may be used uninitialized". Are you
> saying that this warning is not triggered anymore after your change?
>
I don't get a warning after my change.
But I'm using on this system a quite old gcc (4.3.1).
I'll recompile git with a more recent gcc and see what happens.
Just for clarification:
"int cmp = cmp;"
*suppresses* only the warning but "cmp" is still uninitialized?
(I did'nt know this trick before.)
//richard
^ permalink raw reply
* [UI issue + BUG] recovering from rebase aborting due to untracked files
From: Yann Dirson @ 2010-01-15 10:44 UTC (permalink / raw)
To: git
During an interactive rebase, it happened that some testing operations on
one commit created files that were normally added by a later commit,
leading to the following conflict:
$ git rebase --continue
error: Untracked working tree file 'xxxx' would be overwritten by merge.
Aborting
Could not apply 8a2ea0a... L10n of photo and games.
$
No clue is given about what to do next. It would be nice if one could
just removes the faulty files, and use "rebase --continue".
Unfortunately, doing the following results in the rebase being prematurely
finished with success, with all patches starting with the one causing the
problem being silently dropped.
Now it is not so hard for an experienced user to rewind and avoid doing
the mistake a second time, but some safeguards would be nice.
Does anyone with knowledge of rebase internals see what goes wrong and how
to fix it best ?
^ permalink raw reply
* Re: [PATCH 0/9] Gitweb caching v5
From: Jakub Narebski @ 2010-01-15 10:28 UTC (permalink / raw)
To: J.H.; +Cc: John 'Warthog9' Hawley, git
In-Reply-To: <4B4FEF33.2040605@eaglescrag.net>
On Fri, 15 Jan 2010, J.H. wrote:
> On 01/14/2010 05:40 PM, Jakub Narebski wrote:
>> "John 'Warthog9' Hawley" <warthog9@eaglescrag.net> writes:
>>> it updates a
>>> number of elements in the caching engine, and this is a much cleaner
>>> break-out of the tree vs. what I am currently developing against.
>>
>> Is caching engine part changed since v2?
>
> Slightly, not dramatically. Only changes were to modify the caching
> engine to deal with the change in output mechanism (I.E. my $output ->
> print {$fh})
O.K.
It is still quite large code dump...
>>> John 'Warthog9' Hawley (9):
[...]
>>> gitweb: Add option to force version match
>> For me it needs to be disabled in gitweb test suite (t/gitweb-lib.sh),
>> if it is enabled by default. I really like that I can test current
>> gitweb without need to recompile git.
>>
>> Also it should have tests that it works as intended (both for matching
>> and non-matching versions) in t/t9501-gitweb-standalone-http-status.sh
>
> I'll get t9501 cleaned up and make sure that the tests default to
> turning it off, and I'll add a test to confirm that this works.
I'll send you proposed fixup to squash, so if you want you can simply
wait for a bit.
[...]
>>> gitweb: cleanup error message produced by undefined $site_header
>> Shouldn't there be such protection for other such variables, like
>> $site_footer and $home_text (and a bit diferent protection against
>> undefined $projects_list)? By the way, how did you arrived at
>> undefined $site_header: deafult build configuration leaves it empty,
>> but defined.
>
> I would have to go back and figure it out, but it's something I hit
> years ago and added that check to keep it from spewing all over my logs.
> Could easily add it to the others mentioned.
Please remember that while for $home_text, $site_header and $site_footer
it would be enough to replace
if (-f $file_variable) {
...
}
with
if (defined $file_variable && -f $file_variable) {
...
}
for undefined $projects_list you have to fail (use die_error).
Defensive programming, here protecting against errors in gitweb config,
is a good idea IMHO.
>>> gitweb: Convert output to using indirect file handle
>> I have alternate solution, using shorter filehandle name (just $out)
>> in
>>
>> git://repo.or.cz/git/jnareb-git.git gitweb/cache-kernel
>> http://repo.or.cz/w/git/jnareb-git.git/shortlog/refs/heads/gitweb/cache-kernel
>>
>> I would have to think a bit about separate handle for binary files;
>> I am not sure if it is really required.
>
> For caching you have to have it. When your outputing the data back from
> the cache you need to switch the output mode for the browser to receive
> the data properly. Otherwise the resulting output from the caching
> engine is going to be garbage. The caching engine explicitly stores the
> binary files separate from the rest of the response.
I think you don't. Just read from cache file and print to browser in
binary (:raw) mode; IIUC the ':utf8' is needed only when you print from
Perl.
>>> gitweb: File based caching layer (from git.kernel.org)
>> I am working (time permitting) in spliting this large code drop into
>> smaller commits, namely:
>
> first up, is there a reason not to take the caching layer as it stands
> while you work on these? I'm fine with adding test cases for what's
> there now if you want, but I guess I'm confused about explicitly wanting
> to break these into smaller commits.
It's there a reason to take this big code dump while we (me and you) are
working on it? As I see there is no other work on gitweb now, and for the
time being you can run your fork for a bit. Or is it about planned
deployment on git.fedora.org or something? Anyway when there is official
release of git including gitweb output caching, it should be easy to switch
off from caching fork.
The caching code has also a few issues: coding style, Perl style (e.g.
not using $cache_enabled / $caching_enabled as boolean), duplicated code,
unnecessary open/close dance around stat (you can stat file which is not
closed), not using atomic write (I'm not sure how important this issue
is, especially with locking), not being able to replace cache by some
other caching module, etc.
>> - href(..., -path_info => 0) (for cache key)
>
> You actually *really* want to have the full url vs. just the path_info.
Errr... it is not about full url (although I errorneously used relative
URL for human-readable cache key) vs only path_info, but about path_info
(for example http://git.public.com/test.git) and query (for example
http://git.public.com/?p=test.git) URLs which leads to exactly the same
view.
> While I accept that this means that you will end up with multiple
> copies of data being stored it helps dramatically if you have multiple
> sites pointing into the same caching space. If you happen to have two
> distinct trees
>
> http://git.public.com/?p=test.git;a=summary
> http://git.private.com/?p=test.git;a=summary
>
> That respectively point to:
>
> /group/public/git/test.git
> /group/private/git/test.git
>
> you'll end up squashing the cache files needlessly and erroneously as
> what's in the cache file will depend on what last site was hit that
> generated the file.
So the key (the human-readable key, not it's MD5 digest) would be
href(-replay=>1, -full_url=>1, -path_info=>0);
>> - simple file based caching + tests
>> - global expire time + tests
>> - output caching in gitweb (WIP)
>> - adaptive expiration time (planned)
>> - tee output / cache write (planned)
>
> You sadly can't 'tee' the output as this would re-introduce the
> stampeding heard problem which is one of the reasons the caching layer
> came about in the first place. Suppose you could give one person the
> output but make everyone else wait for the cache to finish writing out,
> or have the waiting client processes tail the file while it's generated
> but those both seem a little excessive vs. just waiting.
The "tee" is about serving [one person] the output, while cache is being
written. It is a bit orthogonal issue to the 'stampeding herd' protection.
>> - expire time variation from CHI (planned)
This feature is meant to prevent cache miss stampedes[1]
[1] http://search.cpan.org/~jswartz/CHI-0.33/lib/CHI.pm#expires_variance
>> - locking for single writer (planned)
...or rather locking to avoid 'stampeding herd' problem.
BTW I don't recall if it isn't the solution you used, but if there exists
stale cache entry, the other clients can use stale version instead of
forcing to wait till the writer finishes updating cache.
>> - server-side generating info (planned)
>> - AJAX-y generating info (wishlist)
>
> If it's helpful I can genuinely devote several more days to this to get
> these cleaned up. Which would save you a fair amount of time in
> breaking this up.
I'm in the middle of working on gitweb caching, with the intent of arriving
at (super)set of features that are in your patch series.
See http://repo.or.cz/w/?p=git/jnareb-git.git;a=shortlog;h=refs/heads/gitweb/cache-kernel
(this branch is rebased / amended / rewritten).
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH 3/3] difftool: Use eval to expand '--extcmd' expressions
From: Johannes Sixt @ 2010-01-15 8:40 UTC (permalink / raw)
To: David Aguilar; +Cc: gitster, git
In-Reply-To: <1263539762-8269-3-git-send-email-davvid@gmail.com>
David Aguilar schrieb:
> - $GIT_DIFFTOOL_EXTCMD "$LOCAL" "$REMOTE"
> + (eval $GIT_DIFFTOOL_EXTCMD "\"$LOCAL\"" "\"$REMOTE\"")
The new code is broken if $LOCAL or $REMOTE can contain double-quotes. How
about this alternative:
eval $GIT_DIFFTOOL_EXTCMD '"$LOCAL"' '"$REMOTE"'
which I find more readable as well.
What's the reason for the sub-shell? Do you want to protect from shell
code in $GIT_DIFFTOOL_EXTCMD that modifies difftool's variables?
-- Hannes
^ permalink raw reply
* Re: [PATCH v2] Test t5560: Fix test when run with dash
From: Johannes Sixt @ 2010-01-15 8:30 UTC (permalink / raw)
To: Tarmigan Casebolt; +Cc: Junio C Hamano, Michael Haggerty, git, Shawn O. Pearce
In-Reply-To: <1263537842-5792-1-git-send-email-tarmigan+git@gmail.com>
Tarmigan Casebolt schrieb:
> REQUEST_METHOD="GET" some_shell_function
> I can't tell from my reading of the POSIX spec whether my usage was
> wrong or if dash is wrong,
According to POSIX, variables set as shown above for shell functions are
not exported and retain their value after the function returns. I would
not be surprised if dash got this right, and the tests fail because they
were written for bash, which gets it wrong.
In particular,
f() { sh -c 'echo +$v+'; }
v=x f
echo +$v+
sh -c 'echo +$v+'"
Should print
++
+x+
++
I can test only ash, bash, zsh, and ksh, of which only ksh gets it right.
-- Hannes
^ permalink raw reply
* [PATCH] Remove some junk characters from COPYING
From: Ramkumar Ramachandra @ 2010-01-15 8:22 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 192 bytes --]
I removed a few ^L characters from COPYING. Kindly find patch
attached. Again, I'm sorry I couldn't include it inline- I'm behind a
restrictive firewall, and Gmail mangles up patches.
-- Ram
[-- Attachment #2: 0001-Remove-some-junk-characters-from-COPYING.patch --]
[-- Type: text/x-patch, Size: 2369 bytes --]
From 9c59a1588c796b022903573ef7f281dacc8d4858 Mon Sep 17 00:00:00 2001
From: Ramkumar Ramachandra <artagnon@gmail.com>
Date: Fri, 15 Jan 2010 13:41:38 +0530
Subject: [PATCH] Remove some junk characters from COPYING
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
---
COPYING | 10 +++++-----
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/COPYING b/COPYING
index 6ff87c4..78e208a 100644
--- a/COPYING
+++ b/COPYING
@@ -76,7 +76,7 @@ patent must be licensed for everyone's free use or not licensed at all.
The precise terms and conditions for copying, distribution and
modification follow.
-\f
+
GNU GENERAL PUBLIC LICENSE
TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
@@ -131,7 +131,7 @@ above, provided that you also meet all of these conditions:
License. (Exception: if the Program itself is interactive but
does not normally print such an announcement, your work based on
the Program is not required to print an announcement.)
-\f
+
These requirements apply to the modified work as a whole. If
identifiable sections of that work are not derived from the Program,
and can be reasonably considered independent and separate works in
@@ -189,7 +189,7 @@ access to copy from a designated place, then offering equivalent
access to copy the source code from the same place counts as
distribution of the source code, even though third parties are not
compelled to copy the source along with the object code.
-\f
+
4. You may not copy, modify, sublicense, or distribute the Program
except as expressly provided under this License. Any attempt
otherwise to copy, modify, sublicense or distribute the Program is
@@ -246,7 +246,7 @@ impose that choice.
This section is intended to make thoroughly clear what is believed to
be a consequence of the rest of this License.
-\f
+
8. If the distribution and/or use of the Program is restricted in
certain countries either by patents or by copyrighted interfaces, the
original copyright holder who places the Program under this License
@@ -299,7 +299,7 @@ PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE
POSSIBILITY OF SUCH DAMAGES.
END OF TERMS AND CONDITIONS
-\f
+
How to Apply These Terms to Your New Programs
If you develop a new program, and you want it to be of the greatest
--
1.6.5
^ permalink raw reply related
* Re: [PATCH 2/2] Fix variable initialization in insert_packed_refs().
From: Johannes Sixt @ 2010-01-15 7:34 UTC (permalink / raw)
To: Richard Weinberger; +Cc: git, gitster
In-Reply-To: <201001150029.01486.richard@nod.at>
Richard Weinberger schrieb:
> - int cmp = cmp, len;
> + int cmp, len;
If you look around in the code, you'll find more *cough* initializations
*cough* like this. They are written this way for a reason: they avoid
unwarranted compiler warnings "'foo' may be used uninitialized". Are you
saying that this warning is not triggered anymore after your change?
-- Hannes
^ permalink raw reply
* Re: [PATCH 01/18] rebase -i: Make the condition for an "if" more transparent
From: Paolo Bonzini @ 2010-01-15 7:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Eric Blake, git, Michael Haggerty
In-Reply-To: <7v8wc0fuqw.fsf@alter.siamese.dyndns.org>
On 01/14/2010 06:42 PM, Junio C Hamano wrote:
> Eric Blake<ebb9@byu.net> writes:
>
>> Michael Haggerty<mhagger<at> alum.mit.edu> writes:
>>
>>> current_sha1=$(git rev-parse --verify HEAD)
>>> - if test "$no_ff$current_sha1" = "$parent_sha1"; then
>>> + if test -z "$no_ff" -a "$current_sha1" = "$parent_sha1"
>>
>> 'test cond1 -a cond2' is not portable. Use 'test cond1&& test cond2'.
>
> I avoid "test -a/-o" myself without even thinking (I am from old-school),
> but at the same time I thought the progress in the world made such caution
> obsolescent.
>
> Not so. Even though POSIX.1 lists -a/-o as options to "test", they are
> marked "Obsolescent XSI" ("Strictly Conforming POSIX Applications and
> Strictly Conforming XSI Applications shall not use obsolescent features").
The reason for this is that the precedence rules were never well
specified, and this made many sane-looking uses of "test -a/-o" problematic.
For example, if $x is "=", these work according to POSIX (it's not
portable, but in practice it's okay):
$ test -z "$x"
$ test -z "$x" && test a = b
but this doesn't
$ test -z "$x" -a a = b
bash: test: too many arguments
because it groups "test -n = -a" and is left with "a = b".
Similarly, if $x is "-f", these
$ test "$x"
$ test "$x" || test c = d
correctly adds an implicit "-n", but this fails:
$ test "$x" -o c = d
bash: test: too many arguments
If anybody cleans up git's usage of test -a/-o, feel free to cut'n'paste
the above into the commit messages.
Paolo
^ permalink raw reply
* [PATCH 3/3] difftool: Use eval to expand '--extcmd' expressions
From: David Aguilar @ 2010-01-15 7:16 UTC (permalink / raw)
To: gitster; +Cc: git
In-Reply-To: <1263539762-8269-1-git-send-email-davvid@gmail.com>
It was not possible to pass quoted commands to '--extcmd'.
By using 'eval' we ensure that expressions with spaces and
quotes are supported.
Signed-off-by: David Aguilar <davvid@gmail.com>
---
git-difftool--helper.sh | 3 +--
t/t7800-difftool.sh | 13 +++++++++++++
2 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/git-difftool--helper.sh b/git-difftool--helper.sh
index d806eae..a1c5c09 100755
--- a/git-difftool--helper.sh
+++ b/git-difftool--helper.sh
@@ -48,11 +48,10 @@ launch_merge_tool () {
fi
if use_ext_cmd; then
- $GIT_DIFFTOOL_EXTCMD "$LOCAL" "$REMOTE"
+ (eval $GIT_DIFFTOOL_EXTCMD "\"$LOCAL\"" "\"$REMOTE\"")
else
run_merge_tool "$merge_tool"
fi
-
}
if ! use_ext_cmd; then
diff --git a/t/t7800-difftool.sh b/t/t7800-difftool.sh
index 69e1c34..a183f1d 100755
--- a/t/t7800-difftool.sh
+++ b/t/t7800-difftool.sh
@@ -235,8 +235,21 @@ test_expect_success 'difftool --extcmd cat' '
test_expect_success 'difftool -x cat' '
diff=$(git difftool --no-prompt -x cat branch) &&
test "$diff" = branch"$LF"master
+'
+
+test_expect_success 'difftool --extcmd echo arg1' '
+ diff=$(git difftool --no-prompt --extcmd sh\ -c\ \"echo\ \$1\" branch)
+ test "$diff" = file
+'
+test_expect_success 'difftool --extcmd cat arg1' '
+ diff=$(git difftool --no-prompt --extcmd sh\ -c\ \"cat\ \$1\" branch)
+ test "$diff" = master
+'
+test_expect_success 'difftool --extcmd cat arg2' '
+ diff=$(git difftool --no-prompt --extcmd sh\ -c\ \"cat\ \$2\" branch)
+ test "$diff" = branch
'
test_done
--
1.6.6.6.g627fb.dirty
^ permalink raw reply related
* [PATCH 2/3] difftool: Add '-x' and as an alias for '--extcmd'
From: David Aguilar @ 2010-01-15 7:16 UTC (permalink / raw)
To: gitster; +Cc: git
In-Reply-To: <1263539762-8269-1-git-send-email-davvid@gmail.com>
This adds '-x' as a shorthand for the '--extcmd' option.
Arguments to '--extcmd' can be specified separately, which
was not originally possible.
This also fixes the brief help text so that it mentions
both '-x' and '--extcmd'.
Signed-off-by: David Aguilar <davvid@gmail.com>
---
Documentation/git-difftool.txt | 3 ++-
git-difftool.perl | 21 ++++++++++++++-------
t/t7800-difftool.sh | 8 ++++++++
3 files changed, 24 insertions(+), 8 deletions(-)
diff --git a/Documentation/git-difftool.txt b/Documentation/git-difftool.txt
index f67d2db..5c68cff 100644
--- a/Documentation/git-difftool.txt
+++ b/Documentation/git-difftool.txt
@@ -7,7 +7,7 @@ git-difftool - Show changes using common diff tools
SYNOPSIS
--------
-'git difftool' [--tool=<tool>] [-y|--no-prompt|--prompt] [<'git diff' options>]
+'git difftool' [<options>] <commit>{0,2} [--] [<path>...]
DESCRIPTION
-----------
@@ -58,6 +58,7 @@ is set to the name of the temporary file containing the contents
of the diff post-image. `$BASE` is provided for compatibility
with custom merge tool commands and has the same value as `$LOCAL`.
+-x <command>::
--extcmd=<command>::
Specify a custom command for viewing diffs.
'git-difftool' ignores the configured defaults and runs
diff --git a/git-difftool.perl b/git-difftool.perl
index f8ff245..d639de3 100755
--- a/git-difftool.perl
+++ b/git-difftool.perl
@@ -1,5 +1,5 @@
#!/usr/bin/env perl
-# Copyright (c) 2009 David Aguilar
+# Copyright (c) 2009-2010 David Aguilar
#
# This is a wrapper around the GIT_EXTERNAL_DIFF-compatible
# git-difftool--helper script.
@@ -23,8 +23,9 @@ my $DIR = abs_path(dirname($0));
sub usage
{
print << 'USAGE';
-usage: git difftool [-g|--gui] [-t|--tool=<tool>] [-y|--no-prompt]
- ["git diff" options]
+usage: git difftool [-t|--tool=<tool>] [-x|--extcmd=<cmd>]
+ [-y|--no-prompt] [-g|--gui]
+ ['git diff' options]
USAGE
exit 1;
}
@@ -62,14 +63,20 @@ sub generate_command
$skip_next = 1;
next;
}
- if ($arg =~ /^--extcmd=/) {
- $ENV{GIT_DIFFTOOL_EXTCMD} = substr($arg, 9);
- next;
- }
if ($arg =~ /^--tool=/) {
$ENV{GIT_DIFF_TOOL} = substr($arg, 7);
next;
}
+ if ($arg eq '-x' || $arg eq '--extcmd') {
+ usage() if $#ARGV <= $idx;
+ $ENV{GIT_DIFFTOOL_EXTCMD} = $ARGV[$idx + 1];
+ $skip_next = 1;
+ next;
+ }
+ if ($arg =~ /^--extcmd=/) {
+ $ENV{GIT_DIFFTOOL_EXTCMD} = substr($arg, 9);
+ next;
+ }
if ($arg eq '-g' || $arg eq '--gui') {
my $tool = Git::command_oneline('config',
'diff.guitool');
diff --git a/t/t7800-difftool.sh b/t/t7800-difftool.sh
index 1d9e07b..69e1c34 100755
--- a/t/t7800-difftool.sh
+++ b/t/t7800-difftool.sh
@@ -225,8 +225,16 @@ test_expect_success 'difftool.<tool>.path' '
test_expect_success 'difftool --extcmd=cat' '
diff=$(git difftool --no-prompt --extcmd=cat branch) &&
test "$diff" = branch"$LF"master
+'
+test_expect_success 'difftool --extcmd cat' '
+ diff=$(git difftool --no-prompt --extcmd cat branch) &&
+ test "$diff" = branch"$LF"master
+'
+test_expect_success 'difftool -x cat' '
+ diff=$(git difftool --no-prompt -x cat branch) &&
+ test "$diff" = branch"$LF"master
'
--
1.6.6.6.g627fb.dirty
^ permalink raw reply related
* [PATCH 1/3] t7800-difftool.sh: Simplify the --extcmd test
From: David Aguilar @ 2010-01-15 7:16 UTC (permalink / raw)
To: gitster; +Cc: git
Instead of running 'grep', 'echo', and 'wc' we simply compare
git-difftool's output against a known good value.
Signed-off-by: David Aguilar <davvid@gmail.com>
---
t/t7800-difftool.sh | 13 +++++--------
1 files changed, 5 insertions(+), 8 deletions(-)
diff --git a/t/t7800-difftool.sh b/t/t7800-difftool.sh
index 8ee186a..1d9e07b 100755
--- a/t/t7800-difftool.sh
+++ b/t/t7800-difftool.sh
@@ -15,6 +15,9 @@ if ! test_have_prereq PERL; then
test_done
fi
+LF='
+'
+
remove_config_vars()
{
# Unset all config variables used by git-difftool
@@ -219,19 +222,13 @@ test_expect_success 'difftool.<tool>.path' '
restore_test_defaults
'
-test_expect_success 'difftool --extcmd=...' '
+test_expect_success 'difftool --extcmd=cat' '
diff=$(git difftool --no-prompt --extcmd=cat branch) &&
+ test "$diff" = branch"$LF"master
- lines=$(echo "$diff" | wc -l) &&
- test "$lines" -eq 2 &&
- lines=$(echo "$diff" | grep master | wc -l) &&
- test "$lines" -eq 1 &&
- lines=$(echo "$diff" | grep branch | wc -l) &&
- test "$lines" -eq 1 &&
- restore_test_defaults
'
test_done
--
1.6.6.6.g627fb.dirty
^ permalink raw reply related
* [PATCH v2] Test t5560: Fix test when run with dash
From: Tarmigan Casebolt @ 2010-01-15 6:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Michael Haggerty, git, Shawn O. Pearce, Tarmigan Casebolt
In-Reply-To: <7vfx69hyd5.fsf@alter.siamese.dyndns.org>
The dash shell is more finicky than some others.
In particular, it does not seem to like the pattern of setting an
environment variable on the same line as you call a shell function
like this:
REQUEST_METHOD="GET" some_shell_function
as you might use to set a variable only for one command if that
command were an executable or a shell builtin.
Reported-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Tarmigan Casebolt <tarmigan+git@gmail.com>
---
Junio, that description matches my understanding of the problem.
I can't tell from my reading of the POSIX spec whether my usage was
wrong or if dash is wrong, which is why I shied away from an
explanation. As a practical matter though, this patch does fix the
issue.
This version takes a slighty different approach that I think leaves
things clearer and doesn't pass in tons of arguements to the shell
function. If you prefer the old approach, I can send a patch that way
instead.
---
t/t5560-http-backend-noserver.sh | 15 ++++++++++-----
1 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/t/t5560-http-backend-noserver.sh b/t/t5560-http-backend-noserver.sh
index 5f8c88e..44885b8 100755
--- a/t/t5560-http-backend-noserver.sh
+++ b/t/t5560-http-backend-noserver.sh
@@ -14,8 +14,9 @@ run_backend() {
}
GET() {
- REQUEST_METHOD="GET" \
+ export REQUEST_METHOD="GET" &&
run_backend "/repo.git/$1" &&
+ unset REQUEST_METHOD &&
if ! grep "Status" act.out >act
then
printf "Status: 200 OK\r\n" >act
@@ -25,9 +26,11 @@ GET() {
}
POST() {
- REQUEST_METHOD="POST" \
- CONTENT_TYPE="application/x-$1-request" \
+ export REQUEST_METHOD="POST" &&
+ export CONTENT_TYPE="application/x-$1-request" &&
run_backend "/repo.git/$1" "$2" &&
+ unset REQUEST_METHOD &&
+ unset CONTENT_TYPE &&
if ! grep "Status" act.out >act
then
printf "Status: 200 OK\r\n" >act
@@ -43,13 +46,15 @@ log_div() {
. "$TEST_DIRECTORY"/t556x_common
expect_aliased() {
+ export REQUEST_METHOD="GET" &&
if test $1 = 0; then
- REQUEST_METHOD=GET run_backend "$2"
+ run_backend "$2"
else
- REQUEST_METHOD=GET run_backend "$2" &&
+ run_backend "$2" &&
echo "fatal: '$2': aliased" >exp.err &&
test_cmp exp.err act.err
fi
+ unset REQUEST_METHOD
}
test_expect_success 'http-backend blocks bad PATH_INFO' '
--
1.6.6
^ permalink raw reply related
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