* Re: Possible bug: "git log" ignores "--encoding=UTF-8" option if --pretty=format:%e%n%s%n is used
From: Jeff King @ 2008-11-13 5:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Constantine Plotnikov, git
In-Reply-To: <7vod0ki531.fsf@gitster.siamese.dyndns.org>
On Wed, Nov 12, 2008 at 09:10:26PM -0800, Junio C Hamano wrote:
> > What about "git rev-list --pretty=raw"? Is that also porcelain?
>
> Does it re-encode? I didn't check, but ideally it shouldn't (but I do not
> care too much either way, to be honest).
Yes, it uses the same pretty_print_commit routine as the "log".
> > I would be curious to hear your take on our failure to respect
> > --encoding for --pretty=format. Is it a bug to be fixed, or a historical
> > behavior to be maintained?
>
> I think the fix you outlined was quite reasonable.
One thing I just realized that makes it even more reasonable: we
properly munge the encoding header when we _do_ re-encode. So whether we
re-encode or not, you will always get the correct encoding for what is
being output via "%e". Which means that a tool which handles the current
"broken" behavior by re-encoding themselves will trivially handle the
new version: the output will just always be in the --encoding specified
instead of whatever the original encoding was.
And if there are tools that are not looking at the output encoding (and
blindly assuming --encoding works), then they are already broken by the
current behavior, and we will be fixing them.
So I think it is safe to "fix" it as I described.
-Peff
^ permalink raw reply
* Re: [RFC PATCH 0/4] deny push to current branch of non-bare repo
From: Jeff King @ 2008-11-13 5:37 UTC (permalink / raw)
To: Kyle Moffett; +Cc: Junio C Hamano, git, Sam Vilain
In-Reply-To: <f73f7ab80811122122i4ae3ba6dn2ceb314b86660a70@mail.gmail.com>
On Thu, Nov 13, 2008 at 12:22:20AM -0500, Kyle Moffett wrote:
> somebody to push something for me to test, they push directly to that
> repo, and when I'm done playing with a previous run I just do:
>
> $ git checkout new/branch/to/test
> $ make clean
> $ ./configure
> $ make
> $ make check
OK, I see how using a detached HEAD makes sense. But I think just going
straight to a detached HEAD might make even more sense. With your
proposed behavior, you need to be prepared to unexpectedly and
asynchronously move to a detached HEAD at any time, so why not just
start there in the first place?
And then the "push to current branch" problem is neatly solved: you have
no current branch.
So:
$ git checkout new/branch/to/test^0
$ make, configure, etc
-Peff
^ permalink raw reply
* Re: [RFC PATCH 0/4] deny push to current branch of non-bare repo
From: Kyle Moffett @ 2008-11-13 5:22 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git, Sam Vilain
In-Reply-To: <20081112084412.GA3860@coredump.intra.peff.net>
On Wed, Nov 12, 2008 at 3:44 AM, Jeff King <peff@peff.net> wrote:
> On Tue, Nov 11, 2008 at 07:44:06PM -0500, Kyle Moffett wrote:
>> Hmm, I wonder if it would be possible to also add a "detach" variant;
>> which would create a detached-HEAD at the current commit when
>> automatically receiving a push to the working branch. I have a
>> post-receive script that does so right now on a couple repositories.
>> It's still a little confusing to someone actively working in the
>> repository being pushed to, but it's much easier to explain than the
>> current default behavior.
>
> A neat idea, but I'm not sure what workflow that is meant to support.
Basically, I have a remote tree on a fast multicore box used for runs
of a test suite on various peoples different branches. When I want
somebody to push something for me to test, they push directly to that
repo, and when I'm done playing with a previous run I just do:
$ git checkout new/branch/to/test
$ make clean
$ ./configure
$ make
$ make check
Occasionally I notice a bug which I want to temporarily fix to let the
build continue, even though I will need to have the author merge that
fix as a part of his original buggy patch. If nobody pushes the
branch I'm currently testing again, I can "git diff" just fine to see
what I had to fix. If somebody pushes to a different branch than the
one I'm testing, it's also fine. The inconsistency is pushing to the
branch I'm on.
So it would be handy to be able to mark that repository as
"detach-HEAD-on-push-of-current-branch", which would let me remember
where I was, even if that's not where that branch is anymore.
There are other ways I could probably do something very similar, but
since the config option was being added it seemed it would probably be
easy to extend. If nobody else is interested in that behavior, I will
just keep maintaining my own hook, but I thought I'd mention it.
Cheers,
Kyle Moffett
^ permalink raw reply
* Re: Possible bug: "git log" ignores "--encoding=UTF-8" option if --pretty=format:%e%n%s%n is used
From: Junio C Hamano @ 2008-11-13 5:10 UTC (permalink / raw)
To: Jeff King; +Cc: Constantine Plotnikov, git
In-Reply-To: <20081113043454.GA5048@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> What about "git rev-list --pretty=raw"? Is that also porcelain?
Does it re-encode? I didn't check, but ideally it shouldn't (but I do not
care too much either way, to be honest).
> I would be curious to hear your take on our failure to respect
> --encoding for --pretty=format. Is it a bug to be fixed, or a historical
> behavior to be maintained?
I think the fix you outlined was quite reasonable.
^ permalink raw reply
* Re: Possible bug: "git log" ignores "--encoding=UTF-8" option if --pretty=format:%e%n%s%n is used
From: Jeff King @ 2008-11-13 4:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Constantine Plotnikov, git
In-Reply-To: <7vvdusjtg8.fsf@gitster.siamese.dyndns.org>
On Wed, Nov 12, 2008 at 05:38:47PM -0800, Junio C Hamano wrote:
> > BTW for some reason --pretty=raw is affected by encoding option on the
> > command line.
>
> Unfortunately, that is what you get for reading from a Porcelain output,
> which is meant for, and are subject to improvement for, human consumption.
>
> If you want bit-for-bit information, you can always ask "git cat-file".
What about "git rev-list --pretty=raw"? Is that also porcelain?
I would be curious to hear your take on our failure to respect
--encoding for --pretty=format. Is it a bug to be fixed, or a historical
behavior to be maintained?
-Peff
^ permalink raw reply
* Re: running out of memory when doing a clone of a large repository?
From: Nicolas Pitre @ 2008-11-13 3:22 UTC (permalink / raw)
To: Paul E. Rybski; +Cc: git
In-Reply-To: <491B2550.1050005@cs.cmu.edu>
On Wed, 12 Nov 2008, Paul E. Rybski wrote:
> Hi,
> I've recently started evaluating git for use on one of my projects. I
> used git-svn to convert a fairly large subversion repository and one of
> its branches into two separate git repositories following the
> instructions found here:
>
> http://www.simplisticcomplexity.com/2008/03/05/cleanly-migrate-your-subversion-repository-to-a-git-repository/
>
> From that, I created a 1.5G repository from the trunk of the subversion
> repo and a 1.1G repository from one of the branches. I then tried to
> clone the repositories from one machine to another via ssh and the
> smaller 1.1G repository of the subversion branch (with 1932 commits)
> came over just fine but the larger 1.5G repository of the subversion
> trunk (5865 commits) died with the following error:
>
> remote: Counting objects: 48415, done.
> remote: warning: suboptimal pack - out of memory
> error: git-upload-pack: git-pack-objects died with error.
> fatal: git-upload-pack: aborting due to possible repository corruption
> on the remote side.
> remote: aborting due to possible repository corruption on the remote side.
> fatal: early EOF
> fatal: index-pack failed
>
> Is this simply because the git repository is too large for the machine
> that's trying to send it over ssh?
Possibly.
> Is there a way to restrict the memory usage of git or do I need to get
> more RAM or somehow not import the full subversion history of my
> original trunk?
It is possible that the inport from svn didn't produce a fully packed
repository. Try a "git repack -a -f -d" on the server machine. If you
get the same out-of-memory problem then ideally you should copy the
whole directory to a bigger machine and run 'git repack -a -f -d" there.
Then you may copy it back to the small machine and subsequent clone
requests should be just fine.
You could also investigate the pack.windowMemory configuration variable
on the server side. If you have lots of big files then setting this to
64m for example may help.
> I'm using Ubuntu 8.04.1 on both machines and using the Ubuntu packages
> of git version 1.5.4.3.
There was a bug in versions prior to v1.5.6.4 affecting memory usage.
Upgrading to this version or later on the server machine might help too.
> The machine holding the repository is a 5-year
> old AthlonXP 3200 with 1G RAM and 32-bit Ubuntu. The machine I'm
> cloning the repository on is a more recent Intel Dual Core Quad Q6600
> with 4GRAM and 64-bit Ubuntu.
>
> Any advice would be greatly appreciated.
>
> Thanks!
>
> -Paul
>
> --
> Paul E. Rybski, Ph.D., Systems Scientist
> The Robotics Institute, Carnegie Mellon University
> Phone: 412-268-7417, Fax: 412-268-7350
> Web: http://www.cs.cmu.edu/~prybski
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
Nicolas
^ permalink raw reply
* Re: [PATCH v2] Edit recipient addresses with the --compose flag
From: Junio C Hamano @ 2008-11-13 3:18 UTC (permalink / raw)
To: Ian Hilt; +Cc: Git Mailing List, Pierre Habouzit
In-Reply-To: <1226544602-1839-1-git-send-email-ian.hilt@gmx.com>
Ian Hilt <ian.hilt@gmx.com> writes:
> Sometimes specifying the recipient addresses can be tedious on the
> command-line. This commit allows the user to edit the recipient
> addresses in their editor of choice.
>
> Signed-off-by: Ian Hilt <ian.hilt@gmx.com>
> ---
> Here's an updated commit with improved regex's from Junio and Francis.
This heavily depends on Pierre's patch, so I am CC'ing him for comments.
Until his series settles down, I cannot apply this anyway.
> @@ -489,6 +492,9 @@ GIT: for the patch you are writing.
> GIT:
> GIT: Clear the body content if you don't wish to send a summary.
> From: $tpl_sender
> +To: $tpl_to
> +Cc: $tpl_cc
> +Bcc: $tpl_bcc
> Subject: $tpl_subject
> In-Reply-To: $tpl_reply_to
>
> @@ -512,9 +518,31 @@ EOT
> open(C,"<",$compose_filename)
> or die "Failed to open $compose_filename : " . $!;
>
> + local $/;
> + my $c_file = <C>;
> + $/ = "\n";
> + close(C);
> +
> + my (@tmp_to, @tmp_cc, @tmp_bcc);
> +
> + if ($c_file =~ /^To:\s*(\S.+?)\s*\nCc:/ism) {
> + @tmp_to = get_recipients($1);
> + }
Why "\S.+?" and not "\S.*?"? A local user whose login name is 'q' is
disallowed?
Why does the user must keep "Cc:" in order for this new code to pick up
the list of recipients? In other words, you are forbidding the user from
removing the entire "Cc:" line, even when the message should not be Cc'ed
to anywhere. Instead there has to remain an empty Cc: line. Worse yet,
such an empty "Cc:" line is printed to C2 with your patch and eventually
fed to sendmail. I think it is a violation of 2822 to have Cc: that is
empty, as the format is specified as:
cc = "Cc:" address-list CRLF
bcc = "Bcc:" (address-list / [CFWS]) CRLF
address-list = (address *("," address)) / obs-addr-list
> + if ($c_file =~ /^Cc:\s*(\S.+?)\s*\nBcc:/ism) {
> + @tmp_cc = get_recipients($1);
> + }
> + if ($c_file =~ /^Bcc:\s*(\S.+?)\s*\nSubject:/ism) {
> + @tmp_bcc = get_recipients($1);
> + }
Exactly the same comment applies to Bcc and Subject part of the parsing.
I think the parsing code you introduced simply suck. Why isn't it done as
a part of the main loop to read the same file that already exists?
Unlike your additional code above that reads the whole file into a scalar
only to discard, the existing main loop processes one line at a file
(which should be more memory efficient), and you are not handling the
header continuation line anyway, processing one line at a time would make
your code much simpler (for one thing, you do not have to do /sm at all).
Also it won't be confused as your version would if the message happens to
have "To:" or "Cc:" in the message part, thanks to $in_body variable check
that is already in the code.
^ permalink raw reply
* [PATCH v2] Edit recipient addresses with the --compose flag
From: Ian Hilt @ 2008-11-13 2:50 UTC (permalink / raw)
To: Git Mailing List
Sometimes specifying the recipient addresses can be tedious on the
command-line. This commit allows the user to edit the recipient
addresses in their editor of choice.
Signed-off-by: Ian Hilt <ian.hilt@gmx.com>
---
Here's an updated commit with improved regex's from Junio and Francis.
git-send-email.perl | 47 ++++++++++++++++++++++++++++++++++++++++++++---
1 files changed, 44 insertions(+), 3 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index 9039cfd..4d8aaa7 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -480,6 +480,9 @@ if ($compose) {
my $tpl_sender = $sender || $repoauthor || $repocommitter || '';
my $tpl_subject = $initial_subject || '';
my $tpl_reply_to = $initial_reply_to || '';
+ my $tpl_to = join(', ', @to);
+ my $tpl_cc = join(', ', @initial_cc);
+ my $tpl_bcc = join(', ', @bcclist);
print C <<EOT;
From $tpl_sender # This line is ignored.
@@ -489,6 +492,9 @@ GIT: for the patch you are writing.
GIT:
GIT: Clear the body content if you don't wish to send a summary.
From: $tpl_sender
+To: $tpl_to
+Cc: $tpl_cc
+Bcc: $tpl_bcc
Subject: $tpl_subject
In-Reply-To: $tpl_reply_to
@@ -512,9 +518,31 @@ EOT
open(C,"<",$compose_filename)
or die "Failed to open $compose_filename : " . $!;
+ local $/;
+ my $c_file = <C>;
+ $/ = "\n";
+ close(C);
+
+ my (@tmp_to, @tmp_cc, @tmp_bcc);
+
+ if ($c_file =~ /^To:\s*(\S.+?)\s*\nCc:/ism) {
+ @tmp_to = get_recipients($1);
+ }
+ if ($c_file =~ /^Cc:\s*(\S.+?)\s*\nBcc:/ism) {
+ @tmp_cc = get_recipients($1);
+ }
+ if ($c_file =~ /^Bcc:\s*(\S.+?)\s*\nSubject:/ism) {
+ @tmp_bcc = get_recipients($1);
+ }
+
+
my $need_8bit_cte = file_has_nonascii($compose_filename);
my $in_body = 0;
my $summary_empty = 1;
+
+ open(C,"<",$compose_filename)
+ or die "Failed to open $compose_filename : " . $!;
+
while(<C>) {
next if m/^GIT: /;
if ($in_body) {
@@ -543,15 +571,21 @@ EOT
} elsif (/^From:\s*(.+)\s*$/i) {
$sender = $1;
next;
- } elsif (/^(?:To|Cc|Bcc):/i) {
- print "To/Cc/Bcc fields are not interpreted yet, they have been ignored\n";
- next;
}
print C2 $_;
}
close(C);
close(C2);
+ if (@tmp_to) {
+ @to = @tmp_to;
+ }
+ if (@tmp_cc) {
+ @initial_cc = @tmp_cc;
+ }
+ if (@tmp_bcc) {
+ @bcclist = @tmp_bcc;
+ }
if ($summary_empty) {
print "Summary email is empty, skipping it\n";
$compose = -1;
@@ -1095,3 +1129,10 @@ sub file_has_nonascii {
}
return 0;
}
+
+sub get_recipients {
+ my $match = shift(@_);
+ my @recipients = split(/\s*,\s*(?![^"]+(?:\"[^*]*)*")/, $match);
+
+ return @recipients;
+}
--
1.6.0.3.523.g304d0
^ permalink raw reply related
* What's in git.git (Nov 2008, #02; Wed, 12)
From: Junio C Hamano @ 2008-11-13 2:16 UTC (permalink / raw)
To: git
The last maintenance release 1.6.0.4 was released a few days ago. There
are a few fixes already on 'maint', and also a handful more fixes cooking
in 'next', for 1.6.0.5.
I'd like to start closing the cycle for 1.6.1 by declaring -rc0 by the end
of this week. In early next month, hopefully -rc1 can contain everything
we have in 'next' tonight, plus a handful more topics that are currently
parked in 'pu'.
* The 'maint' branch has these fixes since the last announcement.
Alex Riesen (7):
Add mksnpath which allows you to specify the output buffer
Fix mkpath abuse in dwim_ref and dwim_log of sha1_name.c
Fix potentially dangerous uses of mkpath and git_path
Add git_snpath: a .git path formatting routine with output buffer
Fix potentially dangerous use of git_path in ref.c
git_pathdup: returns xstrdup-ed copy of the formatted path
Use git_pathdup instead of xstrdup(git_path(...))
Alexandre Julliard (2):
checkout: Don't crash when switching away from an invalid branch.
git-submodule: Avoid printing a spurious message.
Christian Couder (2):
Documentation: rev-list: change a few instances of "git-cmd" to "git cmd"
Documentation: bisect: change a few instances of "git-cmd" to "git cmd"
Christian Jaeger (1):
Git.pm: do not break inheritance
Clemens Buchacher (2):
do not force write of packed refs
push: fix local refs update if already up-to-date
Daniel Lowe (1):
Fix non-literal format in printf-style calls
Jeff King (1):
refactor handling of "other" files in ls-files and status
Johannes Schindelin (1):
Fix fetch/pull when run without --update-head-ok
Junio C Hamano (11):
pull: allow "git pull origin $something:$current_branch" into an unborn
branch
Fix "checkout --track -b newbranch" on detached HEAD
reset --hard/read-tree --reset -u: remove unmerged new paths
demonstrate breakage of detached checkout with symbolic link HEAD
Enhance hold_lock_file_for_{update,append}() API
Update draft 1.6.0.4 release notes
format-patch documentation: mention the special case of showing a single
commit
GIT 1.6.0.4
Makefile: help people who run 'make check' by mistake
checkout: Fix "initial checkout" detection
Start 1.6.0.5 cycle
Matt Kraai (1):
Remove the period after the git-check-attr summary
Mikael Magnusson (1):
Document that git-log takes --all-match.
Miklos Vajna (5):
Fix git branch -m for symrefs.
rename_ref(): handle the case when the reflog of a ref does not exist
Fix git update-ref --no-deref -d.
git branch -m: forbid renaming of a symref
update-ref --no-deref -d: handle the case when the pointed ref is packed
Nicolas Pitre (1):
Fix pack.packSizeLimit and --max-pack-size handling
Quy Tonthat (1):
Update RPM spec for the new location of git-cvsserver.
Stefan Naewe (1):
git ls-remote: make usage string match manpage
Yann Dirson (1):
Add reference for status letters in documentation.
* The 'master' branch has these since the last announcement
in addition to the above.
Alex Riesen (1):
Fix potentially dangerous uses of mkpath and git_path
Alexander Gavrilov (5):
builtin-blame: Reencode commit messages according to git-log rules.
Windows: Make OpenSSH properly detect tty detachment.
gitweb: Use single implementation of export_ok check.
gitweb: Add a per-repository authorization hook.
gitweb: Fix mod_perl support.
Brian Downing (2):
Always initialize xpparam_t to 0
Allow alternate "low-level" emit function from xdl_diff
Christian Couder (1):
bisect: fix missing "exit"
Daniel Lowe (1):
Fix non-literal format in printf-style calls
David M. Syzdek (1):
autoconf: Add link tests to each AC_CHECK_FUNC() test
David Symonds (1):
git-diff: Add --staged as a synonym for --cached.
Giuseppe Bilotta (5):
gitweb: parse project/action/hash_base:filename PATH_INFO
gitweb: generate project/action/hash URLs
gitweb: use_pathinfo filenames start with /
gitweb: parse parent..current syntax from PATH_INFO
gitweb: generate parent..current URLs
Jeff King (1):
t5400: expect success for denying deletion
John Chapman (2):
git-p4: Support purged files and optimize memory usage
git-p4: Cache git config for performance
Junio C Hamano (6):
Fix reading of cloud tags
rebase-i-p: minimum fix to obvious issues
git-rebase--interactive.sh: comparision with == is bashism
Update draft release notes to 1.6.1
Update draft release notes to 1.6.1
git.html: Update the links to stale versions
Markus Heidelberg (1):
Makefile: add install-man rules (quick and normal)
Miklos Vajna (1):
parse-opt: migrate builtin-checkout-index.
Nicolas Pitre (5):
index-pack: rationalize delta resolution code
index-pack: smarter memory usage during delta resolution
fix multiple issues in index-pack
improve index-pack tests
index-pack: don't leak leaf delta result
Pete Harlan (2):
contrib/hooks/post-receive-email: Put rev display in separate function
contrib/hooks/post-receive-email: Make revision display configurable
René Scharfe (3):
blame: inline get_patch()
add xdi_diff_hunks() for callers that only need hunk lengths
blame: use xdi_diff_hunks(), get rid of struct patch
Stephen Haberman (7):
rebase-i-p: test to exclude commits from todo based on its parents
rebase-i-p: use HEAD for updating the ref instead of mapping OLDHEAD
rebase-i-p: delay saving current-commit to REWRITTEN if squashing
rebase-i-p: fix 'no squashing merges' tripping up non-merges
rebase-i-p: only list commits that require rewriting in todo
rebase-i-p: do not include non-first-parent commits touching UPSTREAM
rebase-i-p: if todo was reordered use HEAD as the rewritten parent
^ permalink raw reply
* What's cooking in git.git (Nov 2008, #04; Wed, 12)
From: Junio C Hamano @ 2008-11-13 2:16 UTC (permalink / raw)
To: git
Here are the topics that have been cooking. Commits prefixed
with '-' are only in 'pu' while commits prefixed with '+' are
in 'next'.
The topics list the commits in reverse chronological order. The topics
meant to be merged to the maintenance series have "maint-" in their names.
I think we should declare -rc0 by the end of this week, with the goal of
including everything that are in 'next' as of tonight, plus the "narrow
checkout" and possibly Pierre's send-email that acts as format-patch
frontend, by the time we hit -rc1, perhaps soon after the end of month.
----------------------------------------------------------------
[New Topics]
* mk/maint-cg-push (Mon Nov 10 22:47:11 2008 +0100) 1 commit
+ git push: Interpret $GIT_DIR/branches in a Cogito compatible way
* jk/commit-v-strip (Wed Nov 12 03:23:37 2008 -0500) 5 commits
+ status: show "-v" diff even for initial commit
+ Merge branch 'jk/maint-commit-v-strip' into jk/commit-v-strip
+ commit: Fix stripping of patch in verbose mode.
+ wt-status: refactor initial commit printing
+ define empty tree sha1 as a macro
* jk/maint-commit-v-strip (Wed Nov 12 03:25:52 2008 -0500) 1 commit
+ commit: Fix stripping of patch in verbose mode.
* ph/send-email (Tue Nov 11 00:54:02 2008 +0100) 4 commits
- git send-email: ask less questions when --compose is used.
- git send-email: add --annotate option
- git send-email: interpret unknown files as revision lists
- git send-email: make the message file name more specific.
* nd/rename-cache (Sat Nov 8 18:27:33 2008 +0700) 2 commits
- diffcore-rename: add config option to allow to cache renames
- diffcore-rename: support rename cache
----------------------------------------------------------------
[Will merge to "master" soon]
* jk/deny-push-to-current (Sat Nov 8 20:49:27 2008 -0500) 2 commits
+ receive-pack: detect push to current branch of non-bare repo
+ t5516: refactor oddball tests
* dl/xdiff (Fri Nov 7 21:24:33 2008 -0800) 1 commit
+ xdiff: give up scanning similar lines early
This performance fix may eventually need to be cherry-picked to 'maint'.
* lt/decorate (Wed Nov 12 11:51:28 2008 +0100) 7 commits
+ rev-list documentation: clarify the two parts of history
simplification
+ Document "git log --simplify-by-decoration"
+ Document "git log --source"
+ revision traversal: '--simplify-by-decoration'
+ Make '--decorate' set an explicit 'show_decorations' flag
+ revision: make tree comparison functions take commits rather than
trees
+ Add a 'source' decorator for commits
* gb/gitweb-snapshot-pathinfo (Sun Nov 2 10:21:39 2008 +0100) 3 commits
+ gitweb: embed snapshot format parameter in PATH_INFO
+ gitweb: retrieve snapshot format from PATH_INFO
+ gitweb: make the supported snapshot formats array global
Got sick of waiting for re-Ack.
* jn/gitweb-customlinks (Sun Oct 12 00:02:32 2008 +0200) 1 commit
+ gitweb: Better processing format string in custom links in navbar
Got sick of waiting for some sort of response from Pasky.
* st/tag (Wed Nov 5 00:20:36 2008 +0100) 2 commits
+ tag: Add more tests about mixing incompatible modes and options
+ tag: Check that options are only allowed in the appropriate mode
* ds/uintmax-config (Mon Nov 3 09:14:28 2008 -0900) 5 commits
- autoconf: Enable threaded delta search when pthreads are supported
+ Add autoconf tests for pthreads
+ Make Pthread link flags configurable
+ Add Makefile check for FreeBSD 4.9-SECURITY
+ Build: add NO_UINTMAX_T to support ancient systems
I split the part that unconditionally enable threaded delta search on any
platform on which Pthread library is detected to be available from the
topmost one. Will merge the rest to 'master' soon.
* jk/diff-convfilter (Sun Oct 26 00:50:02 2008 -0400) 8 commits
+ enable textconv for diff in verbose status/commit
+ wt-status: load diff ui config
+ only textconv regular files
+ userdiff: require explicitly allowing textconv
+ refactor userdiff textconv code
+ add userdiff textconv tests
+ document the diff driver textconv feature
+ diff: add missing static declaration
* jk/diff-convfilter-test-fix (Fri Oct 31 01:09:13 2008 -0400) 4 commits
+ Avoid using non-portable `echo -n` in tests.
+ add userdiff textconv tests
+ document the diff driver textconv feature
+ diff: add missing static declaration
An update to the one above.
----------------------------------------------------------------
[Actively Cooking]
* bc/maint-keep-pack (Sun Nov 9 23:59:58 2008 -0600) 9 commits
+ pack-objects: extend --local to mean ignore non-local loose
objects too
+ sha1_file.c: split has_loose_object() into local and non-local
counterparts
+ t7700: demonstrate mishandling of loose objects in an alternate
ODB
+ builtin-gc.c: use new pack_keep bitfield to detect .keep file
existence
+ repack: do not fall back to incremental repacking with [-a|-A]
+ repack: don't repack local objects in packs with .keep file
+ pack-objects: new option --honor-pack-keep
+ packed_git: convert pack_local flag into a bitfield and add
pack_keep
+ t7700: demonstrate mishandling of objects in packs with a .keep
file
A few commits were rewound from 'next' and replaced with new ones.
* np/pack-safer (Sun Nov 9 13:11:06 2008 -0800) 11 commits
+ t5303: fix printf format string for portability
+ t5303: work around printf breakage in dash
+ pack-objects: don't leak pack window reference when splitting
packs
+ extend test coverage for latest pack corruption resilience
improvements
+ pack-objects: allow "fixing" a corrupted pack without a full
repack
+ make find_pack_revindex() aware of the nasty world
+ make check_object() resilient to pack corruptions
+ make packed_object_info() resilient to pack corruptions
+ make unpack_object_header() non fatal
+ better validation on delta base object offsets
+ close another possibility for propagating pack corruption
* mv/remote-rename (Mon Nov 10 21:43:03 2008 +0100) 4 commits
+ git-remote: document the migration feature of the rename
subcommand
+ git-remote rename: migrate from remotes/ and branches/
+ remote: add a new 'origin' variable to the struct
+ Implement git remote rename
* jc/blame (Wed Jun 4 22:58:40 2008 -0700) 2 commits
+ blame: show "previous" information in --porcelain/--incremental
format
+ git-blame: refactor code to emit "porcelain format" output
* nd/narrow (Wed Oct 1 11:04:09 2008 +0700) 9 commits
- grep: skip files outside sparse checkout area
- checkout_entry(): CE_NO_CHECKOUT on checked out entries.
- Prevent diff machinery from examining worktree outside sparse
checkout
- ls-files: Add tests for --sparse and friends
- update-index: add --checkout/--no-checkout to update
CE_NO_CHECKOUT bit
- update-index: refactor mark_valid() in preparation for new options
- ls-files: add options to support sparse checkout
- Introduce CE_NO_CHECKOUT bit
- Extend index to save more flags
Early parts looked Ok; I am trying to find time to review the whole thing
but fixing bugs in topics from other people here and there took almost all
my time this weekend. Not good.
----------------------------------------------------------------
[On Hold]
* jc/send-pack-tell-me-more (Thu Mar 20 00:44:11 2008 -0700) 1 commit
- "git push": tellme-more protocol extension
This seems to have a deadlock during communication between the peers.
Someone needs to pick up this topic and resolve the deadlock before it can
continue.
* jk/renamelimit (Sat May 3 13:58:42 2008 -0700) 1 commit
- diff: enable "too large a rename" warning when -M/-C is explicitly
asked for
This would be the right thing to do for command line use,
but gitk will be hit due to tcl/tk's limitation, so I am holding
this back for now.
^ permalink raw reply
* Re: [PATCH] Doc: Add a simplified help on top of the "History Simplification"
From: Junio C Hamano @ 2008-11-13 2:16 UTC (permalink / raw)
To: Santi Béjar; +Cc: git, Nanako Shiraishi
In-Reply-To: <1226487088-5308-1-git-send-email-santi@agolina.net>
Thanks, will queue.
^ permalink raw reply
* Re: git commit -v does not removes the patch
From: Junio C Hamano @ 2008-11-13 2:15 UTC (permalink / raw)
To: Jeff King; +Cc: Santi Béjar, Git Mailing List
In-Reply-To: <20081112081609.GA3720@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Here's a patch series that at least improves the situation by turning
> off the diff-stripping if we never put in a diff in the first place.
> That way only people who actually _use_ "-v" will have to pay for it.
> It has the fix I sent to Santi earlier, as well as some related
> cleanups.
>
> 1/5: define empty tree sha1 as a macro
> 2/5: wt-status: refactor initial commit printing
> 3/5: status: show "-v" diff even for initial commit
> 4/5: commit: loosen pattern for matching "-v" diff
> 5/5: commit: only strip diff from message in verbose mode
Makes sense. Thanks, will queue for 'master' with minor futzing to lift
minimum fix to 'maint'.
^ permalink raw reply
* Re: [PATCH] Remove the period after the git-check-attr summary
From: Junio C Hamano @ 2008-11-13 2:15 UTC (permalink / raw)
To: Matt Kraai; +Cc: git
In-Reply-To: <1226060815-7548-1-git-send-email-kraai@ftbfs.org>
Matt Kraai <kraai@ftbfs.org> writes:
> The period at the end of the git-check-attr summary causes there to be
> two periods after the summary in the git(1) manual page.
>
> Signed-off-by: Matt Kraai <kraai@ftbfs.org>
Thanks. I think what you wrote after the --- marker is a perfect
justification of this change, so I lifted them up.
^ permalink raw reply
* Re: git integration with monodevelop
From: Miguel de Icaza @ 2008-11-13 1:42 UTC (permalink / raw)
To: Jakub Narebski
Cc: monodevelop-list, Andreas Ericsson, Git Mailing List,
Shawn Pearce
In-Reply-To: <m33ahwio3v.fsf@localhost.localdomain>
> I assume that results of Mono's Google Summer of Code 2008 projects
> to create managed git implementation in C# (git#)[1][2] were not
> very successfull? Taking into account that JGit isn't yet full git
> implementation, after much longer development...
They were a complete disaster, one student was going to focus on the
front-end, the other on the back-end.
Nothing came out of it.
>
> [1] http://code.google.com/soc/2008/mono/appinfo.html?csaid=E6D8A717A88A7632
> [2] http://code.google.com/soc/2008/mono/appinfo.html?csaid=F2E71A4D93E7EF37
>
^ permalink raw reply
* Re: Possible bug: "git log" ignores "--encoding=UTF-8" option if --pretty=format:%e%n%s%n is used
From: Junio C Hamano @ 2008-11-13 1:38 UTC (permalink / raw)
To: Constantine Plotnikov; +Cc: Jeff King, git
In-Reply-To: <85647ef50811120508j5074f892p1e2a95acfae8c0a8@mail.gmail.com>
"Constantine Plotnikov" <constantine.plotnikov@gmail.com> writes:
> BTW for some reason --pretty=raw is affected by encoding option on the
> command line.
Unfortunately, that is what you get for reading from a Porcelain output,
which is meant for, and are subject to improvement for, human consumption.
If you want bit-for-bit information, you can always ask "git cat-file".
^ permalink raw reply
* [PATCH] t7700: test that 'repack -a' packs alternate packed objects
From: Brandon Casey @ 2008-11-13 0:50 UTC (permalink / raw)
To: gitster; +Cc: peff, git, spearce, nico, Brandon Casey
In-Reply-To: <WFmMnhNsYRw3IUD8hZk59At-5jc1rZU5GaB35sb1epRZ6zwd7IMw9V94SQyEliIEyriM4J5j3AM@cipher.nrlssc.navy.mil>
Previously, when 'repack -a' was called and there were no packs in the local
repository without a .keep file, the repack would fall back to calling
pack-objects with '--unpacked --incremental'. This resulted in the created
pack file, if any, to be missing the packed objects in the alternate object
store. Test that this specific case has been fixed.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
---
Here is a test to demonstrate what
[PATCH 5/6] repack: do not fall back to incremental repacking with [-a|-A]
fixes.
This should apply cleanly to next since it includes
a836cfa3 t7700: demonstrate mishandling of loose objects in an alternate ODB
which has a few context lines showing through in the diff below.
-brandon
t/t7700-repack.sh | 16 ++++++++++++++++
1 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/t/t7700-repack.sh b/t/t7700-repack.sh
index 960bff4..3f602ea 100755
--- a/t/t7700-repack.sh
+++ b/t/t7700-repack.sh
@@ -53,5 +53,21 @@ test_expect_success 'loose objects in alternate ODB are not repacked' '
test -z "$found_duplicate_object"
'
+test_expect_success 'packed obs in alt ODB are repacked even when local repo is packless' '
+ mkdir alt_objects/pack
+ mv .git/objects/pack/* alt_objects/pack &&
+ git repack -a &&
+ myidx=$(ls -1 .git/objects/pack/*.idx) &&
+ test -f "$myidx" &&
+ for p in alt_objects/pack/*.idx; do
+ git verify-pack -v $p | sed -n -e "/^[0-9a-f]\{40\}/p"
+ done | while read sha1 rest; do
+ if ! ( git verify-pack -v $myidx | grep "^$sha1" ); then
+ echo "Missing object in local pack: $sha1"
+ return 1
+ fi
+ done
+'
+
test_done
--
1.6.0.3.552.g12334
^ permalink raw reply related
* Re* [take 2] git send-email updates
From: Junio C Hamano @ 2008-11-13 0:01 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: git
In-Reply-To: <7vk5b9x0kj.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Actually, "send-email --format-patch master..fixes Documentation/" may be
> a useful command to send out only documentation fixes. For such a usage,
> Documentation/ should not be taken as a maildir. If we would want to
> support such usage (and I'd say why not), a token can fall into one (or
> two) of three categories:
>
> - can it be a rev?
>
> - is it a tracked path (either blob or a leading dir)?
>
> - is it a file/dir that is not tracked?
>
> The first two would be format-patch candidate. The last one is the
> traditional mail source. Because the latter two are disjoint set, and
> because it does not matter if you have a tracked file 'master' and a
> branch 'master' in your repo (either will be passed to format-patch
> anyway), the actual disambiguity is reduced, but it still is different
> from what you have in your patch, I suspect.
>
> As to options, how about doing this:
>
> --no-format-patch means never ever run format-patch, behave exactly as
> before;
>
> --format-patch means what you have in your patch. guess and favor
> format-patch parameter when ambiguous;
>
> without either option, guess and favor mbox/maildir but still run
> format-patch if remaining parameters and options need to
> (e.g. "send-email my-cover-letter origin/master..master" will find
> my-cover-letter which is not tracked and take it as mbox, and grab
> patches from commits between origin/master..master, and send all of
> them).
This patch on top of your [2/4] illustrates what I had in mind (it also
removes the "print foo" while at it).
git-send-email.perl | 35 +++++++++++++++++++++++++++++++----
1 files changed, 31 insertions(+), 4 deletions(-)
diff --git c/git-send-email.perl w/git-send-email.perl
index 6f5a613..9aa3500 100755
--- c/git-send-email.perl
+++ w/git-send-email.perl
@@ -152,7 +152,7 @@ if ($@) {
# Behavior modification variables
my ($quiet, $dry_run) = (0, 0);
-my $format_patch;
+my $format_patch = 'unspecified';
my $compose_filename = $repo->repo_path() . "/.gitsendemail.msg.$$";
# Variables with corresponding config settings
@@ -243,6 +243,15 @@ unless ($rc) {
usage();
}
+if ($format_patch && $format_patch eq 'unspecified') {
+ # No --format-patch nor --no-format-patch on the command line
+ $format_patch = 0;
+} elsif (!$format_patch) {
+ $format_patch = undef;
+} else {
+ $format_patch = 1;
+}
+
# Now, let's fill any that aren't set in with defaults:
sub read_config {
@@ -374,11 +383,27 @@ if (@alias_files and $aliasfiletype and defined $parse_alias{$aliasfiletype}) {
# returns 1 if the conflict must be solved using it as a format-patch argument
sub check_file_rev_conflict($) {
my $f = shift;
+
+ if (!defined $format_patch) {
+ # The command line explicitly forbids acting as a wrapper
+ return 0;
+ }
+
+ # If it is a tracked path it can't be tracking the e-mails you
+ # are going to send out to describe the change to this repository.
+ eval {
+ $repo->command(['ls-files', '--error-unmatch', $f],
+ { STDERR => 0 });
+ };
+ if (!$@) {
+ return 1;
+ }
+
+ # Can it be interpreted as a rev?
try {
$repo->command('rev-parse', '--verify', '--quiet', $f);
- if (defined($format_patch)) {
- print "foo\n";
- return $format_patch;
+ if ($format_patch) {
+ return 1;
}
die(<<EOF);
File '$f' exists but it could also be the range of commits
@@ -408,6 +433,8 @@ while (my $f = pop @ARGV) {
closedir(DH);
} elsif ((-f $f or -p $f) and !check_file_rev_conflict($f)) {
push @files, $f;
+ } elsif (!defined $format_patch) {
+ die("--no-format-patch was given but $f is not a valid send-email argument");
} else {
push @rev_list_opts, $f;
}
^ permalink raw reply related
* git svn branch
From: yb_Art @ 2008-11-12 23:47 UTC (permalink / raw)
To: git
I'm using the binary from google code on my mac os-x leopard machine,
and it doesn't have git svn branch. How can I work around this
issue? Is there anyway to create a branch on the svn repository using
git?
^ permalink raw reply
* Re: git integration with monodevelop
From: Govind Salinas @ 2008-11-13 0:00 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Git Mailing List, Shawn Pearce, Michael Hutchinson
In-Reply-To: <491AB078.6020208@op5.se>
On Wed, Nov 12, 2008 at 4:31 AM, Andreas Ericsson <ae@op5.se> wrote:
> Andreas Ericsson wrote:
>>
>> Recently, I've started learning C#. More for fun than anything else,
>> but one of the mono core devs sniffed me out and said they've been
>> thinking of porting jgit to C# to get a working IDE integration in
>> monodevelop. Currently, the only option available (with IDE
>> integration anyways) to the poor C# devs is either Microsoft's
>> crappy VSS, or the less crappy but still far from fantastic
>> Subversion.
>>
>> So in an effort to learn C#, I've decided to play along with this
>> (hopefully with some help from the MonoDevelop team), but it seems
>> to me that the best place to start is the fledgling libgit2 and link
>> that with git-sharp. The primary reason for this is ofcourse that I
>> think it'd be a terrible waste to have yet another from-scratch
>> implementation of git in a new language (ruby, java, C#, C...). The
>> secondary reason is that it would be neat to have more OSS projects
>> use my favourite scm.
>>
>> Besides, getting something to rely on libgit2 early on is probably
>> the best way to get more people interested in making development of
>> it proceed rapidly.
>>
>> Thoughts anyone?
>>
>> Please reply-to-all as this goes cross-list
>> (currently, Cc ae@op5.se, spearce@spearce.org, git@vger.kernel.org,
>> m.j.hutchinson@gmail.com, in case monodevelop-list uses reply-to
>> header).
>>
>
> Ouch. Scratch monodevelop-list from that Cc list. It appears to be
> members-only (although not listed as such on their list-server).
>
Hi,
I started working on a C# UI a long time ago but I abandoned it due
to lack of interest from others and time constraints. You are welcome
to take it and build on it if you like. It wraps the C git binaries and the UI
is separate from the "plumbing".
http://repo.or.cz/w/Widgit.git
-Govind
^ permalink raw reply
* Re: git integration with monodevelop
From: Michael Hutchinson @ 2008-11-12 23:56 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: monodevelop-list, Git Mailing List, Shawn Pearce
In-Reply-To: <491AAE6D.8030304@op5.se>
On Wed, Nov 12, 2008 at 5:22 AM, Andreas Ericsson <ae@op5.se> wrote:
> Recently, I've started learning C#. More for fun than anything else,
> but one of the mono core devs sniffed me out and said they've been
> thinking of porting jgit to C# to get a working IDE integration in
> monodevelop. Currently, the only option available (with IDE
> integration anyways) to the poor C# devs is either Microsoft's
> crappy VSS, or the less crappy but still far from fantastic
> Subversion.
I'm glad you're interested :-)
We do have an interface in MD for integrating VCS providers, and
although the only existing one is SVN, I believe some users are
working on bzr and perforce addins. I'd prefer to see git get
established as the default (D)VCS ...
Currently, to implement a VCS provider one needs to subclass
VersionControlSystem, as demonstrated by the SVN provider:
http://anonsvn.mono-project.com/viewvc/trunk/monodevelop/main/src/addins/VersionControl/MonoDevelop.VersionControl.Subversion/MonoDevelop.VersionControl.Subversion.addin.xml?view=markup.
We may need to extend the interfaces in order to expose more
DVCS-specific features, but I think it's best to find and fix these as
needed rather than speculatively implementing things.
> So in an effort to learn C#, I've decided to play along with this
> (hopefully with some help from the MonoDevelop team), but it seems
> to me that the best place to start is the fledgling libgit2 and link
> that with git-sharp. The primary reason for this is ofcourse that I
> think it'd be a terrible waste to have yet another from-scratch
> implementation of git in a new language (ruby, java, C#, C...). The
> secondary reason is that it would be neat to have more OSS projects
> use my favourite scm.
That's actually one of the reasons we'd like a full managed
implementation --it'd be trivial to include to with cross-platform
Mono-based apps without worrying about architecture, C dependencies,
etc. For example, Tomboy could use git to store its notes, so users
would have a versioned history and better synch/merge. Then, for
example, you could build a Silverlight version that would have full
history in local storage.
> Besides, getting something to rely on libgit2 early on is probably
> the best way to get more people interested in making development of
> it proceed rapidly.
>
> Thoughts anyone?
I hadn't heard of libgit2 (it looks pretty recent) but it looks
interesting -- at least stable APIs would no longer be a worry.
However, I think fully managed is the way to go, from the point of
view of much easier dependencies (on windows, mac, silverlight and
older linux distros) and licensing.
--
Michael Hutchinson
http://mjhutchinson.com
^ permalink raw reply
* Re: [PATCH] git-diff: Add --staged as a synonym for --cached.
From: Junio C Hamano @ 2008-11-12 23:42 UTC (permalink / raw)
To: Avery Pennarun
Cc: Junio C Hamano, Jeff King, Johannes Schindelin,
Björn Steinbrink, David Symonds, git, Stephan Beyer
In-Reply-To: <32541b130811121439tbfc54aeq2999dbebf149d5bc@mail.gmail.com>
"Avery Pennarun" <apenwarr@gmail.com> writes:
> I assume the reason is that "git diff tree1..tree2" works with the
> differences between tree1 and tree2, much like "git log tree1..tree2"
> does.
Actually, that perception is already confused. The analogue to "log A..B"
is expressed as "diff A...B", and not "diff A..B".
That is one of the reasons why I tend to teach against using "diff A..B"
unless you know what it is doing. I'd suggest to get out of that habit
before you confuse yourself even more ;-).
The _only_ reason diff takes A..B and A...B syntax is because the command
line parameter parser was easy to write that way. IOW, it was an artifact
of the implementation convenience.
^ permalink raw reply
* Re: [PATCH] Git.pm: Make _temp_cache use the repository directory
From: Marten Svanfeldt (dev) @ 2008-11-12 23:27 UTC (permalink / raw)
To: piyo; +Cc: msysgit, git, Eric Wong
In-Reply-To: <1f748ec60811121406j7ac72c7eqcfbe68132b2ebfc0@mail.gmail.com>
Hi,
Clifford Caoile wrote:
> Hi Marten Svanfeldt:
>
> On Wed, Nov 12, 2008 at 11:28 PM, Marten Svanfeldt (dev)
> <developer@svanfeldt.com> wrote:
..
> I suppose if I wanted to used ${workingdir}/.git instead of
> ${workingdir}, I should replace the $tmpdir line above with $tmpdir =
> $self->repo_path() . "/.git" ?
No. repo_path() is the path to the repository, so the .git directory. If
you instead want within the working directory it is wc_path().
>
> Best regards,
> Clifford Caoile
-Marten Svanfeldt
^ permalink raw reply
* Re: fixing duplicated history
From: Felipe Balbi @ 2008-11-12 22:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: me, git
In-Reply-To: <7vod0klfng.fsf@gitster.siamese.dyndns.org>
On Wed, Nov 12, 2008 at 02:53:55PM -0800, Junio C Hamano wrote:
> Felipe Balbi <me@felipebalbi.com> writes:
>
> > I have a git tree which history is completely messed up with duplicated
> > entries. By reading git man pages I saw that it might be possible to
> > delete those duplicated entries with git reflog delete, am I reading it
> > right ?
> >
> > If so, would it cause any problems to the users who already cloned the
> > original tree ? I mean, will git see it as a different history line and
> > try a merge or will it figure it's the same tree with the duplicated
> > entries removed ?
>
> I assume that you meant "commit" by "entry", and also I assume that you
> read "git filter-branch" not "git reflog delete". Then you are right.
>
> And rewriting history with filter-branch will cause problems to the
> downstream users.
Yes, you got me right. Hmm, so if it'll cause problems to the downstream
users I can't do anything, unfortunately :-(
Unless they wanna clone the tree again :-p
Thanks for the info Junio.
--
balbi
^ permalink raw reply
* Re: fixing duplicated history
From: Junio C Hamano @ 2008-11-12 22:53 UTC (permalink / raw)
To: me; +Cc: git
In-Reply-To: <20081112222346.GA24013@frodo>
Felipe Balbi <me@felipebalbi.com> writes:
> I have a git tree which history is completely messed up with duplicated
> entries. By reading git man pages I saw that it might be possible to
> delete those duplicated entries with git reflog delete, am I reading it
> right ?
>
> If so, would it cause any problems to the users who already cloned the
> original tree ? I mean, will git see it as a different history line and
> try a merge or will it figure it's the same tree with the duplicated
> entries removed ?
I assume that you meant "commit" by "entry", and also I assume that you
read "git filter-branch" not "git reflog delete". Then you are right.
And rewriting history with filter-branch will cause problems to the
downstream users.
^ permalink raw reply
* Re: fixing duplicated history
From: Robin Rosenberg @ 2008-11-12 22:52 UTC (permalink / raw)
To: me; +Cc: git
In-Reply-To: <20081112222346.GA24013@frodo>
onsdag 12 november 2008 23:23:51 skrev Felipe Balbi:
> Hi,
>
> I have a git tree which history is completely messed up with duplicated
> entries. By reading git man pages I saw that it might be possible to
> delete those duplicated entries with git reflog delete, am I reading it
> right ?
No. The reflog is not the history, except your very local log of what
the heads pointed to. You do not see the reflog unless you ask for it,
and nobody else can see it (i.e. *your* reflog).
What looks like duplicate entries may commit that have been cherry
picked into one or more branches that have been merged thereafter. If
you look carefully they have different id's.
-- robin
^ 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