* Re: question concerning branches
From: Andreas Ericsson @ 2009-08-20 7:33 UTC (permalink / raw)
To: Ingo Brueckl; +Cc: Junio C Hamano, git
In-Reply-To: <4a8c4ece@wupperonline.de>
Ingo Brueckl wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> This is one of the most useful features.
>
> Wow. I'm sursprised to hear that, because I consider it at the moment as a
> very strange one.
>
>> For example, it is an essential
>> part of supporting the workflow described here:
>> http://gitster.livejournal.com/25892.html
>
> Here is what I'd expect to do with git (described with my own words, not in
> git commands):
>
> 1. commit the quick fix to the release branch
> 2. push this single commit to origin and master
>
> Now that all branches have the commit a later push and pull should notice
> this and "skip" it.
>
> This leads to a second question I have. Assuming I have three patches in my
> repo (#1, #2 and #3), is it possible to push only #2 (because it is a
> quick fix) and later, maybe after I committed #4, the rest, i.e. #1, #2 and
> #4?
>
If they're on different branches, yes. If they're on the same branch, no.
This is because a commit in git is named uniquely not only by its contents,
but also by its ancestry.
You can, however, run "git rebase --interactive" and re-order the commits
before you push them, so that #2 becomes #1 and vice versa. Then you can
push only #1 (the old #2) while leaving #2 (the old #1), #3 and #4 on
your machine only. This involves knowing the commit identifier of #1
though. Assuming it's "deadbeef", you can update the remote branch "foo"
to hold your new commit by running the following command:
git push <remote> deadbeef:refs/heads/foo
HTH
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.
^ permalink raw reply
* Re: [PATCH next] t7407: use 'cut' utility rather than bash's substring expansion notation
From: Johan Herland @ 2009-08-20 6:56 UTC (permalink / raw)
To: git; +Cc: Brandon Casey, gitster, Brandon Casey
In-Reply-To: <QHfHFS_5JGiL-O8GMDfdfscFUdxV1xVObzr6e5LPleagDRd7bCg8I9YUwL9xkbgM64vyf_EVLLg@cipher.nrlssc.navy.mil>
On Thursday 20 August 2009, Brandon Casey wrote:
> From: Brandon Casey <drafnel@gmail.com>
>
> The substring expansion notation is a bashism that we have not so far
> adopted. There is precedence for using the 'cut' utility for extracting
> a substring. So do so here.
>
> Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
> ---
> t/t7407-submodule-foreach.sh | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/t/t7407-submodule-foreach.sh b/t/t7407-submodule-foreach.sh
> index de1730d..44ea8ac 100755
> --- a/t/t7407-submodule-foreach.sh
> +++ b/t/t7407-submodule-foreach.sh
> @@ -207,8 +207,8 @@ cat > expect <<EOF
> $nested2sha1 nested1/nested2 (heads/master)
> $nested3sha1 nested1/nested2/nested3 (heads/master)
> $submodulesha1 nested1/nested2/nested3/submodule (heads/master)
> - $sub1sha1 sub1 (${sub1sha1:0:7})
> - $sub2sha1 sub2 (${sub1sha1:0:7})
> + $sub1sha1 sub1 ($(echo $sub1sha1 | cut -c 1-7))
> + $sub2sha1 sub2 ($(echo $sub1sha1 | cut -c 1-7))
Typo (both in the original, and the patch), should be:
$sub2sha1 sub2 ($(echo $sub2sha1 | cut -c 1-7))
> $sub3sha1 sub3 (heads/master)
> EOF
Otherwise:
Acked-by: Johan Herland <johan@herland.net>
Thanks,
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: [PATCH] Add test case for rev-list --parents --show-all
From: Junio C Hamano @ 2009-08-20 4:13 UTC (permalink / raw)
To: Adam Simpkins; +Cc: Santi Béjar, Git Mailing List
In-Reply-To: <20090819225852.GA21187@facebook.com>
Adam Simpkins <simpkins@facebook.com> writes:
> This test case ensures that rev-list --parents --show-all gets the
> parent history correct. Normally, --parents rewrites parent history to
> skip TREESAME parents. However, --show-all causes TREESAME parents to
> still be included in the revision list, so the parents should still be
> included too.
>
> Signed-off-by: Adam Simpkins <simpkins@facebook.com>
> ---
>
> Looking through the code, I believe TREESAME commits are the only ones
> affected by my earlier bug in simplify_commit().
What I meant was actually a test for the graph part (i.e. the problem we
would see if we did not apply your update to graph_is_interesting()), but
protecting the simplify_commit() logic with test from breakage is a good
thing to do as well.
Thanks.
^ permalink raw reply
* Re: question concerning branches
From: Randal L. Schwartz @ 2009-08-20 3:01 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Ingo Brueckl, Jakub Narebski, git
In-Reply-To: <alpine.LFD.2.01.0908191441070.3158@localhost.localdomain>
>>>>> "Linus" == Linus Torvalds <torvalds@linux-foundation.org> writes:
Linus> git branch new-feature
Linus> git checkout new-feature
Or my favorite: "git checkout -b new-feature".
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion
^ permalink raw reply
* Re: [PATCH] block-sha1: Windows declares ntohl() in winsock2.h
From: Brandon Casey @ 2009-08-20 2:45 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Junio C Hamano, Sebastian Schuberth, Artur Skawina, Johannes Sixt,
msysGit, Linus Torvalds, Git Mailing List
In-Reply-To: <alpine.LFD.2.00.0908192201180.6044@xanadu.home>
Nicolas Pitre wrote:
> On Tue, 18 Aug 2009, Brandon Casey wrote:
>
>> The SUNWspro compiler doesn't set __i386__. Instead it sets __i386, and
>> I think __x86_64 and __amd64 where appropriate. So, compilation with
>> the SUNWspro compiler on x86 is currently unaffected by these changes and
>> falls back to the generic routines.
>>
>> It seems that v5.10 of the compiler can grok both the __asm__ statements
>> and the ({...}) naked block notation and passes all of the tests when the
>> block_sha1 code is modified to add defined(__i386) to each of the macro
>> statements.
>>
>> The 5.8 version cannot grok the naked block, and requires spelling __asm__
>> as __asm for inline assembly. Even then it appears that there is a bug in
>> the assembly that is produced (a google search told me so), so the assembly
>> code does not successfully compile.
>>
>> I haven't had much time to think about how or whether to address this.
>>
>> Adding something like the following would get ugly real quick:
>>
>> (defined(__i386) && defined(__SUNPRO_C) && (__SUNPRO_C >= 0x5100))
>
> I think the best solution in this case might simply be to add something
> like this somewhere at the top of git-compat-util.h after the system
> includes:
>
> /*
> * The SUNWspro compiler uses different symbols than gcc.
> * Let's standardize on the gcc flavor.
> */
> #if defined(__i386) && !defined(__i386__)
> #define __i386__
> #endif
> #if (defined(__x86_64) || defined(__amd64)) && !defined(__x86_64__)
> #define __x86_64__
> #endif
Yes, I had this idea too.
> /*
> * SUNWspro from version 5.10 supports gcc extensions such as gcc's
> * statement expressions and extended inline asm, so let's pretend...
> */
> #if defined(__SUNPRO_C) && (__SUNPRO_C >= 0x5100))
> #define __GNUC__
> #endif
I hadn't thought of this. I'll test to make sure the other statements
that are protected by ifdef __GNUC__ work correctly with SUNWspro v5.10.
-brandon
^ permalink raw reply
* Re: gitweb and symbolic links
From: Changsheng Jiang @ 2009-08-20 2:32 UTC (permalink / raw)
To: Marco Gualtieri; +Cc: git
In-Reply-To: <2367E9DF-6FB1-48E6-AC9A-73E84C9D54E1@math.utoronto.ca>
Most WEB servers disable following link for security reasons. Check
it's disabled first.
Changsheng Jiang
On Thu, Aug 20, 2009 at 09:15, Marco Gualtieri<mgualt@math.utoronto.ca> wrote:
> Hello,
>
> I am wondering about a possibly easy bug which you may be aware of.
>
> For some reason if I place a symbolic link in a directory under the project
> root, gitweb is no longer able to find the project. I was looking through
> the .cgi file but I don't know enough perl to fix the problem myself.
>
> Let me know if this makes sense.
> Cheers
> Marco
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH] block-sha1: Windows declares ntohl() in winsock2.h
From: Linus Torvalds @ 2009-08-20 2:30 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Brandon Casey, Junio C Hamano, Sebastian Schuberth, Artur Skawina,
Johannes Sixt, msysGit, Git Mailing List
In-Reply-To: <alpine.LFD.2.00.0908192201180.6044@xanadu.home>
On Wed, 19 Aug 2009, Nicolas Pitre wrote:
>
> I think the best solution in this case might simply be to add something
> like this somewhere at the top of git-compat-util.h after the system
> includes:
I think we can just test __i386.
Gcc defines that one too (in fact, in general, gcc always defines both the
__x and the __x__ versions, although I'm sure there are exceptions)
Linus
^ permalink raw reply
* Re: [PATCH] block-sha1: Windows declares ntohl() in winsock2.h
From: Nicolas Pitre @ 2009-08-20 2:26 UTC (permalink / raw)
To: Brandon Casey
Cc: Junio C Hamano, Sebastian Schuberth, Artur Skawina, Johannes Sixt,
msysGit, Linus Torvalds, Git Mailing List
In-Reply-To: <XJM0H8pTiCJpryS-arPltHCHwsm0djqVixaH1NwBqT2pci2MA9karw@cipher.nrlssc.navy.mil>
On Tue, 18 Aug 2009, Brandon Casey wrote:
> The SUNWspro compiler doesn't set __i386__. Instead it sets __i386, and
> I think __x86_64 and __amd64 where appropriate. So, compilation with
> the SUNWspro compiler on x86 is currently unaffected by these changes and
> falls back to the generic routines.
>
> It seems that v5.10 of the compiler can grok both the __asm__ statements
> and the ({...}) naked block notation and passes all of the tests when the
> block_sha1 code is modified to add defined(__i386) to each of the macro
> statements.
>
> The 5.8 version cannot grok the naked block, and requires spelling __asm__
> as __asm for inline assembly. Even then it appears that there is a bug in
> the assembly that is produced (a google search told me so), so the assembly
> code does not successfully compile.
>
> I haven't had much time to think about how or whether to address this.
>
> Adding something like the following would get ugly real quick:
>
> (defined(__i386) && defined(__SUNPRO_C) && (__SUNPRO_C >= 0x5100))
I think the best solution in this case might simply be to add something
like this somewhere at the top of git-compat-util.h after the system
includes:
/*
* The SUNWspro compiler uses different symbols than gcc.
* Let's standardize on the gcc flavor.
*/
#if defined(__i386) && !defined(__i386__)
#define __i386__
#endif
#if (defined(__x86_64) || defined(__amd64)) && !defined(__x86_64__)
#define __x86_64__
#endif
/*
* SUNWspro from version 5.10 supports gcc extensions such as gcc's
* statement expressions and extended inline asm, so let's pretend...
*/
#if defined(__SUNPRO_C) && (__SUNPRO_C >= 0x5100))
#define __GNUC__
#endif
Nicolas
^ permalink raw reply
* Re: difftool, open all diff files immediately, not in serial
From: Seba Illingworth @ 2009-08-20 1:39 UTC (permalink / raw)
To: git
In-Reply-To: <200908042347.48705.trast@student.ethz.ch>
Thomas Rast <trast <at> student.ethz.ch> writes:
> I posted the script below on IRC the other week[1] in reply to someone
> looking for a way to do this for 'meld'. I'm not sure this is the
> *fastest* way to do this, but I'm at least trying to take a few
> shortcuts...
I've come up with a simple script that diffs the files in a background task:
for name in $(git diff --name-only $1); do git difftool $1 $name & done
Then aliased the script for usage:
git diffall [--staged]
Being a bash newbie, I'd appreciate any feedback on what seems to be
a simple solution...??
^ permalink raw reply
* gitweb and symbolic links
From: Marco Gualtieri @ 2009-08-20 1:15 UTC (permalink / raw)
To: git
Hello,
I am wondering about a possibly easy bug which you may be aware of.
For some reason if I place a symbolic link in a directory under the
project root, gitweb is no longer able to find the project. I was
looking through the .cgi file but I don't know enough perl to fix the
problem myself.
Let me know if this makes sense.
Cheers
Marco
^ permalink raw reply
* [PATCH] git-compat-util.h: remove superfluous test for __sun__
From: Brandon Casey @ 2009-08-20 1:27 UTC (permalink / raw)
To: gitster; +Cc: git, Brandon Casey
From: Brandon Casey <drafnel@gmail.com>
This 'ifndef' macro is entered only when __sun__ is not defined. This test
will never fail since it is located inside of the 'else' branch of an 'if'
macro which tests whether __sun__ is defined. It has had no effect since
the merge at 436f66b7.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
---
git-compat-util.h | 2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/git-compat-util.h b/git-compat-util.h
index 9f941e4..71b5acb 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -57,10 +57,8 @@
# endif
#elif !defined(__APPLE__) && !defined(__FreeBSD__) && !defined(__USLC__) && !defined(_M_UNIX) && !defined(sgi)
#define _XOPEN_SOURCE 600 /* glibc2 and AIX 5.3L need 500, OpenBSD needs 600 for S_ISLNK() */
-#ifndef __sun__
#define _XOPEN_SOURCE_EXTENDED 1 /* AIX 5.3L needs this */
#endif
-#endif
#define _ALL_SOURCE 1
#define _GNU_SOURCE 1
#define _BSD_SOURCE 1
--
1.6.4
^ permalink raw reply related
* [PATCH next] t7407: use 'cut' utility rather than bash's substring expansion notation
From: Brandon Casey @ 2009-08-20 1:24 UTC (permalink / raw)
To: gitster; +Cc: git, Brandon Casey
From: Brandon Casey <drafnel@gmail.com>
The substring expansion notation is a bashism that we have not so far
adopted. There is precedence for using the 'cut' utility for extracting
a substring. So do so here.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
---
t/t7407-submodule-foreach.sh | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/t/t7407-submodule-foreach.sh b/t/t7407-submodule-foreach.sh
index de1730d..44ea8ac 100755
--- a/t/t7407-submodule-foreach.sh
+++ b/t/t7407-submodule-foreach.sh
@@ -207,8 +207,8 @@ cat > expect <<EOF
$nested2sha1 nested1/nested2 (heads/master)
$nested3sha1 nested1/nested2/nested3 (heads/master)
$submodulesha1 nested1/nested2/nested3/submodule (heads/master)
- $sub1sha1 sub1 (${sub1sha1:0:7})
- $sub2sha1 sub2 (${sub1sha1:0:7})
+ $sub1sha1 sub1 ($(echo $sub1sha1 | cut -c 1-7))
+ $sub2sha1 sub2 ($(echo $sub1sha1 | cut -c 1-7))
$sub3sha1 sub3 (heads/master)
EOF
--
1.6.4
^ permalink raw reply related
* Re: Continue git clone after interruption
From: Sam Vilain @ 2009-08-20 0:26 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Jakub Narebski, Tomasz Kontusz, git, Johannes Schindelin
In-Reply-To: <alpine.LFD.2.00.0908191552020.6044@xanadu.home>
On Wed, 2009-08-19 at 17:13 -0400, Nicolas Pitre wrote:
> > It's the "cheaply deepen history" that I doubt would be easy. This is
> > the most difficult part, I think (see also below).
>
> Don't think so. Try this:
>
> mkdir test
> cd test
> git init
> git fetch --depth=1 git://git.kernel.org/pub/scm/git/git.git
>
> REsult:
>
> remote: Counting objects: 1824, done.
> remote: Compressing objects: 100% (1575/1575), done.
> Receiving objects: 100% (1824/1824), 3.01 MiB | 975 KiB/s, done.
> remote: Total 1824 (delta 299), reused 1165 (delta 180)
> Resolving deltas: 100% (299/299), done.
> From git://git.kernel.org/pub/scm/git/git
> * branch HEAD -> FETCH_HEAD
>
> You'll get the very latest revision for HEAD, and only that. The size
> of the transfer will be roughly the size of a daily snapshot, except it
> is fully up to date. It is however non resumable in the event of a
> network outage. My proposal is to replace this with a "git archive"
> call. It won't get all branches, but for the purpose of initialising
> one's repository that should be good enough. And the "git archive" can
> be fully resumable as I explained.
>
> Now to deepen that history. Let's say you want 10 more revisions going
> back then you simply perform the fetch again with a --depth=10. Right
> now it doesn't seem to work optimally, but the pack that is then being
> sent could be made of deltas against objects found in the commits we
> already have. Currently it seems that a pack that also includes those
> objects we already have in addition to those we want is created, which
> is IMHO a flaw in the shallow support that shouldn't be too hard to fix.
> Each level of deepening should then be as small as standard fetches
> going forward when updating the repository with new revisions.
Nicholas, apart from starting with most recent commits and working
backwards, this is very similar to the "bundle slicing" idea defined in
GitTorrent. What the GitTorrent research project has so far achieved is
defining a slicing algorithm, and figuring out how well slicing works,
in terms of wasted bandwidth.
If you do it right, then you can support download spreading across
mirrors, too. Eg, given a starting point, a 'slice size' - which I
based on uncompressed object size but could as well be based on commit
count - and a slice number to fetch, you should be able to look up in
the revision list index the revisions to select and then make a thin
pack corresponding to those commits. Currently creating this index is
the slowest part of creating bundle fragments in my Perl implementation.
Once Nick Edelen's project is mergeable, we have a mechanism for being
able to relatively quickly draw a manifest of objects for these slices.
So how much bandwidth is lost?
Eg, for git.git, taking the complete object list, slicing it into 1024k
(uncompressed) bundle slices, and making thin packs from those slices we
get:
Generating index...
Length is 1291327524, 1232 blocks
Slice #0: 1050390 => 120406 (11%)
Slice #1: 1058162 => 124978 (11%)
Slice #2: 1049858 => 104363 (9%)
...
Slice #51: 1105090 => 43140 (3%)
Slice #52: 1091282 => 45367 (4%)
Slice #53: 1067675 => 39792 (3%)
...
Slice #211: 1086238 => 25451 (2%)
Slice #212: 1055705 => 31294 (2%)
Slice #213: 1059460 => 7767 (0%)
...
Slice #1129: 1109209 => 38182 (3%)
Slice #1130: 1125925 => 29829 (2%)
Slice #1131: 1120203 => 14446 (1%)
Final slice: 623055 => 49345
Overall compressed: 39585851
Calculating Repository bundle size...
Counting objects: 107369, done.
Compressing objects: 100% (28059/28059), done.
Writing objects: 100% (107369/107369), 29.20 MiB | 48321 KiB/s, done.
Total 107369 (delta 78185), reused 106770 (delta 77609)
Bundle size: 30638967
Overall inefficiency: 29%
In the above output, the first figure is the complete un-delta'd,
uncompressed size of the slice - that is, the size of all of the new
objects that the commit introduces. The second figure is the full size
of a thin pack with those objects in it. ie the above tells me that in
git.git there are 1.2GB of uncompressed objects. Each slice ends up
varying in size between about 10k and 200k, but most of the slices end
up between 15k and 50k.
Actually the test script was thrown off by a loose root and that added
about 3MB to the compressed size, so the overall inefficiency with this
block size is actually more like 20%. I think I am running into the
flaw you mention above, too, especially when I do a larger block size
run:
Generating index...
Length is 1291327524, 62 blocks
Slice #0: 21000218 => 1316165 (6%)
Slice #1: 20988208 => 1107636 (5%)
...
Slice #59: 21102776 => 1387722 (6%)
Slice #60: 20974960 => 876648 (4%)
Final slice: 6715954 => 261218
Overall compressed: 50071857
Calculating Repository bundle size...
Counting objects: 107369, done.
Compressing objects: 100% (28059/28059), done.
Writing objects: 100% (107369/107369), 29.20 MiB | 48353 KiB/s, done.
Total 107369 (delta 78185), reused 106770 (delta 77609)
Bundle size: 30638967
Overall inefficiency: 63%
Somehow we made larger packs but the total packed size was larger.
Trying with 100MB "blocks" I get:
Generating index...
Length is 1291327524, 13 blocks
Slice #0: 104952661 => 4846553 (4%)
Slice #1: 104898188 => 2830056 (2%)
Slice #2: 105007998 => 2856535 (2%)
Slice #3: 104909972 => 2583402 (2%)
Slice #4: 104909440 => 2187708 (2%)
Slice #5: 104859786 => 2555686 (2%)
Slice #6: 104873317 => 2358914 (2%)
Slice #7: 104881597 => 2183894 (2%)
Slice #8: 104863418 => 3555224 (3%)
Slice #9: 104896599 => 3192564 (3%)
Slice #10: 104876697 => 3895707 (3%)
Slice #11: 104903491 => 3731555 (3%)
Final slice: 32494360 => 1270887
Overall compressed: 38048685
Calculating Repository bundle size...
Counting objects: 107369, done.
Compressing objects: 100% (28059/28059), done.
Writing objects: 100% (107369/107369), 29.20 MiB | 48040 KiB/s, done.
Total 107369 (delta 78185), reused 106770 (delta 77609)
Bundle size: 30638967
Overall inefficiency: 24%
In the above, we broke the git.git download into 13 partial downloads of
a few meg each, at the expense of an extra 24% of download.
Anyway I've hopefully got more to add to this but this will do for a
starting point.
Sam
^ permalink raw reply
* What's a good setup for submitting patches to the list properly?
From: Thell Fowler @ 2009-08-20 0:09 UTC (permalink / raw)
To: git
Sorry for once again.
I haven't been able to figure out a good setup for posting patches to the
list correctly, perhaps someone could tell me where I'm going wrong.
Alpine is setup to access git @ tbfowler.name with the 'postpone' folder
being the 'Drafts' folder on the remote mail host, and a local mbox folder
~/mail/git
Locally I prepped the emails using:
git format-patch --cover-letter --full-index -n
--in-reply-to=1249428804.2774.52.camel@GWPortableVCS --thread --signoff -6
--stdout>>~/mail/git
http://article.gmane.org/gmane.comp.version-control.git/124834
Thinking that the cover letter would be in reply to a previous thread, and
that the rest would show as a reply to that. After doing the
format-patch, I went into Alpine's git folder selected the messages and
saved them to the Drafts folder, then did 'compose' for each one, filling
in the information I thought was needed.
At that point, the msg list looked flat, so I opened Evolution Mail and
looked at them there, they cascaded properly, so I sent them. Yet, now,
looking on gmane each of the patch msgs is a top level post and the cover
letter correctly posted as a reply to the previous thread.
What could I have done/checked before sending to make sure that these
would have posted properly?
--
Thell
^ permalink raw reply
* [PATCH 6/6] Add diff tests for trailing-space on incomplete lines
From: Thell Fowler @ 2009-08-19 23:09 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <cover.1250719760.git.git@tbfowler.name>
- Adds 7 --no-index tests to t4015-diff-whitespace.sh specifically
to ensure that xutils.c xdl_hash_record_with_whitespace and
xdl_recmatch process to the end of the record and handle an
incomplete line terminator the same as a new-line.
Signed-off-by: Thell Fowler <git@tbfowler.name>
---
t/t4015-diff-whitespace.sh | 33 +++++++++++++++++++++++++++++++++
1 files changed, 33 insertions(+), 0 deletions(-)
diff --git a/t/t4015-diff-whitespace.sh b/t/t4015-diff-whitespace.sh
index 6d13da30dad5a78fb17a01e86ef33072ea9e6250..193ddbe0659ede17154ffda3b25ebc5e6c686d6e 100755
--- a/t/t4015-diff-whitespace.sh
+++ b/t/t4015-diff-whitespace.sh
@@ -395,4 +395,37 @@ test_expect_success 'combined diff with autocrlf conversion' '
'
+# Ignore trailing-space testing on incomplete lines.
+prepare_diff_file () {
+ printf "%s%$2s" foo "" >"$1"
+ if [ $3 = "+nl" ]
+ then
+ printf "\n" >>"$1"
+ fi
+}
+
+diff_trailing () {
+ foo="foo___"
+ prepare_diff_file "left" "$2" "$3"
+ lfoo=$( expr substr $foo 1 $((3+$2)) )
+ lfoo=${lfoo}"$3"
+
+ prepare_diff_file "right" "$4" "$5"
+ rfoo=$( expr substr $foo 1 $((3+$4)) )
+ rfoo=${rfoo}"$5"
+
+ label="-$1 $lfoo $rfoo"
+
+ test_expect_success "$label" \
+ "! git diff --no-index -$1 -- left right | grep -q foo"
+}
+
+diff_trailing w 0 +nl 1 -nl
+diff_trailing w 0 -nl 1 -nl
+diff_trailing b 0 +nl 0 -nl
+diff_trailing b 1 +nl 0 -nl
+diff_trailing b 1 -nl 0 -nl
+diff_trailing -ignore-space-at-eol 0 +nl 0 -nl
+diff_trailing -ignore-space-at-eol 2 +nl 2 -nl
+
test_done
--
1.6.4.172.g5c0d0.dirty
^ permalink raw reply related
* [PATCH 5/6] Make diff --ignore-space-at-eol handle incomplete lines.
From: Thell Fowler @ 2009-08-19 23:08 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <cover.1250719760.git.git@tbfowler.name>
- When processing with --ignore-space-change a diff would be found
whenever an incomplete line was encountered. xdl_recmatch should
process the full length of the record instead of assuming both
sides have a terminator.
Signed-off-by: Thell Fowler <git@tbfowler.name>
---
xdiff/xutils.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/xdiff/xutils.c b/xdiff/xutils.c
index e126de450c99fb1e557c2cfc0ffe54e8e3e80394..a8ed102d528bdb5d8f0839eb392b35dc1c534fba 100644
--- a/xdiff/xutils.c
+++ b/xdiff/xutils.c
@@ -216,7 +216,7 @@ int xdl_recmatch(const char *l1, long s1, const char *l2, long s2, long flags)
}
return (i1 >= s1 && i2 >= s2);
} else if (flags & XDF_IGNORE_WHITESPACE_AT_EOL) {
- for (i1 = i2 = 0; i1 < s1 && i2 < s2; ) {
+ for (i1 = i2 = 0; i1 <= s1 && i2 <= s2; ) {
if (l1[i1] != l2[i2]) {
while (i1 < s1 && isspace(l1[i1]))
i1++;
--
1.6.4.172.g5c0d0.dirty
^ permalink raw reply related
* [PATCH 4/6] Make diff -b handle trailing-spaces on incomplete lines.
From: Thell Fowler @ 2009-08-19 23:07 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <cover.1250719760.git.git@tbfowler.name>
- When processing trailing spaces with --ignore-space-change a diff
would be found whenever an incomplete line terminated before the
whitespace handling started regardless of actual trailing-spaces.
xdl_recmatch should process the full length of the record instead
of assuming both sides have a terminator, and should treat the
terminator as a whitespace like it does with '\n'.
Signed-off-by: Thell Fowler <git@tbfowler.name>
---
xdiff/xutils.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/xdiff/xutils.c b/xdiff/xutils.c
index 1f28f4fb4e0a8fdc6c9aa1904cf0362dd1e7b977..e126de450c99fb1e557c2cfc0ffe54e8e3e80394 100644
--- a/xdiff/xutils.c
+++ b/xdiff/xutils.c
@@ -203,9 +203,9 @@ int xdl_recmatch(const char *l1, long s1, const char *l2, long s2, long flags)
}
return (i1 >= s1 && i2 >= s2);
} else if (flags & XDF_IGNORE_WHITESPACE_CHANGE) {
- for (i1 = i2 = 0; i1 < s1 && i2 < s2; ) {
- if (isspace(l1[i1])) {
- if (!isspace(l2[i2]))
+ for (i1 = i2 = 0; i1 <= s1 && i2 <= s2; ) {
+ if (isspace(l1[i1]) || (i1 == s1 && i2 < s2)) {
+ if (!isspace(l2[i2]) && i2 != s2)
return 0;
while (isspace(l1[i1]) && i1 < s1)
i1++;
--
1.6.4.172.g5c0d0.dirty
^ permalink raw reply related
* [RFC/PATCH 7/6] git clone: Add --recursive to automatically checkout (nested) submodules
From: Johan Herland @ 2009-08-19 23:07 UTC (permalink / raw)
To: git; +Cc: gitster, johan, barkalow
In-Reply-To: <1250646324-961-1-git-send-email-johan@herland.net>
Many projects using submodules expect all submodules to be checked out
in order to build/work correctly. A common command sequence for
developers on such projects is:
git clone url/to/project
cd project
git submodule update --init (--recursive)
This patch introduces the --recursive option to git-clone. The new
option causes git-clone to recursively clone and checkout all
submodules of the cloned project. Hence, the above command sequence
can be reduced to:
git clone --recursive url/to/project
--recursive is ignored if no checkout is done by the git-clone.
The patch also includes documentation and a selftest.
Signed-off-by: Johan Herland <johan@herland.net>
---
Hi,
It just hit me today that yesterday's patch series missed the last part
of the puzzle...
I'm not at all married to the '--recursive' name for this option, but
I wasn't able to think of anything better that wasn't too long.
Have fun! :)
...Johan
Documentation/git-clone.txt | 10 +++++++++-
builtin-clone.c | 11 ++++++++++-
t/t7407-submodule-foreach.sh | 12 ++++++++++++
3 files changed, 31 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt
index 2c63a0f..88ea272 100644
--- a/Documentation/git-clone.txt
+++ b/Documentation/git-clone.txt
@@ -12,7 +12,7 @@ SYNOPSIS
'git clone' [--template=<template_directory>]
[-l] [-s] [--no-hardlinks] [-q] [-n] [--bare] [--mirror]
[-o <name>] [-u <upload-pack>] [--reference <repository>]
- [--depth <depth>] [--] <repository> [<directory>]
+ [--depth <depth>] [--recursive] [--] <repository> [<directory>]
DESCRIPTION
-----------
@@ -147,6 +147,14 @@ objects from the source repository into a pack in the cloned repository.
with a long history, and would want to send in fixes
as patches.
+--recursive::
+ After the clone is created, initialize all submodules within,
+ using their default settings. This is equivalent to running
+ 'git submodule update --init --recursive' immediately after
+ the clone is finished. This option is ignored if the cloned
+ repository does not have a worktree/checkout (i.e. if any of
+ `--no-checkout`/`-n`, `--bare`, or `--mirror` is given)
+
<repository>::
The (possibly remote) repository to clone from. See the
<<URLS,URLS>> section below for more information on specifying
diff --git a/builtin-clone.c b/builtin-clone.c
index 32dea74..0d2b4a8 100644
--- a/builtin-clone.c
+++ b/builtin-clone.c
@@ -38,7 +38,7 @@ static const char * const builtin_clone_usage[] = {
};
static int option_quiet, option_no_checkout, option_bare, option_mirror;
-static int option_local, option_no_hardlinks, option_shared;
+static int option_local, option_no_hardlinks, option_shared, option_recursive;
static char *option_template, *option_reference, *option_depth;
static char *option_origin = NULL;
static char *option_upload_pack = "git-upload-pack";
@@ -59,6 +59,8 @@ static struct option builtin_clone_options[] = {
"don't use local hardlinks, always copy"),
OPT_BOOLEAN('s', "shared", &option_shared,
"setup as shared repository"),
+ OPT_BOOLEAN(0, "recursive", &option_recursive,
+ "setup as shared repository"),
OPT_STRING(0, "template", &option_template, "path",
"path the template repository"),
OPT_STRING(0, "reference", &option_reference, "repo",
@@ -73,6 +75,10 @@ static struct option builtin_clone_options[] = {
OPT_END()
};
+static const char *argv_submodule[] = {
+ "submodule", "update", "--init", "--recursive", NULL
+};
+
static char *get_repo_path(const char *repo, int *is_bundle)
{
static char *suffix[] = { "/.git", ".git", "" };
@@ -608,6 +614,9 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
err |= run_hook(NULL, "post-checkout", sha1_to_hex(null_sha1),
sha1_to_hex(remote_head->old_sha1), "1", NULL);
+
+ if (!err && option_recursive)
+ err = run_command_v_opt(argv_submodule, RUN_GIT_CMD);
}
strbuf_release(&reflog_msg);
diff --git a/t/t7407-submodule-foreach.sh b/t/t7407-submodule-foreach.sh
index de1730d..25ec281 100755
--- a/t/t7407-submodule-foreach.sh
+++ b/t/t7407-submodule-foreach.sh
@@ -220,4 +220,16 @@ test_expect_success 'test "status --recursive"' '
test_cmp expect actual
'
+test_expect_success 'use "git clone --recursive" to checkout all submodules' '
+ git clone --recursive super clone4 &&
+ test -d clone4/.git &&
+ test -d clone4/sub1/.git &&
+ test -d clone4/sub2/.git &&
+ test -d clone4/sub3/.git &&
+ test -d clone4/nested1/.git &&
+ test -d clone4/nested1/nested2/.git &&
+ test -d clone4/nested1/nested2/nested3/.git &&
+ test -d clone4/nested1/nested2/nested3/submodule/.git
+'
+
test_done
--
1.6.4.304.g1365c.dirty
^ permalink raw reply related
* [PATCH 3/6] Make diff -w handle trailing-spaces on incomplete lines.
From: Thell Fowler @ 2009-08-19 23:07 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <cover.1250719760.git.git@tbfowler.name>
- When processing trailing spaces with --ignore-all-space a diff
would be found whenever one side had 0 spaces and either (or both)
sides was an incomplete line. xdl_recmatch should process the
full length of the record instead of assuming both sides have a
terminator.
Signed-off-by: Thell Fowler <git@tbfowler.name>
---
xdiff/xutils.c | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/xdiff/xutils.c b/xdiff/xutils.c
index c6512a53b08a8c9039614738310aa2786f4fbb1c..1f28f4fb4e0a8fdc6c9aa1904cf0362dd1e7b977 100644
--- a/xdiff/xutils.c
+++ b/xdiff/xutils.c
@@ -191,14 +191,14 @@ int xdl_recmatch(const char *l1, long s1, const char *l2, long s2, long flags)
int i1, i2;
if (flags & XDF_IGNORE_WHITESPACE) {
- for (i1 = i2 = 0; i1 < s1 && i2 < s2; ) {
+ for (i1 = i2 = 0; i1 <= s1 && i2 <= s2; ) {
if (isspace(l1[i1]))
- while (isspace(l1[i1]) && i1 < s1)
+ while (isspace(l1[i1]) && i1 <= s1)
i1++;
if (isspace(l2[i2]))
- while (isspace(l2[i2]) && i2 < s2)
+ while (isspace(l2[i2]) && i2 <= s2)
i2++;
- if (i1 < s1 && i2 < s2 && l1[i1++] != l2[i2++])
+ if (i1 <= s1 && i2 <= s2 && l1[i1++] != l2[i2++])
return 0;
}
return (i1 >= s1 && i2 >= s2);
--
1.6.4.172.g5c0d0.dirty
^ permalink raw reply related
* [PATCH 2/6] Make xdl_hash_record_with_whitespace ignore eof
From: Thell Fowler @ 2009-08-19 23:06 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <cover.1250719760.git.git@tbfowler.name>
- When xdl_hash_record_with_whitespace encountered an incomplete
line the hash would be different than the identical line with
either --ignore-space-change or --ignore-space-at-eol on an
incomplete line because they only terminated with a check for
a new-line.
Signed-off-by: Thell Fowler <git@tbfowler.name>
---
xdiff/xutils.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/xdiff/xutils.c b/xdiff/xutils.c
index 04ad468702209b77427e635370d41001986042ce..c6512a53b08a8c9039614738310aa2786f4fbb1c 100644
--- a/xdiff/xutils.c
+++ b/xdiff/xutils.c
@@ -248,12 +248,12 @@ static unsigned long xdl_hash_record_with_whitespace(char const **data,
if (flags & XDF_IGNORE_WHITESPACE)
; /* already handled */
else if (flags & XDF_IGNORE_WHITESPACE_CHANGE
- && ptr[1] != '\n') {
+ && ptr[1] != '\n' && ptr + 1 < top) {
ha += (ha << 5);
ha ^= (unsigned long) ' ';
}
else if (flags & XDF_IGNORE_WHITESPACE_AT_EOL
- && ptr[1] != '\n') {
+ && ptr[1] != '\n' && ptr + 1 < top) {
while (ptr2 != ptr + 1) {
ha += (ha << 5);
ha ^= (unsigned long) *ptr2;
--
1.6.4.172.g5c0d0.dirty
^ permalink raw reply related
* [PATCH] graph API: display uninteresting commits as '^' instead of '*'
From: Adam Simpkins @ 2009-08-19 23:06 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
Using --graph and --show-all together now displays UNINTERESTING commits
using '^' characters instead of '*'.
Something like the following command will demonstrate the change:
git log --graph --show-all ^HEAD~2 HEAD
Signed-off-by: Adam Simpkins <simpkins@facebook.com>
---
graph.c | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/graph.c b/graph.c
index 6746d42..50b68a4 100644
--- a/graph.c
+++ b/graph.c
@@ -775,6 +775,14 @@ static void graph_output_commit_char(struct git_graph *graph, struct strbuf *sb)
}
/*
+ * For UNINTERESTING commits (displayed with --show-all), print '^'
+ */
+ if (graph->commit->object.flags & UNINTERESTING) {
+ strbuf_addch(sb, '^');
+ return;
+ }
+
+ /*
* If revs->left_right is set, print '<' for commits that
* come from the left side, and '>' for commits from the right
* side.
--
1.6.0.4
^ permalink raw reply related
* [PATCH 1/6] Add supplemental test for trailing-whitespace on incomplete lines.
From: Thell Fowler @ 2009-08-19 23:06 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <cover.1250719760.git.git@tbfowler.name>
*** For illustrative purposes only and not meant for upstream ***
- Adds a stand-alone test that loops through A-side B-side with
and without new-lines from 0 to 3 spaces per side.
This is a draft test meant to expose the issue with xutils.c
handling of incomplete lines and trailing-spaces.
Signed-off-by: Thell Fowler <git@tbfowler.name>
---
t/t4015-diff-trailing-whitespace.sh | 95 +++++++++++++++++++++++++++++++++++
1 files changed, 95 insertions(+), 0 deletions(-)
create mode 100755 t/t4015-diff-trailing-whitespace.sh
diff --git a/t/t4015-diff-trailing-whitespace.sh b/t/t4015-diff-trailing-whitespace.sh
new file mode 100755
index 0000000000000000000000000000000000000000..c4937c1b457c24b35565b09e7b262443a05f9795
--- /dev/null
+++ b/t/t4015-diff-trailing-whitespace.sh
@@ -0,0 +1,95 @@
+#!/bin/sh
+
+test_description='Test trailing whitespace in diff engine.
+
+'
+. ./test-lib.sh
+. "$TEST_DIRECTORY"/diff-lib.sh
+
+# Trailing-space testing with and without newlines.
+prepare_diff_file () {
+ printf "%s%$2s" foo "" >"$1"
+ if [ $3 = "+nl" ]
+ then
+ printf "\n" >>"$1"
+ fi
+}
+
+diff_trailing () {
+ foo="foo___"
+ prepare_diff_file "left" "$2" "$3"
+ lfoo=$( expr substr $foo 1 $((3+$2)) )
+ lfoo=${lfoo}"$3"
+
+ prepare_diff_file "right" "$4" "$5"
+ rfoo=$( expr substr $foo 1 $((3+$4)) )
+ rfoo=${rfoo}"$5"
+
+ label="-$1 $lfoo $rfoo ($6)"
+
+ if [ "$6" != "should_diff" ]
+ then
+ negate='!'
+ else
+ negate=''
+ fi
+
+ if [ -z "$7" ]
+ then
+ test_expect_success "$label" \
+ "$negate git diff --no-index -$1 -- left right | grep -q foo"
+ else
+ test_expect_failure "$label" \
+ "$negate git diff --no-index -$1 -- left right | grep -q foo"
+ fi
+
+ test_debug "git diff --no-index -$1 -- left right | grep foo"
+}
+
+touch diffout
+for arg in -ignore-all-space -ignore-space-at-eol -ignore-space-change
+do
+ for i1 in 0 1 2 3
+ do
+ for i2 in 0 1 2 3
+ do
+ diff_trailing $arg $i1 +nl $i2 -nl should_not_diff >> diffout
+ diff_trailing $arg $i1 -nl $i2 +nl should_not_diff >> diffout
+
+ if [ $i1 -ne $i2 ]
+ then
+ diff_trailing $arg $i1 +nl $i2 +nl should_not_diff >> diffout
+ diff_trailing $arg $i1 -nl $i2 -nl should_not_diff >> diffout
+ fi
+ done
+ done
+done
+
+test_debug 'grep "FAIL" diffout'
+
+for arg in all eol change
+do
+ grep "FAIL" diffout | \
+ grep "$arg" | \
+ cut -d " " -f 4- | \
+
+ ## Playing with filtering to isolate core issue.
+ #sort -k 2,2 -k 3,3 | \
+ #awk '{ forward = $2 " " $3; reverse = $3 " " $2}
+ # !seen[forward]++ && !seen[reverse]++' | \
+ #sort -k 2,2 | \
+
+ ## Playing with filtering to isolate core issue.
+ ## This seems like the most illustrative output...
+ awk '{ key=$3 ; gsub(/-/, "+", key) ; key=$2 ":" key ; if ( hash[key]++ == 0 ) print ; }'
+
+ ## Playing with filtering to isolate core issue.
+ #awk '{ if ( $3 ~ /.*\-/ )
+ # print $0
+ # else
+ # print $1 " " $3 " " $2 " " $4
+ # ; }' | \
+ #sort -k 2,2 -k 3,3
+done
+
+test_done
--
1.6.4.172.g5c0d0.dirty
^ permalink raw reply related
* [PATCH 0/6 RFC] Series to correct xutils incomplete line handling.
From: Thell Fowler @ 2009-08-19 23:05 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <1249428804.2774.52.camel@GWPortableVCS>
[1/6]
Add supplemental test for trailing-whitespace on incomplete lines.
-- This patch is for illustrative purposes only. It exposes the current
failures of git diff whitespace ignore options when dealing with trailing-
spaces on incomplete lines.
[2/6] through [5/6]
Make xdl_hash_record_with_whitespace ignore eof
Make diff -w handle trailing-spaces on incomplete lines.
Make diff -b handle trailing-spaces on incomplete lines.
Make diff --ignore-space-at-eol handle incomplete lines.
-- These alter the record ptr loops to go to the end of the record and to
treat the terminator as it would '\n'.
[6/6]
Add diff tests for trailing-space on incomplete lines
-- Just the seven test cases that would identify future breakage.
t/t4015-diff-trailing-whitespace.sh | 95 +++++++++++++++++++++++++++++++++++
t/t4015-diff-whitespace.sh | 33 ++++++++++++
xdiff/xutils.c | 20 ++++----
3 files changed, 138 insertions(+), 10 deletions(-)
create mode 100755 t/t4015-diff-trailing-whitespace.sh
^ permalink raw reply
* [PATCH] Add test case for rev-list --parents --show-all
From: Adam Simpkins @ 2009-08-19 22:58 UTC (permalink / raw)
To: Junio C Hamano, Santi Béjar, Git Mailing List
In-Reply-To: <20090819225547.GR8147@facebook.com>
This test case ensures that rev-list --parents --show-all gets the
parent history correct. Normally, --parents rewrites parent history to
skip TREESAME parents. However, --show-all causes TREESAME parents to
still be included in the revision list, so the parents should still be
included too.
Signed-off-by: Adam Simpkins <simpkins@facebook.com>
---
Looking through the code, I believe TREESAME commits are the only ones
affected by my earlier bug in simplify_commit().
t/t6015-rev-list-show-all-parents.sh | 31 +++++++++++++++++++++++++++++++
1 files changed, 31 insertions(+), 0 deletions(-)
create mode 100644 t/t6015-rev-list-show-all-parents.sh
diff --git a/t/t6015-rev-list-show-all-parents.sh b/t/t6015-rev-list-show-all-parents.sh
new file mode 100644
index 0000000..8b146fb
--- /dev/null
+++ b/t/t6015-rev-list-show-all-parents.sh
@@ -0,0 +1,31 @@
+#!/bin/sh
+
+test_description='--show-all --parents does not rewrite TREESAME commits'
+
+. ./test-lib.sh
+
+test_expect_success 'set up --show-all --parents test' '
+ test_commit one foo.txt &&
+ commit1=`git rev-list -1 HEAD` &&
+ test_commit two bar.txt &&
+ commit2=`git rev-list -1 HEAD` &&
+ test_commit three foo.txt &&
+ commit3=`git rev-list -1 HEAD`
+ '
+
+test_expect_success '--parents rewrites TREESAME parents correctly' '
+ echo $commit3 $commit1 > expected &&
+ echo $commit1 >> expected &&
+ git rev-list --parents HEAD -- foo.txt > actual &&
+ test_cmp expected actual
+ '
+
+test_expect_success '--parents --show-all does not rewrites TREESAME parents' '
+ echo $commit3 $commit2 > expected &&
+ echo $commit2 $commit1 >> expected &&
+ echo $commit1 >> expected &&
+ git rev-list --parents --show-all HEAD -- foo.txt > actual &&
+ test_cmp expected actual
+ '
+
+test_done
--
1.6.0.4
^ permalink raw reply related
* Re: [PATCH] graph API: fix bug in graph_is_interesting()
From: Adam Simpkins @ 2009-08-19 22:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Santi Béjar, Git Mailing List
In-Reply-To: <7v4os41frm.fsf@alter.siamese.dyndns.org>
On Tue, Aug 18, 2009 at 11:25:49PM -0700, Junio C Hamano wrote:
> Junio C Hamano <gitster@pobox.com> writes:
> >
> > When simplify_commit() logic (now called get_comit_action()) decides to
> > show this commit because revs->show_all was specified, we did not rewrite
> > its parents, but now we will?
>
> That is, here is what I meant...
>
> - if (action == commit_show && revs->prune && revs->dense && want_ancestry(revs)) {
> + if (action == commit_show &&
> + !revs->show_all &&
> + revs->prune && revs->dense && want_ancestry(revs)) {
>
> We may want to add some tests to demonstrate the breakage this fix
> addresses.
Yes, you're right. Thanks for catching that. I'll submit a test case
that checks this scenario.
--
Adam Simpkins
simpkins@facebook.com
^ 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