* 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
* 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 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 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
* [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
* [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 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 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
* 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
* 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 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 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: 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: bug: transform a binary file into a symlink in one commit => invalid binary patch
From: Jeff King @ 2009-01-26 0:35 UTC (permalink / raw)
To: Pixel; +Cc: git
In-Reply-To: <lyhc3q9pl1.fsf@leia.mandriva.com>
On Fri, Jan 23, 2009 at 01:25:30PM +0100, Pixel wrote:
> i hit a bug (git 1.6.1): when you transform a binary file into a
> symlink in one commit, the binary patch can't be used in "git apply".
> Is it a known issue?
Not that I know of.
Below is a patch against the test suite that fairly neatly displays the
problem. I didn't get a chance to look into actually fixing it, though
(I'm not even sure the problem is in apply, and not in the generated
patch).
---
diff --git a/t/t4130-apply-symlink-binary.sh b/t/t4130-apply-symlink-binary.sh
new file mode 100755
index 0000000..0ee2ba1
--- /dev/null
+++ b/t/t4130-apply-symlink-binary.sh
@@ -0,0 +1,30 @@
+#!/bin/sh
+
+test_description='apply handles binary to symlink conversion'
+. ./test-lib.sh
+
+test_expect_success 'create commit with binary' '
+ echo content >file && git add file &&
+ printf "\0" > binary && git add binary &&
+ git commit -m one
+'
+
+test_expect_success 'convert binary to symlink' '
+ rm binary &&
+ ln -s file binary &&
+ git add binary &&
+ git commit -m two
+'
+
+test_expect_success 'create patch' '
+ git diff-tree --binary HEAD^ HEAD >patch
+'
+
+test_expect_success 'apply patch' '
+ git reset --hard HEAD^ &&
+ git apply patch &&
+ test -h binary &&
+ test_cmp binary file
+'
+
+test_done
^ permalink raw reply related
* Re: [PATCH 0/2] Add submodule-support to git archive
From: Junio C Hamano @ 2009-01-26 0:41 UTC (permalink / raw)
To: Lars Hjemli; +Cc: Nanako Shiraishi, Johannes Schindelin, git
In-Reply-To: <8c5c35580901251512q5058dde3rdfae81979c46c36a@mail.gmail.com>
Lars Hjemli <hjemli@gmail.com> writes:
> 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.
Ok, then I'll simply revert and then queue the new ones on top of it.
Thanks.
^ permalink raw reply
* Re: [PATCH 3/3] Valgrind support: check for more than just programming errors
From: Johannes Schindelin @ 2009-01-26 0:43 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20090125234249.GE19099@coredump.intra.peff.net>
Hi,
On Sun, 25 Jan 2009, Jeff King wrote:
> 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"?
Yep, that was half the change to "that only binaries are tested...".
Thanks,
Dscho
^ permalink raw reply
* Re: [PATCH 1/2] rebase -i --root: simplify code
From: Johannes Schindelin @ 2009-01-26 0:44 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, gitster
In-Reply-To: <200901260049.25563.trast@student.ethz.ch>
Hi,
On Mon, 26 Jan 2009, Thomas Rast wrote:
> 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.
Will fix tomorrow.
Thanks,
Dscho
^ permalink raw reply
* Re: [PATCH 2/2] rebase -i --root: fix check for number of arguments
From: Johannes Schindelin @ 2009-01-26 0:49 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, gitster
In-Reply-To: <200901260108.07402.trast@student.ethz.ch>
Hi,
On Mon, 26 Jan 2009, Thomas Rast wrote:
> 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.)
It does need to remember, as pick_one wants to look at the parent to be
able to fast-forward.
But the sane fix is to add a file "$DOTEST"/root in case we're running
under --root.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] git-svn: fix memory leak when checking for empty symlinks
From: Eric Wong @ 2009-01-26 1:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
By enforcing SVN::Pool usage when calling get_file once again.
This regression was introduced with the reintroduction of
SVN::Ra::get_file() usage in
dbc6c74d0858d77e61e092a48d467e725211f8e9
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
git-svn.perl | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index d4cb538..5d39b39 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -4021,7 +4021,8 @@ my ($ra_invalid, $can_do_switch, %ignored_err, $RA);
BEGIN {
# enforce temporary pool usage for some simple functions
no strict 'refs';
- for my $f (qw/rev_proplist get_latest_revnum get_uuid get_repos_root/) {
+ for my $f (qw/rev_proplist get_latest_revnum get_uuid get_repos_root
+ get_file/) {
my $SUPER = "SUPER::$f";
*$f = sub {
my $self = shift;
--
Eric Wong
^ permalink raw reply related
* Re: [PATCH] git-svn: add --ignore-paths option for fetching
From: Eric Wong @ 2009-01-26 1:18 UTC (permalink / raw)
To: public_vi; +Cc: Thomas Rast, git
In-Reply-To: <497CEC56.3020900@tut.by>
public_vi <public_vi@tut.by> wrote:
> Eric Wong wrote:
>> Thomas Rast <trast@student.ethz.ch> wrote:
>>
>>
>> Also, indentation is always done with tabs in git-svn (and the vast
>> majority of git as well).
>>
>>
> Whitespace is invisible for me now, I only checked according to
> Documentation/SubmittingPatches about extra lines adds or removes caused
> just by whitespace difference.
>>
>>
>> Vitaly: thank you for the patch. Can you also provide a testcase to
>> ensure this functionality doesn't break during refactorings? Thanks.
>>
>>
> Already done it with testcase. There are two new packs of patches sent
> to git@vger.kernel.org, the first is outdated too, the second is current.
> (I don't yet completely know how things should be done).
Thanks Vitaly, acked and pushed out with minor fixes to
git://git.bogomips.org/git-svn.git
git-svn: Add test for --ignore-paths parameter
[ew: replaced 'echo -e' with printf so it works on POSIX shells]
[ew: added Vitaly to copyright even though it's based on my test]
git-svn: documented --ignore-paths
[ew: trailing whitespace removed]
git-svn: add --ignore-paths option for fetching
[ew: replaced 4-space indent with tabs]
[ew: prefixed $ignore_regex with an underscore to be consistent
with other globals in git-svn]
[ew: rearranged functions to minimize diff and removed prototype
usage to be consistent with the rest of git-svn (and other
Perl code in git (and they're ugly to me)]
--
Eric Wong
^ permalink raw reply
* [ANNOUNCE] GIT 1.6.1.1
From: Junio C Hamano @ 2009-01-26 1:19 UTC (permalink / raw)
To: git; +Cc: linux-kernel
The latest maintenance release GIT 1.6.1.1 is available at the
usual places:
http://www.kernel.org/pub/software/scm/git/
git-1.6.1.1.tar.{gz,bz2} (source tarball)
git-htmldocs-1.6.1.1.tar.{gz,bz2} (preformatted docs)
git-manpages-1.6.1.1.tar.{gz,bz2} (preformatted docs)
The RPM binary packages for a few architectures are also provided
as courtesy.
RPMS/$arch/git-*-1.6.1.1-1.fc9.$arch.rpm (RPM)
----------------------------------------------------------------
GIT v1.6.1.1 Release Notes
==========================
Fixes since v1.6.1
------------------
* "git add frotz/nitfol" when "frotz" is a submodule should have errored
out, but it didn't.
* "git apply" took file modes from the patch text and updated the mode
bits of the target tree even when the patch was not about mode changes.
* "git bisect view" on Cygwin did not launch gitk
* "git checkout $tree" did not trigger an error.
* "git commit" tried to remove COMMIT_EDITMSG from the work tree by mistake.
* "git describe --all" complained when a commit is described with a tag,
which was nonsense.
* "git diff --no-index --" did not trigger no-index (aka "use git-diff as
a replacement of diff on untracked files") behaviour.
* "git format-patch -1 HEAD" on a root commit failed to produce patch
text.
* "git fsck branch" did not work as advertised; instead it behaved the same
way as "git fsck".
* "git log --pretty=format:%s" did not handle a multi-line subject the
same way as built-in log listers (i.e. shortlog, --pretty=oneline, etc.)
* "git daemon", and "git merge-file" are more careful when freopen fails
and barf, instead of going on and writing to unopened filehandle.
* "git http-push" did not like some RFC 4918 compliant DAV server
responses.
* "git merge -s recursive" mistakenly overwritten an untracked file in the
work tree upon delete/modify conflict.
* "git merge -s recursive" didn't leave the index unmerged for entries with
rename/delete conflictd.
* "git merge -s recursive" clobbered untracked files in the work tree.
* "git mv -k" with more than one errorneous paths misbehaved.
* "git read-tree -m -u" hence branch switching incorrectly lost a
subdirectory in rare cases.
* "git rebase -i" issued an unnecessary error message upon a user error of
marking the first commit to be "squash"ed.
* "git shortlog" did not format a commit message with multi-line
subject correctly.
Comes with many documentation updates.
^ permalink raw reply
* [PATCH] gitweb: ensure the default stylesheet is accessible
From: Giuseppe Bilotta @ 2009-01-26 1:28 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Junio C Hamano, Giuseppe Bilotta
On some installations the CSS fails to be linked correctly when
path_info is enabled, since the link refers to "gitweb.css", whereas it
should be "${my_uri}/gitweb.css". Fix by setting the appropriate default
in the Makefile.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
Makefile | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
index 4ef8234..4f60de9 100644
--- a/Makefile
+++ b/Makefile
@@ -215,7 +215,7 @@ GITWEB_STRICT_EXPORT =
GITWEB_BASE_URL =
GITWEB_LIST =
GITWEB_HOMETEXT = indextext.html
-GITWEB_CSS = gitweb.css
+GITWEB_CSS = $${my_uri}/gitweb.css
GITWEB_LOGO = git-logo.png
GITWEB_FAVICON = git-favicon.png
GITWEB_SITE_HEADER =
--
1.5.6.5
^ permalink raw reply related
* Re: [PATCH] gitweb: ensure the default stylesheet is accessible
From: Jakub Narebski @ 2009-01-26 1:48 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git, Junio C Hamano
In-Reply-To: <1232933322-9186-1-git-send-email-giuseppe.bilotta@gmail.com>
On Mon, 26 Jan 2009, Giuseppe Bilotta wrote:
> On some installations the CSS fails to be linked correctly when
> path_info is enabled, since the link refers to "gitweb.css", whereas it
> should be "${my_uri}/gitweb.css". Fix by setting the appropriate default
> in the Makefile.
Why "on some installations"? What does "some" mean? I don't think it
is something indeterministic: please spell when one can have problems
with linking CSS file.
Wouldn't it be simpler to deal with problem of base URL when using
path_info gitweb URLs to add BASE element to HTML head if we use
path_info? Something like:
if ($ENV{'PATH_INFO'}) { # $path_info is unfortunately stripped
print qq(<base href="$my_uri">\n);
}
somewhere in git_header_html() subroutine?
See also comment below.
>
> Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
> ---
> Makefile | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index 4ef8234..4f60de9 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -215,7 +215,7 @@ GITWEB_STRICT_EXPORT =
> GITWEB_BASE_URL =
> GITWEB_LIST =
> GITWEB_HOMETEXT = indextext.html
> -GITWEB_CSS = gitweb.css
> +GITWEB_CSS = $${my_uri}/gitweb.css
> GITWEB_LOGO = git-logo.png
> GITWEB_FAVICON = git-favicon.png
It is not the same case for git-logo.png and git-favicon.png as for
gitweb.css? If it is not, please explain why in commit message.
If it is, then your patch is only partial solution to path_info
problem.
> GITWEB_SITE_HEADER =
> --
> 1.5.6.5
>
>
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] http-push: refactor request url creation
From: Ray Chuan @ 2009-01-26 1:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Schindelin
In-Reply-To: <7vpribdszr.fsf@gitster.siamese.dyndns.org>
Hi,
On Mon, Jan 26, 2009 at 4:35 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> @@ -304,17 +312,7 @@ static void start_fetch_loose(struct
>> transfer_request *request)
>>
>> git_SHA1_Init(&request->c);
>>
>> - url = xmalloc(strlen(remote->url) + 50);
>> ...
>> - strcpy(request->url, url);
>> + request->url = get_remote_object_url(remote->url, hex, 0);
>> ...
>> - curl_easy_setopt(slot->curl, CURLOPT_URL, url);
>> + curl_easy_setopt(slot->curl, CURLOPT_URL, request->url);
>
> The original code gave a separate "url" to setop() but this gives the same
> string. Does curl_easy_setop() copies the given string away? IOW is this
> change safe?
>
curl strdup's it, so this is safe.
The stack is like this:
curl_easy_setopt
calls Curl_setopt (at 391)
calls setstropt (at 1566)
calls strdup (at 276).
http://cool.haxx.se/cvs.cgi/curl/lib/easy.c?annotate=1.132 (for
curl_easy_setopt)
http://cool.haxx.se/cvs.cgi/curl/lib/url.c?annotate=1.782 (for
Curl_setopt, setstropt)
--
Cheers,
Ray Chuan
^ permalink raw reply
* Re: [PATCH] gitweb: last-modified time should be commiter, not author
From: Jakub Narebski @ 2009-01-26 1:54 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git
In-Reply-To: <1232923370-4427-1-git-send-email-giuseppe.bilotta@gmail.com>
On Sun, 25 Jan 2009, Giuseppe Bilotta wrote:
> Subject: [PATCH] gitweb: last-modified time should be commiter, not author
Should be really either "[PATCH 1/2]" or "[PATCH 5/4]" or "[PATCH 5/6]"
just in case for the next patch, because next patch _depends_ on this
one, and just in case of threading problem it should be marked as it;
it also makes easier to apply patches from emails saved as individual
files each.
>
> The last-modified time header added by RSS to increase cache hits from
> readers should be set to the date the repository was last modified. The
> author time in this respect is not a good guess because the last commit
> might come from a oldish patch.
>
> Use the committer time for the last-modified header to ensure a more
> correct guess of the last time the repository was modified.
Good catch, good thinking IMHO. Committer date has much better chance
to be monotonic than author date, and is more close related to
_publishing_ date (author date is more of _creation_ date).
Lack signoff; if Junio forges it (or you reply that it should be
signed off), you can add from me
Acked-by: Jakub Narebski <jnareb@gmail.com>
P.S. I wonder what other web interfaces do, for example cgit. I guess
that web interfaces for other SCMs like SVN::Web, ViewVC etc. do not
have this problem because they have only one, single date.
> ---
> gitweb/gitweb.perl | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index 756868a..8c49c75 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -6015,7 +6015,7 @@ sub git_feed {
> }
> if (defined($commitlist[0])) {
> %latest_commit = %{$commitlist[0]};
> - %latest_date = parse_date($latest_commit{'author_epoch'});
> + %latest_date = parse_date($latest_commit{'committer_epoch'});
> print $cgi->header(
> -type => $content_type,
> -charset => 'utf-8',
> --
> 1.5.6.5
>
>
--
Jakub Narebski
Poland
^ 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