* Re: [FEATURE REQUEST] - extend git request-pull to send email
From: Junio C Hamano @ 2011-02-03 22:59 UTC (permalink / raw)
To: Eugene Sajine; +Cc: git
In-Reply-To: <AANLkTi=kXJF_rYGMyh1gj49J7fh-ZxD7Bo8o_ELHb-2M@mail.gmail.com>
Eugene Sajine <euguess@gmail.com> writes:
> Specifying the "--to user@server.com" could be a trigger for this functionality.
> All additional parameters from git send-mail should be available.
>
> What do you think?
Horrible ;-).
If this were not about request-pull but some other command that produces a
summary of recent changes you have, which you might want to distribute to
people who are involved in the project (e.g. Meta/cook), it might make
sense to have "generate and then e-mail" feature inside the command,
because such a command needs to inspect the history and grab various kinds
of information anyway, and adding "people involved" to the mix might make
sense.
But you are talking about request-pull, which is by design is meant to be
sent to a single recipient. If the user has to say --to user@example.com,
how is it different from piping the output to "| mail to@example.com"?
^ permalink raw reply
* Re: [FEATURE REQUEST] - extend git request-pull to send email
From: Junio C Hamano @ 2011-02-03 23:06 UTC (permalink / raw)
To: Eugene Sajine; +Cc: git
In-Reply-To: <7vpqr8zpux.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
>> What do you think?
>
> Horrible ;-).
Just a quick note.
Please take this with a huge grain of salt, considering that the comment
is coming from somebody who thinks --compose and format-patch integration
to git-send-email was also a bad idea.
^ permalink raw reply
* [PATCH] gitweb: Mention optional Perl modules in INSTALL
From: Jakub Narebski @ 2011-02-03 23:20 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
Some optional additional Perl modules are required for some of extra
features. Mention those in gitweb/INSTALL.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
gitweb/INSTALL | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/gitweb/INSTALL b/gitweb/INSTALL
index 8230531..4964a67 100644
--- a/gitweb/INSTALL
+++ b/gitweb/INSTALL
@@ -237,6 +237,12 @@ Requirements
- Perl modules: CGI, Encode, Fcntl, File::Find, File::Basename.
- web server
+The following optional Perl modules are required for extra features
+ - Digest::MD5 - for gravatar support
+ - CGI::Fast and FCGI - for running gitweb as FastCGI script
+ - HTML::TagCloud - for fancy tag cloud in project list view
+ - HTTP::Date or Time::ParseDate - to support If-Modified-Since for feeds
+
Example web server configuration
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
^ permalink raw reply related
* Re: [FEATURE REQUEST] - extend git request-pull to send email
From: Eugene Sajine @ 2011-02-03 23:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vlj1wzpiq.fsf@alter.siamese.dyndns.org>
On Thu, Feb 3, 2011 at 6:06 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
>>> What do you think?
>>
>> Horrible ;-).
>
> Just a quick note.
>
> Please take this with a huge grain of salt, considering that the comment
> is coming from somebody who thinks --compose and format-patch integration
> to git-send-email was also a bad idea.
>
;) Anyway thanks for prompt answer;))
Well, it is of course pretty cool that you can pipe the output to mail
but there are at least three problems that i currently see with this:
1. it is not cross-platform solution
2. By default subject gets empty;)
3. I probably would like the from address to be the one that I'm using
in git configuration...
Thanks,
Eugene
^ permalink raw reply
* git log --summary outputs extra newlines inconsistently
From: Anders Kaseorg @ 2011-02-03 23:33 UTC (permalink / raw)
To: git
‘git log --summary’ seems to output a newline after every non-merge
commit.
$ git log --summary --pretty=format:'%h %s'
3c0eee3 Linux 2.6.37
65f4288 Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6
9fc3bbb ipv4/route.c: respect prefsrc for local routes
8a87694 remove trim_fs method from Documentation/filesystems/Locking
989d873 Merge master.kernel.org:/home/rmk/linux-2.6-arm
d9a1abe arch/mn10300/kernel/irq.c: fix build
867c202 ima: fix add LSM rule bug
…
Oddly, those newlines show up even with -z!
$ git log --summary --pretty=format:%h -z
3c0eee3
^@65f4288^@9fc3bbb
^@8a87694
^@989d873^@d9a1abe
^@867c202
…
This makes the output annoying to parse in both cases.
(I’m using Git 1.7.4-rc2.)
Anders
^ permalink raw reply
* Re: [FEATURE REQUEST] - extend git request-pull to send email
From: Eugene Sajine @ 2011-02-03 23:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <AANLkTikmOvCXqcCSvOgyxVoh8Gvk1KOhcLng68PvdVwy@mail.gmail.com>
> 3. I probably would like the from address to be the one that I'm using
> in git configuration...
It probably should be the reply-to....
Thanks,
Eugene
^ permalink raw reply
* [BUG?] git.el: M-x git-commit-file produces error if font lock is disabled
From: Jonathan Nieder @ 2011-02-04 0:10 UTC (permalink / raw)
To: Alexandre Julliard; +Cc: Kevin Ryde, git, David Kågedal
In-Reply-To: <87lkkgw9mg.fsf@wine.dyndns.org>
Hi,
Kevin Ryde reports[1]:
> If font lock is disabled, M-x git-commit-file gets an error when setting
> up the log message edit buffer.
>
> M-: (global-font-lock-mode 0)
> M-x git-status
> /some/git/directory
> c <- on a modified file
>
> => Font-lock trying to use keywords before setting them up
>
> I suppose font-lock-compile-keywords should not be used if font lock is
> not enabled. I suspect font-lock-add-keywords might be the right thing
> instead. It seems to work for me (the code is supposed to replace the
> normal log-edit-mode keywords is it?).
and suggests a patch[2]. Does it make sense?
Ignorantly,
Jonathan
[1] http://bugs.debian.org/577834 from a while ago.
Sorry for the long delay.
[2]
contrib/emacs/git.el | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/contrib/emacs/git.el b/contrib/emacs/git.el
index 214930a..0c93ef1 100644
--- a/contrib/emacs/git.el
+++ b/contrib/emacs/git.el
@@ -1337,7 +1337,7 @@ The FILES list must be sorted."
(log-edit 'git-do-commit nil '((log-edit-listfun . git-log-edit-files)
(log-edit-diff-function . git-log-edit-diff)) buffer)
(log-edit 'git-do-commit nil 'git-log-edit-files buffer))
- (setq font-lock-keywords (font-lock-compile-keywords git-log-edit-font-lock-keywords))
+ (font-lock-add-keywords nil git-log-edit-font-lock-keywords 'set)
(setq paragraph-separate (concat (regexp-quote git-log-msg-separator) "$\\|Author: \\|Date: \\|Merge: \\|Signed-off-by: \\|\f\\|[ ]*$"))
(setq buffer-file-coding-system coding-system)
(re-search-forward (regexp-quote (concat git-log-msg-separator "\n")) nil t))))
--
1.7.4
^ permalink raw reply related
* Re: git to p4 conversion
From: Vitor Antunes @ 2011-02-04 0:03 UTC (permalink / raw)
To: git
In-Reply-To: <AANLkTikW_sU8oCmU9wN5q1OPPJrQbS2YZAvS0C_nBQbD@mail.gmail.com>
Hi Endre,
Endre Czirbesz <endre <at> czirbesz.hu> writes:
>
> Hello Ian,
>
> Thanks for your reply.
>
> 2011/2/3 Ian Wienand <ianw <at> vmware.com>:
> > What exactly did you try?
> I am not at my work computer now, but as I remember:
>
> cd workdir
> git-p4 clone //depot/projectdir/...@all .
> git clone myprojectrepo .
I think what you should do is add the git repository as a remote with something
like:
git remote add remotename myprojectrepo
git pull remotename master
git p4 submit
Hope this helps,
Vitor
^ permalink raw reply
* git-p4 - workflow suggestions
From: Kaizer H. Sogiawala @ 2011-02-04 0:23 UTC (permalink / raw)
To: git
Hi,
We are primarily a Perforce shop. I am looking for a git-p4 workflow
that will alllow a sub-team (2-20 developers) to use git as their
primary source control repository. This sub-team is tasked with
refactoring and will need heavy-duty branch/merge support. The
main/central source code repository (and branch) is in Perforce.
I am looking at approaches that will allow me to "git-p4 clone" from
Perforce (a branch in perforce, say trunk) into a bare/shared git
repository. This repository is then cloned by each developer of the
git-sub-team to perform regular development/push/pull/merge/rebase
activities.
Periodically, a gatekeeper would pull changes from Perforce to git and
push changes from git to Perforce. Can this be done?
So far, I have looked at the:
- git-p4 documentation
- Version Control with Git book By: Jon Loeliger (particularly the
git-svn section)
- Mailing list (particularly following thread answered by Tor Arvid Lund)
- googl'n around this topic
Most discussion is around how to use git-p4 as a sync mechanism for a
single user. When I attempt to git-p4 clone (import) and then create a
shared/bare repository out of it and emulating multiple user, the
git-p4 sync mechanism breaks down after couple of merges. The git-p4
sync/rebase/submit will try to reapply duplicate changes and trip
pretty early in the cycle.
If you have a working model of making available a p4 branch for a
sub-team using git-p4, I would really appreciate a writeup or blog.
Thanks in advance.
--
Kaizer
^ permalink raw reply
* [BUG?] remote-http: interrupted fetch leaves bad index behind
From: Jonathan Nieder @ 2011-02-04 1:09 UTC (permalink / raw)
To: git; +Cc: Török Edwin, Shawn O. Pearce, Tay Ray Chuan,
Daniel Barkalow
In-Reply-To: <20101105170640.30975.94952.reportbug@deb0>
Hi gitsters,
Török Edwin wrote[1]:
> If I run 'git remote update' when the remote is an http URL, and then
> I Ctrl-C in the middle of a pack download, I get the .idx and .pack.temp.
>
> Next time when I run 'git remote update' it tells me it can't find some refs:
> error: Unable to find 72128861501dc742d33e88b473482e17f6672d4c under http://git.clamav.net/clamav-devel.git
> Cannot obtain needed object 72128861501dc742d33e88b473482e17f6672d4c
> error: Fetch failed.
Steps to reproduce:
1. Disable smart HTTP[2].
2.
git init reproduce
cd reproduce
git remote add clam http://git.clamav.net/clamav-devel.git
3. git fetch clam
Wait a few seconds (there will be no output). Hit ^C.
$ ls .git/objects/pack/
pack-98c82c9d2da21d2efddc4544d68332235795df19.idx.temp.temp
$ git fetch clam
error: wrong index v2 file size in .git/objects/pack/pack-98c82c9d2da21d2efddc4544d68332235795df19.idx.temp
error: Unable to find fe96c524670f23f73008c0e6b4001c096e4f9532 under http://git.clamav.net/clamav-devel.git
Cannot obtain needed object fe96c524670f23f73008c0e6b4001c096e4f9532
error: Fetch failed.
Ideas?
Jonathan
[1] http://bugs.debian.org/602528
[2]
diff --git a/remote-curl.c b/remote-curl.c
index 04d4813..b0ad1aa 100644
--- a/remote-curl.c
+++ b/remote-curl.c
@@ -625,10 +625,12 @@ static int fetch_git(struct discovery *heads,
static int fetch(int nr_heads, struct ref **to_fetch)
{
+#if 0
struct discovery *d = discover_refs("git-upload-pack");
if (d->proto_git)
return fetch_git(d, nr_heads, to_fetch);
else
+#endif
return fetch_dumb(nr_heads, to_fetch);
}
^ permalink raw reply related
* Re: Q: does index-pack work in place on windows?
From: Nicolas Pitre @ 2011-02-04 1:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Erik Faye-Lund, Johannes Sixt, git, Shawn O. Pearce
In-Reply-To: <7vk4hhwpfb.fsf@alter.siamese.dyndns.org>
On Wed, 2 Feb 2011, Junio C Hamano wrote:
> Nicolas Pitre <nico@fluxnic.net> writes:
>
> >> $ git index-pack
> >> .git/objects/pack/pack-d634271f4d7ca70c00148e967a343c3c46cd7705.pack
> >> Unlink of file '.git/objects/pack/pack-d634271f4d7ca70c00148e967a343c3c46cd7705.idx'
> >> failed. Should I try again? (y/n)? n
> >> fatal: unable to create
> >> '.git/objects/pack/pack-d634271f4d7ca70c00148e967a343c3c46cd7705.idx':
> >> File exists
> >
> > Why would you do such thing in the first place?
> >
> > If the pack exists along with its index on disk, there is no point
> > recreating it. Maybe index-pack should just bail out early in that
> > case.
>
> I am trying to see if an index-pack with slight modification would be a
> good replacement for verify-pack.
OK, then you don't intend to reuse it as is. If you really wanted to
have index-pack work in place then you would have to use
free_pack_by_name() somewhere before writing the new pack index out, but
that is still a dubious use case.
index-pack _could_ be a replacement for verify-pack. It certainly can
validate a pack since it is its purpose, possibly faster than
verify-pack. You'd still have to compare the existing pack index
against the one index-pack creates without overwriting that original
index, taking into accound index version differences, etc.
However index-pack won't tell you what is broken in the pack when
corruptions are to be found. It will simply tell you at the very end
that the checksum hash doesn't match, or that some deltas were not
resolved, that kind of thing, whereas verify-pack has the ability to
tell you exactly what doesn't match with the info in the index or the
like as soon as it encounters a problem.
Nicolas
^ permalink raw reply
* git-blame.el: does not show one-line summary in echo area
From: Jonathan Nieder @ 2011-02-04 1:43 UTC (permalink / raw)
To: David Kågedal
Cc: Sergei Organov, Andreas Schwab, git, Kevin Ryde, Martin Nordholts,
Alexandre Julliard, Xavier Maillard, Jakub Narebski
In-Reply-To: <87d42s3pv2.fsf@lysator.liu.se>
Hi David et al,
David Kågedal wrote:
> Sergei Organov <osv@javad.com> writes:
>> Now, I've evaluated (require 'format-spec) in my Emacs 22 (yes, 22, not
>> 23), and now git-blame almost works there. The problem I see is that it
>> doesn't output anything in the echo area. It color-codes the buffer, it
>> does show correct pop-up when mouse is over a region, but it doesn't
>> print anything in the echo area when I move cursor through the regions.
>> Any idea how to debug/fix this?
>
> Well, it appears I removed the output to the echo area. I didn't think
> it worked very well, and the new output format mostly replaces it by
> showing the hash.
>
> There are also technical reasons for removing it (it couldn't be
> implemented very cleanly).
I don't use git-blame.el ("git blame", "git gui blame", and "git log
-S/-G" take care of my needs already) but it seems to me that this
change was a regression. The emacs support before v1.6.6-rc0~120^2
had a simple way to find out the purpose of each line of code, while
after that there is no simple way. And it is what the README
promises:
* git-blame.el:
Emacs implementation of incremental git-blame. When you turn it on
while viewing a file, the editor buffer will be updated by setting
the background of individual lines to a color that reflects which
commit it comes from. And when you move around the buffer, a
one-line summary will be shown in the echo area.
Any advice for people who want to fix that? Is anyone interested in
doing so? (It is quite likely I am guessing incorrectly about what is
useful, but I would imagine that at least the documentation could use
updating.)
Jonathan
^ permalink raw reply
* Re: Q: does index-pack work in place on windows?
From: Junio C Hamano @ 2011-02-04 1:59 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Erik Faye-Lund, Johannes Sixt, git, Shawn O. Pearce
In-Reply-To: <alpine.LFD.2.00.1102031958000.12104@xanadu.home>
Nicolas Pitre <nico@fluxnic.net> writes:
> On Wed, 2 Feb 2011, Junio C Hamano wrote:
>
>> I am trying to see if an index-pack with slight modification would be a
>> good replacement for verify-pack.
> ...
> index-pack _could_ be a replacement for verify-pack. It certainly can
> validate a pack since it is its purpose, possibly faster than
> verify-pack. You'd still have to compare the existing pack index
> against the one index-pack creates without overwriting that original
> index, taking into accound index version differences, etc.
We already know index-pack is a lot faster when you have a lot of deep
deltas, as it works from a base to its immediate delta children while
pinning that base, as opposed to verify-pack that verifies each and every
object in the pack in the index order, inflating and then applying
potentially long delta chains repeatedly---the only thing that could be
helping it right now is the in-core delta base cache.
> However index-pack won't tell you what is broken in the pack when
> corruptions are to be found.
Yes, but at that point, you are pretty much lost anyway, as the only thing
you can do to salvage salvageable parts of the broken pack, if you still
trust its associated .idx file, is to walk the table of contents and ask
for each individual object; knowing where the .pack or .idx is broken with
the current verify-pack does not help you very much.
^ permalink raw reply
* Re: [1.8.0] reorganize the mess that the source tree has become
From: Miles Bader @ 2011-02-04 2:06 UTC (permalink / raw)
To: Hilco Wijbenga; +Cc: git, Nicolas Pitre, George Spelvin, Eugene Sajine
In-Reply-To: <AANLkTikhPRGZ9DxCWbWvBiac_DYiXYsnEdHVOnbHUdU4@mail.gmail.com>
Hilco Wijbenga <hilco.wijbenga@gmail.com> writes:
> Quite frankly, I'm surprised there are (presumably experienced)
> developers who do not immediately see the value of a little
> organization. Surely, given the use of code conventions, formatting
> rules, etcetera, the obvious one step further is to also organize
> where the files go?
I think one of the problems is that what's been suggested seems like
window-dressing. Moving everything into src/ and calling it "organized"
doesn't actually accomplish much other than perhaps making the README
file more visible to newbs; things are _still_ a mess, just a mess with
four more letters...
-Miles
--
Back, n. That part of your friend which it is your privilege to contemplate in
your adversity.
^ permalink raw reply
* Re: Q: does index-pack work in place on windows?
From: Nicolas Pitre @ 2011-02-04 2:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Erik Faye-Lund, Johannes Sixt, git, Shawn O. Pearce
In-Reply-To: <7v1v3ozhij.fsf@alter.siamese.dyndns.org>
On Thu, 3 Feb 2011, Junio C Hamano wrote:
> Nicolas Pitre <nico@fluxnic.net> writes:
>
> > However index-pack won't tell you what is broken in the pack when
> > corruptions are to be found.
>
> Yes, but at that point, you are pretty much lost anyway, as the only thing
> you can do to salvage salvageable parts of the broken pack, if you still
> trust its associated .idx file, is to walk the table of contents and ask
> for each individual object; knowing where the .pack or .idx is broken with
> the current verify-pack does not help you very much.
Well... given that you do have to compare both the generated index and
the on-disk index at some point, it is then possible to identify
corrupted objects and their location. And with pack index version 2
including a CRC for the packed data, you should be able to tell if the
corruption is actually in the pack or in the index (or both if the final
pack/index SHA1 sum doesn't match).
Nicolas
^ permalink raw reply
* What's cooking in git.git (Feb 2011, #01; Thu, 3)
From: Junio C Hamano @ 2011-02-04 3:06 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 tip of 'next' has been rewound, as 1.7.4 is now out. A few topics
that were merged to 'next' during 1.7.4 pre-release freeze period have
been kicked back to 'pu' to make sure I didn't make silly mistakes while
rebasing them on top of 1.7.4 to reduce future merge conflicts.
--------------------------------------------------
[Stalled]
* nd/index-doc (2010-09-06) 1 commit
- doc: technical details about the index file format
Half-written but it is a good start. I may need to give some help in
describing more recent index extensions.
* cb/ignored-paths-are-precious (2010-08-21) 1 commit
- checkout/merge: optionally fail operation when ignored files need to be overwritten
This needs tests; also we know of longstanding bugs in related area that
needs to be addressed---they do not have to be part of this series but
their reproduction recipe would belong to the test script for this topic.
It would hurt users to make the new feature on by default, especially the
ones with subdirectories that come and go.
* jk/tag-contains (2010-07-05) 4 commits
- Why is "git tag --contains" so slow?
- default core.clockskew variable to one day
- limit "contains" traversals based on commit timestamp
- tag: speed up --contains calculation
The idea of the bottom one is probably Ok, except that the use of object
flags needs to be rethought, or at least the helper needs to be moved to
builtin/tag.c to make it clear that it should not be used outside the
current usage context.
* jc/rename-degrade-cc-to-c (2011-01-06) 3 commits
- diffcore-rename: fall back to -C when -C -C busts the rename limit
- diffcore-rename: record filepair for rename src
- diffcore-rename: refactor "too many candidates" logic
IIRC, this was a weather-baloon "if you wanted to, this may be how you
would do it" without test updates. People who care need to help moving
things forward.
* jc/rerere-remaining (2011-01-06) 1 commit
- rerere "remaining"
Just a handful of weatherballoon patches without proper tests, in response
to feature/minor fix requests.
* ab/p4 (2011-01-11) 1 commit
- git-p4: correct indenting and formatting
Lacks sign-off but is trivial.
* tr/maint-branch-no-track-head (2010-12-14) 1 commit
- branch: do not attempt to track HEAD implicitly
Probably needs a re-roll to exclude either (1) any ref outside the
hierarchies for branches (i.e. refs/{heads,remotes}/), or (2) only refs
outside refs/ hierarchies (e.g. HEAD, ORIG_HEAD, ...). The latter feels
safer and saner.
* hv/mingw-fs-funnies (2010-12-14) 5 commits
- mingw_rmdir: set errno=ENOTEMPTY when appropriate
- mingw: add fallback for rmdir in case directory is in use
- mingw: make failures to unlink or move raise a question
- mingw: work around irregular failures of unlink on windows
- mingw: move unlink wrapper to mingw.c
Will be rerolled (Heiko, 2010-12-23)
* mz/rebase (2010-12-28) 31 commits
- rebase -i: remove unnecessary state rebase-root
- rebase -i: don't read unused variable preserve_merges
- git-rebase--am: remove unnecessary --3way option
- rebase -m: don't print exit code 2 when merge fails
- rebase -m: remember allow_rerere_autoupdate option
- rebase: remember strategy and strategy options
- rebase: remember verbose option
- rebase: extract code for writing basic state
- rebase: factor out sub command handling
- rebase: make -v a tiny bit more verbose
- rebase -i: align variable names
- rebase: show consistent conflict resolution hint
- rebase: extract am code to new source file
- rebase: extract merge code to new source file
- rebase: remove $branch as synonym for $orig_head
- rebase -i: support --stat
- rebase: factor out call to pre-rebase hook
- rebase: factor out clean work tree check
- rebase: factor out reference parsing
- rebase: reorder validation steps
- rebase -i: remove now unnecessary directory checks
- rebase: factor out command line option processing
- rebase: align variable content
- rebase: align variable names
- rebase: stricter check of standalone sub command
- rebase: act on command line outside parsing loop
- rebase: improve detection of rebase in progress
- rebase: remove unused rebase state 'prev_head'
- rebase: read state outside loop
- rebase: refactor reading of state
- rebase: clearer names for directory variables
Will be rerolled (Martin, Jan 28).
--------------------------------------------------
[Cooking]
* nd/struct-pathspec (2011-01-31) 22 commits
- t6004: add pathspec globbing test for log family
- t7810: overlapping pathspecs and depth limit
- grep: drop pathspec_matches() in favor of tree_entry_interesting()
- grep: use writable strbuf from caller for grep_tree()
- grep: use match_pathspec_depth() for cache/worktree grepping
- grep: convert to use struct pathspec
- Convert ce_path_match() to use match_pathspec_depth()
- Convert ce_path_match() to use struct pathspec
- struct rev_info: convert prune_data to struct pathspec
- pathspec: add match_pathspec_depth()
- tree_entry_interesting(): optimize wildcard matching when base is matched
- tree_entry_interesting(): support wildcard matching
- tree_entry_interesting(): fix depth limit with overlapping pathspecs
- tree_entry_interesting(): support depth limit
- tree_entry_interesting(): refactor into separate smaller functions
- diff-tree: convert base+baselen to writable strbuf
- glossary: define pathspec
- Move tree_entry_interesting() to tree-walk.c and export it
- tree_entry_interesting(): remove dependency on struct diff_options
- Convert struct diff_options to use struct pathspec
- diff-no-index: use diff_tree_setup_paths()
- Add struct pathspec
(this branch is used by en/object-list-with-pathspec.)
* en/object-list-with-pathspec (2010-09-20) 2 commits
- Add testcases showing how pathspecs are handled with rev-list --objects
- Make rev-list --objects work together with pathspecs
(this branch uses nd/struct-pathspec.)
The above two were rebased on 1.7.4; I think the result is correct, but
extra sets of eyeballs are always appreciated.
* tr/merge-unborn-clobber (2010-08-22) 1 commit
(merged to 'next' on 2011-02-03 at ccfc03d)
+ Exhibit merge bug that clobbers index&WT
* jc/unpack-trees (2010-12-22) 2 commits
(merged to 'next' on 2011-02-03 at 5bd48f8)
+ unpack_trees(): skip trees that are the same in all input
+ unpack-trees.c: cosmetic fix
* jc/fsck-fixes (2011-01-26) 2 commits
(merged to 'next' on 2011-02-03 at 98e1c63)
+ fsck: do not give up too early in fsck_dir()
+ fsck: drop unused parameter from traverse_one_object()
* tr/diff-words-test (2011-01-18) 4 commits
(merged to 'next' on 2011-02-03 at d346665)
+ t4034 (diff --word-diff): add a minimum Perl drier test vector
+ t4034 (diff --word-diff): style suggestions
+ userdiff: simplify word-diff safeguard
+ t4034: bulk verify builtin word regex sanity
I thought this was Ok; further comments, anybody?
* rr/fi-import-marks-if-exists (2011-01-15) 1 commit
(merged to 'next' on 2011-02-03 at 8c9d4ce)
+ fast-import: Introduce --import-marks-if-exists
Looked reasonable.
* jn/unpack-lstat-failure-report (2011-01-12) 2 commits
(merged to 'next' on 2011-02-03 at 76586d2)
+ unpack-trees: handle lstat failure for existing file
+ unpack-trees: handle lstat failure for existing directory
Looked reasonable.
* ef/alias-via-run-command (2011-01-07) 1 commit
(merged to 'next' on 2011-02-03 at 4ce47ce)
+ alias: use run_command api to execute aliases
Will merge to 'master' shortly.
* uk/checkout-ambiguous-ref (2011-01-11) 1 commit
(merged to 'next' on 2011-02-03 at 9044724)
+ checkout: fix bug with ambiguous refs
Will merge to 'master' shortly.
* cb/setup (2010-12-27) 1 commit
(merged to 'next' on 2011-02-03 at 073980f)
+ setup: translate symlinks in filename when using absolute paths
Will merge to 'master' shortly.
* ae/better-template-failure-report (2010-12-18) 1 commit
(merged to 'next' on 2011-02-03 at 3b269c9)
+ Improve error messages when temporary file creation fails
Will merge to 'master' shortly.
* jn/cherry-pick-strategy-option (2010-12-10) 1 commit
(merged to 'next' on 2011-02-03 at 1c10f16)
+ cherry-pick/revert: add support for -X/--strategy-option
Will merge to 'master' shortly.
* ab/i18n (2010-10-07) 161 commits
- po/de.po: complete German translation
- po/sv.po: add Swedish translation
- gettextize: git-bisect bisect_next_check "You need to" message
- gettextize: git-bisect [Y/n] messages
- gettextize: git-bisect bisect_replay + $1 messages
- gettextize: git-bisect bisect_reset + $1 messages
- gettextize: git-bisect bisect_run + $@ messages
- gettextize: git-bisect die + eval_gettext messages
- gettextize: git-bisect die + gettext messages
- gettextize: git-bisect echo + eval_gettext message
- gettextize: git-bisect echo + gettext messages
- gettextize: git-bisect gettext + echo message
- gettextize: git-bisect add git-sh-i18n
- gettextize: git-stash drop_stash say/die messages
- gettextize: git-stash "unknown option" message
- gettextize: git-stash die + eval_gettext $1 messages
- gettextize: git-stash die + eval_gettext $* messages
- gettextize: git-stash die + eval_gettext messages
- gettextize: git-stash die + gettext messages
- gettextize: git-stash say + gettext messages
- gettextize: git-stash echo + gettext message
- gettextize: git-stash add git-sh-i18n
- gettextize: git-submodule "blob" and "submodule" messages
- gettextize: git-submodule "path not initialized" message
- gettextize: git-submodule "[...] path is ignored" message
- gettextize: git-submodule "Entering [...]" message
- gettextize: git-submodule $errmsg messages
- gettextize: git-submodule "Submodule change[...]" messages
- gettextize: git-submodule "cached cannot be used" message
- gettextize: git-submodule $update_module say + die messages
- gettextize: git-submodule die + eval_gettext messages
- gettextize: git-submodule say + eval_gettext messages
- gettextize: git-submodule echo + eval_gettext messages
- gettextize: git-submodule add git-sh-i18n
- gettextize: git-pull "rebase against" / "merge with" messages
- gettextize: git-pull "[...] not currently on a branch" message
- gettextize: git-pull "You asked to pull" message
- gettextize: git-pull split up "no candidate" message
- gettextize: git-pull eval_gettext + warning message
- gettextize: git-pull eval_gettext + die message
- gettextize: git-pull die messages
- gettextize: git-pull add git-sh-i18n
- gettext docs: add "Testing marked strings" section to po/README
- gettext docs: the Git::I18N Perl interface
- gettext docs: the git-sh-i18n.sh Shell interface
- gettext docs: the gettext.h C interface
- gettext docs: add "Marking strings for translation" section in po/README
- gettext docs: add a "Testing your changes" section to po/README
- po/pl.po: add Polish translation
- po/hi.po: add Hindi Translation
- po/en_GB.po: add British English translation
- po/de.po: add German translation
- Makefile: only add gettext tests on XGETTEXT_INCLUDE_TESTS=YesPlease
- gettext docs: add po/README file documenting Git's gettext
- gettextize: git-am printf(1) message to eval_gettext
- gettextize: git-am core say messages
- gettextize: git-am "Apply?" message
- gettextize: git-am clean_abort messages
- gettextize: git-am cannot_fallback messages
- gettextize: git-am die messages
- gettextize: git-am eval_gettext messages
- gettextize: git-am multi-line getttext $msg; echo
- gettextize: git-am one-line gettext $msg; echo
- gettextize: git-am add git-sh-i18n
- gettext tests: add GETTEXT_POISON tests for shell scripts
- gettext tests: add GETTEXT_POISON support for shell scripts
- Makefile: MSGFMT="msgfmt --check" under GNU_GETTEXT
- Makefile: add GNU_GETTEXT, set when we expect GNU gettext
- gettextize: git-shortlog basic messages
- gettextize: git-revert split up "could not revert/apply" message
- gettextize: git-revert literal "me" messages
- gettextize: git-revert "Your local changes" message
- gettextize: git-revert basic messages
- gettextize: git-notes "Refusing to %s notes in %s" message
- gettextize: git-notes GIT_NOTES_REWRITE_MODE error message
- gettextize: git-notes basic commands
- gettextize: git-gc "Auto packing the repository" message
- gettextize: git-gc basic messages
- gettextize: git-describe basic messages
- gettextize: git-clean clean.requireForce messages
- gettextize: git-clean basic messages
- gettextize: git-bundle basic messages
- gettextize: git-archive basic messages
- gettextize: git-status "renamed: " message
- gettextize: git-status "Initial commit" message
- gettextize: git-status "Changes to be committed" message
- gettextize: git-status shortstatus messages
- gettextize: git-status "nothing to commit" messages
- gettextize: git-status basic messages
- gettextize: git-push "prevent you from losing" message
- gettextize: git-push basic messages
- gettextize: git-tag tag_template message
- gettextize: git-tag basic messages
- gettextize: git-reset "Unstaged changes after reset" message
- gettextize: git-reset reset_type_names messages
- gettextize: git-reset basic messages
- gettextize: git-rm basic messages
- gettextize: git-mv "bad" messages
- gettextize: git-mv basic messages
- gettextize: git-merge "Wonderful" message
- gettextize: git-merge "You have not concluded your merge" messages
- gettextize: git-merge "Updating %s..%s" message
- gettextize: git-merge basic messages
- gettextize: git-log "--OPT does not make sense" messages
- gettextize: git-log basic messages
- gettextize: git-grep "--open-files-in-pager" message
- gettextize: git-grep basic messages
- gettextize: git-fetch split up "(non-fast-forward)" message
- gettextize: git-fetch update_local_ref messages
- gettextize: git-fetch formatting messages
- gettextize: git-fetch basic messages
- gettextize: git-diff basic messages
- gettextize: git-commit advice messages
- gettextize: git-commit "enter the commit message" message
- gettextize: git-commit print_summary messages
- gettextize: git-commit formatting messages
- gettextize: git-commit "middle of a merge" message
- gettextize: git-commit basic messages
- gettextize: git-checkout "Switched to a .. branch" message
- gettextize: git-checkout "HEAD is now at" message
- gettextize: git-checkout describe_detached_head messages
- gettextize: git-checkout: our/their version message
- gettextize: git-checkout basic messages
- gettextize: git-branch "(no branch)" message
- gettextize: git-branch "git branch -v" messages
- gettextize: git-branch "Deleted branch [...]" message
- gettextize: git-branch "remote branch '%s' not found" message
- gettextize: git-branch basic messages
- gettextize: git-add refresh_index message
- gettextize: git-add "remove '%s'" message
- gettextize: git-add "pathspec [...] did not match" message
- gettextize: git-add "Use -f if you really want" message
- gettextize: git-add "no files added" message
- gettextize: git-add basic messages
- gettextize: git-clone "Cloning into" message
- gettextize: git-clone basic messages
- gettext tests: test message re-encoding under C
- po/is.po: add Icelandic translation
- gettext tests: mark a test message as not needing translation
- gettext tests: test re-encoding with a UTF-8 msgid under Shell
- gettext tests: test message re-encoding under Shell
- gettext tests: add detection for is_IS.ISO-8859-1 locale
- gettext tests: test if $VERSION exists before using it
- gettextize: git-init "Initialized [...] repository" message
- gettextize: git-init basic messages
- gettext tests: skip lib-gettext.sh tests under GETTEXT_POISON
- gettext tests: add GETTEXT_POISON=YesPlease Makefile parameter
- gettext.c: use libcharset.h instead of langinfo.h when available
- gettext.c: work around us not using setlocale(LC_CTYPE, "")
- builtin.h: Include gettext.h
- Makefile: use variables and shorter lines for xgettext
- Makefile: tell xgettext(1) that our source is in UTF-8
- Makefile: provide a --msgid-bugs-address to xgettext(1)
- Makefile: A variable for options used by xgettext(1) calls
- gettext tests: locate i18n lib&data correctly under --valgrind
- gettext: setlocale(LC_CTYPE, "") breaks Git's C function assumptions
- gettext tests: rename test to work around GNU gettext bug
- gettext: add infrastructure for translating Git with gettext
- builtin: use builtin.h for all builtin commands
- tests: use test_cmp instead of piping to diff(1)
- t7004-tag.sh: re-arrange git tag comment for clarity
It is getting ridiculously painful to keep re-resolving the conflicts with
other topics in flight, even with the help with rerere.
Needs a bit more minor work to get the basic code structure right.
^ permalink raw reply
* Re: moving to a git-backed wiki
From: Jeff King @ 2011-02-04 6:03 UTC (permalink / raw)
To: Sverre Rabbelier
Cc: J.H., Vincent Hanquez, Jay Soffian, Scott Chacon, Junio C Hamano,
git
In-Reply-To: <AANLkTikshY8qHoFvghSu8q21j5Unp==Hf583OE2tkNrS@mail.gmail.com>
On Thu, Feb 03, 2011 at 08:06:34PM +0100, Sverre Rabbelier wrote:
> On Thu, Feb 3, 2011 at 18:45, Jeff King <peff@peff.net> wrote:
> > Most of us don't really care if git is the ultimate storage mechanism. I
> > could even build the git interface as a purely client thing on top of
> > the CGI interface; the problem is that scraping the wiki pages for new
> > versions over the net would be horribly inefficient.
>
> Note that MediaWiki has a stable API that you could use instead :).
The initial import is still pretty painful over the network, but at
least I know I am getting accurate data from the API now. And I can
share the git repository, and just use the RecentChanges API to get
updates.
The result is at:
https://github.com/peff/wikitest/wiki
You can see an example of the full history:
https://github.com/peff/wikitest/wiki/_history
or a page history:
https://github.com/peff/wikitest/wiki/GitFaq/_history
Or download the repository for yourself:
git://github.com/peff/wikitest.wiki.git
The whole git wiki is about a 4M git repository (and at least some of
that is spam that's deleted but still in the history).
This is has been a cute exercise, but I'm not sure mirroring it in a
gollum wiki really makes sense. It's cool that gollum understands
MediaWiki enough to actually render the pages at all, but there are
obviously lots of corner cases that it just doesn't get (formatting
issues, missing images, some redirect naming issues).
Still, it's useful as a local repo doing diffs. I just wrote the initial
importer (which I'm happy to share if somebody wants to see some ugly
code), but to act as a useful client, it still needs:
1. Incremental updating from the RecentChanges API.
2. Push support (or more likely something similar to "git svn
dcommit") to push edits back.
-Peff
^ permalink raw reply
* Re: moving to a git-backed wiki
From: Jeff King @ 2011-02-04 6:16 UTC (permalink / raw)
To: Felipe Contreras
Cc: J.H., Vincent Hanquez, Jay Soffian, Scott Chacon, Junio C Hamano,
git
In-Reply-To: <AANLkTi=qR5xYBg3NKRASuyatnEm1k3fVNc-i5VOwszpM@mail.gmail.com>
On Thu, Feb 03, 2011 at 10:34:38PM +0200, Felipe Contreras wrote:
> > Forget about a git-backed wiki for a moment, and imagine a regular old
> > Mediawiki. What are the operations you can perform? You can look at
> > the current or any past version of a page, you can do diffs between
> > versions of pages, and you can create a new version of a page. All
> > through some CGI forms.
>
> Howe about these?
I've never really used a wiki in any in-depth way, so be gentle if my
utter cluelessness about these features shows through.
> 1) Support for discussion; since changes can be controversial.
Doesn't this just happen on special Talk: pages? Couldn't these just be
pages with special names?
> 2) Support for article move; so everything is kept organized.
Isn't that even simpler in a git-backed wiki? You just move the files.
Obviously you would want to update links, too, and presumably the wiki
software helps with that. But that is outside the scope of data storage.
In a git-backed wiki, you would get one atomic commit with the move and
link updating.
> 3) Support for "who is linking here". Also helps reorganization.
Again, is that a fundamental storage issue? It seems like you could
implement that easily on top of basic storage with a grep (and some
caching if you are going to let people do it a lot via the web).
> 4) Support for categories. Ditto.
I have no idea how categories work. Special page naming and/or
directories?
> 5) Support for watchlist, e-mail notifications. So that you are
> up-to-date with the changes.
Post-receive hook?
> 6) Support for contribution backtracking. So that it's easy to know who's who.
git log? git blame? :)
> 7) Personal wiki pages (with discussion). So you can put information
> about yourself, and general notes.
Specially named pages for people?
Obviously I'm just filling in these features off the top of my head.
MediaWiki is a mature system, and I doubt that either ikiwiki or gollum
has nearly the same featureset. But that was never my point. In the bit
you quoted, my point was that a git-interface to a wiki was useful and
feasible. And I stand by that.
Even with just the basic functionality of fetch/diff/push, that still
makes it a useful interface into an existing wiki for a large number of
users who just want to do simple stuff (or power users who happen to be
doing simple stuff at the moment).
I also happen to think you could put all of those features into a
git-backed wiki, and build the web features on _top_ of git access. But
I'm not volunteering to work on that.
-Peff
^ permalink raw reply
* Re: [1.8.0] (v2) default "git merge" without argument to "git merge @{u}"
From: Thomas Hochstein @ 2011-02-04 7:31 UTC (permalink / raw)
To: git
In-Reply-To: <20110131225529.GC14419@sigill.intra.peff.net>
Jeff King schrieb:
> And surely there
> are other git-backed alternatives (it's been a while since I've looked).
ikiwiki, for example, with Hosting on <http://branchable.com/>?
^ permalink raw reply
* Re: [1.8.0] reorganize the mess that the source tree has become
From: Tor Arntsen @ 2011-02-04 8:30 UTC (permalink / raw)
To: Miles Bader
Cc: Hilco Wijbenga, git, Nicolas Pitre, George Spelvin, Eugene Sajine
In-Reply-To: <87bp2sy2mf.fsf@catnip.gol.com>
On Fri, Feb 4, 2011 at 03:06, Miles Bader <miles@gnu.org> wrote:
> Hilco Wijbenga <hilco.wijbenga@gmail.com> writes:
>> Quite frankly, I'm surprised there are (presumably experienced)
>> developers who do not immediately see the value of a little
>> organization. Surely, given the use of code conventions, formatting
>> rules, etcetera, the obvious one step further is to also organize
>> where the files go?
>
> I think one of the problems is that what's been suggested seems like
> window-dressing. Moving everything into src/ and calling it "organized"
> doesn't actually accomplish much other than perhaps making the README
> file more visible to newbs; things are _still_ a mess, just a mess with
> four more letters...
What Miles says is my feeling as well. And having a 'bin/' as was suggested
in one post doesn't make much sense to me either - if you want your compiled
output to go elsewhere than the source directory then the normal way of doing
that is to do and out-of-tree build (so if that's not working - I have
not checked -
then that's something which would be worth looking into.)
-Tor
^ permalink raw reply
* [PATCH maint] start_command: flush buffers in the WIN32 code path as well
From: Johannes Sixt @ 2011-02-04 8:41 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Pat Thoyts, msysgit, Git Mailing List, Junio C Hamano
In-Reply-To: <alpine.DEB.1.00.1102031426110.1541@bonsai2>
From: Johannes Sixt <j6t@kdbg.org>
The POSIX code path did The Right Thing already, but we have to do the same
on Windows.
This bug caused failures in t5526-fetch-submodules, where the output of
'git fetch --recurse-submodules' was in the wrong order.
Debugged-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
---
Am 2/3/2011 21:26, schrieb Johannes Schindelin:
> Have you seen my response where I proved that it is a fflush() issue, most
> likely with mingw_spawn()?
I think this is the correct fix.
run-command.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/run-command.c b/run-command.c
index 2a1041e..f91e446 100644
--- a/run-command.c
+++ b/run-command.c
@@ -194,6 +194,7 @@ fail_pipe:
}
trace_argv_printf(cmd->argv, "trace: run_command:");
+ fflush(NULL);
#ifndef WIN32
{
@@ -201,7 +202,6 @@ fail_pipe:
if (pipe(notify_pipe))
notify_pipe[0] = notify_pipe[1] = -1;
- fflush(NULL);
cmd->pid = fork();
if (!cmd->pid) {
/*
--
1.7.4.1253.g00c7
^ permalink raw reply related
* Re: [1.8.0] Change branch --set-uptream to take an argument
From: Stefan Haller @ 2011-02-04 8:54 UTC (permalink / raw)
To: Jay Soffian, Matthieu Moy; +Cc: Junio C Hamano, git
In-Reply-To: <AANLkTimOLPVp0EdhTsrPcF7gtykh3o-yE7KimBSJwfY3@mail.gmail.com>
Jay Soffian <jaysoffian@gmail.com> wrote:
> 1. Deprecate --track and --no-track (remove from documentation and
> usage). I wonder if anyone ever uses them?
I use --no-track quite frequently, and I always find it unfortunate that
I have to (sometimes I forget). I need it when I want to create a new
local branch off of master, and my local master is not up to date, but
I'm too lazy to bring it up to date because I have some other branch
checked out currently; so I do
$ git fetch
$ git checkout -b new_branch origin/master
This will by default make origin/master the upstream branch of
new_branch, which is never what I want.
To avoid the problem, I would have to
$ git checkout master
$ git pull
$ git checkout -b new_branch
I guess I would like a config setting of
branch.autosetupmerge=onlyifnamematches or some such.
I realize this is probably not related to the discussion of whether or
how --set-upstream should be fixed; I just wanted to comment on your
question.
--
Stefan Haller
Berlin, Germany
http://www.haller-berlin.de/
^ permalink raw reply
* Re: [PATCH] git-p4: Corrected typo.
From: Thomas Berg @ 2011-02-04 8:59 UTC (permalink / raw)
To: Vitor Antunes; +Cc: git
In-Reply-To: <AANLkTin5yR84x=3Qb3W9bZYhUHwbcrhf60Z1CwHyYHOL@mail.gmail.com>
On Mon, Jan 31, 2011 at 4:54 PM, Vitor Antunes <vitor.hda@gmail.com> wrote:
> Hi Thomas,
>
>> On Mon, Jan 31, 2011 at 12:51 PM, Thomas Berg <merlin66b@gmail.com> wrote:
>>> I also discovered bugs in git-p4: in some cases, if the first submit
>>> to a new branch in Perforce is not identical to the branch it derives
>>> from, the import was not correct.
>
> I forgot to answer this specific topic. I also noticed this bug.
> Basically, git-p4 choses the first commit from the origin branch to
> start the branch from. My idea was to walk through the commit tree in
> the original branch until I find a commit in which the diff is null.
> Unfortunately, I don't know what is the best approach to achieve this
> in git. Do you have any ideas?
The thing is that the diff doesn't have to be null either, if an
"evil" branching has happened - the submit that creates the new
branch contains a different tree than the source branch. It would
probably work well in most cases though, you could just fall back to
the current behaviour if no zero-diff parent is found. I'm sure it's
easy with some git plumbing commands, but I'm of little help there.
I haven't had time to test your patches yet, hope to get some time soon...
Cheers,
Thomas
^ permalink raw reply
* Re: git to p4 conversion
From: Tor Arvid Lund @ 2011-02-04 9:25 UTC (permalink / raw)
To: Vitor Antunes; +Cc: git, Endre Czirbesz, Ian Wienand
In-Reply-To: <loom.20110204T004658-497@post.gmane.org>
[on this mailing list, please don't cull the CC list]
On Fri, Feb 4, 2011 at 1:03 AM, Vitor Antunes <vitor.hda@gmail.com> wrote:
> Hi Endre,
>
<snip>
> I think what you should do is add the git repository as a remote with something
> like:
>
> git remote add remotename myprojectrepo
> git pull remotename master
> git p4 submit
That's not what I would do... When I try this, the 'git pull ...'
creates a merge, which I don't want to do when using git-p4.
But I think we're close to something that would work ok:
Endre, you should start like you already have; by git-p4 cloning your
project from perforce. (You maybe want to have a dummy file checked in
to your <projectdir> in perforce, so that the 'git-p4 clone' command
produces at least one commit in your git repo)...
Then, do 'git remote add tempremote <path-to-your-existing-git-repo>'
like Vitor suggests.
At this point I would do:
$ git checkout -b tempbranch tempremote/master
$ git rebase master
$ git-p4 submit
So, the 'git rebase master' should be like applying each of your
existing git commits *on-top-of* the git-p4 branch that you already
have. And that is the key to git-p4 knowing what to push to the
perforce server.
Thus, if I wanted to get all my existing git history into perforce,
this is how I would do it.
-- Tor Arvid
^ permalink raw reply
* Re: git-blame.el: does not show one-line summary in echo area
From: Jakub Narebski @ 2011-02-04 10:03 UTC (permalink / raw)
To: David Kågedal
Cc: Jonathan Nieder, Xavier Maillard, Alexandre Julliard,
Martin Nordholts, Kevin Ryde, git, Andreas Schwab, Sergei Organov
In-Reply-To: <87tygkm8h7.fsf@krank.kagedal.org>
Dnia piątek 4. lutego 2011 10:53, David Kågedal napisał:
> 3) Showing when you move to a different blame chunk, by showing a
> one-line summary in the echo area.
There is even some prior art for this to borrow from, namely cperl-mode
shows information about syntax at given point in echo area (minibuffer
area) after some delay. Just FYI.
--
Jakub Narebski
Poland
^ 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