* Anyone have access to 64-bit Vista?
From: Geoffrey Lee @ 2009-01-27 9:30 UTC (permalink / raw)
To: git
I'm trying to develop for TortoiseGit on a 64-bit Vista SP1 system,
but I'm having trouble registering the shell extensions with explorer.
I'm hoping somebody else here who has access to 64-bit Vista can tell
me if TortoiseGit runs on their machine? I want to find out if this
problem is only affecting my machine.
http://code.google.com/p/tortoisegit/
-Geoffrey Lee
^ permalink raw reply
* Re: Valgrind updates
From: Johannes Schindelin @ 2009-01-27 9:31 UTC (permalink / raw)
To: Jeff King; +Cc: Linus Torvalds, Junio C Hamano, git
In-Reply-To: <20090127044838.GA735@coredump.intra.peff.net>
Hi,
On Mon, 26 Jan 2009, Jeff King wrote:
> On Mon, Jan 26, 2009 at 07:38:56PM -0800, Linus Torvalds wrote:
>
> > > ==valgrind== Syscall param write(buf) points to uninitialised byte(s)
> > > ==valgrind== at 0x5609E40: __write_nocancel (in /lib/libpthread-2.6.1.so)
> > > ==valgrind== by 0x4D0380: xwrite (wrapper.c:129)
> > > ==valgrind== by 0x4D046E: write_in_full (wrapper.c:159)
> > > ==valgrind== by 0x4C0697: write_buffer (sha1_file.c:2275)
> > > ==valgrind== by 0x4C0B1C: write_loose_object (sha1_file.c:2387)
> >
> > Looks entirely bogus.
> >
> > I suspect that valgrind for some reason doesn't see the writes made by
> > zlib as being initialization, possibly due to some incorrect valgrind
> > annotations on deflate(). We've just totally initialized that whole
> > buffer with deflate().
> >
> > It definitely does not look like a git bug, but a valgrind run issue.
>
> Yes, this is exactly the issue I ran into when doing the valgrind stuff
> a few months ago. I spent several hours looking carefully at the code
> and came to the same conclusion. Anything zlib touches needs to be
> manually suppressed for uninitialized writes (which I _thought_ was
> covered in the suppressions I sent out originally, but maybe they need
> to be tweaked for Dscho's system).
Indeed. I used the "..." wildcard to account for slight differences in
Git's code calling path.
Sorry for the noise,
Dscho
^ permalink raw reply
* Re: [PATCH/RFC v1 5/6] combine-diff.c: remove a call to fstat() inside show_patch_diff()
From: Mike Ralphson @ 2009-01-27 9:35 UTC (permalink / raw)
To: Kjetil Barvik; +Cc: git
In-Reply-To: <1233004637-15112-6-git-send-email-barvik@broadpark.no>
2009/1/26 Kjetil Barvik <barvik@broadpark.no>:
> Currently inside show_patch_diff() we have and fstat() call after an
> ok lstat() call. Since we before the call to fstat() have already
> test for the link case with S_ISLNK() the fstat() can be removed.
s/have and/have an/ ?
^ permalink raw reply
* Re: [RFC/PATCH 0/3] fix "Funny: git -p submodule summary"
From: Johannes Sixt @ 2009-01-27 10:06 UTC (permalink / raw)
To: Jeff King; +Cc: Johannes Schindelin, git
In-Reply-To: <20090127062512.GA10487@coredump.intra.peff.net>
Jeff King schrieb:
> JSixt, there are some tweaks to the Windows code to report back the exec
> error. They look obviously correct to me, but I have no box to test
> (even compile test) them on.
Generally, I like this series, in particular since it does not degrade
performance on Windows ;)
But the following is needed in addition.
- Note that run_command returns the negated exit code, therefore, we
must negate it again in the call to exit(). Without this t6030 failed.
(And negative exit codes causes grief on Windows because bash for some
reason does not recognize that as failure.)
- The close() calls can overwrite errno. And since fork() should not
(cannot?) fail with ENOENT, it's safe to remove the #ifdef __MINGW32__.
-- Hannes
diff --git a/git.c b/git.c
index 79a836c..35635d1 100644
--- a/git.c
+++ b/git.c
@@ -414,7 +414,7 @@ static void execv_dashed_external
*/
status = run_command_v_opt(argv, 0);
if (status != -ERR_RUN_COMMAND_EXEC)
- exit(status);
+ exit(-status);
errno = ENOENT; /* as if we called execvp */
argv[0] = tmp;
diff --git a/run-command.c b/run-command.c
index 2437798..b05c734 100644
--- a/run-command.c
+++ b/run-command.c
@@ -187,27 +187,24 @@ int start_command
if (s2 >= 0)
dup2(s2, 2), close(s2);
#endif
if (cmd->pid < 0) {
+ int err = errno;
if (need_in)
close_pair(fdin);
else if (cmd->in)
close(cmd->in);
if (need_out)
close_pair(fdout);
else if (cmd->out)
close(cmd->out);
if (need_err)
close_pair(fderr);
-#ifndef __MINGW32__
- return -ERR_RUN_COMMAND_FORK;
-#else
- return errno == ENOENT ?
+ return err == ENOENT ?
-ERR_RUN_COMMAND_EXEC :
-ERR_RUN_COMMAND_FORK;
-#endif
}
if (need_in)
close(fdin[0]);
else if (cmd->in)
^ permalink raw reply related
* Re: git 1.6.1 on AIX 5.3
From: Mike Ralphson @ 2009-01-27 10:10 UTC (permalink / raw)
To: Perry Smith; +Cc: git, Jeff King
In-Reply-To: <9E98493A-B17A-4905-8BEA-3E0B837961D6@gmail.com>
2009/1/26 Perry Smith <pedzsan@gmail.com>:
> Thanks guys. I picked up coreutils version 7. I didn't
> install them but just moved ginstall over to /usr/local/bin.
>
> A few other comments: I had to add in the --without-tcltk flag. I don't
> have tcl installed but the config did not autodetect that it was not present.
Yup, I usually build with NO_TCLTK=YesPlease in my config.mak, which
you can see from the link Peff posted.
When you said 'out of tree builds' I thought you meant using the AIX
defaults in the Makefile without running ./configure, but it seems
not, you meant is a clone of the tree buildable by itself or are only
release snapshots buildable. Sorry.
./configure is (deliberately) a second-class citizen in the world of
git, and may still get you a slightly suboptimal build compared with
the defaults on platforms such as AIX... e.g. it doesn't test for
performance-related switches such as INTERNAL_QSORT. If you have run
configure, there's some file you need to blow away to get back to a
non-autoconf world... is it config.mak.autogen?
Despite that, your problem with --without-tcltk falling back to wish,
but not falling back if that isn't installed does look like something
we should fix, as per Peff's mail.
> I can't tell if make test is happy or not. The output looks like its happy
> but the exit code is 2.
>
> Below is my "configure" script if anyone is interested.
>
> #!/usr/bin/env bash
>
> export CONFIG_SHELL=/usr/local/bin/bash
> export LDFLAGS='-L/usr/local/lib -L/usr/local/ssl/lib'
> export CFLAGS='-I/usr/local/include -I/usr/local/ssl/include'
> export CC=gcc
> echo CONFIG_SHELL set to ${CONFIG_SHELL}
>
> ${CONFIG_SHELL} ../../src/git-1.6.1/configure --without-tcltk
>
> #
> # Note that to install you need to do:
> # make INSTALL=ginstall install
> # to use GNU's install program
I build with SHELL_PATH={path}/bash as well. If I don't, the test
suite exits after t0000-basic.sh with an unexpected error despite
passing all the tests.
gmake -C t/ all
gmake[1]: Entering directory `/usr/local/src/gitbuild/t'
rm -f -r test-results
gmake aggregate-results-and-cleanup
gmake[2]: Entering directory `/usr/local/src/gitbuild/t'
*** t0000-basic.sh ***
* passed all remaining 40 test(s)
FATAL: Unexpected exit with code 0
gmake[2]: *** [t0000-basic.sh] Error 1
gmake[2]: Leaving directory `/usr/local/src/gitbuild/t'
gmake[1]: *** [all] Error 2
gmake[1]: Leaving directory `/usr/local/src/gitbuild/t'
gmake: *** [test] Error 2
Is that what you're seeing? There's many more test scripts than that 8-)
With GIT_SKIP_TESTS='t3900 t3901 t5100.[12] t8005' (to omit some cases
not handled by the version of iconv I have access to on all the AIX
boxes I deploy to) the test suit runs to completion on AIX 5.3 for me.
BTW Are you running AIX's make or GNU make?
Mike
^ permalink raw reply
* Re: connecting existing local git repository to svn
From: Michael J Gruber @ 2009-01-27 10:35 UTC (permalink / raw)
To: Ittay Dror; +Cc: git
In-Reply-To: <497E8927.1060506@gmail.com>
Ittay Dror venit, vidit, dixit 01/27/09 05:10:
> Hi,
>
>
> I'd like to create a branch in a subversion repository so that I can
> work with git-svn on it.
>
>
> My git repository is already with a history, that I don't want to
> replicate to subversion, I want to start with subversion having just the
> latest revision and then continue from there normally (git svn
> dcommit/rebase).
>
>
> How can I do that?
Create the svn branch (with svn) and "git svn clone". Pull in your git
branch under a new name (if that is what you want).
Now, you can e.g. "git merge -s theirs" your other git branch into
master, git svn rebase and dcommit. Untested, but comes with best wishes ;)
Do you want to discard your existing git history completely?
Cheers,
Michael
^ permalink raw reply
* Re: connecting existing local git repository to svn
From: Ittay Dror @ 2009-01-27 10:41 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git
In-Reply-To: <497EE386.5050805@drmicha.warpmail.net>
Michael J Gruber wrote:
> Ittay Dror venit, vidit, dixit 01/27/09 05:10:
>
>> Hi,
>>
>>
>> I'd like to create a branch in a subversion repository so that I can
>> work with git-svn on it.
>>
>>
>> My git repository is already with a history, that I don't want to
>> replicate to subversion, I want to start with subversion having just the
>> latest revision and then continue from there normally (git svn
>> dcommit/rebase).
>>
>>
>> How can I do that?
>>
>
> Create the svn branch (with svn) and "git svn clone". Pull in your git
> branch under a new name (if that is what you want).
> Now, you can e.g. "git merge -s theirs" your other git branch into
> master, git svn rebase and dcommit. Untested, but comes with best wishes ;)
>
but wouldn't that create a revision in svn for each commit in git?
what i want is something like:
git: ----v1----v2----v3--v4---v5
svn: \---v4--v5
so the svn history starts from v3, but the git history remains unchanged.
ittay
> Do you want to discard your existing git history completely?
>
> Cheers,
> Michael
>
^ permalink raw reply
* Re: Emacs git-mode feature request: support fill-paragraph correctly
From: Alexandre Julliard @ 2009-01-27 11:03 UTC (permalink / raw)
To: Peter Simons; +Cc: git
In-Reply-To: <87tz7mth3g.fsf@write-only.cryp.to>
Peter Simons <simons@cryp.to> writes:
> Other modes, such as message-mode, do support that kind of thing
> correctly, so apparently it is possible to configure what the editor
> considers as a paragraph. Is there some Emacs wizard out there who'd
> be kind enough to improve git-mode accordingly?
You could try something like this:
diff --git a/contrib/emacs/git.el b/contrib/emacs/git.el
index 3c37d0d..e314c44 100644
--- a/contrib/emacs/git.el
+++ b/contrib/emacs/git.el
@@ -1331,6 +1331,7 @@ Return the list of files that haven't been handled."
(log-edit-diff-function . git-log-edit-diff)) buffer)
(log-edit 'git-do-commit nil 'git-log-edit-files buffer))
(setq font-lock-keywords (font-lock-compile-keywords git-log-edit-font-lock-keywords))
+ (setq paragraph-separate (concat (regexp-quote git-log-msg-separator) "$\\|Author: \\|Date: \\|Merge: \\|Signed-off-by: \\|\f\\|[ ]*$"))
(setq buffer-file-coding-system coding-system)
(re-search-forward (regexp-quote (concat git-log-msg-separator "\n")) nil t))))
--
Alexandre Julliard
julliard@winehq.org
^ permalink raw reply related
* Re: Translations [of Documentation] in Git release?
From: Jakub Narebski @ 2009-01-27 11:16 UTC (permalink / raw)
To: Peter Krefting; +Cc: Git Mailing List, Mike Hommey, Dill, Sverre Rabbelier
In-Reply-To: <Pine.LNX.4.64.0901270800100.26770@ds9.cixit.se>
On Tue, 27 Jan 2009, Peter Krefting wrote:
> Sverre Rabbelier:
>
> > Perhaps the basics can be translated at least, the documents that do
> > not require much change because they represent stable concepts?
>
> I usually start out translating the program output, then manual pages,
> and then, time permitting, documentation.
The problem with translating program output (program messages) in Git
is twofold: fundamental and technical. Fundamental, that program
output is considered API (at least for plumbing commands) and used
when scripting (this might be ameliorated with "I am script" switch
or environmental variable). Technical, because Git is mixture of
programs in C, shell scripts, and Perl scripts, and you have to come
with technical means of translating messages in all three of them.
> Git is a bit special in that regard since "--help" gets hardwired to
> display the manual page, so one can't just translate the help screen.
Not in all cases. Sometimes it shows "long usage". Perhaps that should
be made more consistent?
--
Jakub Narebski
Poland
^ permalink raw reply
* [PATCH] Fix submodule squashing into unrelated commit
From: Johannes Schindelin @ 2009-01-27 11:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vljsxyv58.fsf@gitster.siamese.dyndns.org>
Actually, I think the issue is pretty independent of submodules; when
"git commit" gets an empty parameter, it misinterprets it as a file.
So avoid passing an empty parameter to "git commit".
Actually, this is a nice cleanup, as MSG_FILE and EDIT_COMMIT were mutually
exclusive; use one variable instead
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
We might want to safeguard "git commit", too.
git-rebase--interactive.sh | 9 ++++-----
t/t3404-rebase-interactive.sh | 2 +-
2 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index 002929e..3ac7162 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -373,17 +373,15 @@ do_next () {
pick_one -n $sha1 || failed=t
case "$(peek_next_command)" in
squash|s)
- EDIT_COMMIT=
USE_OUTPUT=output
MSG_OPT=-F
- MSG_FILE="$MSG"
+ EDIT_OR_FILE="$MSG"
cp "$MSG" "$SQUASH_MSG"
;;
*)
- EDIT_COMMIT=-e
USE_OUTPUT=
MSG_OPT=
- MSG_FILE=
+ EDIT_OR_FILE=-e
rm -f "$SQUASH_MSG" || exit
cp "$MSG" "$GIT_DIR"/SQUASH_MSG
rm -f "$GIT_DIR"/MERGE_MSG || exit
@@ -397,7 +395,8 @@ do_next () {
GIT_AUTHOR_NAME="$GIT_AUTHOR_NAME" \
GIT_AUTHOR_EMAIL="$GIT_AUTHOR_EMAIL" \
GIT_AUTHOR_DATE="$GIT_AUTHOR_DATE" \
- $USE_OUTPUT git commit --no-verify $MSG_OPT "$MSG_FILE" $EDIT_COMMIT || failed=t
+ $USE_OUTPUT git commit --no-verify \
+ $MSG_OPT "$EDIT_OR_FILE" || failed=t
fi
if test $failed = t
then
diff --git a/t/t3404-rebase-interactive.sh b/t/t3404-rebase-interactive.sh
index 6ffb9ad..4becc55 100755
--- a/t/t3404-rebase-interactive.sh
+++ b/t/t3404-rebase-interactive.sh
@@ -484,7 +484,7 @@ test_expect_success 'submodule rebase setup' '
git commit -a -m "Three changes submodule"
'
-test_expect_failure 'submodule rebase -i' '
+test_expect_success 'submodule rebase -i' '
FAKE_LINES="1 squash 2 3" git rebase -i A
'
--
1.6.1.482.g7d54be
^ permalink raw reply related
* Re: [PATCH/RFC v1 5/6] combine-diff.c: remove a call to fstat() inside show_patch_diff()
From: Kjetil Barvik @ 2009-01-27 12:03 UTC (permalink / raw)
To: Mike Ralphson; +Cc: git
In-Reply-To: <e2b179460901270135j6e4cb887radbe664ac98f39f1@mail.gmail.com>
Mike Ralphson <mike.ralphson@gmail.com> writes:
> 2009/1/26 Kjetil Barvik <barvik@broadpark.no>:
>> Currently inside show_patch_diff() we have and fstat() call after an
>> ok lstat() call. Since we before the call to fstat() have already
>> test for the link case with S_ISLNK() the fstat() can be removed.
>
> s/have and/have an/ ?
Correct! Will fix. Thanks!
-- kjetil
^ permalink raw reply
* Re: [PATCH/RFC v1 5/6] combine-diff.c: remove a call to fstat() inside show_patch_diff()
From: Mike Ralphson @ 2009-01-27 12:06 UTC (permalink / raw)
To: Kjetil Barvik; +Cc: git
In-Reply-To: <86myddj6qi.fsf@broadpark.no>
2009/1/27 Kjetil Barvik <barvik@broadpark.no>
> Mike Ralphson <mike.ralphson@gmail.com> writes:
>
> > 2009/1/26 Kjetil Barvik <barvik@broadpark.no>:
> >> Currently inside show_patch_diff() we have and fstat() call after an
> >> ok lstat() call. Since we before the call to fstat() have already
> >> test for the link case with S_ISLNK() the fstat() can be removed.
> >
> > s/have and/have an/ ?
>
> Correct! Will fix. Thanks!
Typo stood out and blinded me to the rest of the grammar... How about:
Currently inside show_patch_diff() we have an fstat() call after an
ok lstat() call. Since before the call to fstat() we have already
tested for the link case with S_ISLNK(), the fstat() can be removed.
'Half-a-job' Mike
^ permalink raw reply
* Re: connecting existing local git repository to svn
From: Sverre Rabbelier @ 2009-01-27 12:16 UTC (permalink / raw)
To: Ittay Dror; +Cc: Michael J Gruber, git
In-Reply-To: <497EE4E8.8070705@gmail.com>
On Tue, Jan 27, 2009 at 11:41, Ittay Dror <ittay.dror@gmail.com> wrote:
> git: ----v1----v2----v3--v4---v5
> svn: \---v4--v5
>
> so the svn history starts from v3, but the git history remains unchanged.
Create the new branch from v3 then, and use git svn to pull it in.
Then you can do 'git rebase that-svn-branch' on your git branch to put
all commits (not as one big commit) on top of that branch point. Now
you 'git checkout' that-svn-branch and do 'git reset --hard
the-git-branch', which should now consist of
v1--v2--v3--v4(git)--v5(git), etc. If you do 'git svn dcommit' from
the that-svn-branch now it should dcommit to svn each of your git
commits individually. Of course, don't forget to make a backup before
you start messing around :P.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [RFC/PATCH 0/3] fix "Funny: git -p submodule summary"
From: Jeff King @ 2009-01-27 12:23 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Johannes Schindelin, git
In-Reply-To: <497EDCB0.8080806@kdbg.org>
On Tue, Jan 27, 2009 at 11:06:40AM +0100, Johannes Sixt wrote:
> - Note that run_command returns the negated exit code, therefore, we must
> negate it again in the call to exit(). Without this t6030 failed. (And
> negative exit codes causes grief on Windows because bash for some reason
> does not recognize that as failure.)
Oops, indeed. And you made me realize that I forgot to run the test
script against this patchset.
However, I'm not sure just negating the exit code is sufficient.
run_command can return codes in the 10000 range for its own internal
errors. We don't want to pass those out through exit, which will
truncate them to 8 bits.
> - The close() calls can overwrite errno.
Good point.
> And since fork() should not (cannot?) fail with ENOENT, it's safe to
> remove the #ifdef __MINGW32__.
Yeah, I thought of that, but I was worried it might make the code a
little bit non-obvious (but it does clean up an ifdef, which is ugly,
too).
Thanks for your feedback. I'll squash in your fixes and repost 2/3 later
today.
-Peff
^ permalink raw reply
* Re: [RFC/PATCH 0/3] fix "Funny: git -p submodule summary"
From: Johannes Sixt @ 2009-01-27 12:46 UTC (permalink / raw)
To: Jeff King; +Cc: Johannes Schindelin, git
In-Reply-To: <20090127122315.GA22628@sigill.intra.peff.net>
Jeff King schrieb:
> However, I'm not sure just negating the exit code is sufficient.
> run_command can return codes in the 10000 range for its own internal
> errors. We don't want to pass those out through exit, which will
> truncate them to 8 bits.
Exit code and start_command/finish_command's return code handling is a
complete mess IMHO and deserves a clean-up series of its own. If the few
codes at 10000 and above are truncated to 8 bits, then we get exit codes
16 and higher; I think that's good enough for this series.
-- Hannes
^ permalink raw reply
* Re: connecting existing local git repository to svn
From: Ittay Dror @ 2009-01-27 12:48 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Michael J Gruber, git
In-Reply-To: <bd6139dc0901270416u22b60fefp472935470b1db929@mail.gmail.com>
Sverre Rabbelier wrote:
> On Tue, Jan 27, 2009 at 11:41, Ittay Dror <ittay.dror@gmail.com> wrote:
>
>> git: ----v1----v2----v3--v4---v5
>> svn: \---v4--v5
>>
>> so the svn history starts from v3, but the git history remains unchanged.
>>
>
> Create the new branch from v3 then, and use git svn to pull it in.
> Then you can do 'git rebase that-svn-branch' on your git branch to put
> all commits (not as one big commit) on top of that branch point. Now
> you 'git checkout' that-svn-branch and do 'git reset --hard
> the-git-branch', which should now consist of
> v1--v2--v3--v4(git)--v5(git), etc. If you do 'git svn dcommit' from
> the that-svn-branch now it should dcommit to svn each of your git
>
sorry, my ascii art was confusing:
git: ----v1----v2----v3--v4---v5
svn: v1-4---v5
v1-4 is v1 to v4 squashed together. (e.g., if i added a file in v2 and
removed in v3 it will not appear in svn history)
hope it is clear now.
ittay
> commits individually. Of course, don't forget to make a backup before
> you start messing around :P.
>
>
^ permalink raw reply
* Re: connecting existing local git repository to svn
From: Michael J Gruber @ 2009-01-27 13:02 UTC (permalink / raw)
To: Ittay Dror; +Cc: Sverre Rabbelier, git
In-Reply-To: <497F0280.2070400@gmail.com>
Ittay Dror venit, vidit, dixit 01/27/09 13:48:
>
> Sverre Rabbelier wrote:
>
>> On Tue, Jan 27, 2009 at 11:41, Ittay Dror <ittay.dror@gmail.com> wrote:
>>
>>> git: ----v1----v2----v3--v4---v5
>>> svn: \---v4--v5
>>>
>>> so the svn history starts from v3, but the git history remains unchanged.
>>>
>> Create the new branch from v3 then, and use git svn to pull it in.
>> Then you can do 'git rebase that-svn-branch' on your git branch to put
>> all commits (not as one big commit) on top of that branch point. Now
>> you 'git checkout' that-svn-branch and do 'git reset --hard
>> the-git-branch', which should now consist of
>> v1--v2--v3--v4(git)--v5(git), etc. If you do 'git svn dcommit' from
>> the that-svn-branch now it should dcommit to svn each of your git
>>
> sorry, my ascii art was confusing:
>
> git: ----v1----v2----v3--v4---v5
> svn: v1-4---v5
>
> v1-4 is v1 to v4 squashed together. (e.g., if i added a file in v2 and
> removed in v3 it will not appear in svn history)
Well, for git and svn "revisions" are really "versions" of the complete
tree, not changesets. Have messed around with hg lately? ;)
On the other hand, a commit that introduces a new version is the
difference with respect to the previous "version".
Ususally it's clear what is meant, but you seem to mix both notions.
So, if v? denotes a version, then v4 is the result of all commits
leading up to v4. It *is* v4. "squashing" applies only to commits
("changes").
In any case, Sverre's as well as my suggestions should do what you want.
Why not try it out if you doubt it?
Cheers,
Michael
^ permalink raw reply
* [PATCH] Windows: Fix intermittent failures of t7701
From: Johannes Sixt @ 2009-01-27 13:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
From: Johannes Sixt <j6t@kdbg.org>
The last test case checks whether unpacked objects receive the time stamp
of the pack file. Due to different implementations of stat(2) by MSYS and
our version in compat/mingw.c, the test fails in about half of the test
runs.
Note the following facts:
- The test uses perl's -M operator to compare the time stamps. Since we
depend on MSYS perl, the result of this operator is based on MSYS's
implementation of the stat(2) call.
- NTFS on Windows records fractional seconds.
- The MSYS implementation of stat(2) *rounds* fractional seconds to full
seconds instead of truncating them. This becomes obvious by comparing the
modification times reported by 'ls --full-time $f' and 'stat $f' for
various files $f.
- Our implementation of stat(2) in compat/mingw.c *truncates* to full
seconds.
The consequence of this is that
- add_packed_git() picks up truncated whole second modification times
from the pack file time stamp, which is then used for the loose objects,
while the pack file retains its time stamp in fractional seconds;
- but the test case compares the pack file's rounded modification times
to the loose objects' truncated modification times.
And half of the time the rounded modification time is not the same as its
truncated modification time.
The fix is that we replace perl by 'test-chmtime -v +0', which prints the
truncated whole-second mtime without modifying it.
We want to catch failures of test-chmtime; but since it appears in a pipe,
we cannot access its exit code. Therefore, we at least make sure that it
prints time stamps of all files that are passed on its command line.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
---
t/t7701-repack-unpack-unreachable.sh | 15 +++++++++------
1 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/t/t7701-repack-unpack-unreachable.sh b/t/t7701-repack-unpack-unreachable.sh
index 63a8225..e6e9f99 100755
--- a/t/t7701-repack-unpack-unreachable.sh
+++ b/t/t7701-repack-unpack-unreachable.sh
@@ -50,12 +50,15 @@ test_expect_success '-A with -d option leaves unreachable objects unpacked' '
compare_mtimes ()
{
- perl -e 'my $reference = shift;
- foreach my $file (@ARGV) {
- exit(1) unless(-f $file && -M $file == -M $reference);
- }
- exit(0);
- ' -- "$@"
+ test-chmtime -v +0 "$@" |
+ {
+ read ref files &&
+ while read t name; do
+ test $ref = $t || break
+ files="$files $name"
+ done &&
+ test "$files" = "$*"
+ }
}
test_expect_success '-A without -d option leaves unreachable objects packed' '
--
1.6.1.1.1203.g5882
^ permalink raw reply related
* Re: Valgrind updates
From: Mark Brown @ 2009-01-27 13:14 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Linus Torvalds, Jeff King, Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0901270512171.14855@racer>
On Tue, Jan 27, 2009 at 05:26:34AM +0100, Johannes Schindelin wrote:
> I suspected that zlib does something "cute" with alignments, i.e. that it
> writes a possibly odd number of bytes, but then rounds up the buffer to
> the next multiple of two of four bytes.
I don't recall anything along those lines in zlib but it does generate
warnings with valgrind which require overrides - it has at least one
unrolled loop which roll on beyond initialised memory (but keep within
memory that zlib knows it has allocated). It rolls back the results of
the loop before producing output, but it's possible that some unused
bits in the stream may be derived from the results.
^ permalink raw reply
* [PATCHv3] gitweb: make static files accessible with PATH_INFO
From: Giuseppe Bilotta @ 2009-01-27 13:29 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Junio C Hamano, Giuseppe Bilotta
When PATH_INFO is defined, static files such as the defalt CSS or the
shortcut icon are not accessible beyond the summary page (e.g. in
shortlog or commit view).
Fix this by adding a <base> tag pointing to the script base URL.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
Of course, last time I forgot that the BASE href is supposed to be
absolute. While Opera apparently has no problem with it being relative,
other browsers such as Firefox are stricter about it.
gitweb/gitweb.perl | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 931db4f..411b1f6 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -2901,6 +2901,14 @@ sub git_header_html {
<meta name="robots" content="index, nofollow"/>
<title>$title</title>
EOF
+# the stylesheet, favicon etc urls won't work correctly with path_info unless we set the appropriate base URL
+ if ($ENV{'PATH_INFO'}) {
+ my $base = $my_url;
+ my $sname = $ENV{'SCRIPT_NAME'};
+ $base =~ s,\Q$sname\E$,,;
+ $base .= "/";
+ print "<base href=\"$base\"/>\n";
+ }
# print out each stylesheet that exist
if (defined $stylesheet) {
#provides backwards capability for those people who define style sheet in a config file
--
1.5.6.5
^ permalink raw reply related
* Wrong url using relative submodule over gitorious-ssh
From: Robert Wohlrab @ 2009-01-27 13:37 UTC (permalink / raw)
To: git
Hi,
I tried to use submodules in git. Since I am using gitorious at the moment it
would be nice to have relative urls to be able to checkout as user and as
developer. When I am using a checkout over git's native protocol it works fine
but when I am trying to use ssh it creates a bogus url and nothing changes if
I am using more ../ before the url.
Lets explain it by example. First thing is that we are assuming that we
checked out it over git's own protocol (it is emulated by setting the origin
url in my example)
$ mkdir test1
$ cd test1
$ git init
$ git remote add origin git://gitorious.org/test/mainline.git
$ git submodule init
$ git submodule add ../../test2/mainline.git subdir
Initialized empty Git repository in ~/test1/subdir/.git/
remote: Counting objects: 123, done.
....
Ok, you will receive a
Initialized empty Git repository in ~/test1/subdir/.git/
fatal: The remote end hung up unexpectedly
Clone of 'git://gitorious.org/test2/mainline.git' into submodule path
'subdir' failed
but that is fine because git://gitorious.org/test2/mainline.git is a valid
gitorious url (if somebody would create test2 as project).
Lets take a look at gitorious urls for ssh push access. They look like
git@gitorious.org:test1/mainline.git - similar to the ones used for pull over
the public git daemon.
$ mkdir test1
$ cd test1
$ git init
$ git remote add origin git@gitorious.org:test1/mainline.git
$ git submodule init
$ git submodule add ../../test2/mainline.git subdir
Initialized empty Git repository in ~/test1/subdir/.git/
Access denied or bad repository path
fatal: The remote end hung up unexpectedly
Clone of 'git@gitorious.org:test1/test2/mainline.git' into submodule path
'subdir' failed
This is definitely not the url I expected. It is unimportant how many more ../
I add but the test1/ will not get away. It is also important that their is no
/ after : or otherwise the clone will fail too.
This is an important issue for KDE because they want to use (Qt's) gitorious
and maybe submodules when they want switch to git.
$ git --version
git version 1.6.1.1.230.gdfb04
and on my origin/next test
$ git --version
git version 1.6.1.1.363.g2a3bd
--
Robert Wohlrab
^ permalink raw reply
* Re: [PATCH] mergetool: respect autocrlf by using checkout-index
From: Hannu Koivisto @ 2009-01-27 13:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Charles Bailey, git, Theodore Tso
In-Reply-To: <7vocxt3bsc.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> Perhaps something along this line to teach
>>
>> $ git merge-file --attribute-path=frotz.c file1 orig_file file2
>>
>> to merge what happened since orig_file to file2 into file1, and deposit
>> the result after converting it appropriately for path "frotz.c" obeying
>> core.autocrlf and gitattribute rules.
>>
>> I see rerere.c::merge() has the exact same issue, but its breakage is half
>> hidden by its use of fopen(path, "w"). It should explicitly use
>> convert_to_working_tree() like this patch does, and write the results out
>> in binary mode.
>
> Second try. I forgot how convert_* worked X-<.
Argh, it seems I have wasted your time. That patch may do
something useful but in this case with _or without_ it all the
files seem to be correct in the filesystem before I save the merge
result in emerge. I.e. it seems that for some reason Emacs detects
the coding system of the result file incorrectly. I'll investigate
that at some point especially if ediff suffers from the same
problem.
--
Hannu
^ permalink raw reply
* Re: Emacs git-mode feature request: support fill-paragraph correctly
From: Peter Simons @ 2009-01-27 14:07 UTC (permalink / raw)
To: git
In-Reply-To: <873af59fkm.fsf@wine.dyndns.org>
Hi Alexandre,
> diff --git a/contrib/emacs/git.el b/contrib/emacs/git.el
> index 3c37d0d..e314c44 100644
> --- a/contrib/emacs/git.el
> +++ b/contrib/emacs/git.el
> @@ -1331,6 +1331,7 @@ Return the list of files that haven't been handled."
> (log-edit-diff-function . git-log-edit-diff)) buffer)
> (log-edit 'git-do-commit nil 'git-log-edit-files buffer))
> (setq font-lock-keywords (font-lock-compile-keywords git-log-edit-font-lock-keywords))
> + (setq paragraph-separate (concat (regexp-quote git-log-msg-separator) "$\\|Author: \\|Date: \\|Merge: \\|Signed-off-by: \\|\f\\|[ ]*$"))
> (setq buffer-file-coding-system coding-system)
> (re-search-forward (regexp-quote (concat git-log-msg-separator "\n")) nil t))))
that patch has the desired effect (tested with GNU Emacs 22.3.1 and
GIT 1.6.1). Thank you very much.
Now, I'd be hugely in favor of applying that change to the repository
so that future versions of GIT have it.
Take care,
Peter
^ permalink raw reply
* Re: Translations [of Documentation] in Git release?
From: Peter Krefting @ 2009-01-27 14:45 UTC (permalink / raw)
To: Git Mailing List; +Cc: Mike Hommey, Dill, Sverre Rabbelier, Jakub Narebski
In-Reply-To: <200901271216.59687.jnareb@gmail.com>
Jakub Narebski:
> Fundamental, that program output is considered API (at least for
> plumbing commands) and used when scripting (this might be ameliorated
> with "I am script" switch or environmental variable).
That's a bug. Protocol data (which one could consider the plumbing
output to be) should never be forwarded to the end-user, except for
debugging purposes. It is the porcelain's task here to translate the
messages for the user.
Plumbing commands could still output semi-readable English, but it is
still to be considered protocol, and be hidden from the user. Having
low-level protocol data filter through to the end-user is a common
mistake in software, unfortunately, and makes internationalization and
localization a lot harder.
Of course, if the user insists on calling the plumbing commands
directly, he will not get translated output. That's expected behaviour.
> Technical, because Git is mixture of programs in C, shell scripts,
> and Perl scripts, and you have to come with technical means of
> translating messages in all three of them.
Gettext has succesfully been used to translate messages in all of these
environments, so that should not be a big problem.
> Not in all cases. Sometimes it shows "long usage". Perhaps that
> should be made more consistent?
Consistency is good.
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* "malloc failed"
From: David Abrahams @ 2009-01-27 15:04 UTC (permalink / raw)
To: git
I've been abusing Git for a purpose it wasn't intended to serve:
archiving a large number of files with many duplicates and
near-duplicates. Every once in a while, when trying to do something
really big, it tells me "malloc failed" and bails out (I think it's
during "git add" but because of the way I issued the commands I can't
tell: it could have been a commit or a gc). This is on a 64-bit linux
machine with 8G of ram and plenty of swap space, so I'm surprised.
Git is doing an amazing job at archiving and compressing all this stuff
I'm putting in it, but I have to do it a wee bit at a time or it craps
out. Bug?
--
Dave Abrahams
BoostPro Computing
http://www.boostpro.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