* Re: Unable to index file
From: Linus Torvalds @ 2008-12-12 18:15 UTC (permalink / raw)
To: Ramon Tayag; +Cc: git
In-Reply-To: <alpine.LFD.2.00.0812120956050.3340@localhost.localdomain>
On Fri, 12 Dec 2008, Linus Torvalds wrote:
>
> Now, admittedly git is probably being really annoyingly anal about this
> all, and we probably should loosen the restrictions on it a bit, but I'd
> like to know why it happens. I cannot recall this having been reported
> before, so it's some specific filesystem or OS that causes this, I think.
Anyway, the "loosen the symlink lstat() requirements" patch would likely
look something like this. I can't really test it, though, since I only
have filesystems that have matching lstat()/readlink() sizes.
Linus
---
sha1_file.c | 11 ++++++-----
1 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/sha1_file.c b/sha1_file.c
index 0e021c5..222c793 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -2522,9 +2522,9 @@ int index_fd(unsigned char *sha1, int fd, struct stat *st, int write_object,
int index_path(unsigned char *sha1, const char *path, struct stat *st, int write_object)
{
- int fd;
+ int fd, len;
char *target;
- size_t len;
+ size_t bufsize;
switch (st->st_mode & S_IFMT) {
case S_IFREG:
@@ -2537,9 +2537,10 @@ int index_path(unsigned char *sha1, const char *path, struct stat *st, int write
path);
break;
case S_IFLNK:
- len = xsize_t(st->st_size);
- target = xmalloc(len + 1);
- if (readlink(path, target, len + 1) != st->st_size) {
+ bufsize = 1+xsize_t(st->st_size);
+ target = xmalloc(bufsize);
+ len = readlink(path, target, bufsize);
+ if (len < 0) {
char *errstr = strerror(errno);
free(target);
return error("readlink(\"%s\"): %s", path,
^ permalink raw reply related
* Re: Unable to index file
From: Linus Torvalds @ 2008-12-12 18:07 UTC (permalink / raw)
To: Ramon Tayag; +Cc: git
In-Reply-To: <f25d5ad20812120647m646698d7t9849c8ccb08c465e@mail.gmail.com>
On Fri, 12 Dec 2008, Ramon Tayag wrote:
>
> 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
What platform/filesystem is this?
Git is rather particular about symlinks, and it looks like your platform
does something odd, and that makes git unhappy about your symlink.
In particular:
ls -l vendor/rails/actionpack/test/fixtures/layout_tests/layouts/
...
lrwxrwxrwx 1 root root 48 2008-12-12 18:22 symlinked -> ../../symlink_parent
notice how the symlink content is "../../symlink_parent", but then take a
look at the _size_ of the symlink: 48 bytes.
Git expects the lstat() information to match the return from readlink(),
and it doesn't.
For exact details, see "index_path()" in sha1_file.c:
case S_IFLNK:
len = xsize_t(st->st_size);
target = xmalloc(len + 1);
if (readlink(path, target, len + 1) != st->st_size) {
char *errstr = strerror(errno);
ie we consider it an error if we get less than st_size characters back
from readlink().
Now, admittedly git is probably being really annoyingly anal about this
all, and we probably should loosen the restrictions on it a bit, but I'd
like to know why it happens. I cannot recall this having been reported
before, so it's some specific filesystem or OS that causes this, I think.
Linus
^ permalink raw reply
* diff -b / -w and empty diffs
From: Lars Noschinski @ 2008-12-12 17:57 UTC (permalink / raw)
To: git
Hello!
If the difference between two files is only whitespace, "git diff -b"
leads to diffs just consisting of the "diff" and "index" lines. I would
like an option to suppress those files in the diff output because it
breaks "git diff -b > patch; git apply patch" workflows (and often I'm
just interested in "real" changes).
Is there any reason why such behaviour is not implemented yet (besides
the fact that nobody cared to do it)?
^ permalink raw reply
* [patch] documentation: Explain how to free up space after filter-branch
From: Thomas Jarosch @ 2008-12-12 17:42 UTC (permalink / raw)
To: git; +Cc: Björn Steinbrink
Explain how to free up space after filter-branch.
Thanks to Björn Steinbrink for pointing me in the right direction.
Signed-off-by: Thomas Jarosch <thomas.jarosch@intra2net.com>
diff --git a/Documentation/git-filter-branch.txt b/Documentation/git-filter-branch.txt
index fed6de6..1432380 100644
--- a/Documentation/git-filter-branch.txt
+++ b/Documentation/git-filter-branch.txt
@@ -319,6 +319,18 @@ git filter-branch --index-filter \
mv $GIT_INDEX_FILE.new $GIT_INDEX_FILE' HEAD
---------------------------------------------------------------
+Free up the space in .git if the rewritten version is correct
+by deleting refs/original and pruning the reflog:
+
+----------------------------------------------------
+git for-each-ref --format='%(refname)' refs/original
+ | xargs -i git update-ref -d {}
+
+git reflog expire --expire=0 --all
+git repack -a -d --depth=250 --window=250
+git prune
+----------------------------------------------------
+
Author
------
^ permalink raw reply related
* Re: [PATCH 2/3 (edit v2)] gitweb: Cache $parent_commit info in git_blame()
From: Jakub Narebski @ 2008-12-12 17:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nanako Shiraishi, git, Luben Tuikov
In-Reply-To: <7vr64e9jq6.fsf@gitster.siamese.dyndns.org>
On Fri, 12 Dec 2008, Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
> > Only commit message has changed.
>
> Which is a bit unnice, because it will conflict with the original [3/3]
> that I queued already (with a pair of fixes, including but not limited to
> the one you sent "Oops, it should have been like this" for).
>
> I can hand wiggle the patch to make it apply, but I'd prefer if I did not
> have to do this every time I receive a patch.
I'm sorry about that; I have forgot to change order of patches to have
original 1/3, 3/3, 2/3 (I should have used 'stg float' for that).
> I think the conflict was trivial (just a single s/rev/short_rev/) and I
> did not make a silly mistake when I fixed it up, but please check the
> result on 'pu' after I push the results out.
I did the reordering, and gitweb on compared top of reordered stack
of patches with gitweb from top of 'pu' branch, and the only
difference in the area touched by git_blame improvements series is
one comment I have added in v2 of 3/3.
Thank you for your work.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: What's cooking in git.git (Nov 2008, #06; Wed, 26)
From: Nguyen Thai Ngoc Duy @ 2008-12-12 16:54 UTC (permalink / raw)
To: Johannes Sixt
Cc: Junio C Hamano, Daniel Barkalow, Shawn O. Pearce,
Johannes Schindelin, git
In-Reply-To: <4942952E.1060706@viscovery.net>
On 12/12/08, Johannes Sixt <j.sixt@viscovery.net> wrote:
> Nguyen Thai Ngoc Duy schrieb:
>
> > On 12/12/08, Junio C Hamano <gitster@pobox.com> wrote:
> >> So "git grep -e frotz Documentation/", whether you only check out
> >> Documentation or the whole tree, should grep only in Documentation area,
> >> and "git grep -e frotz" should grep in the whole tree, even if you happen
> >> to have a sparse checkout. By definition, a sparse checkout has no
> >> modifications outside the checkout area, so whenever grep wants to look
> >> for strings outside the checkout area it should pretend as if the same
> >> content as what the index records is in the work tree. This is consistent
> >> with the way how "git diff" in a sparsely checked out work tree should
> >> behave.
> >
> > Assume someone is using sparse checkout with KDE git repository. They
> > sparse-checkout kdeutils module and do "git grep -e foo". I would
> > expect that the command only searches in kdeutils only (and is the
> > current behavior).
>
>
> But what if the same persion notices a #define in a kdeutils header file
> and want's to know whether it is unused in order to remove it:
>
> $ git grep FOO
> kdeutils/foo.h:#define FOO bar
"git grep --cached FOO" ?
> Conclusion from this output: "It's only defined, but not used anywhere."
> But this conclusion is not necessarily correct because FOO could be used
> outside kdeutils.
>
> So, no, "git grep" should disregard the checkout area.
>
> -- Hannes
>
--
Duy
^ permalink raw reply
* Re: Clarifying "invalid tag signature file" error message from git filter-branch (and others)
From: Jakub Narebski @ 2008-12-12 16:53 UTC (permalink / raw)
To: Jim Meyering; +Cc: James Youngman, Brandon Casey, git
In-Reply-To: <87zlj1hd0r.fsf@rho.meyering.net>
Jim Meyering <jim@meyering.net> writes:
> 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 parsecvs (considering it's not
> really being maintained, afaik), so if the git crowd
> can recommend something better, I'm all ears.
The page you might want to consult is
http://git.or.cz/gitwiki/InterfacesFrontendsAndTools
There you have listed git-cvsimport, which uses cvsps to extract
patchset, is in git, and is as far as I know the only tool that allow
incremental import; parsecvs which requires access to *,v files you
use; cvs2svn (cvs2git) which have learned fast-import format and can
be used to import (fast) CVS repositories, but incremental import
(difficult that it is) is only in plans, AFAIK.
So I would recommend trying cvs2svn / cvs2git.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: What's cooking in git.git (Nov 2008, #06; Wed, 26)
From: Johannes Sixt @ 2008-12-12 16:45 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy
Cc: Junio C Hamano, Daniel Barkalow, Shawn O. Pearce,
Johannes Schindelin, git
In-Reply-To: <fcaeb9bf0812120813m2949e36ar7905d5688b8f6ecb@mail.gmail.com>
Nguyen Thai Ngoc Duy schrieb:
> On 12/12/08, Junio C Hamano <gitster@pobox.com> wrote:
>> So "git grep -e frotz Documentation/", whether you only check out
>> Documentation or the whole tree, should grep only in Documentation area,
>> and "git grep -e frotz" should grep in the whole tree, even if you happen
>> to have a sparse checkout. By definition, a sparse checkout has no
>> modifications outside the checkout area, so whenever grep wants to look
>> for strings outside the checkout area it should pretend as if the same
>> content as what the index records is in the work tree. This is consistent
>> with the way how "git diff" in a sparsely checked out work tree should
>> behave.
>
> Assume someone is using sparse checkout with KDE git repository. They
> sparse-checkout kdeutils module and do "git grep -e foo". I would
> expect that the command only searches in kdeutils only (and is the
> current behavior).
But what if the same persion notices a #define in a kdeutils header file
and want's to know whether it is unused in order to remove it:
$ git grep FOO
kdeutils/foo.h:#define FOO bar
Conclusion from this output: "It's only defined, but not used anywhere."
But this conclusion is not necessarily correct because FOO could be used
outside kdeutils.
So, no, "git grep" should disregard the checkout area.
-- Hannes
^ permalink raw reply
* Re: Clarifying "invalid tag signature file" error message from git filter-branch (and others)
From: Brandon Casey @ 2008-12-12 16:44 UTC (permalink / raw)
To: Jim Meyering; +Cc: James Youngman, git
In-Reply-To: <87zlj1hd0r.fsf@rho.meyering.net>
Jim Meyering wrote:
> "James Youngman" <jay@gnu.org> wrote:
>> On Thu, Dec 11, 2008 at 11:13 PM, Brandon Casey <casey@nrlssc.navy.mil> wrote:
>>> 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.
I've only used git-cvsimport. AFAIK it creates light-weight tags in
git rather than annotated tags.
It also uses an unmaintained tool: cvsps. There are some additional
patches in a git repository somewhere that fix a few known problems.
You could try that James.
-brandon
^ permalink raw reply
* Re: Clarifying "invalid tag signature file" error message from git filter-branch (and others)
From: Brandon Casey @ 2008-12-12 16:21 UTC (permalink / raw)
To: James Youngman; +Cc: git, Jim Meyering
In-Reply-To: <c5df85930812111559p287ea6afk54a9759302288d5e@mail.gmail.com>
James Youngman 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?
Yes and no. I meant that if you knew the "real" timestamp, possibly by
extracting it from the original repository, then you can use that.
Otherwise yes, as a workaround, use the timestamp in the object being
tagged.
> $ 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
The committer information should be used, though in this repository it will
probably always be the same as the author.
-brandon
^ permalink raw reply
* Re: What's cooking in git.git (Nov 2008, #06; Wed, 26)
From: Nguyen Thai Ngoc Duy @ 2008-12-12 16:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Daniel Barkalow, Shawn O. Pearce, Johannes Schindelin, git
In-Reply-To: <7vy6ym9nm8.fsf@gitster.siamese.dyndns.org>
On 12/12/08, Junio C Hamano <gitster@pobox.com> wrote:
> So "git grep -e frotz Documentation/", whether you only check out
> Documentation or the whole tree, should grep only in Documentation area,
> and "git grep -e frotz" should grep in the whole tree, even if you happen
> to have a sparse checkout. By definition, a sparse checkout has no
> modifications outside the checkout area, so whenever grep wants to look
> for strings outside the checkout area it should pretend as if the same
> content as what the index records is in the work tree. This is consistent
> with the way how "git diff" in a sparsely checked out work tree should
> behave.
Assume someone is using sparse checkout with KDE git repository. They
sparse-checkout kdeutils module and do "git grep -e foo". I would
expect that the command only searches in kdeutils only (and is the
current behavior).
--
Duy
^ permalink raw reply
* Re: What's cooking in git.git (Nov 2008, #06; Wed, 26)
From: Nguyen Thai Ngoc Duy @ 2008-12-12 16:08 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Junio C Hamano, Shawn O. Pearce, Johannes Schindelin, git
In-Reply-To: <alpine.LNX.1.00.0812111520490.19665@iabervon.org>
On 12/12/08, Daniel Barkalow <barkalow@iabervon.org> wrote:
> > Well, if you set core.defaultsparse properly, those files should
> > appear/disappear as you wish (and as of now if you define your
> > checkout area with "git checkout --{include-,exclude-,}sparse" then
> > core.defaultsparse should be updated accordingly). I don't say
> > core.defaultsparse is perfect.
>
>
> Right, so in order to get reasonable behavior, the user must use
> --{include,exclude}-sparse. I think that this should be the *default*
> behavior, and probably the *only porcelain-supported* behavior, because
> otherwise it's confusing.
It's pretty hard (or intrusive) to enforce such behaviour. How about
showing files that does not match core.defaultsparse in "git status"
along with instructions how to add them to core.defaultsparse? That
way people can keep it consistent and less modification to current
code.
--
Duy
^ permalink raw reply
* Re: Clarifying "invalid tag signature file" error message from git filter-branch (and others)
From: James Youngman @ 2008-12-12 16:05 UTC (permalink / raw)
To: Jim Meyering; +Cc: Brandon Casey, git
In-Reply-To: <87zlj1hd0r.fsf@rho.meyering.net>
On Fri, Dec 12, 2008 at 11:02 AM, Jim Meyering <jim@meyering.net> wrote:
> "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.
Maybe, but then afaik CVS tags don't have timestamps, so some of the
data that git-mktag seems to want doesn't exist anyway.
But until we know the answer to the next question, I don't think we
know how we would generate such a freshly-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.
Thanks,
James.
^ 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: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
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