* Re: [RFC] Enable compilation by Makefile for the MSVC toolchain
From: Daniel Barkalow @ 2009-08-18 16:51 UTC (permalink / raw)
To: Marius Storm-Olsen
Cc: Johannes.Schindelin, msysgit, git, lznuaa, bonzini, kusmabite
In-Reply-To: <1250600335-8642-1-git-send-email-mstormo@gmail.com>
On Tue, 18 Aug 2009, Marius Storm-Olsen wrote:
> From: Marius Storm-Olsen <mstormo@gmail.com>
>
> By using GNU Make we can also compile with the MSVC toolchain.
> This is a rudementary patch, only meant as an RFC for now!!
>
> !! DO NOT COMMIT THIS UPSTREAM !!
> ---
> So, instead of rely on these vcproj files which *will* go stale, we can
> simply use the same Makefile system which everyone else is using. :)
> After all, we're just compiling with a different compiler. The end result
> will still rely on the *msysGit environment* to function, so we already
> require it. Thus, GNU Make is present, and we can use it.
>
> This implementation is a quick hack to make it compile (hence the RFC
> subject), so please don't even consider basing anything ontop of it ;)
>
> But, do point out all the do's and don'ts, and I'll try to polish it up
> to something which we can add to Frank's series..
>
>
> Makefile | 97 +++++++++++++++++++++++++++++++++++++++++++++++---------
> compat/msvc.h | 77 +++++++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 158 insertions(+), 16 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index daf4296..2e14976 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -214,9 +214,13 @@ uname_V := $(shell sh -c 'uname -v 2>/dev/null || echo not')
>
> CFLAGS = -g -O2 -Wall
> LDFLAGS =
> +ARFLAGS = rcs\ # whitespace intentional
> ALL_CFLAGS = $(CFLAGS)
> ALL_LDFLAGS = $(LDFLAGS)
> STRIP ?= strip
> +COMPFLAG = -c
> +COBJFLAG = -o\ # whitespace intended
> +LOBJFLAG = -o\ # whitespace intended
I think it's nicer to write the significant whitespace with non-whitespace
text using something like:
empty=
space=$(empty) $(empty)
(...)
ARFLAGS = rcs$(space)
COBJFLAG = -o$(space)
On the other hand, I think it would be clearer to put the "rcs" in the
default version of $(AR), and have a $(AROBJFLAG) set to nothing there,
since the "rcs" isn't actually at all like the "-OUT:" with respect to
what it's doing there.
Possibly also to have two variables for the output of the toolchain
wrapper, one that is before the name of the file and one that's attached
to the name of the file.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [RFC] Enable compilation by Makefile for the MSVC toolchain
From: Junio C Hamano @ 2009-08-18 16:51 UTC (permalink / raw)
To: Marius Storm-Olsen
Cc: Johannes.Schindelin, msysgit, git, lznuaa, bonzini, kusmabite
In-Reply-To: <1250600335-8642-1-git-send-email-mstormo@gmail.com>
Marius Storm-Olsen <mstormo@gmail.com> writes:
Marius Storm-Olsen <mstormo@gmail.com> writes:
> +ARFLAGS = rcs\ # whitespace intentional
> +COMPFLAG = -c
> +COBJFLAG = -o\ # whitespace intended
> +LOBJFLAG = -o\ # whitespace intended
> ...
> +ifneq (,$(findstring Microsoft Visual Studio, $(INCLUDE)))
> + CC = cl
> + COBJFLAG = -Fo
> + LOBJFLAG = -OUT:
> + CFLAGS =
> git.o: git.c common-cmds.h GIT-CFLAGS
> ...
> - $(ALL_CFLAGS) -c $(filter %.c,$^)
> + $(ALL_CFLAGS) $(COMPFLAG) $(COBJFLAG)git.o $(filter %.c,$^)
Since use of make implies use of shell, this makes me wonder if it would
make sense to go one step further by giving msvc users a thin shell
wrapper mcvc-cc that turns bog-standard cc command line into whatever cl
uses.
^ permalink raw reply
* Re: [PATCH] block-sha1: Windows declares ntohl() in winsock2.h
From: Junio C Hamano @ 2009-08-18 16:50 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Sebastian Schuberth, Artur Skawina, Johannes Sixt, msysGit,
Linus Torvalds, Git Mailing List
In-Reply-To: <alpine.LFD.2.00.0908181240400.6044@xanadu.home>
Nicolas Pitre <nico@cam.org> writes:
> On Tue, 18 Aug 2009, Nicolas Pitre wrote:
>
>> Well... Given that git already uses ntohl/htonl quite extensively in
>> its core already, I'd suggest making this more globally available
>> instead.
>
> What about something like this?
For git's own use, I would be much happier with this change.
But given that there are some people wanting to snarf block-sha1/*.[ch]
out to use them standalone, I have a slight hesitation against introducing
the dependency to git-compat-util.h, making it unclear to them that all
this file wants from outside are ntohl, htonl and memcpy.
^ permalink raw reply
* Re: [PATCH v5 0/6] {checkout,reset,stash} --patch
From: Jeff King @ 2009-08-18 16:48 UTC (permalink / raw)
To: Thomas Rast
Cc: Junio C Hamano, git, Sverre Rabbelier, Nanako Shiraishi,
Nicolas Sebrecht, Pierre Habouzit
In-Reply-To: <200908151204.36709.trast@student.ethz.ch>
On Sat, Aug 15, 2009 at 12:04:35PM +0200, Thomas Rast wrote:
> > Getting greedy, is there a reason not to have "stash apply -p" as well?
>
> Should be doable, I'll look at it.
I took a look at this today. It is actually a bit harder than I had
hoped. The problem is that a stash is not a _state_, but rather two
states whose difference is of interest to us.
So it's not right to just pick hunks out of the stash as compared with
the current tree. You will get "false" hunks for the changes between
the current tree and the base upon which the stash was created. In fact,
we actually do a full 3-way merge with the current state and the new
state with the stash base as the ancestor.
The strategy I employ in the patch below is to actually just prune the
stash tree against the base, and then use that result to do the merge.
For example, consider the following situation:
$ echo base >file && git add file && git commit -m base
$ echo stash >file && git stash
$ echo tree >file && git add file
Now you have a stash whose base has 'base' and whose content has
'stash', and your current tree has 'tree'. Applying the stash should
therefore cause a conflict (but I am using such a simple example because
we can still illustrate what's happening).
You can see that ignoring the base creates an incorrect result. You
would see that the stash has 'stash' and we have 'tree', and ask about
applying the hunk
-tree
+stash
but that's not right. We should have a conflict.
So what I do instead is to load the base tree into a temporary index,
then git-add--interactive the changes from the stashed tree, then put
write the result into a new tree, which becomes our new merge point. So
you will be asked if you want to apply the hunk
-base
+stash
If not, then the resulting tree will have 'base'. Since the base also
has 'base', the stash has done nothing, and the 3-way merge will keep
your tree contents. If you do, then the resulting tree will have
'stash', and you will have a 3-way merge with a conflict.
Now there is a slight problem with that. What if you had already applied
or recreated part of the stash? In other words, instead of 'tree' in
your current content, you had 'stash'? We would _still_ ask if you
wanted to replace 'base' with 'stash', even though when we get to the
three-way merge, it will be a no-op.
Hmm. I was about to write "so we need some clever way of integrating the
interactive hunk selection with a 3-way merge". But I just had a
thought: we should do it in the reverse order. We do the three-way merge
into a temporary index, and then ask the user to apply the result of
_that_ tree into the working tree. Or maybe I am missing something else
obvious and you can enlighten me.
I'll try to experiment with merging first, though I doubt I will have
any more time for the next day or two. In the meantime, you can peek at
the current patch I have below. It has two additional problems:
1. For --index mode, it actually invokes add--interactive twice. It
would be nice to do both passes at the same time, but I don't think
it is possible with the current add--interactive infrastructure.
2. You will notice a hack-ish 'sleep' in the test; because of the
double add--interactive, when piping from stdin, the first one eats
the responses in its input buffer and the second one never sees
them.
-Peff
---
git-add--interactive.perl | 28 ++++++++++++++++++++++++++++
git-stash.sh | 35 +++++++++++++++++++++++++++++------
t/t3905-stash-apply-patch.sh | 42 ++++++++++++++++++++++++++++++++++++++++++
3 files changed, 99 insertions(+), 6 deletions(-)
create mode 100755 t/t3905-stash-apply-patch.sh
diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index 392efb9..cbbf0a7 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -97,6 +97,28 @@ my %patch_modes = (
PARTICIPLE => 'stashing',
FILTER => undef,
},
+ 'stash-apply-tree' => {
+ DIFF => 'diff-index -R -p --cached',
+ APPLY => sub {
+ apply_patch 'apply --cached', $patch_mode_revision, @_;
+ },
+ APPLY_CHECK => 'apply --cached',
+ VERB => 'Apply',
+ TARGET => ' to working tree',
+ PARTICIPLE => 'applying',
+ FILTER => undef,
+ },
+ 'stash-apply-index' => {
+ DIFF => 'diff-index -R -p --cached',
+ APPLY => sub {
+ apply_patch 'apply --cached', $patch_mode_revision, @_;
+ },
+ APPLY_CHECK => 'apply --cached',
+ VERB => 'Apply',
+ TARGET => ' to index',
+ PARTICIPLE => 'applying',
+ FILTER => undef,
+ },
'reset_head' => {
DIFF => 'diff-index -p --cached',
APPLY => sub { apply_patch 'apply -R --cached', @_; },
@@ -1507,6 +1529,12 @@ sub process_args {
'checkout_head' : 'checkout_nothead');
$arg = shift @ARGV or die "missing --";
}
+ } elsif ($1 eq 'stash-apply-tree'
+ || $1 eq 'stash-apply-index') {
+ $patch_mode = $1;
+ $arg = shift @ARGV or die "missing --";
+ $patch_mode_revision = $arg;
+ $arg = shift @ARGV or die "missing --";
} elsif ($1 eq 'stage' or $1 eq 'stash') {
$patch_mode = $1;
$arg = shift @ARGV or die "missing --";
diff --git a/git-stash.sh b/git-stash.sh
index 9efc46d..8090bbf 100755
--- a/git-stash.sh
+++ b/git-stash.sh
@@ -214,8 +214,19 @@ show_stash () {
git diff $flags $b_commit $w_commit
}
+munge_tree_interactive () {
+ (
+ GIT_INDEX_FILE="$TMP-index"
+ export GIT_INDEX_FILE
+ git read-tree --reset "$2" &&
+ git add--interactive --patch=stash-apply-$1 "$3" -- >&3 &&
+ git write-tree
+ )
+}
+
apply_stash () {
unstash_index=
+ patch_mode=
while test $# != 0
do
@@ -226,6 +237,9 @@ apply_stash () {
-q|--quiet)
GIT_QUIET=t
;;
+ -p|--patch)
+ patch_mode=t
+ ;;
*)
break
;;
@@ -258,12 +272,21 @@ apply_stash () {
if test -n "$unstash_index" && test "$b_tree" != "$i_tree" &&
test "$c_tree" != "$i_tree"
then
- git diff-tree --binary $s^2^..$s^2 | git apply --cached
- test $? -ne 0 &&
- die 'Conflicts in index. Try without --index.'
- unstashed_index_tree=$(git write-tree) ||
- die 'Could not save index tree'
- git reset
+ if test -n "$patch_mode"; then
+ i_tree=`munge_tree_interactive index $b_tree $i_tree` 3>&1
+ fi
+ if test "$b_tree" != "$i_tree"; then
+ git diff-tree --binary $b_tree $i_tree | git apply --cached
+ test $? -ne 0 &&
+ die 'Conflicts in index. Try without --index.'
+ unstashed_index_tree=$(git write-tree) ||
+ die 'Could not save index tree'
+ git reset
+ fi
+ fi
+
+ if test -n "$patch_mode"; then
+ w_tree=`munge_tree_interactive tree $b_tree $w_tree` 3>&1
fi
eval "
diff --git a/t/t3905-stash-apply-patch.sh b/t/t3905-stash-apply-patch.sh
new file mode 100755
index 0000000..07cd69b
--- /dev/null
+++ b/t/t3905-stash-apply-patch.sh
@@ -0,0 +1,42 @@
+#!/bin/sh
+
+test_description='git stash apply --patch'
+. ./lib-patch-mode.sh
+
+test_expect_success 'setup' '
+ test_commit one bar bar_head &&
+ test_commit two foo foo_head &&
+ set_state bar bar_work bar_index &&
+ set_state foo foo_work foo_index &&
+ save_head &&
+ git stash
+'
+
+test_expect_success 'saying "n" does nothing' '
+ git reset --hard &&
+ (echo n; echo n) | git stash apply -p &&
+ verify_state bar bar_head bar_head &&
+ verify_state foo foo_head foo_head
+'
+
+# n/y will apply foo but not bar
+test_expect_success 'git stash apply -p' '
+ git reset --hard &&
+ (echo n; echo y) | git stash apply -p &&
+ verify_state bar bar_head bar_head &&
+ verify_state foo foo_work foo_head
+'
+
+# we need two per file, for index and working tree
+test_expect_success 'git stash apply -p --index' '
+ git reset --hard &&
+ (echo n; echo y; sleep 2; echo n; echo y) | git stash apply -p --index &&
+ verify_state bar bar_head bar_head &&
+ verify_state foo foo_work foo_index
+'
+
+test_expect_success 'none of this moved HEAD' '
+ verify_saved_head
+'
+
+test_done
--
1.6.4.304.ge0c3be.dirty
^ permalink raw reply related
* Re: Windows & executable bit
From: Johan 't Hart @ 2009-08-18 16:47 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Erik Faye-Lund, Thomas Rast, Ferry Huberts, msysgit, git
In-Reply-To: <alpine.DEB.1.00.0908181459380.4680@intel-tinevez-2-302>
Johannes Schindelin schreef:
> Hi,
> Bah, you're right. I let myself fool by the lowercase 'm'. Sorry.
Haha. Looking with developer eyes. I know that problem from someone...
Oh yea, me.
^ permalink raw reply
* Re: [PATCH] block-sha1: Windows declares ntohl() in winsock2.h
From: Junio C Hamano @ 2009-08-18 16:43 UTC (permalink / raw)
To: Sebastian Schuberth
Cc: Linus Torvalds, Junio C Hamano, Artur Skawina, Johannes Sixt,
msysGit, Nicolas Pitre, Git Mailing List
In-Reply-To: <bdca99240908180923x49213f30q79cf9424c6aa8202@mail.gmail.com>
Sebastian Schuberth <sschuberth@gmail.com> writes:
> On Tue, Aug 18, 2009 at 18:08, Linus
> Torvalds<torvalds@linux-foundation.org> wrote:
>
>>> I'd suggest not using a gcc builtin, since if you're using gcc you might
>>> as well just use inline asm that has been around forever (unlike the
>>> builtin).
>>
>> That seems to be what glibc does too.
>>
>> Here's a patch.
>
> Looks good to me, compiles & runs fine on Windows (with Hannes' patch
> also applied).
But the Windows part that avoids arpa/inet.h and includes winsock2.h, only
to undef the two macros immediately after doing so, now looks quite silly.
Are there non i386/amd64 Windows we care about?
Squashing Linus's and Hannes's patch here is what I came up with.
-- >8 --
block-sha1: avoid potentially inefficient ntohl/htonl on i386/x86-64
Johannes Sixt reports that on Windows ntohl()/htonl() are not found in
<arpa/inet.h>, and minimally we need to include <winsock2.h> instead.
Sebastian Schuberth points out that they are implemented as out-of-line
functions on Windows, which defeats the use of these byteorder "macros"
for performance.
Use bswap instruction through gcc inline asm instead on i386/x86-64
as a generic solution to this.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>,
---
diff --git a/block-sha1/sha1.c b/block-sha1/sha1.c
index a1228cf..fa909a3 100644
--- a/block-sha1/sha1.c
+++ b/block-sha1/sha1.c
@@ -7,8 +7,6 @@
*/
#include <string.h>
-#include <arpa/inet.h>
-
#include "sha1.h"
#if defined(__i386__) || defined(__x86_64__)
@@ -24,8 +22,15 @@
#define SHA_ROL(x,n) SHA_ASM("rol", x, n)
#define SHA_ROR(x,n) SHA_ASM("ror", x, n)
+#undef htonl
+#undef ntohl
+#define htonl(x) ({ unsigned int __res; __asm__("bswap %0":"=r" (__res):"0" (x)); __res; })
+#define ntohl(x) htonl(x)
+
#else
+#include <arpa/inet.h>
+
#define SHA_ROT(X,l,r) (((X) << (l)) | ((X) >> (r)))
#define SHA_ROL(X,n) SHA_ROT(X,n,32-(n))
#define SHA_ROR(X,n) SHA_ROT(X,32-(n),n)
^ permalink raw reply related
* Re: [PATCH] block-sha1: Windows declares ntohl() in winsock2.h
From: Nicolas Pitre @ 2009-08-18 16:43 UTC (permalink / raw)
To: Junio C Hamano
Cc: Sebastian Schuberth, Artur Skawina, Johannes Sixt, msysGit,
Linus Torvalds, Git Mailing List
In-Reply-To: <alpine.LFD.2.00.0908181147510.6044@xanadu.home>
On Tue, 18 Aug 2009, Nicolas Pitre wrote:
> Well... Given that git already uses ntohl/htonl quite extensively in
> its core already, I'd suggest making this more globally available
> instead.
What about something like this?
diff --git a/block-sha1/sha1.c b/block-sha1/sha1.c
index 464cb25..51a27c1 100644
--- a/block-sha1/sha1.c
+++ b/block-sha1/sha1.c
@@ -4,9 +4,7 @@
* and to avoid unnecessary copies into the context array.
*/
-#include <string.h>
-#include <arpa/inet.h>
-
+#include "../git-compat-util.h"
#include "sha1.h"
#if defined(__i386__) || defined(__x86_64__)
diff --git a/compat/bswap.h b/compat/bswap.h
new file mode 100644
index 0000000..b436360
--- /dev/null
+++ b/compat/bswap.h
@@ -0,0 +1,19 @@
+/*
+ * Let's make sure we always have a sane definition for ntohl()/htonl().
+ * Some libraries define those as a function call, just to perform byte
+ * shifting, bringing significant overhead to what should be a sinple
+ * operation.
+ */
+
+#if defined(__GNUC__) && (defined(__i386__) || defined(__x86_64__))
+
+#define bswap32(x) ({ \
+ unsigned int __res; \
+ __asm__("bswap %0" : "=r" (__res) : "0" (x)); \
+ __res; })
+#undef ntohl
+#undef htonl
+#define ntohl(x) bswap32(x)
+#define htonl(x) bswap32(x)
+
+#endif
diff --git a/git-compat-util.h b/git-compat-util.h
index 9f941e4..000859e 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -176,6 +176,8 @@ extern char *gitbasename(char *);
#endif
#endif
+#include "compat/bswap.h"
+
/* General helper functions */
extern void usage(const char *err) NORETURN;
extern void die(const char *err, ...) NORETURN __attribute__((format (printf, 1, 2)));
^ permalink raw reply related
* Re: [PATCH] block-sha1: Windows declares ntohl() in winsock2.h
From: Nicolas Pitre @ 2009-08-18 16:30 UTC (permalink / raw)
To: Junio C Hamano
Cc: Sebastian Schuberth, Artur Skawina, Johannes Sixt, msysGit,
Linus Torvalds, Git Mailing List
In-Reply-To: <7v4os5gs0p.fsf@alter.siamese.dyndns.org>
On Tue, 18 Aug 2009, Junio C Hamano wrote:
> Sebastian Schuberth <sschuberth@gmail.com> writes:
>
> > On Tue, Aug 18, 2009 at 14:56, Artur Skawina<art.08.09@gmail.com> wrote:
> > ...
> >> I'd limit it to windows and any other ia32 platform that doesn't pick the
> >> bswaps itself; as is, it just adds an unnecessary hidden gcc dependency.
> >>
> >> Hmm, it's actually a gcc-4.3+ dependency, so it won't even build w/ gcc 4.2;
> >> something like this would be required: "(__GNUC__>=4 && __GNUC_MINOR__>=3)" .
> >
> > So, as you say the code makes no difference under Linux, would you be
> > OK with just testing for GCC 4.3+, and not for Windows? That would get
> > rid of the "hidden" GCC dependency and not make the preprocessor
> > checks overly complex. Moreover, limiting my patch to any "platform
> > that doesn't pick the bswaps itself" could possibly require
> > maintenance on compiler / CRT updates.
>
> I would say that should be fine, but I'd let Linus and Nico to overrule me
> on this if they have any input.
Well... Given that git already uses ntohl/htonl quite extensively in
its core already, I'd suggest making this more globally available
instead.
Nicolas
^ permalink raw reply
* Re: [RFC] Enable compilation by Makefile for the MSVC toolchain
From: Reece Dunn @ 2009-08-18 16:28 UTC (permalink / raw)
To: Johan 't Hart
Cc: Marius Storm-Olsen, Johannes.Schindelin, msysgit, git, lznuaa,
bonzini, kusmabite
In-Reply-To: <4A8AD561.1020303@gmail.com>
2009/8/18 Johan 't Hart <johanthart@gmail.com>:
> Marius Storm-Olsen schreef:
>>
>> From: Marius Storm-Olsen <mstormo@gmail.com>
>>
>> By using GNU Make we can also compile with the MSVC toolchain.
>> This is a rudementary patch, only meant as an RFC for now!!
>>
>
> Would this mean that only the MSVC toolchain is used to build git in batch?
> Or does GNU Make create a .vcproj file like CMake? Because that ofcource is
> the whole purpose of using CMake. One can use the Visual Studio IDE to hack
> on git.
... unless you add a file to the vcproj, or change the project
settings: you'll need to update the CMake file and the Make file (for
the POSIX builds), otherwise you're going to break things.
- Reece
^ permalink raw reply
* Re: [PATCH] block-sha1: Windows declares ntohl() in winsock2.h
From: Sebastian Schuberth @ 2009-08-18 16:23 UTC (permalink / raw)
To: Linus Torvalds
Cc: Junio C Hamano, Artur Skawina, Johannes Sixt, msysGit,
Nicolas Pitre, Git Mailing List
In-Reply-To: <alpine.LFD.2.01.0908180906441.3162@localhost.localdomain>
On Tue, Aug 18, 2009 at 18:08, Linus
Torvalds<torvalds@linux-foundation.org> wrote:
>> I'd suggest not using a gcc builtin, since if you're using gcc you might
>> as well just use inline asm that has been around forever (unlike the
>> builtin).
>
> That seems to be what glibc does too.
>
> Here's a patch.
Looks good to me, compiles & runs fine on Windows (with Hannes' patch
also applied).
--
Sebastian Schuberth
^ permalink raw reply
* Re: [RFC] Enable compilation by Makefile for the MSVC toolchain
From: Johan 't Hart @ 2009-08-18 16:22 UTC (permalink / raw)
To: Marius Storm-Olsen
Cc: Johannes.Schindelin, msysgit, git, lznuaa, bonzini, kusmabite
In-Reply-To: <1250600335-8642-1-git-send-email-mstormo@gmail.com>
Marius Storm-Olsen schreef:
> From: Marius Storm-Olsen <mstormo@gmail.com>
>
> By using GNU Make we can also compile with the MSVC toolchain.
> This is a rudementary patch, only meant as an RFC for now!!
>
Would this mean that only the MSVC toolchain is used to build git in
batch? Or does GNU Make create a .vcproj file like CMake? Because that
ofcource is the whole purpose of using CMake. One can use the Visual
Studio IDE to hack on git.
^ permalink raw reply
* Re: [msysGit] Re: [PATCH 02/11] Fix declare variable at mid of function
From: Frank Li @ 2009-08-18 16:11 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Marius Storm-Olsen, Reece Dunn, git, msysgit
In-Reply-To: <alpine.DEB.1.00.0908181132470.4680@intel-tinevez-2-302>
> Okay, I will wait for Frank's updates (just fetched tgit.git and it still
> contains the old branch), merge the early part and add the compiler flags.
>
Today, I just update 5 patch according review feedback.
Do I need send it again?
I have push my change to tgit
git://repo.or.cz/tgit.git
branch vcpatch2
How do I know if patch has been applied main line?
^ permalink raw reply
* Re: [PATCH] block-sha1: Windows declares ntohl() in winsock2.h
From: Linus Torvalds @ 2009-08-18 16:08 UTC (permalink / raw)
To: Junio C Hamano
Cc: Sebastian Schuberth, Artur Skawina, Johannes Sixt, msysGit,
Nicolas Pitre, Git Mailing List
In-Reply-To: <alpine.LFD.2.01.0908180836440.3162@localhost.localdomain>
On Tue, 18 Aug 2009, Linus Torvalds wrote:
>
> I'd suggest not using a gcc builtin, since if you're using gcc you might
> as well just use inline asm that has been around forever (unlike the
> builtin).
That seems to be what glibc does too.
Here's a patch.
Linus
---
block-sha1/sha1.c | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/block-sha1/sha1.c b/block-sha1/sha1.c
index 464cb25..e6e7170 100644
--- a/block-sha1/sha1.c
+++ b/block-sha1/sha1.c
@@ -22,6 +22,11 @@
#define SHA_ROL(x,n) SHA_ASM("rol", x, n)
#define SHA_ROR(x,n) SHA_ASM("ror", x, n)
+#undef htonl
+#undef ntohl
+#define htonl(x) ({ unsigned int __res; __asm__("bswap %0":"=r" (__res):"0" (x)); __res; })
+#define ntohl(x) htonl(x)
+
#else
#define SHA_ROT(X,l,r) (((X) << (l)) | ((X) >> (r)))
^ permalink raw reply related
* Simple commit mechanism for non-technical users
From: D Sundstrom @ 2009-08-18 16:05 UTC (permalink / raw)
To: git
I use git to manage all project artifacts, including documentation,
proposals, presentations, and so on.
However, I have a hard time convincing non-technical staff to learn
enough about git or to take the time to go through the effort of
committing changes to a repository. So the steady stream of email
attachments with "Acme Specification v3" or "final final spemco
proprosal" continues.
I'd hoped there was a simple web interface that would allow a user to
upload and commit a file to a repository, but I've had no luck finding
one. (I've used cgit for browsing, but it is read-only).
Is anyone aware of a simple way I can have my non-technical users
manage their documents against a git repository? Ideally this would
involve no installation of software on their machine (unless it were
compelling, for example, the Finder plugin for SVN on the mac was a
great tool for these users; or at least those on a mac...)
-David
^ permalink raw reply
* Re: git find (was: [RFC PATCH v3 8/8] --sparse for porcelains)
From: Jakub Narebski @ 2009-08-18 16:00 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: skillzero, Johannes Schindelin, Junio C Hamano, git
In-Reply-To: <fcaeb9bf0908180735s583bfdcajc354723c9faa48@mail.gmail.com>
On Tue, Aug 18, 2009, Nguyen Thai Ngoc Duy wrote:
> On Tue, Aug 18, 2009 at 1:25 PM, Jakub Narebski<jnareb@gmail.com> wrote:
> >
> > Well, I also think that it would be nice and useful to have "git find"
> > in addition to current "git grep".
>
> Can you make a draft on how you want "git find" to be? Except the
> "-exec" part, Git allows us to search using various commands
> (ls-files, rev-list, log). I don't think a single "git find" can cover
> them all. I was thinking about putting more find-options to search
> commands we already have. ls-files would support -exec, for example.
Both git-rev-list and git-ls-files are plumbing, not porcelain. Among
tools / commands you have mentioned only git-log is porcelain.
You need to process output of git-ls-files if you want to use more
complicated search criteria.
>
> A few things that I'd love to have supported:
> - --depth for ls-files (probably all pathspec-as-argument commands)
> - logical combination of search criteria
> - unified blob locator. git-show understands SHA-1:/path/to/blob
> syntax. What if git-log can output using similar syntax, then feed
> them to git-grep in order to grep through (across commits)?
Draft specification for git-find. git-find, like git-grep, searches
the filesystem dimension, and not time dimension like git-log.
git-find(1)
===========
NAME
----
git-find - Search for files in a repository
SYNOPSIS
--------
'git find' [--cached] [-z|--null] [(<tree> | <path>)...] [<expression>]
OPTIONS
-------
--cached::
Instead of searching in the working tree files, check
the blobs registered in the index file.
EXPRESSIONS
-----------
The expression is made up of options (which affect overall operation rather
than the processing of a specific file, and always return true), tests
(which return a true or false value), and actions (which have side effects
and return a true or false value), all separated by operators. `--and` is
assumed where the operator is omitted. If the expression contains no
actions other than `--prune`, `--print` is performed on all files for which
the expression is true.
OPTIONS
~~~~~~~
--max-depth <levels>::
Descend at most levels (a non-negative integer) levels of
directories below the command line arguments. `--max-depth 0`
means only apply the tests and actions to the command line
arguments.
--min-depth <levels>::
Do not apply any tests or actions at levels less than levels
(a non-negative integer). `--min-depth 1` means process all
files except the command line arguments.
TESTS
~~~~~
--false::
Always false.
--true::
Always true.
--name <pattern>::
--iname <pattern>::
--path <pattern>::
--ipath <pattern>::
[Entire] Filename matches glob.
--regex <expr>::
--iregex <expr>::
Entire file name matches regular expression.
--lname <pattern>::
--ilname <pattern>::
True if the file is a symbolic link whose contents match glob.
--size <n>[<unit>]::
True if the file uses N units of space, rounding up.
--empty::
File is empty and is either a regular file or a directory.
--type <C>::
True if file is of type C: 'd' for directory, 'f' for regular
file, 'l' for symbolic link, 's' for submodule, 'x' for
executable regular file (replaces `-perm` from 'find').
ACTIONS
~~~~~~~
(--exec | --ok) <command> ;
Execute command; true if 0 status is returned.
(--execdir | --okdir) <command> ;
Like `--exec`, but the specified command is run from the
subdirectory containing the matched file.
--print::
--print0::
--printf <format>::
--fprint <file>::
--fprint0 <file>::
--fprintf <file> <format>::
True; print the full file name.
--prune::
True; if the file is a directory, do not descend into it.
--quit::
Exit immediately.
OPERATORS
~~~~~~~~~
--and::
--or::
--not::
( ... )::
Specify how multiple expressions are combined using Boolean
expressions. `--and` is the default operator.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: Git User's Survey 2009 partial summary, part 2 - from first 10
From: Nicolas Sebrecht @ 2009-08-18 15:54 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200908171224.44686.jnareb@gmail.com>
The 17/08/09, Jakub Narebski wrote:
> Git User's Survey 2009 partial summary, part 2 - git difficulty,
> proficiency, uses, install, OS, editors.
Thanks for these partial summaries.
> 3) Have you found Git easy to learn?
> 4) Have you found Git easy to use?
> (Choice - Single answer)
>
> ================================================
> Answer | to learn [%] | to use [%]
> ------------------------------------------------
> Very easy | 4% | 9%
> Easy | 20% | 36%
> Reasonably easy | 55% | 45%
> Hard | 19% | 8%
> Very hard | 2% | 1%
> ------------------------------------------------
> Total respondents | 2942 | 2959
> ================================================
<...>
> What's interesting is comparing (percentage) results for questions
> 3. and 4.; how hard is git to learn versus how hard is to use. It
> seems like Git is reasonably easy to learn, and reasonably easy to
> easy to use. So it looks like Git just have somewhat steep learning
> curve, and the difficulty to learn pays in being more powerful to
> use.
I believe it would be interesting to know who (from the question 6.)
think what later. We may expect that people of the grade 4 and 5 ("can
offer advice" and "know it very well") underestimate the difficulty to
learn Git.
Also (and as you said), this "Git's users" survey won't have answers
from unsatisfied users who left Git. We can't rate the number of users
who left Git because they found it too much hard to learn.
> 6) Rate your own proficiency with Git:
> (Choice - Single answer)
>
> You can think of it as 1-5 numerical grade of your proficiency in Git.
>
> ================================================
> Proficiency | resp [%] | resp [n]
> ------------------------------------------------
> 1. novice | 4% | 114
> 2. casual, needs advice | 17% | 520
> 3. everyday use | 38% | 1138
> 4. can offer advice | 34% | 1020
> 5. know it very well | 6% | 192
> --------------------------+---------------------
> Total respondents | 2984
> Skipped this question | 105
> ================================================
--
Nicolas Sebrecht
^ permalink raw reply
* Re: [PATCH] block-sha1: Windows declares ntohl() in winsock2.h
From: Linus Torvalds @ 2009-08-18 15:40 UTC (permalink / raw)
To: Junio C Hamano
Cc: Sebastian Schuberth, Artur Skawina, Johannes Sixt, msysGit,
Nicolas Pitre, Git Mailing List
In-Reply-To: <7v4os5gs0p.fsf@alter.siamese.dyndns.org>
On Tue, 18 Aug 2009, Junio C Hamano wrote:
> Sebastian Schuberth <sschuberth@gmail.com> writes:
>
> > On Tue, Aug 18, 2009 at 14:56, Artur Skawina<art.08.09@gmail.com> wrote:
> > ...
> >> I'd limit it to windows and any other ia32 platform that doesn't pick the
> >> bswaps itself; as is, it just adds an unnecessary hidden gcc dependency.
> >>
> >> Hmm, it's actually a gcc-4.3+ dependency, so it won't even build w/ gcc 4.2;
> >> something like this would be required: "(__GNUC__>=4 && __GNUC_MINOR__>=3)" .
> >
> > So, as you say the code makes no difference under Linux, would you be
> > OK with just testing for GCC 4.3+, and not for Windows? That would get
> > rid of the "hidden" GCC dependency and not make the preprocessor
> > checks overly complex. Moreover, limiting my patch to any "platform
> > that doesn't pick the bswaps itself" could possibly require
> > maintenance on compiler / CRT updates.
>
> I would say that should be fine, but I'd let Linus and Nico to overrule me
> on this if they have any input.
I'd suggest not using a gcc builtin, since if you're using gcc you might
as well just use inline asm that has been around forever (unlike the
builtin).
Just do:
#if defined(__GNUC__)
#define htonl(x) ({ unsigned int __res; \
__asm__("bswap %0":"=r" (__res):"0" (x)); \
__res; })
#define ntohl(x) htonl(x)
#endif
or similar in the x86 section that does the rol/ror thing.
Linus
^ permalink raw reply
* Re: [PATCH 01/11] Fix build failure at VC because function declare use old style at regex.c
From: Frank Li @ 2009-08-18 15:03 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, kusmabite, msysgit
In-Reply-To: <alpine.DEB.1.00.0908171822130.4991@intel-tinevez-2-302>
- there are a lot more functions with K&R style function definitions than
> just regerror().
>
I double check it. VC can compile K&R style function. This patch is redundancy
^ permalink raw reply
* Re: git find (was: [RFC PATCH v3 8/8] --sparse for porcelains)
From: Nguyen Thai Ngoc Duy @ 2009-08-18 14:35 UTC (permalink / raw)
To: Jakub Narebski; +Cc: skillzero, Johannes Schindelin, Junio C Hamano, git
In-Reply-To: <200908180825.55289.jnareb@gmail.com>
On Tue, Aug 18, 2009 at 1:25 PM, Jakub Narebski<jnareb@gmail.com> wrote:
> Well, I also think that it would be nice and useful to have "git find"
> in addition to current "git grep".
Can you make a draft on how you want "git find" to be? Except the
"-exec" part, Git allows us to search using various commands
(ls-files, rev-list, log). I don't think a single "git find" can cover
them all. I was thinking about putting more find-options to search
commands we already have. ls-files would support -exec, for example.
A few things that I'd love to have supported:
- --depth for ls-files (probably all pathspec-as-argument commands)
- logical combination of search criteria
- unified blob locator. git-show understands SHA-1:/path/to/blob
syntax. What if git-log can output using similar syntax, then feed
them to git-grep in order to grep through (across commits)?
--
Duy
^ permalink raw reply
* Re: [RFC] Enable compilation by Makefile for the MSVC toolchain
From: Johannes Schindelin @ 2009-08-18 14:11 UTC (permalink / raw)
To: Marius Storm-Olsen; +Cc: msysgit, git, lznuaa, bonzini, kusmabite
In-Reply-To: <1250600335-8642-1-git-send-email-mstormo@gmail.com>
Hi,
On Tue, 18 Aug 2009, Marius Storm-Olsen wrote:
> So, instead of rely on these vcproj files which *will* go stale, we can
> simply use the same Makefile system which everyone else is using. :)
> After all, we're just compiling with a different compiler. The end
> result will still rely on the *msysGit environment* to function, so we
> already require it. Thus, GNU Make is present, and we can use it.
We can also use sed or perl to generate/modify the .vcproj files, or run
CMake (once Pau got it to build), and package the stuff using zip (once I
got that to build).
> diff --git a/Makefile b/Makefile
> index daf4296..2e14976 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -214,9 +214,13 @@ uname_V := $(shell sh -c 'uname -v 2>/dev/null || echo not')
>
> CFLAGS = -g -O2 -Wall
> LDFLAGS =
> +ARFLAGS = rcs\ # whitespace intentional
> ALL_CFLAGS = $(CFLAGS)
> ALL_LDFLAGS = $(LDFLAGS)
> STRIP ?= strip
> +COMPFLAG = -c
> +COBJFLAG = -o\ # whitespace intended
> +LOBJFLAG = -o\ # whitespace intended
These probably want to go into the Microsoft Visual C++ specific section.
> @@ -874,6 +878,58 @@ ifneq (,$(findstring CYGWIN,$(uname_S)))
> COMPAT_OBJS += compat/cygwin.o
> UNRELIABLE_FSTAT = UnfortunatelyYes
> endif
> +ifneq (,$(findstring Microsoft Visual Studio, $(INCLUDE)))
> + pathsep = ;
> + MOZILLA_SHA1 = 1
> + NO_PREAD = YesPlease
> + NO_OPENSSL = YesPlease
> + NO_LIBGEN_H = YesPlease
> + NO_SYMLINK_HEAD = YesPlease
> + NO_IPV6 = YesPlease
> + NO_SETENV = YesPlease
> + NO_UNSETENV = YesPlease
> + NO_STRCASESTR = YesPlease
> + NO_STRLCPY = YesPlease
> + NO_MEMMEM = YesPlease
> + NEEDS_LIBICONV = YesPlease
> + OLD_ICONV = YesPlease
> + NO_C99_FORMAT = YesPlease
> + NO_STRTOUMAX = YesPlease
> + NO_MKDTEMP = YesPlease
> + NO_MKSTEMPS = YesPlease
> + SNPRINTF_RETURNS_BOGUS = YesPlease
> + NO_SVN_TESTS = YesPlease
> + NO_PERL_MAKEMAKER = YesPlease
> + RUNTIME_PREFIX = YesPlease
> + NO_POSIX_ONLY_PROGRAMS = YesPlease
> + NO_ST_BLOCKS_IN_STRUCT_STAT = YesPlease
> + NO_NSEC = YesPlease
> + USE_WIN32_MMAP = YesPlease
> + UNRELIABLE_FSTAT = UnfortunatelyYes
> + OBJECT_CREATION_USES_RENAMES = UnfortunatelyNeedsTo
> + NO_REGEX = YesPlease
> +
> + NO_CURL = YesPlease
> + NO_PTHREADS = YesPlease
> +
> + CC = cl
> + COBJFLAG = -Fo
> + LOBJFLAG = -OUT:
> + CFLAGS =
> + BASIC_CFLAGS += -nologo -MT -I. -I../zlib -Icompat/vcbuild -Icompat/vcbuild/include -DWIN32 -D_CONSOLE
> + COMPAT_CFLAGS += -D__USE_MINGW_ACCESS -DNOGDI -Icompat -Icompat/fnmatch -Icompat/regex -Icompat/fnmatch
> + COMPAT_OBJS += compat/mingw.o compat/msvc.o compat/fnmatch/fnmatch.o compat/winansi.o
> + COMPAT_CFLAGS += -DSTRIP_EXTENSION=\".exe\"
> +
> + LINK = link
> + BASIC_LDFLAGS += -NOLOGO -SUBSYSTEM:CONSOLE -NODEFAULTLIB:MSVCRT.lib advapi32.lib shell32.lib wininet.lib ws2_32.lib ../zlib/projects/vc9/Win32_LIB_Release/zlib.lib
> + NO_CFLAGS_TO_LINKER = YesPlease
> + EXTLIBS =
> + AR = lib
> + ARFLAGS = -OUT:
> +
> + X = .exe
> +else
> ifneq (,$(findstring MINGW,$(uname_S)))
> pathsep = ;
> NO_PREAD = YesPlease
This means that gcc is never used when Visual C++ is available? Hmm.
> diff --git a/compat/msvc.h b/compat/msvc.h
> index 6071565..a9d5f7f 100644
> --- a/compat/msvc.h
> +++ b/compat/msvc.h
> @@ -10,50 +10,120 @@
>
> /*Configuration*/
>
> +#ifndef NO_PREAD
> #define NO_PREAD
> +#endif
Why? You now have the stuff in two places. If you want to keep them in
compat/msvc.h to be able to generate .vcproj files, I'd rather not have
them duplicated in the Makefile.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] block-sha1: Windows declares ntohl() in winsock2.h
From: Junio C Hamano @ 2009-08-18 13:39 UTC (permalink / raw)
To: Sebastian Schuberth
Cc: Artur Skawina, Johannes Sixt, msysGit, Junio C Hamano,
Linus Torvalds, Nicolas Pitre, Git Mailing List
In-Reply-To: <bdca99240908180617n75dfd0b5nfe069aba6e74b722@mail.gmail.com>
Sebastian Schuberth <sschuberth@gmail.com> writes:
> On Tue, Aug 18, 2009 at 14:56, Artur Skawina<art.08.09@gmail.com> wrote:
> ...
>> I'd limit it to windows and any other ia32 platform that doesn't pick the
>> bswaps itself; as is, it just adds an unnecessary hidden gcc dependency.
>>
>> Hmm, it's actually a gcc-4.3+ dependency, so it won't even build w/ gcc 4.2;
>> something like this would be required: "(__GNUC__>=4 && __GNUC_MINOR__>=3)" .
>
> So, as you say the code makes no difference under Linux, would you be
> OK with just testing for GCC 4.3+, and not for Windows? That would get
> rid of the "hidden" GCC dependency and not make the preprocessor
> checks overly complex. Moreover, limiting my patch to any "platform
> that doesn't pick the bswaps itself" could possibly require
> maintenance on compiler / CRT updates.
I would say that should be fine, but I'd let Linus and Nico to overrule me
on this if they have any input.
^ permalink raw reply
* Re: [PATCH] block-sha1: Windows declares ntohl() in winsock2.h
From: Sebastian Schuberth @ 2009-08-18 13:17 UTC (permalink / raw)
To: Artur Skawina; +Cc: Johannes Sixt, msysGit, Junio C Hamano, Git Mailing List
In-Reply-To: <4A8AA511.1060205@gmail.com>
On Tue, Aug 18, 2009 at 14:56, Artur Skawina<art.08.09@gmail.com> wrote:
> I did try using __builtin_bswap32 directly and the result was a few
> (3 or 4, iirc) differently scheduled instructions, that's all, no
> performance difference.
[...]
> I'd limit it to windows and any other ia32 platform that doesn't pick the
> bswaps itself; as is, it just adds an unnecessary hidden gcc dependency.
>
> Hmm, it's actually a gcc-4.3+ dependency, so it won't even build w/ gcc 4.2;
> something like this would be required: "(__GNUC__>=4 && __GNUC_MINOR__>=3)" .
So, as you say the code makes no difference under Linux, would you be
OK with just testing for GCC 4.3+, and not for Windows? That would get
rid of the "hidden" GCC dependency and not make the preprocessor
checks overly complex. Moreover, limiting my patch to any "platform
that doesn't pick the bswaps itself" could possibly require
maintenance on compiler / CRT updates.
--
Sebastian Schuberth
^ permalink raw reply
* Re: [RFC] Enable compilation by Makefile for the MSVC toolchain
From: Erik Faye-Lund @ 2009-08-18 13:09 UTC (permalink / raw)
To: Marius Storm-Olsen; +Cc: Johannes.Schindelin, msysgit, git, lznuaa, bonzini
In-Reply-To: <1250600335-8642-1-git-send-email-mstormo@gmail.com>
On Tue, Aug 18, 2009 at 2:58 PM, Marius Storm-Olsen<mstormo@gmail.com> wrote:
> @@ -1331,14 +1396,14 @@ strip: $(PROGRAMS) git$X
> git.o: git.c common-cmds.h GIT-CFLAGS
> $(QUIET_CC)$(CC) -DGIT_VERSION='"$(GIT_VERSION)"' \
> '-DGIT_HTML_PATH="$(htmldir_SQ)"' \
> - $(ALL_CFLAGS) -c $(filter %.c,$^)
> + $(ALL_CFLAGS) $(COMPFLAG) $(COBJFLAG)git.o $(filter %.c,$^)
>
> git$X: git.o $(BUILTIN_OBJS) $(GITLIBS)
> - $(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ git.o \
> + $(QUIET_LINK)$(LINK) $(LINKER_CFLAGS) $(LOBJFLAG)$@ git.o \
> $(BUILTIN_OBJS) $(ALL_LDFLAGS) $(LIBS)
<snip>
> ifdef NO_EXPAT
> http-walker.o: http-walker.c http.h GIT-CFLAGS
> - $(QUIET_CC)$(CC) -o $*.o -c $(ALL_CFLAGS) -DNO_EXPAT $<
> + $(QUIET_CC)$(CC) $(COBJFLAG)$*.o $(COMPFLAG) $(ALL_CFLAGS) -DNO_EXPAT $<
> endif
Perhaps this is the right time to change the make-system to using the
somewhat standard $(COMPLIE.c), $(OUTPUT_OPTION) etc macros?
--
Erik "kusma" Faye-Lund
kusmabite@gmail.com
(+47) 986 59 656
^ permalink raw reply
* Re: [RFC PATCH] stash: accept options also when subcommand 'save' is omitted
From: Matthieu Moy @ 2009-08-18 13:01 UTC (permalink / raw)
To: git; +Cc: Johannes Schindelin
In-Reply-To: <1250599567-31428-1-git-send-email-Matthieu.Moy@imag.fr>
Matthieu Moy <Matthieu.Moy@imag.fr> writes:
> This allows in particular 'git stash --keep-index' which is shorter than
> 'git stash save --keep-index', and not ambiguous.
Hmm, googling a bit, I just noticed that there's already something in
pu:
ea41cfc4f (Make 'git stash -k' a short form for 'git stash save --keep-index')
which also does the trick, while adding a -k alias for --keep-index.
Not sure which hack is best between my
> +case "$1" in
> + -*)
> + set "save" "$@"
> + ;;
> +esac
> +
And the proposed
*)
- if test $# -eq 0
- then
- save_stash &&
+ case $#,"$1" in
+ 0,|1,-k|1,--keep-index)
+ save_stash "$@" &&
say '(To restore them type "git stash apply")'
- else
+ ;;
+ *)
usage
- fi
+ esac
;;
esac
Mine has at least two advantages:
* It won't require changing the code again when new options are added
to 'git stash save'.
* It works with 'git stash -k -q' for example, while the other
proposal checks that $# == 1, which won't work if there are more
than one option.
But I may have missed its drawbacks ;-)
--
Matthieu
^ permalink raw reply
* Re: [RFC] Enable compilation by Makefile for the MSVC toolchain
From: Marius Storm-Olsen @ 2009-08-18 13:01 UTC (permalink / raw)
To: Johannes.Schindelin; +Cc: msysgit, git, lznuaa, bonzini, kusmabite
In-Reply-To: <1250600335-8642-1-git-send-email-mstormo@gmail.com>
Marius Storm-Olsen said the following on 18.08.2009 14:58:
> This is a rudementary patch, only meant as an RFC for now!!
>
> !! DO NOT COMMIT THIS UPSTREAM !!
..meaning in this case Frank Li's repo, and obviously not git.git. :p
--
.marius
^ 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