* Re: [PATCH v3 2/3] valgrind: ignore ldso and more libz errors
From: Jeff King @ 2009-01-26 0:14 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0901260101030.14855@racer>
On Mon, Jan 26, 2009 at 01:02:24AM +0100, Johannes Schindelin wrote:
> > Your 0/3 cover letter lists this me as the author of this patch, but
> > there is no "From:" line at the top of this email. I don't particularly
> > care one way or the other for this patch, but I wanted to point it out
> > as a potential issue with your patch-sending workflow.
>
> Yep, sorry. I would not touch send-email with lead-protected gloves, so
> what I do is to edit all patches I send. And in this case, I missed the
> fact that there was another "From:". I am sorry.
Heh. I certainly can't blame you for that; I don't use send-email
myself.
It might be convenient for format-patch to have a mode where it uses the
committer as the rfc822 "From:" and then adds a "From:" for the author
in the body if it is not the same as the committer.
It certainly shouldn't be the default, since that would confuse things
like rebase. But it makes sense if you are just going to throw away the
From header anyway when you import into your MUA.
-Peff
^ permalink raw reply
* Re: [PATCH 2/2] rebase -i --root: fix check for number of arguments
From: Thomas Rast @ 2009-01-26 0:07 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, gitster
In-Reply-To: <alpine.DEB.1.00.0901260032000.14855@racer>
[-- Attachment #1: Type: text/plain, Size: 1009 bytes --]
Johannes Schindelin wrote:
>
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> ---
> git-rebase--interactive.sh | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
> index 6e2bf25..5df35b2 100755
> --- a/git-rebase--interactive.sh
> +++ b/git-rebase--interactive.sh
> @@ -571,7 +571,8 @@ first and then run 'git rebase --continue' again."
> ;;
> --)
> shift
> - test ! -z "$REBASE_ROOT" -o $# -eq 1 -o $# -eq 2 || usage
> + test -z "$REBASE_ROOT" -a $# -ge 1 -a $# -le 2 ||
> + test ! -z "$REBASE_ROOT" -a $# -le 1 || usage
> test -d "$DOTEST" &&
> die "Interactive rebase already started"
Acked-by: Thomas Rast <trast@student.ethz.ch>
I'll postpone 1/2 till I've had enough sleep to check whether
--continue ever needed to know about --root, and either remove or fix
the remembering. (Sorry for the noise.)
--
Thomas Rast
trast@{inf,student}.ethz.ch
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH v3 2/3] valgrind: ignore ldso and more libz errors
From: Johannes Schindelin @ 2009-01-26 0:02 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20090125233243.GD19099@coredump.intra.peff.net>
Hi,
On Sun, 25 Jan 2009, Jeff King wrote:
> On Mon, Jan 26, 2009 at 12:19:12AM +0100, Johannes Schindelin wrote:
>
> > On some Linux systems, we get a host of Cond and Addr errors from
> > calls to dlopen that are caused by nss modules. We should be able to
> > safely ignore anything happening in ld-*.so as "not our problem."
> >
> > [Johannes: I added some more...]
> >
> > Signed-off-by: Jeff King <peff@peff.net>
> > Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
>
> Your 0/3 cover letter lists this me as the author of this patch, but
> there is no "From:" line at the top of this email. I don't particularly
> care one way or the other for this patch, but I wanted to point it out
> as a potential issue with your patch-sending workflow.
Yep, sorry. I would not touch send-email with lead-protected gloves, so
what I do is to edit all patches I send. And in this case, I missed the
fact that there was another "From:". I am sorry.
Ciao,
Dscho "who is burning midnight oil again"
^ permalink raw reply
* Re: [PATCH 1/2] rebase -i --root: simplify code
From: Thomas Rast @ 2009-01-25 23:53 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, gitster
In-Reply-To: <200901260049.25563.trast@student.ethz.ch>
[-- Attachment #1: Type: text/plain, Size: 378 bytes --]
Thomas Rast wrote:
> test ! -s "$DOTEST"/upstream && REBASE_ROOT=t
Actually, I think that test never worked (and it's clearly my fault).
The corresponding 'echo $UPSTREAM > "$DOTEST"/upstream' just expanded
to 'echo > ...', resulting in a file containing a single newline, but
never a zero-length file. Duh.
--
Thomas Rast
trast@{inf,student}.ethz.ch
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] rebase -i --root: simplify code
From: Thomas Rast @ 2009-01-25 23:49 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, gitster
In-Reply-To: <alpine.DEB.1.00.0901260031460.14855@racer>
[-- Attachment #1: Type: text/plain, Size: 466 bytes --]
Johannes Schindelin wrote:
>
> When we rebase with --root, what we are actually picking are the commits
> in $ONTO..$HEAD. So $ONTO is really our $UPSTREAM. Spell it out.
[...]
> + UPSTREAM=$ONTO
While I think the simplification is reasonable, it breaks this check:
get_saved_options () {
# ...
test ! -s "$DOTEST"/upstream && REBASE_ROOT=t
}
So you'll have to change that too.
--
Thomas Rast
trast@{inf,student}.ethz.ch
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [PATCH 1/3] Documentation: simplify refspec format description
From: Anders Melchiorsen @ 2009-01-25 23:45 UTC (permalink / raw)
To: gitster; +Cc: git, Anders Melchiorsen
In-Reply-To: <1232927133-30377-1-git-send-email-mail@cup.kalibalik.dk>
The refspec format description was a mix of regexp and BNF, making it
very difficult to read. The format was also wrong: it did not show
that each part of a refspec is optional in different situations.
Rather than having a confusing grammar, just present the format in
informal prose.
Signed-off-by: Anders Melchiorsen <mail@cup.kalibalik.dk>
---
This is a rework of
http://article.gmane.org/gmane.comp.version-control.git/99552/
Documentation/git-push.txt | 8 ++++----
Documentation/pull-fetch-param.txt | 8 ++++----
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index 7b27dc6..3fd4bbb 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -33,10 +33,10 @@ OPTIONS
of a remote (see the section <<REMOTES,REMOTES>> below).
<refspec>...::
- The canonical format of a <refspec> parameter is
- `+?<src>:<dst>`; that is, an optional plus `{plus}`, followed
- by the source ref, followed by a colon `:`, followed by
- the destination ref.
+ The format of a <refspec> parameter is an optional plus
+ `{plus}`, followed by the source ref <src>, followed
+ by a colon `:`, followed by the destination ref <dst>.
+ Find various forms of refspecs in examples section.
+
The <src> side represents the source branch (or arbitrary
"SHA1 expression", such as `master~4` (four parents before the
diff --git a/Documentation/pull-fetch-param.txt b/Documentation/pull-fetch-param.txt
index ebdd948..820c140 100644
--- a/Documentation/pull-fetch-param.txt
+++ b/Documentation/pull-fetch-param.txt
@@ -5,10 +5,10 @@
of a remote (see the section <<REMOTES,REMOTES>> below).
<refspec>::
- The canonical format of a <refspec> parameter is
- `+?<src>:<dst>`; that is, an optional plus `{plus}`, followed
- by the source ref, followed by a colon `:`, followed by
- the destination ref.
+ The format of a <refspec> parameter is an optional plus
+ `{plus}`, followed by the source ref <src>, followed
+ by a colon `:`, followed by the destination ref <dst>.
+ Find various forms of refspecs in examples section.
+
The remote ref that matches <src>
is fetched, and if <dst> is not empty string, the local
--
1.6.0.2.514.g23abd3
^ permalink raw reply related
* [PATCH 3/3] Documentation: rework src/dst description in git push
From: Anders Melchiorsen @ 2009-01-25 23:45 UTC (permalink / raw)
To: gitster; +Cc: git, Anders Melchiorsen
In-Reply-To: <1232927133-30377-3-git-send-email-mail@cup.kalibalik.dk>
This tries to make the description of ref matching in git push easier
to read. Beauty is in the eye of the beholder, though.
Signed-off-by: Anders Melchiorsen <mail@cup.kalibalik.dk>
---
This is a followup to
http://article.gmane.org/gmane.comp.version-control.git/99553/
Documentation/git-push.txt | 23 ++++++++++++-----------
1 files changed, 12 insertions(+), 11 deletions(-)
diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index 6d478c5..1b3de4f 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -38,20 +38,21 @@ OPTIONS
by a colon `:`, followed by the destination ref <dst>.
Find various forms of refspecs in examples section.
+
-The <src> side represents the source branch (or arbitrary
-"SHA1 expression", such as `master~4` (four parents before the
-tip of `master` branch); see linkgit:git-rev-parse[1]) that you
-want to push. The <dst> side represents the destination location.
+The <src> is often the name of the branch you would want to push, but
+it can be any arbitrary "SHA-1 expression", such as `master~4` or
+`HEAD` (see linkgit:git-rev-parse[1]).
+
-The local ref that matches <src> is used
-to fast forward the remote ref that matches <dst>. If
-the optional leading plus `+` is used, the remote ref is updated
-even if it does not result in a fast forward update.
+The <dst> tells which ref on the remote side is updated with this
+push. Arbitrary expressions cannot be used here, an actual ref must
+be named. If `:`<dst> is omitted, the same ref as <src> will be
+updated.
+
-`tag <tag>` means the same as `refs/tags/<tag>:refs/tags/<tag>`.
+The object referenced by <src> is used to fast forward the ref <dst>
+on the remote side. If the optional leading plus `{plus}` is used, the
+remote ref is updated even if it does not result in a fast forward
+update.
+
-A lonely <src> parameter (without a colon and a destination) pushes
-the <src> to the same name in the destination repository.
+`tag <tag>` means the same as `refs/tags/<tag>:refs/tags/<tag>`.
+
Pushing an empty <src> allows you to delete the <dst> ref from
the remote repository.
--
1.6.0.2.514.g23abd3
^ permalink raw reply related
* [PATCH 2/3] Documentation: more git push examples
From: Anders Melchiorsen @ 2009-01-25 23:45 UTC (permalink / raw)
To: gitster; +Cc: git, Anders Melchiorsen
In-Reply-To: <1232927133-30377-2-git-send-email-mail@cup.kalibalik.dk>
Include examples of using HEAD. The order of examples
introduces new concepts one by one. This pushes the
example of deleting a ref to the end of the list.
---
Documentation/git-push.txt | 16 +++++++++++++---
1 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index 3fd4bbb..6d478c5 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -190,9 +190,9 @@ git push origin master::
with it. If `master` did not exist remotely, it would be
created.
-git push origin :experimental::
- Find a ref that matches `experimental` in the `origin` repository
- (e.g. `refs/heads/experimental`), and delete it.
+git push origin HEAD::
+ A handy way to push the current branch to the same name on the
+ remote.
git push origin master:satellite/master dev:satellite/dev::
Use the source ref that matches `master` (e.g. `refs/heads/master`)
@@ -200,6 +200,11 @@ git push origin master:satellite/master dev:satellite/dev::
`refs/remotes/satellite/master`) in the `origin` repository, then
do the same for `dev` and `satellite/dev`.
+git push origin HEAD:master::
+ Push the current branch to the remote ref matching `master` in the
+ `origin` repository. This form is convenient to push the current
+ branch without thinking about its local name.
+
git push origin master:refs/heads/experimental::
Create the branch `experimental` in the `origin` repository
by copying the current `master` branch. This form is only
@@ -207,6 +212,11 @@ git push origin master:refs/heads/experimental::
the local name and the remote name are different; otherwise,
the ref name on its own will work.
+git push origin :experimental::
+ Find a ref that matches `experimental` in the `origin` repository
+ (e.g. `refs/heads/experimental`), and delete it.
+
+
Author
------
Written by Junio C Hamano <gitster@pobox.com>, later rewritten in C
--
1.6.0.2.514.g23abd3
^ permalink raw reply related
* [PATCH 0/3] Documentation: refine refspec description
From: Anders Melchiorsen @ 2009-01-25 23:45 UTC (permalink / raw)
To: gitster; +Cc: git, Anders Melchiorsen
These are the remaining parts of my git-push refspec updates.
I recall having a hard time making sense of the existing
documentation, due to a lot of small questions that popped up.
With these patches, I try to reword things to make them clearer.
It is, however, getting to the point where I have looked at this so
much that I can no longer tell whether I am actually improving things.
Thus, this will be my last submission for this particular itch.
Cheers,
Anders.
^ permalink raw reply
* Re: [PATCH 3/3] Valgrind support: check for more than just programming errors
From: Jeff King @ 2009-01-25 23:42 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0901260019160.14855@racer>
On Mon, Jan 26, 2009 at 12:20:21AM +0100, Johannes Schindelin wrote:
> While it is not strictly necessary to look through the whole PATH to
> find git binaries to override, it is in line with running an expensive
> test (which valgrind is) to make extra sure that no binary is tested
> that actually comes from the git.git checkout.
Should this be "...no binary is tested that _doesn't_ actually come from
the git.git checkout"?
-Peff
^ permalink raw reply
* Re: [PATCH v3 1/3] Add valgrind support in test scripts
From: Jeff King @ 2009-01-25 23:42 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0901260034520.14855@racer>
On Mon, Jan 26, 2009 at 12:35:31AM +0100, Johannes Schindelin wrote:
> > I actually kind of liked the original atomic version over the one with
> > locking. But I find this one acceptable.
>
> The locking is only in there because of you...
I know it came out of our discussion, but I thought it was going a bit
far. That is, what should ideally be a little chunk of code to make some
links keeps getting more and more complex. And as your locking patch
came after my "OK, I guess this is fine" comments, I thought you
realized I was accepting it as-is.
So sorry to make you to go to extra work (and please don't go to extra
work ripping it out on my account -- I just wanted to make clear that I
decided your analysis was sane, and that I am OK with any of the
iterations you posted).
-Peff
^ permalink raw reply
* Re: [PATCH v3 1/3] Add valgrind support in test scripts
From: Johannes Schindelin @ 2009-01-25 23:35 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20090125232954.GC19099@coredump.intra.peff.net>
Hi,
On Sun, 25 Jan 2009, Jeff King wrote:
> On Mon, Jan 26, 2009 at 12:18:50AM +0100, Johannes Schindelin wrote:
>
> > Note: it is safe to run the valgrind tests in parallel, as the links
> > in t/valgrind/bin/ are created using proper locking.
>
> I actually kind of liked the original atomic version over the one with
> locking. But I find this one acceptable.
The locking is only in there because of you...
> > Initial patch and all the hard work by Jeff King.
> >
> > Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
>
> I don't know that there is much of my work left in here, but feel free
> to add:
>
> Signed-off-by: Jeff King <peff@peff.net>
Will do!
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH v3 2/3] valgrind: ignore ldso and more libz errors
From: Jeff King @ 2009-01-25 23:32 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0901260019000.14855@racer>
On Mon, Jan 26, 2009 at 12:19:12AM +0100, Johannes Schindelin wrote:
>
> On some Linux systems, we get a host of Cond and Addr errors
> from calls to dlopen that are caused by nss modules. We
> should be able to safely ignore anything happening in
> ld-*.so as "not our problem."
>
> [Johannes: I added some more...]
>
> Signed-off-by: Jeff King <peff@peff.net>
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Your 0/3 cover letter lists this me as the author of this patch, but
there is no "From:" line at the top of this email. I don't particularly
care one way or the other for this patch, but I wanted to point it out
as a potential issue with your patch-sending workflow.
-Peff
^ permalink raw reply
* [PATCH 2/2] rebase -i --root: fix check for number of arguments
From: Johannes Schindelin @ 2009-01-25 23:32 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, gitster
In-Reply-To: <alpine.DEB.1.00.0901260029480.14855@racer>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
git-rebase--interactive.sh | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index 6e2bf25..5df35b2 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -571,7 +571,8 @@ first and then run 'git rebase --continue' again."
;;
--)
shift
- test ! -z "$REBASE_ROOT" -o $# -eq 1 -o $# -eq 2 || usage
+ test -z "$REBASE_ROOT" -a $# -ge 1 -a $# -le 2 ||
+ test ! -z "$REBASE_ROOT" -a $# -le 1 || usage
test -d "$DOTEST" &&
die "Interactive rebase already started"
--
1.6.1.482.g7d54be
^ permalink raw reply related
* [PATCH 1/2] rebase -i --root: simplify code
From: Johannes Schindelin @ 2009-01-25 23:31 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, gitster
In-Reply-To: <alpine.DEB.1.00.0901260029480.14855@racer>
When we rebase with --root, what we are actually picking are the commits
in $ONTO..$HEAD. So $ONTO is really our $UPSTREAM. Spell it out.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
git-rebase--interactive.sh | 17 ++++++-----------
1 files changed, 6 insertions(+), 11 deletions(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index 21ac20c..6e2bf25 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -581,13 +581,15 @@ first and then run 'git rebase --continue' again."
if test -z "$REBASE_ROOT"
then
UPSTREAM_ARG="$1"
- UPSTREAM=$(git rev-parse --verify "$1") || die "Invalid base"
+ UPSTREAM=$(git rev-parse --verify "$1") ||
+ die "Invalid base"
test -z "$ONTO" && ONTO=$UPSTREAM
shift
else
UPSTREAM_ARG=--root
test -z "$ONTO" &&
die "You must specify --onto when using --root"
+ UPSTREAM=$ONTO
fi
run_pre_rebase_hook "$UPSTREAM_ARG" "$@"
@@ -648,16 +650,9 @@ first and then run 'git rebase --continue' again."
SHORTHEAD=$(git rev-parse --short $HEAD)
SHORTONTO=$(git rev-parse --short $ONTO)
- if test -z "$REBASE_ROOT"
- # this is now equivalent to ! -z "$UPSTREAM"
- then
- SHORTUPSTREAM=$(git rev-parse --short $UPSTREAM)
- REVISIONS=$UPSTREAM...$HEAD
- SHORTREVISIONS=$SHORTUPSTREAM..$SHORTHEAD
- else
- REVISIONS=$ONTO...$HEAD
- SHORTREVISIONS=$SHORTHEAD
- fi
+ SHORTUPSTREAM=$(git rev-parse --short $UPSTREAM)
+ REVISIONS=$UPSTREAM...$HEAD
+ SHORTREVISIONS=$SHORTUPSTREAM..$SHORTHEAD
git rev-list $MERGES_OPTION --pretty=oneline --abbrev-commit \
--abbrev=7 --reverse --left-right --topo-order \
$REVISIONS | \
--
1.6.1.482.g7d54be
^ permalink raw reply related
* [PATCH 0/2] rebase -i --root cleanups
From: Johannes Schindelin @ 2009-01-25 23:31 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, gitster
This is just the first part of my rebase revamp; it would be good to
get the trivial stuff out of the way early, so that I do not have to
send a large patch series nobody wants to read because of its size.
Thomas, these two patches happen to touch your --root realm, maybe you
have comments.
Johannes Schindelin (2):
rebase -i --root: simplify code
rebase -i --root: fix check for number of arguments
git-rebase--interactive.sh | 20 ++++++++------------
1 files changed, 8 insertions(+), 12 deletions(-)
^ permalink raw reply
* Re: [PATCH v3 1/3] Add valgrind support in test scripts
From: Jeff King @ 2009-01-25 23:29 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0901260018340.14855@racer>
On Mon, Jan 26, 2009 at 12:18:50AM +0100, Johannes Schindelin wrote:
> Note: it is safe to run the valgrind tests in parallel, as the links in
> t/valgrind/bin/ are created using proper locking.
I actually kind of liked the original atomic version over the one with
locking. But I find this one acceptable.
> Initial patch and all the hard work by Jeff King.
>
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
I don't know that there is much of my work left in here, but feel free
to add:
Signed-off-by: Jeff King <peff@peff.net>
-Peff
^ permalink raw reply
* Re: Heads up: major rebase -i -p rework coming up
From: Johannes Schindelin @ 2009-01-25 23:29 UTC (permalink / raw)
To: Jakub Narebski, らいしななこ
Cc: Junio C Hamano, Sverre Rabbelier, git
In-Reply-To: <200901252303.29204.jnareb@gmail.com>
Hi,
On Sun, 25 Jan 2009, Jakub Narebski wrote:
> On Sun, 25 Jan 2009, Junio C Hamano wrote:
> > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> >
> > > So maybe I answered my question myself:
> > >
> > > merge parents $sha1 [$sha1...] original $sha1 $msg
> >
> > When you are reparenting, how would original commit get in the
> > picture? You wouldn't want the resulting merge to claim it merged X
> > (which would be what's in original's commit log) when in fact it now
> > merged Y because the user reparented it, would you?
>
> Well, the subject part of merge (with merged branches names) shouldn't,
> I guess, change. The summary (shortlog) part might, or perhaps even
> should following rewrite (if it was present here).
>
> But there is one issue I am wondering about: could we pick up _merge_
> _resolution_? So if you have evil merge, and the change is for example
> splitting commits without visible final changes, or just changing some
> commit message before merge, it would get recreated without problems?
Nanako had a script at some stage; I would prefer an subcommand to "git
rerere" which reconstructs the whole merge in-memory, and then records the
conflict's resolution.
However, I really think you are getting ahead of yourself. That is by no
means something we want to have in rebase -p. And even then, it would
have to be non-automatic, i.e the user has to check the resolution.
We _know_ that git rerere does a fine job most of the time, almost all of
the exceptions to be found when working with rebase -i extensively, as you
are prone to take different decisions during development.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH v1 1/3] Introduce config variable "diff.primer"
From: Jeff King @ 2009-01-25 23:25 UTC (permalink / raw)
To: Keith Cascio; +Cc: git
In-Reply-To: <alpine.GSO.2.00.0901251446260.12651@kiwi.cs.ucla.edu>
On Sun, Jan 25, 2009 at 02:58:34PM -0800, Keith Cascio wrote:
> OK, point taken. I wasn't trying to be idiosyncratic at all. Just
> trying to be explicit and avoid all confusion. Since all diff options
> already have default values, primer looks to me like the layer one
> step above defaults, hence the painting analogy. Mercurial calls it
> "defaults", but that doesn't mean we should necessarily follow in
> their footsteps (see
> http://article.gmane.org/gmane.comp.version-control.git/107103).
>
> I think being as clear as possible about what primer is, that is it
> NOT defaults, helps to feel more comfortable with its consequences,
> i.e. in my opinion, that it will not break things.
I'm not sure I agree that they are not new defaults, but any such
argument is going to get into the exact definition of "default" which is
not really useful to the task at hand.
I think "options" is a better word (as in, pretend like you already
specified these "options" on the command line), but I am not going to
insist on that. I mainly just wanted to point out that I found "primer"
confusing. Enough so that, even though I knew you were interested in
this topic from your previous mails, I saw the word "primer" and said to
myself: "what in the world is this patch about?"
-Peff
^ permalink raw reply
* Re: [PATCH 0/2] Add submodule-support to git archive
From: Johannes Schindelin @ 2009-01-25 23:25 UTC (permalink / raw)
To: Lars Hjemli; +Cc: Junio C Hamano, Nanako Shiraishi, git
In-Reply-To: <8c5c35580901251512q5058dde3rdfae81979c46c36a@mail.gmail.com>
Hi,
On Mon, 26 Jan 2009, Lars Hjemli wrote:
> On Sun, Jan 25, 2009 at 21:35, Junio C Hamano <gitster@pobox.com> wrote:
>
> > Could we switch to incremental refinements once a series hits next,
> > pretty please?
>
> The problem in this particular case is that the design has changed so
> much since the first iteration that we're not really talking about
> incremental refinements but rather a different approach to the same
> problem.
>
> If you want me to build on top of the series in next anyways, would it
> be acceptable if the first patch on top of ee306d2d59 reverts the
> previous attempt? I think the rest of the series will be easier to
> review that way.
I'd appreciate that.
Since 'next' will be rewound eventually, that first iteration and the
revert will disappear at some stage.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 1/2] user-manual: Simplify the user configuration.
From: Jeff King @ 2009-01-25 23:20 UTC (permalink / raw)
To: Wincent Colaiuta
Cc: Felipe Contreras, Junio C Hamano, Johannes Schindelin,
Hannu Koivisto, git
In-Reply-To: <190FD80D-0F10-4C76-9029-1434F362EFDB@wincent.com>
On Sun, Jan 25, 2009 at 11:55:24PM +0100, Wincent Colaiuta wrote:
>> I think there should also be some explanatory text that indicates they
>> are totally interchangeable for the rest of the document. Something
>> like: "When we show configuration in the rest of this document, we will
>> use format X [I think probably "git config $VAR $VALUE"]. But you can
>> use whichever method you are most comfortable with."
>
> I already suggested something similar about 4 days ago:
>
> http://article.gmane.org/gmane.comp.version-control.git/106673/
Oh, I think I must have mixed up reading your post and thinking it was
from Felipe. Sorry.
At any rate, I think what you wrote there is sensible.
-Peff
^ permalink raw reply
* [PATCH 3/3] Valgrind support: check for more than just programming errors
From: Johannes Schindelin @ 2009-01-25 23:20 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0901260014470.14855@racer>
This patch makes --valgrind try to override _all_ Git binaries in the
PATH, and it will make calling *.sh and *.perl scripts directly an
error.
While it is not strictly necessary to look through the whole PATH to
find git binaries to override, it is in line with running an expensive
test (which valgrind is) to make extra sure that no binary is tested
that actually comes from the git.git checkout.
In the same spirit, we can test that neither our test suite nor our
scripts try to run the *.sh or *.perl scripts directly.
It's more like a "because we can" than a "this is tightly connected
to valgrind", but in the author's opinion "because we can" is "so we
should" in this case.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
As I said, I vividly remember chasing a bug which turned out to be
a Git program that was installed, but no longer in git.git, yet
the test suite used it.
This would catch it.
t/test-lib.sh | 42 +++++++++++++++++++++++++++---------------
1 files changed, 27 insertions(+), 15 deletions(-)
diff --git a/t/test-lib.sh b/t/test-lib.sh
index 67d7883..bdfb30f 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -496,23 +496,35 @@ else
# override all git executables in TEST_DIRECTORY/..
GIT_VALGRIND=$TEST_DIRECTORY/valgrind
mkdir -p "$GIT_VALGRIND"/bin
- ls $TEST_DIRECTORY/../git* 2> /dev/null |
- while read symlink_target
+ OLDIFS=$IFS
+ IFS=:
+ for path in $PATH $TEST_DIRECTORY/..
do
- # handle only executables
- test -x "$symlink_target" || continue
-
- base=$(basename "$symlink_target")
- # do not override scripts
- if test ! -d "$symlink_target" &&
- test "#!" != "$(head -c 2 < "$symlink_target")"
- then
- symlink_target=../valgrind.sh
- fi
- # create the link, or replace it if it is out of date
- make_symlink "$symlink_target" \
- "$GIT_VALGRIND/bin/$base" || exit
+ ls "$path"/git "$path"/git-* 2> /dev/null |
+ while read file
+ do
+ # handle only executables
+ test -x "$file" || continue
+
+ base=$(basename "$file")
+ symlink_target=$TEST_DIRECTORY/../$base
+ # do not override scripts
+ if test -x "$symlink_target" &&
+ test ! -d "$symlink_target" &&
+ test "#!" != "$(head -c 2 < "$symlink_target")"
+ then
+ symlink_target=../valgrind.sh
+ fi
+ case "$base" in
+ *.sh|*.perl)
+ symlink_target=../unprocessed-script
+ esac
+ # create the link, or replace it if it is out of date
+ make_symlink "$symlink_target" \
+ "$GIT_VALGRIND/bin/$base" || exit
+ done
done
+ IFS=$OLDIFS
PATH=$GIT_VALGRIND/bin:$PATH
GIT_EXEC_PATH=$GIT_VALGRIND/bin
export GIT_VALGRIND
--
1.6.1.482.g7d54be
^ permalink raw reply related
* [PATCH v3 2/3] valgrind: ignore ldso and more libz errors
From: Johannes Schindelin @ 2009-01-25 23:19 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0901260014470.14855@racer>
On some Linux systems, we get a host of Cond and Addr errors
from calls to dlopen that are caused by nss modules. We
should be able to safely ignore anything happening in
ld-*.so as "not our problem."
[Johannes: I added some more...]
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
t/valgrind/default.supp | 24 ++++++++++++++++++++++++
1 files changed, 24 insertions(+), 0 deletions(-)
diff --git a/t/valgrind/default.supp b/t/valgrind/default.supp
index 2482b3b..b2da4fd 100644
--- a/t/valgrind/default.supp
+++ b/t/valgrind/default.supp
@@ -5,12 +5,36 @@
}
{
+ ignore-zlib-errors-value8
+ Memcheck:Value8
+ obj:*libz.so*
+}
+
+{
ignore-zlib-errors-value4
Memcheck:Value4
obj:*libz.so*
}
{
+ ignore-ldso-cond
+ Memcheck:Cond
+ obj:*ld-*.so
+}
+
+{
+ ignore-ldso-addr8
+ Memcheck:Addr8
+ obj:*ld-*.so
+}
+
+{
+ ignore-ldso-addr4
+ Memcheck:Addr4
+ obj:*ld-*.so
+}
+
+{
writing-data-from-zlib-triggers-errors
Memcheck:Param
write(buf)
--
1.6.1.482.g7d54be
^ permalink raw reply related
* [PATCH v3 1/3] Add valgrind support in test scripts
From: Johannes Schindelin @ 2009-01-25 23:18 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0901260014470.14855@racer>
This patch adds the ability to use valgrind's memcheck tool to
diagnose memory problems in Git while running the test scripts.
It works by creating symlinks to a valgrind script, which have the same
name as our Git binaries, and then putting that directory in front of
the test script's PATH as well as set GIT_EXEC_PATH to that directory.
Git scripts are symlinked from that directory directly. That way, Git
binaries called by Git scripts are valgrinded, too.
Valgrind can be used by specifying "GIT_TEST_OPTS=--valgrind" in the
make invocation. Any invocation of git that finds any errors under
valgrind will exit with failure code 126. Any valgrind output will go
to the usual stderr channel for tests (i.e., /dev/null, unless -v has
been specified).
If you need to pass options to valgrind -- you might want to run
another tool than memcheck, for example -- you can set the environment
variable GIT_VALGRIND_OPTIONS.
A few default suppressions are included, since libz seems to trigger
quite a few false positives. We'll assume that libz works and that we
can ignore any errors which are reported there.
Note: it is safe to run the valgrind tests in parallel, as the links in
t/valgrind/bin/ are created using proper locking.
Initial patch and all the hard work by Jeff King.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
t/README | 8 ++++++-
t/test-lib.sh | 54 +++++++++++++++++++++++++++++++++++++++++++++-
t/valgrind/.gitignore | 1 +
t/valgrind/default.supp | 21 ++++++++++++++++++
t/valgrind/valgrind.sh | 12 ++++++++++
5 files changed, 93 insertions(+), 3 deletions(-)
create mode 100644 t/valgrind/.gitignore
create mode 100644 t/valgrind/default.supp
create mode 100755 t/valgrind/valgrind.sh
diff --git a/t/README b/t/README
index 8f12d48..811bc0d 100644
--- a/t/README
+++ b/t/README
@@ -39,7 +39,8 @@ this:
* passed all 3 test(s)
You can pass --verbose (or -v), --debug (or -d), and --immediate
-(or -i) command line argument to the test.
+(or -i) command line argument to the test, or by setting GIT_TEST_OPTS
+appropriately before running "make".
--verbose::
This makes the test more verbose. Specifically, the
@@ -58,6 +59,11 @@ You can pass --verbose (or -v), --debug (or -d), and --immediate
This causes additional long-running tests to be run (where
available), for more exhaustive testing.
+--valgrind::
+ Execute all Git binaries with valgrind and exit with status
+ 126 on errors (just like regular tests, this will only stop
+ the test script when running under -i). Valgrind errors
+ go to stderr, so you might want to pass the -v option, too.
Skipping Tests
--------------
diff --git a/t/test-lib.sh b/t/test-lib.sh
index 41d5a59..67d7883 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -94,6 +94,8 @@ do
--no-python)
# noop now...
shift ;;
+ --va|--val|--valg|--valgr|--valgri|--valgrin|--valgrind)
+ valgrind=t; shift ;;
*)
break ;;
esac
@@ -467,8 +469,56 @@ test_done () {
# Test the binaries we have just built. The tests are kept in
# t/ subdirectory and are run in 'trash directory' subdirectory.
TEST_DIRECTORY=$(pwd)
-PATH=$TEST_DIRECTORY/..:$PATH
-GIT_EXEC_PATH=$(pwd)/..
+if test -z "$valgrind"
+then
+ PATH=$TEST_DIRECTORY/..:$PATH
+ GIT_EXEC_PATH=$TEST_DIRECTORY/..
+else
+ make_symlink () {
+ test -h "$2" &&
+ test "$1" = "$(readlink "$2")" || {
+ # be super paranoid
+ if mkdir "$2".lock
+ then
+ rm -f "$2" &&
+ ln -s "$1" "$2" &&
+ rm -r "$2".lock
+ else
+ while test -d "$2".lock
+ do
+ say "Waiting for lock on $2."
+ sleep 1
+ done
+ fi
+ }
+ }
+
+ # override all git executables in TEST_DIRECTORY/..
+ GIT_VALGRIND=$TEST_DIRECTORY/valgrind
+ mkdir -p "$GIT_VALGRIND"/bin
+ ls $TEST_DIRECTORY/../git* 2> /dev/null |
+ while read symlink_target
+ do
+ # handle only executables
+ test -x "$symlink_target" || continue
+
+ base=$(basename "$symlink_target")
+ # do not override scripts
+ if test ! -d "$symlink_target" &&
+ test "#!" != "$(head -c 2 < "$symlink_target")"
+ then
+ symlink_target=../valgrind.sh
+ fi
+ # create the link, or replace it if it is out of date
+ make_symlink "$symlink_target" \
+ "$GIT_VALGRIND/bin/$base" || exit
+ done
+ PATH=$GIT_VALGRIND/bin:$PATH
+ GIT_EXEC_PATH=$GIT_VALGRIND/bin
+ export GIT_VALGRIND
+
+ make_symlink ../../templates "$GIT_VALGRIND"/templates || exit
+fi
GIT_TEMPLATE_DIR=$(pwd)/../templates/blt
unset GIT_CONFIG
GIT_CONFIG_NOSYSTEM=1
diff --git a/t/valgrind/.gitignore b/t/valgrind/.gitignore
new file mode 100644
index 0000000..ae3c172
--- /dev/null
+++ b/t/valgrind/.gitignore
@@ -0,0 +1 @@
+/bin/
diff --git a/t/valgrind/default.supp b/t/valgrind/default.supp
new file mode 100644
index 0000000..2482b3b
--- /dev/null
+++ b/t/valgrind/default.supp
@@ -0,0 +1,21 @@
+{
+ ignore-zlib-errors-cond
+ Memcheck:Cond
+ obj:*libz.so*
+}
+
+{
+ ignore-zlib-errors-value4
+ Memcheck:Value4
+ obj:*libz.so*
+}
+
+{
+ writing-data-from-zlib-triggers-errors
+ Memcheck:Param
+ write(buf)
+ obj:/lib/ld-*.so
+ fun:write_in_full
+ fun:write_buffer
+ fun:write_loose_object
+}
diff --git a/t/valgrind/valgrind.sh b/t/valgrind/valgrind.sh
new file mode 100755
index 0000000..24f3a4e
--- /dev/null
+++ b/t/valgrind/valgrind.sh
@@ -0,0 +1,12 @@
+#!/bin/sh
+
+base=$(basename "$0")
+
+exec valgrind -q --error-exitcode=126 \
+ --leak-check=no \
+ --suppressions="$GIT_VALGRIND/default.supp" \
+ --gen-suppressions=all \
+ --log-fd=4 \
+ --input-fd=4 \
+ $GIT_VALGRIND_OPTIONS \
+ "$GIT_VALGRIND"/../../"$base" "$@"
--
1.6.1.482.g7d54be
^ permalink raw reply related
* [PATCH 0/3] Valgrind support
From: Johannes Schindelin @ 2009-01-25 23:18 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0901212332030.3586@pacific.mpi-cbg.de>
I finally decided to give in on both the lock (let's see how many races
we encounter in reality...) and the searching the PATH and handling .sh
and .perl scripts, too. The latter issue is handled by 3/3, which is up
for discussion.
Oh, and BTW, this is vs 'next', and according to my tests, valgrind finds
at least one issue.
Jeff King (1):
valgrind: ignore ldso and more libz errors
Johannes Schindelin (2):
Add valgrind support in test scripts
Valgrind support: check for more than just programming errors
t/README | 8 +++++-
t/test-lib.sh | 66 +++++++++++++++++++++++++++++++++++++++++++++-
t/valgrind/.gitignore | 1 +
t/valgrind/default.supp | 45 ++++++++++++++++++++++++++++++++
t/valgrind/valgrind.sh | 12 ++++++++
5 files changed, 129 insertions(+), 3 deletions(-)
create mode 100644 t/valgrind/.gitignore
create mode 100644 t/valgrind/default.supp
create mode 100755 t/valgrind/valgrind.sh
^ 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