* 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
* 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
* Heads up: rebase -i -p will be made sane again
From: Johannes Schindelin @ 2009-01-27 9:29 UTC (permalink / raw)
To: Stephen Haberman, git
Dear list,
I am progressing to a point where I am almost comfortable to send the
patch series; I want to use the thing myself first, and I want to fix a
design bug.
As always, my code is public, but will be rebased frequently. You have
been warned.
BTW I am really sorry for the state I left the --preserve-merges code for
a long time. Originally, it was never meant to be used interactively, and
that shows sorely.
As for the design bug I want to fix: imagine this history:
------A
/ /
/ /
---- B
\ \
\ \
C-----D-----E = HEAD
A, C and D touch the same file, and A and D agree on the contents.
Now, rebase -p A does the following at the moment:
------A-----E' = HEAD
/ /
/ /
---- B
In other words, C is truly forgotten, and it is pretended that D never
happened, either. That is exactly what test case 2 in t3410 tests for
[*1*].
This is insane.
So after my rebase -i -p revamp, this will happen instead: in the
interactive version you will get the script
pick C
merge parents B' original D
pick E
In the non-interactive version -- or if you change nothing, in the
interactive version, too -- this will lead to a conflict while picking C.
As it should.
Ciao,
Dscho
[*1*] The code in t3410 was not really easy to read, even if there was an
explanation what it tried to do, but the test code was inconsitent,
sometimes tagging, sometimes not, sometimes committing with -a, sometimes
"git add"ing first, yet almost repetitive.
In my endeavor not only to understand it, and either fix my code or the
code in t3410, I refactored it so that others should have a much easier
time to understand what it actually does.
^ permalink raw reply
* Re: [Bug] rebase -i squashes submodule changes into unrelated commit
From: Junio C Hamano @ 2009-01-27 9:20 UTC (permalink / raw)
To: git; +Cc: Johannes Schindelin
In-Reply-To: <7vljsxyv58.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Attempting to rebase three-commit series (two regular changes, followed by
> one commit that changes what commit is bound for a submodule path) to
> squash the first two results in a failure; not just the first two commits
> squashed, but the change to the submodule is also included in the result.
>
> This failure causes the subsequent step to "pick" the change that actually
> changes the submodule to be applied, because there is no change left to be
> applied.
Sorry, an obvious typo is here: s/to be applied,/to fail,/;
^ permalink raw reply
* [Bug] rebase -i squashes submodule changes into unrelated commit
From: Junio C Hamano @ 2009-01-27 9:07 UTC (permalink / raw)
To: git; +Cc: Johannes Schindelin
Attempting to rebase three-commit series (two regular changes, followed by
one commit that changes what commit is bound for a submodule path) to
squash the first two results in a failure; not just the first two commits
squashed, but the change to the submodule is also included in the result.
This failure causes the subsequent step to "pick" the change that actually
changes the submodule to be applied, because there is no change left to be
applied.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
t/t3404-rebase-interactive.sh | 26 ++++++++++++++++++++++++++
1 files changed, 26 insertions(+), 0 deletions(-)
diff --git c/t/t3404-rebase-interactive.sh w/t/t3404-rebase-interactive.sh
index 2cc8e7a..6ffb9ad 100755
--- c/t/t3404-rebase-interactive.sh
+++ w/t/t3404-rebase-interactive.sh
@@ -462,4 +462,30 @@ test_expect_success 'do "noop" when there is nothing to cherry-pick' '
'
+test_expect_success 'submodule rebase setup' '
+ git checkout A &&
+ mkdir sub &&
+ (
+ cd sub && git init && >elif &&
+ git add elif && git commit -m "submodule initial"
+ ) &&
+ echo 1 >file1 &&
+ git add file1 sub
+ test_tick &&
+ git commit -m "One" &&
+ echo 2 >file1 &&
+ test_tick &&
+ git commit -a -m "Two" &&
+ (
+ cd sub && echo 3 >elif &&
+ git commit -a -m "submodule second"
+ ) &&
+ test_tick &&
+ git commit -a -m "Three changes submodule"
+'
+
+test_expect_failure 'submodule rebase -i' '
+ FAKE_LINES="1 squash 2 3" git rebase -i A
+'
+
test_done
^ permalink raw reply related
* Re: [topgit] shared topic branch
From: Fabien Thomas @ 2009-01-27 7:23 UTC (permalink / raw)
To: git; +Cc: martin f krafft
In-Reply-To: <20090126120049.GA9676@lapse.rw.madduck.net>
[-- Attachment #1: Type: text/plain, Size: 1398 bytes --]
>> I'm testing topgit 0.5 in a shared env. (multiple user working on
>> same
>> patch).
>
> Sorry for the late reply!
Thanks to reply :)
>
>
>> My problem is that when i want to push my local work i'm doing
>> "git push" that will force update the remote branch. The problem
>> is that each time master is not up to date i will push my entire
>> master or topic branch to the remote.
>
> I do not understand what you mean. Could yo please try to give us
> more detail? git push is intended to push all local changes to the
> remote, so I don't understand what your problem is.
I'm new to topgit and to git so maybe there is something i've
misunderstood:
on the git side:
the + will overwrite all remote location branche named with that
pattern ?
on topgit:
i'm just doing patches on two computer (home+work) and i'm pushing on
a central repo to "backup/share my changes"
if i'm not up to date and i start a push with the "+" will overwrite
the central repo with my local branch. (overwrite of my central repo
master branch and my topics)
to "solve" my problem i've replaced the remote section with this:
[remote "origin"]
url = ssh://git@xxx.com
fetch = refs/heads/*:refs/remotes/origin/*
fetch = refs/top-bases/*:refs/remotes/origin/top-bases/*
push = refs/top-bases/*:refs/top-bases/*
push = refs/heads/topic/*:refs/heads/topic/*
is it more clear?
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 1860 bytes --]
^ permalink raw reply
* Re: Translations [of Documentation] in Git release?
From: Peter Krefting @ 2009-01-27 7:01 UTC (permalink / raw)
To: Git Mailing List; +Cc: Mike Hommey, Jakub Narebski, Dill, Sverre Rabbelier
In-Reply-To: <bd6139dc0901261130ic64f767gddc960ebe3dfecf2@mail.gmail.com>
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.
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.
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* Re: [PATCH v2] contrib git-resurrect: find traces of a branch name and resurrect it
From: Junio C Hamano @ 2009-01-27 6:31 UTC (permalink / raw)
To: Thomas Rast; +Cc: Boyd Stephen Smith Jr., git, Johannes Schindelin
In-Reply-To: <1232973657-31444-1-git-send-email-trast@student.ethz.ch>
Thomas Rast <trast@student.ethz.ch> writes:
> Add a tool 'git-resurrect.sh <branch>' that tries to find traces of
> the <branch> in the HEAD reflog and, optionally, all merge commits in
> the repository. It can then resurrect the branch, pointing it at the
> most recent of all candidate commits found.
>
> Signed-off-by: Thomas Rast <trast@student.ethz.ch>
> ---
>
> Fixed the -h to upper-case in the short options summaries, and removed
> a stray 'q' in the default assignment of new_name.
I hate to paint bikeshed, but -H "try-hard" looks somewhat unusual doesn't
it? It sounds more like --all (find from all possible sources).
> +. git-sh-setup
> +cd_to_toplevel
Why?
> +search_reflog () {
> + sed -n 's~^\([^ ]*\) .*\tcheckout: moving from '"$1"' .*~\1~p' \
> + < .git/logs/HEAD
> +}
Once you used ". git-sh-setup", use "$GIT_DIR/logs/HEAD". That way, you
can work in a bare repository (and you do not have to cd_to_toplevel,
either, I think).
Oh, don't forget to skip this step if the reflog does not exist.
> +search_reflog_merges () {
> + sed -n 's~^[^ ]* \([^ ]*\) .*\tmerge '"$1"':~\1~p' \
> + < .git/logs/HEAD
> +}
The two commits both point at the HEAD that merges the other branch into,
so this finds a merge commit that has the tip of target branch as its
second parent. Is that really what you want?
> +search_merges () {
> + git rev-list --pretty=tformat:"%h %p:%s" --all |
> + grep "Merge branch.*'$branch'.*into" |
"git merge tr/topic~4" can say "Merge branch 'tr/topic' (early part)".
Also merge into 'master' won't have "into ...".
> + while read sha rest; do
> + parents="$(echo "$rest" | cut -d: -f1)"
> + case "$parents" in
> + *' '*' '*)
> + warn "$branch took part in octopus merge $sha"
> + warn "check manually!"
> + ;;
> + *' '*)
> + echo "$parents" | cut -d' ' -f2
> + ;;
> + esac
> + done
Reading everything down to the root commit sounds like fun. rev-list
gives you the output from newer to older so you may want to break out once
you have found enough candidates.
Anyway, if I were doing this script, I'd write this part like this without
a shell loop:
_x40="[0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f]"
_x40="$_x40$_x40$_x40$_x40$_x40$_x40$_x40$_x40"
git rev-list --all --grep="Merge branch '$1'" \
--pretty=tformat:"%H %P %s" |
sed -ne "s/^$_x40 $_x40 \($_x40\) Merge .*/\1/p"
^ permalink raw reply
* [RFC/PATCH 3/3] git: use run_command to execute dashed externals
From: Jeff King @ 2009-01-27 6:27 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Johannes Sixt, git
In-Reply-To: <20090127062512.GA10487@coredump.intra.peff.net>
We used to simply try calling execvp(); if it succeeded,
then we were done and the new program was running. If it
didn't, then we knew that it wasn't a valid command.
Unfortunately, this interacted badly with the new pager
handling. Now that git remains the parent process and the
pager is spawned, git has to hang around until the pager is
finished. We install an atexit handler to do this, but that
handler never gets called if we successfully run execvp.
You could see this behavior by running any dashed external
using a pager (e.g., "git -p stash list"). The command
finishes running, but the pager is still going. In the case
of less, it then gets an error reading from the terminal and
exits, potentially leaving the terminal in a broken state
(and not showing the output).
This patch just uses run_command to try running the
dashed external. The parent git process then waits for the
external process to complete and then handles the pager
cleanup as it would for an internal command.
Signed-off-by: Jeff King <peff@peff.net>
---
git.c | 14 ++++++++++----
1 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/git.c b/git.c
index 45e493d..79a836c 100644
--- a/git.c
+++ b/git.c
@@ -2,6 +2,7 @@
#include "exec_cmd.h"
#include "cache.h"
#include "quote.h"
+#include "run-command.h"
const char git_usage_string[] =
"git [--version] [--exec-path[=GIT_EXEC_PATH]] [-p|--paginate|--no-pager] [--bare] [--git-dir=GIT_DIR] [--work-tree=GIT_WORK_TREE] [--help] COMMAND [ARGS]";
@@ -392,6 +393,7 @@ static void execv_dashed_external(const char **argv)
{
struct strbuf cmd = STRBUF_INIT;
const char *tmp;
+ int status;
strbuf_addf(&cmd, "git-%s", argv[0]);
@@ -406,10 +408,14 @@ static void execv_dashed_external(const char **argv)
trace_argv_printf(argv, "trace: exec:");
- /* execvp() can only ever return if it fails */
- execvp(cmd.buf, (char **)argv);
-
- trace_printf("trace: exec failed: %s\n", strerror(errno));
+ /*
+ * if we fail because the command is not found, it is
+ * OK to return. Otherwise, we just pass along the status code.
+ */
+ status = run_command_v_opt(argv, 0);
+ if (status != -ERR_RUN_COMMAND_EXEC)
+ exit(status);
+ errno = ENOENT; /* as if we called execvp */
argv[0] = tmp;
--
1.6.1.1.367.g30b36
^ permalink raw reply related
* [RFC/PATCH 2/3] run_command: handle missing command errors more gracefully
From: Jeff King @ 2009-01-27 6:27 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Johannes Sixt, git
In-Reply-To: <20090127062512.GA10487@coredump.intra.peff.net>
When run_command was asked to run a non-existant command,
its behavior varied depending on the platform:
- on POSIX systems, we would fork, and then after the
execvp call failed, we could call die(), which prints a
message to stderr and exits with code 128.
- on Windows, we do a PATH lookup, realize the program
isn't there, and then return ERR_RUN_COMMAND_FORK
The goal of this patch is to make it clear to callers that
the specific error was a missing command. To do this, we
will return the error code ERR_RUN_COMMAND_EXEC, which is
already defined in run-command.h, checked for in several
places, but never actually gets set.
The new behavior is:
- on POSIX systems, we exit the forked process with code
127 (the same as the shell uses to report missing
commands). The parent process recognizes this code and
returns an EXEC error. The stderr message is silenced,
since the caller may be speculatively trying to run a
command. Instead, we use trace_printf so that somebody
interested in debugging can see the error that occured.
- on Windows, we check errno, which is already set
correctly by mingw_spawnvpe, and report an EXEC error
instead of a FORK error
Thus it is safe to speculatively run a command:
int r = run_command_v_opt(argv, 0);
if (r == -ERR_RUN_COMMAND_EXEC)
/* oops, it wasn't found; try something else */
else
/* we failed for some other reason, error is in r */
Signed-off-by: Jeff King <peff@peff.net>
---
run-command.c | 19 ++++++++++++++++---
1 files changed, 16 insertions(+), 3 deletions(-)
diff --git a/run-command.c b/run-command.c
index db9ce59..2437798 100644
--- a/run-command.c
+++ b/run-command.c
@@ -118,7 +118,9 @@ int start_command(struct child_process *cmd)
} else {
execvp(cmd->argv[0], (char *const*) cmd->argv);
}
- die("exec %s failed.", cmd->argv[0]);
+ trace_printf("trace: exec '%s' failed: %s\n", cmd->argv[0],
+ strerror(errno));
+ exit(127);
}
#else
int s0 = -1, s1 = -1, s2 = -1; /* backups of stdin, stdout, stderr */
@@ -197,7 +199,13 @@ int start_command(struct child_process *cmd)
close(cmd->out);
if (need_err)
close_pair(fderr);
+#ifndef __MINGW32__
return -ERR_RUN_COMMAND_FORK;
+#else
+ return errno == ENOENT ?
+ -ERR_RUN_COMMAND_EXEC :
+ -ERR_RUN_COMMAND_FORK;
+#endif
}
if (need_in)
@@ -236,9 +244,14 @@ static int wait_or_whine(pid_t pid)
if (!WIFEXITED(status))
return -ERR_RUN_COMMAND_WAITPID_NOEXIT;
code = WEXITSTATUS(status);
- if (code)
+ switch (code) {
+ case 127:
+ return -ERR_RUN_COMMAND_EXEC;
+ case 0:
+ return 0;
+ default:
return -code;
- return 0;
+ }
}
}
--
1.6.1.1.367.g30b36
^ permalink raw reply related
* [RFC/PATCH 1/3] git: s/run_command/run_builtin/
From: Jeff King @ 2009-01-27 6:26 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Johannes Sixt, git
In-Reply-To: <20090127062512.GA10487@coredump.intra.peff.net>
There is a static function called run_command which
conflicts with the library function in run-command.c; this
isn't a problem currently, but prevents including
run-command.h in git.c.
This patch just renames the static function to something
more specific and non-conflicting.
Signed-off-by: Jeff King <peff@peff.net>
---
git.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/git.c b/git.c
index ecc8fad..45e493d 100644
--- a/git.c
+++ b/git.c
@@ -219,7 +219,7 @@ struct cmd_struct {
int option;
};
-static int run_command(struct cmd_struct *p, int argc, const char **argv)
+static int run_builtin(struct cmd_struct *p, int argc, const char **argv)
{
int status;
struct stat st;
@@ -384,7 +384,7 @@ static void handle_internal_command(int argc, const char **argv)
struct cmd_struct *p = commands+i;
if (strcmp(p->cmd, cmd))
continue;
- exit(run_command(p, argc, argv));
+ exit(run_builtin(p, argc, argv));
}
}
--
1.6.1.1.367.g30b36
^ permalink raw reply related
* [RFC/PATCH 0/3] fix "Funny: git -p submodule summary"
From: Jeff King @ 2009-01-27 6:25 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Johannes Sixt, git
In-Reply-To: <alpine.DEB.1.00.0901081601240.30769@pacific.mpi-cbg.de>
On Thu, Jan 08, 2009 at 04:07:08PM +0100, Johannes Schindelin wrote:
> Just try this with a submodule that has more changes than fit on a screen:
>
> $ git -p submodule summary
>
> In my tests, it consistently fscks up my console. I wonder if this is
> related to ea27a18(spawn pager via run_command interface).
OK, here is a patch series that fixes the problem:
1/3: git: s/run_command/run_builtin/
2/3: run_command: handle missing command errors more gracefully
3/3: git: use run_command to execute dashed externals
1 is a cleanup, 2 is infrastructure support, and 3 is the actual fix.
There are two potential downsides to the fix:
1. There is an extra fork and a parent process sitting in memory for
dashed externals. This is pretty necessary to any fix, since
something has to wait to do pager cleanup, and we can't rely on the
child to do so.
2. A failed attempt to execute a dashed external results in an extra
fork. For builtins, this has no impact, since they take precedence.
For aliases, though, it means we will do an extra fork before
realizing that there is no dashed external and trying the alias.
We can fix '2' by actually doing the PATH lookup ourselves, and only
calling run_command if we know we have a match. We can also reduce the
impact of both by only doing this multi-process magic if we have spawned
a pager; then only a small subset of invocations needs to pay for it.
I chose not to do the second optimization because it makes the code more
complex and inconsistent (we now have two different ways of doing the
same thing, depending on a seemingly unrelated setting) and fragile
(the pager might not be the only atexit handler installed).
The first (doing PATH lookup ourselves) might make sense, though.
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.
-Peff
^ permalink raw reply
* Re: [PATCH 08/10] run test suite without dashed git-commands in PATH
From: Matthew Ogilvie @ 2009-01-27 6:13 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0901261201470.14855@racer>
On Mon, Jan 26, 2009 at 12:06:08PM +0100, Johannes Schindelin wrote:
> So maybe I was wrong to assume that this is cvsserver specific, but then,
> you made that mistake rather easy to make.
Yes, in retrospect I probably should have split off patches 6, 7,
8, and maybe 5 (5-7 fix issues that patch 8 exposes in the test suite)
into a separate patch series. When or if a v2 is needed, should
I split them off then?
> > 4. The test-bin-wrapper.sh script does not actually need to set
> > environment variables (GIT_EXEC_DIT and templates) for purposes
> > of this patch. But my thought was that in this form you could
> > run things straight out of the test-bin directory to manually try
> > out new code without needing to actually install a build or mess
> > with the environment variables yourself. It could also be
> > extended to handle other global wrapper needs relatively easily,
> > such as valgrind.
>
> Umm.
>
> You missed the valgrind patch series.
Actually, I'm (poorly) alluding to some comments in the original patch
8 email, where I pointed out an expected conflict with the valgrind
patches. To briefly recap, there are at least 3 possible strategies
of resolving such a conflict, and I'm not sure which makes the most
sense: Keep valgrind design, and extend it with limited bindir
support. Keep limited bindir design and extend it with valgrind
support. Or keep both, and have the runtime setup logic make
them mutually exclusive.
--
Matthew Ogilvie [mmogilvi_git@miniinfo.net]
^ permalink raw reply
* Re: [topgit] shared topic branch
From: martin f krafft @ 2009-01-26 12:00 UTC (permalink / raw)
To: Fabien Thomas, git
In-Reply-To: <EFB70468-7900-4B22-925D-3FC5F05F951B@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1057 bytes --]
also sprach Fabien Thomas <thomas.fabien@gmail.com> [2008.12.18.2102 +0100]:
> I'm testing topgit 0.5 in a shared env. (multiple user working on same
> patch).
Sorry for the late reply!
> My problem is that when i want to push my local work i'm doing
> "git push" that will force update the remote branch. The problem
> is that each time master is not up to date i will push my entire
> master or topic branch to the remote.
I do not understand what you mean. Could yo please try to give us
more detail? git push is intended to push all local changes to the
remote, so I don't understand what your problem is.
> [remote "origin"]
[...]
> push = +refs/top-bases/*:refs/top-bases/*
> push = +refs/heads/*:refs/heads/*
Those two lines ensure that git pushes all local heads as well as
all top-bases.
--
martin | http://madduck.net/ | http://two.sentenc.es/
it may look like i'm just sitting here doing nothing.
but i'm really actively waiting
for all my problems to go away.
spamtraps: madduck.bogus@madduck.net
[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: how to see full file with diff marks
From: David Aguilar @ 2009-01-27 5:42 UTC (permalink / raw)
To: Ittay Dror; +Cc: Git Mailing List
In-Reply-To: <497E92C1.80102@gmail.com>
On 0, Ittay Dror <ittay.dror@gmail.com> wrote:
> Hi,
>
> I have a large file and I want to view the changes between two commits,
> but in the context of the whole file, not just hunks. How can I do that?
>
> Thanks
> Ittay
In git.git's contrib/difftool directory there's a script
called 'git-difftool' that can show you changes using our
good friends xxdiff, kdiff3, tkdiff, meld, vimdiff, emerge,
etc.
--
David
^ permalink raw reply
* Re: [PATCH] http-push: refactor request url creation
From: Junio C Hamano @ 2009-01-27 4:58 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Ray Chuan, git
In-Reply-To: <alpine.DEB.1.00.0901261141070.14855@racer>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> curl strdup's it, so this is safe.
>
> I might have mentioned that things like this _need_ to go into the commit
> message.
Yeah, and let's not forget advice from Daniel Stenberg.
I'm not sure what the oldest possibly libcurl version git can deal
with, but here's a related quote from the curl_easy_setopt man page:
NOTE: before 7.17.0 strings were not copied. Instead the user was
forced keep them available until libcurl no longer needed them.
^ permalink raw reply
* Re: how to see full file with diff marks
From: Jeff King @ 2009-01-27 4:57 UTC (permalink / raw)
To: Ittay Dror; +Cc: Git Mailing List
In-Reply-To: <497E92C1.80102@gmail.com>
On Tue, Jan 27, 2009 at 06:51:13AM +0200, Ittay Dror wrote:
> I have a large file and I want to view the changes between two commits,
> but in the context of the whole file, not just hunks. How can I do that?
git diff -U9999999 ?
-Peff
^ permalink raw reply
* Re: [PATCH v1 0/3] Introduce config variable "diff.primer"
From: Jeff King @ 2009-01-27 4:54 UTC (permalink / raw)
To: Keith Cascio; +Cc: git
In-Reply-To: <alpine.GSO.2.00.0901261734360.16158@kiwi.cs.ucla.edu>
On Mon, Jan 26, 2009 at 05:47:54PM -0800, Keith Cascio wrote:
> > 2. It is unset. The rationale is that you are using the "c" diff
> > driver, and it has left the value unset. The default then means "if
> > you have no diff driver setup".
>
> I'm in favor of option (2), because [diff] a.k.a [diff ""] serving as
Nit: [diff] and [diff ""] are different. The "dotted" notation which we
use in the code and which git-config respects for a variable "foo" in
each section would look like "diff.foo" and "diff..foo", respectively.
> the fallback for [diff *] feels like a special case. If a full system
> of precedence
Yes, I think having a "this is the default driver whose driver-specific
options are used if you don't have a different driver" is semantically
simple and clear.
> and fallbacks is desired for .git/config, we should adopt explicit
> grammar that lets me define an arbitrary precedence tree over all
> sections. Once a powerful concept is born, somewhere down the road,
> some user will desire its universalization.
OK, now you're scaring me. :) I'm not sure I want to see the grammar you
would use to define an arbitrary precedence tree, or whether such
complexity has any real-world use in git config. I think you would have
to show a concrete example to prove the utility of something like that.
-Peff
^ permalink raw reply
* how to see full file with diff marks
From: Ittay Dror @ 2009-01-27 4:51 UTC (permalink / raw)
To: Git Mailing List
Hi,
I have a large file and I want to view the changes between two commits,
but in the context of the whole file, not just hunks. How can I do that?
Thanks
Ittay
^ permalink raw reply
* Re: Valgrind updates
From: Jeff King @ 2009-01-27 4:48 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Johannes Schindelin, Junio C Hamano, git
In-Reply-To: <alpine.LFD.2.00.0901261934450.3123@localhost.localdomain>
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).
-Peff
^ permalink raw reply
* Re: Valgrind updates
From: Johannes Schindelin @ 2009-01-27 4:46 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Jeff King, Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0901270512171.14855@racer>
Hi,
On Tue, 27 Jan 2009, Johannes Schindelin wrote:
> On Mon, 26 Jan 2009, Linus Torvalds wrote:
>
> > On Tue, 27 Jan 2009, Johannes Schindelin wrote:
> > >
> > > Just that much, most of the backtraces are pretty repetitive. In
> > > fact, I think most if not all of them touch xwrite.c (I got other
> > > errors from my patches, as I expected).
> > >
> > > ==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.
>
> And it gets worse.
>
> 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.
>
> Yet, the buffer in question is 195 bytes, stream.total_count (which
> totally agrees with size - stream.avail_out) says it is 58 bytes, and
> valgrind says that the byte with offset 51 is uninitialized.
>
> So it is definitely a zlib error. And a strange one at that. Even
> allowing for a header, if we have 51 valid bytes in the buffer
> (remember: the 52nd byte is reported uninitialized by valgrind), even on
> a 64-bit machine, it should not be rounded up to 58 bytes reported by
> zlib. And the address of the buffer seems to be even 16-byte aligned
> (that's probably valgrind's doing).
>
> Just for bullocks, I let valgrind check if offset 51 is the only
> uninitialized byte (who knows what zlib is thinking that it's doing?),
> and here's the rub: offset 51 is indeed the _only_ one which valgrind
> thinks is uninitialized!
>
> Wasn't there some zlib wizard in the kernel community? We could throw
> that thing at him, to see why it behaves so strangely...
>
> Of course, it could also be a valgrind issue, as you suggested. Hmpf.
FWIW this test was done with 3.4.0.SVN.
Just to be sure, I upgraded to 3.5.0.SVN, the very newest update (well, as
new as I could make my git svn mirror of valgrind and VEX deliver). Still
there.
Off to bed,
Dscho
^ permalink raw reply
* Re: Valgrind updates
From: Johannes Schindelin @ 2009-01-27 4:26 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Jeff King, Junio C Hamano, git
In-Reply-To: <alpine.LFD.2.00.0901261934450.3123@localhost.localdomain>
Hi,
On Mon, 26 Jan 2009, Linus Torvalds wrote:
> On Tue, 27 Jan 2009, Johannes Schindelin wrote:
> >
> > Just that much, most of the backtraces are pretty repetitive. In
> > fact, I think most if not all of them touch xwrite.c (I got other
> > errors from my patches, as I expected).
> >
> > ==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.
And it gets worse.
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.
Yet, the buffer in question is 195 bytes, stream.total_count (which
totally agrees with size - stream.avail_out) says it is 58 bytes, and
valgrind says that the byte with offset 51 is uninitialized.
So it is definitely a zlib error. And a strange one at that. Even
allowing for a header, if we have 51 valid bytes in the buffer (remember:
the 52nd byte is reported uninitialized by valgrind), even on a 64-bit
machine, it should not be rounded up to 58 bytes reported by zlib. And
the address of the buffer seems to be even 16-byte aligned (that's
probably valgrind's doing).
Just for bullocks, I let valgrind check if offset 51 is the only
uninitialized byte (who knows what zlib is thinking that it's doing?), and
here's the rub: offset 51 is indeed the _only_ one which valgrind thinks
is uninitialized!
Wasn't there some zlib wizard in the kernel community? We could throw
that thing at him, to see why it behaves so strangely...
Of course, it could also be a valgrind issue, as you suggested. Hmpf.
Ciao,
Dscho
^ permalink raw reply
* connecting existing local git repository to svn
From: Ittay Dror @ 2009-01-27 4:10 UTC (permalink / raw)
To: git
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?
Thanks,
Ittay
^ permalink raw reply
* Re: git 1.6.1 on AIX 5.3
From: Jeff King @ 2009-01-27 3:52 UTC (permalink / raw)
To: Perry Smith; +Cc: Mike Ralphson, git
In-Reply-To: <9E98493A-B17A-4905-8BEA-3E0B837961D6@gmail.com>
On Mon, Jan 26, 2009 at 04:57:16PM -0600, Perry Smith wrote:
> 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.
Hmm. It looks like we respect --with[out]-tcltk, and without it we
always say "just use wish from the PATH" without detecting whether it
actually exists:
# No Tcl/Tk switches given. Do not check for Tcl/Tk, use bare
# 'wish'.
TCLTK_PATH=wish
AC_SUBST(TCLTK_PATH)
I'm sure the fix would be something along the lines of
if which wish; then
TCLTK_PATH=wish
else
NO_TCLTK=yes
fi
but I know for fact that is not portable and that there must be some
special autoconf way of doing the same thing.
> I can't tell if make test is happy or not. The output looks like its
> happy but the exit code is 2.
That doesn't sound very happy. You should see either a "command failed"
error from make, or some results like:
'/bin/sh' ./aggregate-results.sh test-results/t*-*
fixed 1
success 4026
failed 0
broken 3
total 4030
where "broken" is OK (it is a test that is marked as "we know this is
broken currently, but ideally it would be fixed in the future") but
"failed" is a problem.
But I believe unless you are using "make -k", that it won't even
aggregate the results if something fails, and you should just see make
complaining about the failed test script.
-Peff
^ permalink raw reply
* Re: Valgrind updates
From: Linus Torvalds @ 2009-01-27 3:38 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jeff King, Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0901270327200.26199@intel-tinevez-2-302>
On Tue, 27 Jan 2009, Johannes Schindelin wrote:
>
> Just that much, most of the backtraces are pretty repetitive. In fact, I
> think most if not all of them touch xwrite.c (I got other errors from my
> patches, as I expected).
>
> ==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.
Linus
^ 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