* Re: [JGIT PATCH 03/15] Add IntList as a more efficient representation of List<Integer>
From: Sverre Rabbelier @ 2008-12-12 15:50 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20081212154115.GO32487@spearce.org>
On Fri, Dec 12, 2008 at 16:41, Shawn O. Pearce <spearce@spearce.org> wrote:
> If you'd like to send a patch to change it, I'll apply it. But I
> don't think its worth my time to make this toString() more efficient.
I mainly mentioned it because it's in a Class meant to be more optimal
than what Java ships with, but I agree with your reasoning that this
toString is not part of what needs to be optimized.
> Other areas of JGit I do try to micro-optimize, because they are
> right smack in the middle of the critical paths.
Hehe, I very much agree with not optimizing prematurely, and if you do
optimize to go for it all the way.
> E.g. look at ObjectId.equals(byte[],int,byte[],int). I hand-unrolled
> the memcmp loop because the JIT on x86 does *soooo* much better
> when the code is spelled out:
<code snipped>
Kind of sad that you have to write this kind of code if you want good
performance, ah well, perhaps someday... (import java.lang.optimized
;) ).
> This block is in the critical path for any tree diff code, in
> particular for a "git log -- a/" sort of operation. Its used
> to compare the SHA-1s from two different tree records to see if
> they differ. Not unrolling this was a huge penalty.
I reckon that is done a lot :). Ashame the JRE can't do that kind of
optimization for you. e.g., if you do:
for(int i = 0; i < constant; i++) {
some_code;
}
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* [PATCH 1/2] cvsserver: add option to configure commit message
From: Fabian Emmes @ 2008-12-12 15:24 UTC (permalink / raw)
To: git; +Cc: gitster, Fabian Emmes, Lars Noschinski
cvsserver annotates each commit message by "via git-CVS emulator". This is
made configurable via gitcvs.commitmsgannotation.
Signed-off-by: Fabian Emmes <fabian.emmes@rwth-aachen.de>
Signed-off-by: Lars Noschinski <lars@public.noschinski.de>
---
Documentation/config.txt | 4 ++++
git-cvsserver.perl | 8 +++++++-
2 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index b233fe5..ee937fe 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -723,6 +723,10 @@ gc.rerereunresolved::
kept for this many days when 'git-rerere gc' is run.
The default is 15 days. See linkgit:git-rerere[1].
+gitcvs.commitmsgannotation::
+ Append this string to each commit message. Set to empty string
+ to disable this feature. Defaults to "via git-CVS emulator".
+
gitcvs.enabled::
Whether the CVS server interface is enabled for this repository.
See linkgit:git-cvsserver[1].
diff --git a/git-cvsserver.perl b/git-cvsserver.perl
index b0a805c..cbcaeb4 100755
--- a/git-cvsserver.perl
+++ b/git-cvsserver.perl
@@ -1358,7 +1358,13 @@ sub req_ci
# write our commit message out if we have one ...
my ( $msg_fh, $msg_filename ) = tempfile( DIR => $TEMP_DIR );
print $msg_fh $state->{opt}{m};# if ( exists ( $state->{opt}{m} ) );
- print $msg_fh "\n\nvia git-CVS emulator\n";
+ if ( defined ( $cfg->{gitcvs}{commitmsgannotation} ) ) {
+ if ($cfg->{gitcvs}{commitmsgannotation} !~ /^\s*$/ ) {
+ print $msg_fh "\n\n".$cfg->{gitcvs}{commitmsgannotation}."\n"
+ }
+ } else {
+ print $msg_fh "\n\nvia git-CVS emulator\n";
+ }
close $msg_fh;
my $commithash = `git-commit-tree $treehash -p $parenthash < $msg_filename`;
--
1.6.1.rc2.20.gde0d
^ permalink raw reply related
* [PATCH 2/2] cvsserver: change generation of CVS author names
From: Fabian Emmes @ 2008-12-12 15:24 UTC (permalink / raw)
To: git; +Cc: gitster, Fabian Emmes, Lars Noschinski
In-Reply-To: <1229095449-24755-1-git-send-email-fabian.emmes@rwth-aachen.de>
CVS username is generated from local part email address.
We take the whole local part but restrict the character set to the
Portable Filename Character Set, which is used for Unix login names
according to Single Unix Specification v3.
Signed-off-by: Fabian Emmes <fabian.emmes@rwth-aachen.de>
Signed-off-by: Lars Noschinski <lars@public.noschinski.de>
---
git-cvsserver.perl | 12 +++++++++---
1 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/git-cvsserver.perl b/git-cvsserver.perl
index cbcaeb4..fef7faf 100755
--- a/git-cvsserver.perl
+++ b/git-cvsserver.perl
@@ -2533,12 +2533,18 @@ sub open_blob_or_die
return $fh;
}
-# Generate a CVS author name from Git author information, by taking
-# the first eight characters of the user part of the email address.
+# Generate a CVS author name from Git author information, by taking the local
+# part of the email address and replacing characters not in the Portable
+# Filename Character Set (see IEEE Std 1003.1-2001, 3.276) by underscores. CVS
+# Login names are Unix login names, which should be restricted to this
+# character set.
sub cvs_author
{
my $author_line = shift;
- (my $author) = $author_line =~ /<([^>@]{1,8})/;
+ (my $author) = $author_line =~ /<([^@>]*)/;
+
+ $author =~ s/[^-a-zA-Z0-9_.]/_/g;
+ $author =~ s/^-/_/;
$author;
}
--
1.6.1.rc2.20.gde0d
^ permalink raw reply related
* Re: [JGIT PATCH 03/15] Add IntList as a more efficient representation of List<Integer>
From: Shawn O. Pearce @ 2008-12-12 15:41 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: git
In-Reply-To: <bd6139dc0812120733o7c828532qbcd78c46a321fe6b@mail.gmail.com>
Sverre Rabbelier <srabbelier@gmail.com> wrote:
> On Fri, Dec 12, 2008 at 16:15, Shawn O. Pearce <spearce@spearce.org> wrote:
> > Hmm, yea, good point. But I don't care too much about the toString()
> > in this case, its meant as a debugging aid and not something one
> > would rely upon. Hence I didn't think it was worth testing for the
> > empty list, writing the first entry, then doing a loop for [1,count).
>
> Fair enough :).
If you'd like to send a patch to change it, I'll apply it. But I
don't think its worth my time to make this toString() more efficient.
Other areas of JGit I do try to micro-optimize, because they are
right smack in the middle of the critical paths.
E.g. look at ObjectId.equals(byte[],int,byte[],int). I hand-unrolled
the memcmp loop because the JIT on x86 does *soooo* much better
when the code is spelled out:
public static boolean equals(final byte[] firstBuffer, final int fi,
final byte[] secondBuffer, final int si) {
return firstBuffer[fi] == secondBuffer[si]
&& firstBuffer[fi + 1] == secondBuffer[si + 1]
&& firstBuffer[fi + 2] == secondBuffer[si + 2]
&& firstBuffer[fi + 3] == secondBuffer[si + 3]
&& firstBuffer[fi + 4] == secondBuffer[si + 4]
&& firstBuffer[fi + 5] == secondBuffer[si + 5]
&& firstBuffer[fi + 6] == secondBuffer[si + 6]
&& firstBuffer[fi + 7] == secondBuffer[si + 7]
&& firstBuffer[fi + 8] == secondBuffer[si + 8]
&& firstBuffer[fi + 9] == secondBuffer[si + 9]
&& firstBuffer[fi + 10] == secondBuffer[si + 10]
&& firstBuffer[fi + 11] == secondBuffer[si + 11]
&& firstBuffer[fi + 12] == secondBuffer[si + 12]
&& firstBuffer[fi + 13] == secondBuffer[si + 13]
&& firstBuffer[fi + 14] == secondBuffer[si + 14]
&& firstBuffer[fi + 15] == secondBuffer[si + 15]
&& firstBuffer[fi + 16] == secondBuffer[si + 16]
&& firstBuffer[fi + 17] == secondBuffer[si + 17]
&& firstBuffer[fi + 18] == secondBuffer[si + 18]
&& firstBuffer[fi + 19] == secondBuffer[si + 19];
}
This block is in the critical path for any tree diff code, in
particular for a "git log -- a/" sort of operation. Its used
to compare the SHA-1s from two different tree records to see if
they differ. Not unrolling this was a huge penalty.
--
Shawn.
^ permalink raw reply
* Re: [JGIT PATCH 03/15] Add IntList as a more efficient representation of List<Integer>
From: Sverre Rabbelier @ 2008-12-12 15:33 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20081212151533.GM32487@spearce.org>
On Fri, Dec 12, 2008 at 16:15, Shawn O. Pearce <spearce@spearce.org> wrote:
> Hmm, yea, good point. But I don't care too much about the toString()
> in this case, its meant as a debugging aid and not something one
> would rely upon. Hence I didn't think it was worth testing for the
> empty list, writing the first entry, then doing a loop for [1,count).
Fair enough :).
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [JGIT PATCH] Fix typos in comments / testcase output
From: Shawn O. Pearce @ 2008-12-12 15:30 UTC (permalink / raw)
To: Mike Ralphson; +Cc: git, Mike Ralphson, Robin Rosenberg
In-Reply-To: <1229079357-19167-1-git-send-email-mike@abacus.co.uk>
Mike Ralphson <mike@abacus.co.uk> wrote:
> Signed-off-by: Mike Ralphson <mike@abacus.co.uk>
Thanks, I've applied this change, and the README correction you
noted but didn't send a patch for. :-)
> Is it me, or is the actual maintainer of JGIT/EGIT not actually
> mentioned anywhere? Apologies if I've got the to and cc round
> the wrong way 8-)
Robin and I run JGit and EGit as a dual-maintainer approach.
We both have write access to the master repository and we apply
each other's patches rather than push directly ourselves. It
helps keep us from cutting corners.
Although I just broke that rule by pushing my own patch to README
and my own patch to SUBMITTING_PATCHES to address the other points
you raised, but these are two auxiliary documents that we don't
pay much attention to, hence they have fallen into disarray... :-\
--
Shawn.
^ permalink raw reply
* Re: [JGIT PATCH 03/15] Add IntList as a more efficient representation of List<Integer>
From: Shawn O. Pearce @ 2008-12-12 15:15 UTC (permalink / raw)
To: sverre; +Cc: git
In-Reply-To: <bd6139dc0812120243y2b1a3dddu4975162114280e17@mail.gmail.com>
Sverre Rabbelier <alturin@gmail.com> wrote:
> On Fri, Dec 12, 2008 at 03:46, Shawn O. Pearce <spearce@spearce.org> wrote:
> > + public String toString() {
> > + final StringBuilder r = new StringBuilder();
> > + r.append('[');
> > + for (int i = 0; i < count; i++) {
> > + if (i > 0)
> > + r.append(", ");
> > + r.append(entries[i]);
> > + }
> > + r.append(']');
> > + return r.toString();
> > + }
> > +}
>
> If you care about speed in your toString at all, pull the if statement
> out of there. A friend of mine did a small benchmark once, and it was
> _a lot_ slower to do the if in the for loop. I reckon you don't
> though, but just in case ;).
Hmm, yea, good point. But I don't care too much about the toString()
in this case, its meant as a debugging aid and not something one
would rely upon. Hence I didn't think it was worth testing for the
empty list, writing the first entry, then doing a loop for [1,count).
--
Shawn.
^ permalink raw reply
* Re: Saving patches from this list
From: Shawn O. Pearce @ 2008-12-12 15:14 UTC (permalink / raw)
To: Mike Ralphson, Stefan Näwe; +Cc: git, Johannes Sixt, Junio C Hamano
In-Reply-To: <e2b179460812120107t74a4a8e3y1654233fe2870ac7@mail.gmail.com>
Mike Ralphson <mike.ralphson@gmail.com> wrote:
> 2008/12/12 Stefan Näwe <stefan.naewe+git@gmail.com>
> > > Stefan Näwe schrieb:
> > > > What's the best way to get patches sent to this list in a form suitable
> > > > for 'git am' without subscribing to this list ?
If you find the article on the web with gmane, add '/raw' onto the
end of direct link URL. E.g. to get:
http://article.gmane.org/gmane.comp.version-control.git/102874
use:
curl http://article.gmane.org/gmane.comp.version-control.git/102874/raw | git am
> Junio's blog[1] shows he's looking at patchwork. Personally I think it
> would be fantastic to have a public patchwork server available. It
> might avoid the chicken and egg problem in that it's currently easier
> (for some people) to get hold of a patch to play with / review only
> after it's accepted.
One of the things I want to do with Gerrit 2 is teach it to read a
mailing list and convert patches it receives into temporary branches
that can be fetched over git://, and also create records in its web
database so reviews can be done on the web interface, then let it
CC the list back with a proper In-Reply-To when comments are posted
on the web to a change it received by email.
IOW, I want to make Gerrit 2 useful to the git community to monitor
patch state without changing our current email based workflow.
But I'm still a good two or three months from being able to do that.
Android's workflow is higher priority to me right now.
--
Shawn.
^ permalink raw reply
* Re: help needed: Splitting a git repository after subversion migration
From: Björn Steinbrink @ 2008-12-12 14:49 UTC (permalink / raw)
To: Thomas Jarosch; +Cc: Michael J Gruber, git
In-Reply-To: <200812121522.38791.thomas.jarosch@intra2net.com>
On 2008.12.12 15:22:15 +0100, Thomas Jarosch wrote:
> On Thursday, 11. December 2008 09:10:09 you wrote:
> > > Now I'll manually check the history of the tags/ and branches/ folder
> > > for more funny tags and write down the revision. If I understood
> > > the git-svn man page correctly, I should be able to specifiy
> > > revision ranges it's going to import. I'll try to skip the broken tags.
> >
> > As long as the breakage only involves branches/tags that are completely
> > useless, it's probably a lot easier to just delete them afterwards.
> >
> > And if you accidently added changes to a tag, after it was created, it's
> > also easier to manually tag to right version in git, and just forgetting
> > about the additional commit.
> >
> > And for a bunch of other cases, rebase -i/filter-branch are probably
> > also better options ;-)
> >
> > Skipping revisions in a git-svn import sounds rather annoying and
> > error-prone.
>
> Sounds very reasonable. When I'm done filtering with filter-branch,
> the original commits are still stored in "refs/originals" and the reflogs.
> What's the best way to get rid of those to free up the space?
See the "purging unwanted history" thread:
http://n2.nabble.com/purging-unwanted-history-td1507638.html
The commands there (starting with the "git for-each-ref") should clean
out all the pre-filter-branch stuff.
> A nice way to find the corresponding commit for a file can be found here:
> http://stackoverflow.com/questions/223678/git-which-commit-has-this-blob
Yeah, I think something similar (or even the same?) is in the git wiki
somewhere. I never had any use for it though ;-)
Björn
^ permalink raw reply
* Unable to index file
From: Ramon Tayag @ 2008-12-12 14:47 UTC (permalink / raw)
To: git
Hi everyone,
I've come across a problem that I don't believe lies in Rails. You
needn't be familiar, I think, with Rails to see what's wrong.
I can't seem to add the files that are in
http://dev.rubyonrails.org/archive/rails_edge.zip
1) Unpack the zip
2) Initialize a git repo inside the folder that was unpacked
3) git add .
See the errors.. :o http://pastie.org/337571
Thanks,
Ramon Tayag
^ permalink raw reply
* Re: help needed: Splitting a git repository after subversion migration
From: Thomas Jarosch @ 2008-12-12 14:22 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: Michael J Gruber, git
In-Reply-To: <20081211081009.GA14639@atjola.homenet>
On Thursday, 11. December 2008 09:10:09 you wrote:
> > Now I'll manually check the history of the tags/ and branches/ folder
> > for more funny tags and write down the revision. If I understood
> > the git-svn man page correctly, I should be able to specifiy
> > revision ranges it's going to import. I'll try to skip the broken tags.
>
> As long as the breakage only involves branches/tags that are completely
> useless, it's probably a lot easier to just delete them afterwards.
>
> And if you accidently added changes to a tag, after it was created, it's
> also easier to manually tag to right version in git, and just forgetting
> about the additional commit.
>
> And for a bunch of other cases, rebase -i/filter-branch are probably
> also better options ;-)
>
> Skipping revisions in a git-svn import sounds rather annoying and
> error-prone.
Sounds very reasonable. When I'm done filtering with filter-branch,
the original commits are still stored in "refs/originals" and the reflogs.
What's the best way to get rid of those to free up the space?
A nice way to find the corresponding commit for a file can be found here:
http://stackoverflow.com/questions/223678/git-which-commit-has-this-blob
Thanks for your help so far!
Thomas
PS: Yes, I have a backup copy of the repository ;-)
^ permalink raw reply
* Re: [PATCH] Fix t7606 on Cygwin: for some reasont it does not recognize a "." in PATH
From: Stefan Näwe @ 2008-12-12 14:01 UTC (permalink / raw)
To: git
In-Reply-To: <81b0412b0812120428mc85ae84r260b722022dc3449@mail.gmail.com>
Alex Riesen <raa.lkml <at> gmail.com> writes:
>
> The test uses the dot to add custom merge strategies
> ---
> t/t7606-merge-custom.sh | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> Attachment (0001-Fix-t7606-on-Cygwin-it-does-not-recognize-a-.-in.patch):
application/octet-stream, 759 bytes
Any special reason why you sent this as an (normally frowned-upon) attachment ?
For me, however, this would be the way to go to be able to download the patch
without any hassle. (see my other post).
Regards,
Stefan
^ permalink raw reply
* Re: Fwd: after first git clone of linux kernel repository there are changed files in working dir
From: Nick Andrew @ 2008-12-12 13:51 UTC (permalink / raw)
To: rdkrsr; +Cc: git
In-Reply-To: <d304880b0812110958u3da52e4fs7e5154ebe9a353a@mail.gmail.com>
On Thu, Dec 11, 2008 at 06:58:01PM +0100, rdkrsr wrote:
> windows xp and msysgit for this. And the file system is NTFS. I'm
> using dual boot to sporadicly use linux and tried also linux in
> virtual box.
You could use git inside your VirtualBox linux install.
> But both isn't really good. Maybe one day I dare to use
> linux as my primary OS.
It's not scary, really.
Nick.
^ permalink raw reply
* [PATCH] Fix t7606 on Cygwin: for some reasont it does not recognize a "." in PATH
From: Alex Riesen @ 2008-12-12 12:29 UTC (permalink / raw)
To: Git Mailing List; +Cc: Junio C Hamano
[-- Attachment #1: Type: text/plain, Size: 142 bytes --]
The test uses the dot to add custom merge strategies
---
t/t7606-merge-custom.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
[-- Attachment #2: 0001-Fix-t7606-on-Cygwin-it-does-not-recognize-a-.-in.patch --]
[-- Type: application/octet-stream, Size: 759 bytes --]
From 928b2b955bd2ef0e400de698c0c0bcde5e64638b Mon Sep 17 00:00:00 2001
From: Alex Riesen <raa.lkml@gmail.com>
Date: Mon, 29 Sep 2008 17:07:00 +0200
Subject: [PATCH] Fix t7606 on Cygwin: for some reasont it does not recognize a "." in PATH
The test uses the dot to add custom merge strategies
---
t/t7606-merge-custom.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/t/t7606-merge-custom.sh b/t/t7606-merge-custom.sh
index 52a451d..20c0907 100755
--- a/t/t7606-merge-custom.sh
+++ b/t/t7606-merge-custom.sh
@@ -11,7 +11,7 @@ cat >git-merge-theirs <<EOF
eval git read-tree --reset -u \\\$\$#
EOF
chmod +x git-merge-theirs
-PATH=.:$PATH
+PATH=$(pwd):"$PATH"
export PATH
test_expect_success 'setup' '
--
1.6.1.rc2.48.g3c7df
^ permalink raw reply related
* Re: Clarifying "invalid tag signature file" error message from git filter-branch (and others)
From: Jim Meyering @ 2008-12-12 11:02 UTC (permalink / raw)
To: James Youngman; +Cc: Brandon Casey, git
In-Reply-To: <c5df85930812111559p287ea6afk54a9759302288d5e@mail.gmail.com>
"James Youngman" <jay@gnu.org> wrote:
> On Thu, Dec 11, 2008 at 11:13 PM, Brandon Casey <casey@nrlssc.navy.mil> wrote:
>
>>> Before conversion:
>>> $ git cat-file tag FINDUTILS-4_1-10
>>> object ce25eb352de8dc53a9a7805ba9efc1c9215d28c2
>>> type commit
>>> tag FINDUTILS-4_1-10
>>> tagger Kevin Dalley
>>
>> The tagger field is missing an email address, a timestamp, and a timezone. It
>> should look something like:
>>
>> tagger Kevin Dalley <kevin.dalley@somewhere.com> 1229036026 -0800
>>
>> git-mktag prevents improperly formatted tags from being created by checking
>> that these fields exist and are well formed.
>>
>> If you know the correct values for the missing fields, then you could
>
> Yes for the email address. But as for the timestamp, it's not in
> the tag file; that only contains the sha1.
> There is a timestamp in the object being tagged, is that the timestamp
> you are talking about?
>
> $ git show --pretty=raw ce25eb352de8dc53a9a7805ba9efc1c9215d28c2
> commit ce25eb352de8dc53a9a7805ba9efc1c9215d28c2
> tree 752cca144d39bc55d05fbe304752b274ba22641c
> parent 9a998755249b0c8c47e8657cff712fa506aa30fc
> author Kevin Dalley <kevin@seti.org> 830638152 +0000
> committer Kevin Dalley <kevin@seti.org> 830638152 +0000
>
> *** empty log message ***
>
> diff --git a/debian.Changelog b/debian.Changelog
> index e3541eb..d0cd295 100644
> --- a/debian.Changelog
> +++ b/debian.Changelog
> @@ -1,5 +1,7 @@
> Sat Apr 27 12:29:06 1996 Kevin Dalley
> <kevin@aplysia.iway.aimnet.com (Kevin Dalley)>
>
> + * find.info, find.info-1, find.info-2: updated to match find.texi
> +
> * debian.rules (debian): update debian revision to 10
>
> * getline.c (getstr): verify that nchars_avail is *really* greater
>
>
>
>
>
>> recreate the tags before doing the filter-branch. If they are unknown, it
>> seems valid enough to use the values from the commit that the tag points
>> to.
>>
>> i.e.
>>
>> tagger Kevin Dalley <kevin@seti.org> 830638152 -0000
>>
>> What tool was used to convert this repository to git? It should be corrected
>> to produce valid annotated tags. Especially if it is a tool within git.
>
> I don't know, Jim Meyering will know though, so I CC'ed him.
I used parsecvs, probably with git-master from the date of
the initial conversion (check the archives for actual date).
That was long enough ago that it was almost certainly before
git-mktag learned to be more strict about its inputs.
James, since you're about to rewrite the history, you may want to
start that process from a freshly-cvs-to-git-converted repository.
I'm not very happy about using cvsparse (considering it's not
really being maintained, afaik), so if the git crowd
can recommend something better, I'm all ears.
^ permalink raw reply
* [JGIT PATCH] Fix typos in comments / testcase output
From: Mike Ralphson @ 2008-12-12 10:55 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, Mike Ralphson, Robin Rosenberg
Signed-off-by: Mike Ralphson <mike@abacus.co.uk>
---
Is it me, or is the actual maintainer of JGIT/EGIT not actually
mentioned anywhere? Apologies if I've got the to and cc round
the wrong way 8-)
This patch is the product of
find . -name "*.java" -type f -exec aspell --mode=ccpp -c {} \;
I would post my aspell wordlists but they're polluted by other
projects...
Possibly also s/packes to/packs so/ in README?
.../org/spearce/egit/core/GitMoveDeleteHook.java | 2 +-
.../org/spearce/jgit/lib/RepositoryTestCase.java | 2 +-
.../spearce/jgit/revwalk/RevCommitParseTest.java | 2 +-
.../spearce/jgit/transport/BundleWriterTest.java | 2 +-
.../spearce/jgit/transport/FetchConnection.java | 2 +-
5 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/org.spearce.egit.core/src/org/spearce/egit/core/GitMoveDeleteHook.java b/org.spearce.egit.core/src/org/spearce/egit/core/GitMoveDeleteHook.java
index cc4059c..7faa65a 100644
--- a/org.spearce.egit.core/src/org/spearce/egit/core/GitMoveDeleteHook.java
+++ b/org.spearce.egit.core/src/org/spearce/egit/core/GitMoveDeleteHook.java
@@ -122,7 +122,7 @@ public boolean moveFolder(final IResourceTree tree, final IFolder source,
final IFolder destination, final int updateFlags,
final IProgressMonitor monitor) {
// TODO: Implement this. Should be relatively easy, but consider that
- // Eclipse thinks folders are real thinsgs, while Git does not care.
+ // Eclipse thinks folders are real things, while Git does not care.
return FINISH_FOR_ME;
}
diff --git a/org.spearce.jgit.test/tst/org/spearce/jgit/lib/RepositoryTestCase.java b/org.spearce.jgit.test/tst/org/spearce/jgit/lib/RepositoryTestCase.java
index 8937145..9e48fde 100644
--- a/org.spearce.jgit.test/tst/org/spearce/jgit/lib/RepositoryTestCase.java
+++ b/org.spearce.jgit.test/tst/org/spearce/jgit/lib/RepositoryTestCase.java
@@ -94,7 +94,7 @@ protected void configure() {
/**
* Utility method to delete a directory recursively. It is
- * also used internally. If a file or directory cannote be removed
+ * also used internally. If a file or directory cannot be removed
* it throws an AssertionFailure.
*
* @param dir
diff --git a/org.spearce.jgit.test/tst/org/spearce/jgit/revwalk/RevCommitParseTest.java b/org.spearce.jgit.test/tst/org/spearce/jgit/revwalk/RevCommitParseTest.java
index 805e29e..9b95924 100644
--- a/org.spearce.jgit.test/tst/org/spearce/jgit/revwalk/RevCommitParseTest.java
+++ b/org.spearce.jgit.test/tst/org/spearce/jgit/revwalk/RevCommitParseTest.java
@@ -226,7 +226,7 @@ public void testParse_explicit_bad_encoded() throws Exception {
*
* What happens here is that an encoding us given, but data is not encoded
* that way (and we can detect it), so we try other encodings. Here data could
- * actually be decoded in the stated encoding, but we overide using UTF-8.
+ * actually be decoded in the stated encoding, but we override using UTF-8.
*
* @throws Exception
*/
diff --git a/org.spearce.jgit.test/tst/org/spearce/jgit/transport/BundleWriterTest.java b/org.spearce.jgit.test/tst/org/spearce/jgit/transport/BundleWriterTest.java
index 3cfb8b1..f13d25c 100644
--- a/org.spearce.jgit.test/tst/org/spearce/jgit/transport/BundleWriterTest.java
+++ b/org.spearce.jgit.test/tst/org/spearce/jgit/transport/BundleWriterTest.java
@@ -117,7 +117,7 @@ assertEquals(db.resolve("c").name(), newRepo.resolve("refs/heads/cc")
// Check that we actually needed the first bundle
Repository newRepo2 = createNewEmptyRepo();
fetchResult = fetchFromBundle(newRepo2, bundle);
- fail("We should not be able to fetch from bundle with prerequisistes that are not fulfilled");
+ fail("We should not be able to fetch from bundle with prerequisites that are not fulfilled");
} catch (MissingBundlePrerequisiteException e) {
assertTrue(e.getMessage()
.indexOf(db.resolve("refs/heads/a").name()) >= 0);
diff --git a/org.spearce.jgit/src/org/spearce/jgit/transport/FetchConnection.java b/org.spearce.jgit/src/org/spearce/jgit/transport/FetchConnection.java
index 461ad71..a56ca6c 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/transport/FetchConnection.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/transport/FetchConnection.java
@@ -126,7 +126,7 @@ public void fetch(final ProgressMonitor monitor, final Collection<Ref> want)
* able to supply a fully connected graph to the client (although it may
* only be transferring the parts the client does not yet have). Its faster
* to assume such remote peers are well behaved and send the correct
- * response to the client. In such tranports this method returns false.
+ * response to the client. In such transports this method returns false.
*
* @return true if the last fetch had to perform a connectivity check on the
* client side in order to succeed; false if the last fetch assumed
--
1.6.0.2
^ permalink raw reply related
* Re: [PATCH v3 3/3] gitweb: Optional grouping of projects by category
From: Jakub Narebski @ 2008-12-12 9:26 UTC (permalink / raw)
To: Sébastien Cevey
Cc: git, Junio C Hamano, Petr Baudis, Gustavo Sverzut Barbieri
In-Reply-To: <87y6ymxf4k.wl%seb@cine7.net>
On Fri, 12 Dec 2008, Sébastien Cevey wrote:
> At Fri, 12 Dec 2008 03:03:55 +0100, Jakub Narebski wrote:
>
> > And no, we don't need to sort by categories first. Let me explain
> > in more detail a bit.
>
> Thanks for the detailed explanation, I understand your preference.
> But as you said, it's a bit arbitrary, I think none is completely
> obvious.
First, I feel a bit bad for derailing this patch. Currently gitweb
does not do pagination of projects list; it is not even possible in
a sane way with current way project searching/selecting is implemented.
So the whole build_projlist_by_category() respecting $from and $to is
moot point.
So if we don't use it, even if it is nice to have for the future, we
don't need to pay cost of extra stable sorting.
>
> I don't really have a strong opinion about which is best, but just to
> illustrate what made me go for the solution B, let me show another
> example:
>
> name / date / cat
> 1 2006 A
> 2 2003 B
> 3 2005 B
> 4 2003 A
> 5 2000 A
> 6 2008 C
> 7 2007 C
> 8 2001 B
> 9 2005 A
>
> We then sort by name and split in pages of N=3 (sorted by cat on each
> page):
>
> A:sort(name) split(max=3) subsort(cat)
> 1 2006 A 4 2003 A 9 2005 A
> 2 2003 B 5 2000 A 8 2001 B
> 3 2005 B 6 2008 C 7 2007 C
>
> B:sort(cat) subsort(name) split(max=3)
> 1 2006 A 9 2005 A 8 2001 B
> 4 2003 A 2 2003 B 6 2008 C
> 5 2000 A 3 2005 B 7 2007 C
>
> With B, we have the second top-entry (2) relegated to the second page,
> which might be surprising because we ordered by name. But what I find
> weird about A is that because of the per-page category sorting, the
> "top-sorted entries at the top" isn't true either (page 3). We have
> "reshuffled" the result of 'sort(name) split(max=3)' on each page.
[...]
> It's perhaps even more apparent if we sort by date:
>
> A:sort(year) split(max=3) subsort(cat)
> 1 2006 A 9 2005 A 4 2003 A
> 6 2008 C 3 2005 B 5 2000 A
> 7 2007 C 2 2003 B 8 2001 B
>
> B:sort(cat) subsort(year) split(max=4)
> 1 2006 A 4 2003 A 3 2005 B
> 9 2005 A 8 2001 B 7 2007 C
> 5 2000 A 2 2003 B 6 2008 C
>
> It feels kind of unnatural that not only projects are not sorted by
> date on each page (they are inside categories), but moreover
> categories are spread over all pages.
>
>
> I guess it depends on your use case, and whether categories are
> important or known by the user. I personally don't really care (I
> never split stuff into pages in the gitweb I use), so I can do a new
> version of my patch that does A if you prefer, just let me know. I
> just wanted to clarify that both solutions sort of suck :-)
Well, with version A you can (I think) simply change
foreach my $cat (sort keys %categories) {
to
foreach my $cat (sort
{ cmp_cat($projlist, \%categories, $oi, $a, $b) } keys %categories) {
to have the following output (see the difference on page 3)
A':sort(name) split(max=3) subsort(sort(cat,name))
1 2006 A 4 2003 A 7 2007 C
2 2003 B 5 2000 A 8 2001 B
3 2005 B 6 2008 C 9 2005 A
where sort_cat might be something like (we took advantage that
categories in %categories have at least one project):
sub cmp_cat {
my ($projlist, $cats, $oi, $a, $b) = @_;
my ($aa, $bb);
# projects in categories are sorted, so we can compare first
# project from a category to sort categories in given ordering
$aa = $projlist->{$cats->{$a}[0]};
$bb = $projlist->{$cats->{$b}[0]};
if ($oi->{'type'} eq 'str') {
return $aa->{$oi->{'key'}} cmp $bb->{$oi->{'key'}};
} else {
return $aa->{$oi->{'key'}} <=> $bb->{$oi->{'key'}};
}
}
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: Saving patches from this list
From: Mike Ralphson @ 2008-12-12 9:07 UTC (permalink / raw)
To: Stefan Näwe; +Cc: git, Johannes Sixt, Junio C Hamano
In-Reply-To: <loom.20081212T082629-274@post.gmane.org>
2008/12/12 Stefan Näwe <stefan.naewe+git@gmail.com>
>
> Johannes Sixt <j.sixt <at> viscovery.net> writes:
>
> >
> > Stefan Näwe schrieb:
> > > What's the best way to get patches sent to this list in a form suitable
> > > for 'git am' without subscribing to this list ?
> >
> > Subscribe to gmane.comp.version-control.git on news.gmane.org with your
> > favorite news reader and browse the list whenever you feel like it.
>
> Do you know how stubborn firewall administrators can be ?
>
> IOW, that's unfortunately not an option for me.
If it's only the occasional patch - (I see you're on gmail too), show
original and copy-and-paste into an editor with tabs set up
appropriately. Works for me.
Junio's blog[1] shows he's looking at patchwork. Personally I think it
would be fantastic to have a public patchwork server available. It
might avoid the chicken and egg problem in that it's currently easier
(for some people) to get hold of a patch to play with / review only
after it's accepted.
That said, I think including a link to a repo/branch from which the
current version of a patch series could be fetched would be an
amazingly useful addition to most [PATCH 0/n] cover-letters...
Mike
[1] http://gitster.livejournal.com/18696.html
^ permalink raw reply
* [PATCH] git-config.txt: fix a typo
From: Jim Meyering @ 2008-12-12 9:00 UTC (permalink / raw)
To: git list
---
Documentation/git-config.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-config.txt b/Documentation/git-config.txt
index 28e1861..19a8917 100644
--- a/Documentation/git-config.txt
+++ b/Documentation/git-config.txt
@@ -279,7 +279,7 @@ If you want to know all the values for a multivar, do:
% git config --get-all core.gitproxy
------------
-If you like to live dangerous, you can replace *all* core.gitproxy by a
+If you like to live dangerously, you can replace *all* core.gitproxy by a
new one with
------------
--
1.6.1.rc2.299.gead4c
^ permalink raw reply related
* Re: Saving patches from this list
From: Stefan Näwe @ 2008-12-12 8:28 UTC (permalink / raw)
To: git
In-Reply-To: <49421AEE.8090902@viscovery.net>
Johannes Sixt <j.sixt <at> viscovery.net> writes:
>
> Stefan Näwe schrieb:
> > What's the best way to get patches sent to this list in a form suitable
> > for 'git am' without subscribing to this list ?
>
> Subscribe to gmane.comp.version-control.git on news.gmane.org with your
> favorite news reader and browse the list whenever you feel like it.
Do you know how stubborn firewall administrators can be ?
IOW, that's unfortunately not an option for me.
Regards,
Stefan
^ permalink raw reply
* Re: Saving patches from this list
From: Johannes Sixt @ 2008-12-12 8:03 UTC (permalink / raw)
To: Stefan Näwe; +Cc: git
In-Reply-To: <loom.20081212T072326-350@post.gmane.org>
Stefan Näwe schrieb:
> What's the best way to get patches sent to this list in a form suitable
> for 'git am' without subscribing to this list ?
Subscribe to gmane.comp.version-control.git on news.gmane.org with your
favorite news reader and browse the list whenever you feel like it.
-- Hannes
^ permalink raw reply
* Saving patches from this list
From: Stefan Näwe @ 2008-12-12 7:27 UTC (permalink / raw)
To: git
I have some kind of a 'meta question' not exactly regarding git.
What's the best way to get patches sent to this list in a form suitable
for 'git am' without subscribing to this list ?
TIA
Stefan
^ permalink raw reply
* Re: What's cooking in git.git (Nov 2008, #06; Wed, 26)
From: Jeff King @ 2008-12-12 3:36 UTC (permalink / raw)
To: Junio C Hamano
Cc: Daniel Barkalow, Nguyen Thai Ngoc Duy, Shawn O. Pearce,
Johannes Schindelin, git
In-Reply-To: <7vmyf29jd6.fsf@gitster.siamese.dyndns.org>
On Thu, Dec 11, 2008 at 07:12:53PM -0800, Junio C Hamano wrote:
> Sure, but as "sparse" does not (again, "it should not, at least to me")
> change the fact that git is about tracking the history of whole tree, not
> just a single file, nor just a subset of files, none of these operations
> should be affected about what the checkout area is.
I agree with Junio here. If you want "git grep foo HEAD^" to ignore
certain files, then sparse _checkout_ is not the right feature. In that
case you want a sparse _repo_, which is not something I think anybody is
seriously working on.
-Peff
^ permalink raw reply
* Re: git-doc CSS dependent, breaks down in text browsers
From: Jeff King @ 2008-12-12 3:33 UTC (permalink / raw)
To: jidanni; +Cc: git, 507475
In-Reply-To: <87wse6zc9x.fsf@jidanni.org>
On Fri, Dec 12, 2008 at 04:29:14AM +0800, jidanni@jidanni.org wrote:
> E.g., pages look like
>
> SYNOPSIS
>
> git-config [<file-option>] [type] [-z|--null] name [value [value_regex]] git-config [<file-option>] [type] --add name
> value git-config [<file-option>] [type] --replace-all name [value [value_regex]] git-config [<file-option>] [type] [-z|
> --null] --get name [value_regex] git-config [<file-option>] [type] [-z|--null] --get-all name [value_regex] git-config...
I think this is another asciidoc issue, as git merely specifies "verse"
format for this section. Probably the most friendly thing to do would be
to use
<pre class="verseblock-content">
instead of
<div class="verseblock-content">
so that non-CSS browsers fall back to preserving the line boundaries
(which is what is making it look so unbearable in your text browser).
But it is definitely something to be fixed in asciidoc, not in the git
documentation.
-Peff
^ permalink raw reply
* Re: What's cooking in git.git (Nov 2008, #06; Wed, 26)
From: Junio C Hamano @ 2008-12-12 3:12 UTC (permalink / raw)
To: Daniel Barkalow
Cc: Nguyen Thai Ngoc Duy, Shawn O. Pearce, Johannes Schindelin, git
In-Reply-To: <alpine.LNX.1.00.0812112045120.19665@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> writes:
> "git diff" is an ambiguous model for "git grep". It equally describes
> the behavior of "git diff" to say that it treats files outside the
> checkout area as matching the index or to say that it never lists files
> outside the checkout area. On the other hand, there is the question of
> whether "git diff branch1 branch2" shows differences that are outside the
> checkout area, and whether "git log" shows commits that only change things
> outside the checkout area, and "git grep" should match the behavior of
> these.
Sure, but as "sparse" does not (again, "it should not, at least to me")
change the fact that git is about tracking the history of whole tree, not
just a single file, nor just a subset of files, none of these operations
should be affected about what the checkout area is.
^ 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