* Re: [PATCH] Set TAR in t/Makefile and in t4116-apply-reverse.sh
From: Stephan Beyer @ 2008-07-25 17:12 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Brandon Casey, git, Junio C Hamano
In-Reply-To: <20080725170522.GG32057@genesis.frugalware.org>
[-- Attachment #1: Type: text/plain, Size: 507 bytes --]
Hi,
Miklos Vajna wrote:
> On Fri, Jul 25, 2008 at 06:37:40PM +0200, Stephan Beyer <s-beyer@gmx.net> wrote:
> > Hence, the test passes also when you run "make" in t/
> > or when you invoke t4116-apply-reverse.sh directly,
> > without $TAR being set.
>
> Thanks, I just hit this issue today. ;-)
Puh, I'm glad that you're not writing
"I've hit this issue yesterday and already sent a patch to this list" :)
Regards,
Stephan
--
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH] index-pack: correctly initialize appended objects
From: Björn Steinbrink @ 2008-07-25 17:13 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Nicolas Pitre, spearce, git
In-Reply-To: <alpine.DEB.1.00.0807251513240.11976@eeepc-johanness>
When index-pack completes a thin pack it appends objects to the pack.
Since the commit 92392b4(index-pack: Honor core.deltaBaseCacheLimit when
resolving deltas) such an object can be pruned in case of memory pressure.
To be able to re-read the object later, a few more fields have to be set.
Noticed by Pierre Habouzit.
Signed-off-by: Björn Steinbrink <B.Steinbrink@gmx.de>
Acked-by: Nicolas Pitre <nico@cam.org>
---
On 2008.07.25 15:15:48 +0200, Johannes Schindelin wrote:
> So, let's add the comment as Nico suggested, and set real_type,
> too?
OK, I hope the comment is what was expected. My lack of knowledge
made we wonder what to write... :-/
> (And it would be smashing if you could verify that the type is
> indeed correctly set to non-delta...)
Hm, we get the object via read_sha1_file, can that return a delta? I
would not expect it to. Sorry, never looked at those code paths
(and don't have the time to investigate at the moment).
index-pack.c | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/index-pack.c b/index-pack.c
index ac20a46..d757b07 100644
--- a/index-pack.c
+++ b/index-pack.c
@@ -699,6 +699,12 @@ static struct object_entry *append_obj_to_pack(
write_or_die(output_fd, header, n);
obj[0].idx.crc32 = crc32(0, Z_NULL, 0);
obj[0].idx.crc32 = crc32(obj[0].idx.crc32, header, n);
+ // This object comes from outside the thin pack, so we need to
+ // initialize the size and type fields
+ obj[0].hdr_size = n;
+ obj[0].size = size;
+ obj[0].type = type;
+ obj[0].real_type = type;
obj[1].idx.offset = obj[0].idx.offset + n;
obj[1].idx.offset += write_compressed(output_fd, buf, size, &obj[0].idx.crc32);
hashcpy(obj->idx.sha1, sha1);
--
1.6.0.rc0.14.g95f8.dirty
^ permalink raw reply related
* Re: [PATCH 2/2] editor.c: Libify launch_editor()
From: Stephan Beyer @ 2008-07-25 17:16 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Johannes Schindelin
In-Reply-To: <1217003322-10291-2-git-send-email-s-beyer@gmx.net>
Hi,
Stephan Beyer wrote:
> This patch removes exit()/die() calls and builtin-specific messages
> from launch_editor(), so that it can be used as a general libgit.a
> function to launch an editor.
>
> Signed-off-by: Stephan Beyer <s-beyer@gmx.net>
> ---
> builtin-commit.c | 6 +++++-
> builtin-tag.c | 6 +++++-
> editor.c | 24 ++++++++++++------------
> foo | 1 +
Ouch! Please exclude "foo"...
Sorry, for this maintainer-unfriendly patch again. *embarrassed*
Stephan
--
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F
^ permalink raw reply
* Re: [PATCH] index-pack: correctly initialize appended objects
From: Shawn O. Pearce @ 2008-07-25 17:20 UTC (permalink / raw)
To: Bjjjrn Steinbrink; +Cc: Johannes Schindelin, Junio C Hamano, Nicolas Pitre, git
In-Reply-To: <20080725171315.GA27285@atjola.homenet>
Bjjjrn Steinbrink <B.Steinbrink@gmx.de> wrote:
> When index-pack completes a thin pack it appends objects to the pack.
> Since the commit 92392b4(index-pack: Honor core.deltaBaseCacheLimit when
> resolving deltas) such an object can be pruned in case of memory pressure.
>
> To be able to re-read the object later, a few more fields have to be set.
>
> Noticed by Pierre Habouzit.
>
> Signed-off-by: Björn Steinbrink <B.Steinbrink@gmx.de>
> Acked-by: Nicolas Pitre <nico@cam.org>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
> On 2008.07.25 15:15:48 +0200, Johannes Schindelin wrote:
> > So, let's add the comment as Nico suggested, and set real_type,
> > too?
>
> OK, I hope the comment is what was expected. My lack of knowledge
> made we wonder what to write... :-/
The commit message makes sense to me. :)
> > (And it would be smashing if you could verify that the type is
> > indeed correctly set to non-delta...)
>
> Hm, we get the object via read_sha1_file, can that return a delta? I
> would not expect it to. Sorry, never looked at those code paths
> (and don't have the time to investigate at the moment).
read_sha1_file() _never_ returns a delta. It always reutrns the
whole object, even if the object was stored as a delta in a pack
somewhere. The function is widely used within git to read an object
for processing, without the caller needing to worry about the types
of compression used to store the object.
> diff --git a/index-pack.c b/index-pack.c
> index ac20a46..d757b07 100644
> --- a/index-pack.c
> +++ b/index-pack.c
> @@ -699,6 +699,12 @@ static struct object_entry *append_obj_to_pack(
> write_or_die(output_fd, header, n);
> obj[0].idx.crc32 = crc32(0, Z_NULL, 0);
> obj[0].idx.crc32 = crc32(obj[0].idx.crc32, header, n);
> + // This object comes from outside the thin pack, so we need to
> + // initialize the size and type fields
> + obj[0].hdr_size = n;
> + obj[0].size = size;
> + obj[0].type = type;
> + obj[0].real_type = type;
> obj[1].idx.offset = obj[0].idx.offset + n;
> obj[1].idx.offset += write_compressed(output_fd, buf, size, &obj[0].idx.crc32);
> hashcpy(obj->idx.sha1, sha1);
--
Shawn.
^ permalink raw reply
* Re: Mailing lists, was Re: [RFC] Git User's Survey 2008
From: Shawn O. Pearce @ 2008-07-25 17:23 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Marek Zawirski, Junio C Hamano, Jakub Narebski, git,
Stephan Beyer
In-Reply-To: <alpine.DEB.1.00.0807241308260.8986@racer>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Thu, 24 Jul 2008, Marek Zawirski wrote:
>
> > Junio C Hamano wrote:
>
> > > I am not sure how and where, but I think j/egit should also be
> > > mentioned and/or asked about.
> >
> > There is no separate mailing list for j/egit, we just used private mails
> > for some discussions/less important notifications.
>
> I hope not for too much, because this is one of the lessons of last year's
> GSoC (and to a large degree this year's Gitorrent project): if you keep
> the project too secret, nobody will know, and as a consequence nobody will
> care.
We've done most patch review discussions right here on git@vger,
but yea, some stuff happens in private. I think what happens in
private this year on egit is really just the standard mentor-student
working relationship prior to posting patches for discussion.
--
Shawn.
^ permalink raw reply
* git-scm.com
From: Scott Chacon @ 2008-07-25 17:35 UTC (permalink / raw)
To: git
Hey all,
A followup on the post I did a few days ago about Git documentation.
I forked Petr's git.or.cz site and put up a version that I think is a
bit more accessible and newbie-friendly at git-scm.com. I had meant
to discuss this with Petr before posting it to you all, but I
published a blog post that got a bit more attention than I expected,
and I didn't want you all to think I didn't care about your opinion,
as some have already accused me of.
Anyhow, I'm discussing with Petr about where we want to go from here -
what changes he'd like to make, etc, but I obviously value your
opinion as well, so please let me know what you think. The content
has barely changed, it's really just a usability overhaul. I want to
make sure that whatever someone is looking for (especially someone
new), they can find in a few clicks and a few seconds.
Next, I will be working on the larger end-user documentation project,
which will linked to from the documentation page of this site, and
probably the main page too. I'll keep this list updated as I go,
since people tend to think I don't care about the community when I try
not to waste your time. :)
Scott
^ permalink raw reply
* [PATCH] Propagate -u/--upload-pack option of "git clone" to transport.
From: Steve Haslam @ 2008-07-25 17:51 UTC (permalink / raw)
To: git; +Cc: Steve Haslam
The -u option to override the remote system's path to git-upload-pack was
being ignored by "git clone"; caused by a missing call to
transport_set_option to set TRANS_OPT_UPLOADPACK. Presumably this crept in
when git-clone was converted from shell to C.
Signed-off-by: Steve Haslam <shaslam@lastminute.com>
---
builtin-clone.c | 4 ++++
t/t5602-clone-remote-exec.sh | 26 ++++++++++++++++++++++++++
2 files changed, 30 insertions(+), 0 deletions(-)
create mode 100755 t/t5602-clone-remote-exec.sh
diff --git a/builtin-clone.c b/builtin-clone.c
index 3522245..e086a40 100644
--- a/builtin-clone.c
+++ b/builtin-clone.c
@@ -480,6 +480,10 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
if (option_quiet)
transport->verbose = -1;
+ if (option_upload_pack)
+ transport_set_option(transport, TRANS_OPT_UPLOADPACK,
+ option_upload_pack);
+
refs = transport_get_remote_refs(transport);
transport_fetch_refs(transport, refs);
}
diff --git a/t/t5602-clone-remote-exec.sh b/t/t5602-clone-remote-exec.sh
new file mode 100755
index 0000000..8367a68
--- /dev/null
+++ b/t/t5602-clone-remote-exec.sh
@@ -0,0 +1,26 @@
+#!/bin/sh
+
+test_description=clone
+
+. ./test-lib.sh
+
+test_expect_success setup '
+ echo "#!/bin/sh" > not_ssh
+ echo "echo \"\$*\" > not_ssh_output" >> not_ssh
+ echo "exit 1" >> not_ssh
+ chmod +x not_ssh
+'
+
+test_expect_success 'clone calls git-upload-pack unqualified with no -u option' '
+ GIT_SSH=./not_ssh git clone localhost:/path/to/repo junk
+ echo "localhost git-upload-pack '\''/path/to/repo'\''" >expected
+ test_cmp expected not_ssh_output
+'
+
+test_expect_success 'clone calls specified git-upload-pack with -u option' '
+ GIT_SSH=./not_ssh git clone -u /something/bin/git-upload-pack localhost:/path/to/repo junk
+ echo "localhost /something/bin/git-upload-pack '\''/path/to/repo'\''" >expected
+ test_cmp expected not_ssh_output
+'
+
+test_done
--
1.6.0.rc0.43.g1cd6
^ permalink raw reply related
* Re: [PATCH] index-pack: correctly initialize appended objects
From: Junio C Hamano @ 2008-07-25 18:15 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Johannes Schindelin, spearce, git, Björn Steinbrink
In-Reply-To: <alpine.LFD.1.10.0807250751220.9968@xanadu.home>
Nicolas Pitre <nico@cam.org> writes:
> On Fri, 25 Jul 2008, Johannes Schindelin wrote:
>
>> Hi,
>>
>> On Thu, 24 Jul 2008, Junio C Hamano wrote:
>>
>> > The function does not seem to use type (which the patch is also setting)
>> > nor real_type (which the patch does not set).
>> >
>> > However, the code checks objects[nth].real_type all over the place in
>> > the code. Doesn't the lack of real_type assignment in
>> > append_obj_to_pack() affect them in any way?
>>
>> >From staring at the code, I thought that real_type was set in
>> resolve_delta(), but I may be wrong.
>>
>> The safer thing would be to set it, but I am not quite sure if we can use
>> "type" directly, or if type can be "delta" for an object that is used to
>> complete the pack, and therefore stored as a non-delta.
>
> Objects to complete the pack are always non delta, so the type and
> real_type should be the same. However that shouldn't matter since at
> that point the object array is not walked anymore, at least not for
> appended objects, and therefore initializing the type at that point is
> redundant.
Thanks. Here is what I committed.
commit 72de2883bd7d4ceda05f107826c7607c594de965
Author: Björn Steinbrink <B.Steinbrink@gmx.de>
Date: Thu Jul 24 18:32:00 2008 +0100
index-pack.c: correctly initialize appended objects
When index-pack completes a thin pack it appends objects to the pack.
Since the commit 92392b4(index-pack: Honor core.deltaBaseCacheLimit when
resolving deltas) such an object can be pruned in case of memory
pressure, and will be read back again by get_data_from_pack(). For this
to work, the fields in object_entry structure need to be initialized
properly.
Noticed by Pierre Habouzit.
Signed-off-by: Björn Steinbrink <B.Steinbrink@gmx.de>
Acked-by: Nicolas Pitre <nico@cam.org>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
diff --git a/index-pack.c b/index-pack.c
index c359f8c..7d5344a 100644
--- a/index-pack.c
+++ b/index-pack.c
@@ -698,6 +698,10 @@ static struct object_entry *append_obj_to_pack(
write_or_die(output_fd, header, n);
obj[0].idx.crc32 = crc32(0, Z_NULL, 0);
obj[0].idx.crc32 = crc32(obj[0].idx.crc32, header, n);
+ obj[0].size = size;
+ obj[0].hdr_size = n;
+ obj[0].type = type;
+ obj[0].real_type = type;
obj[1].idx.offset = obj[0].idx.offset + n;
obj[1].idx.offset += write_compressed(output_fd, buf, size, &obj[0].idx.crc32);
hashcpy(obj->idx.sha1, sha1);
^ permalink raw reply related
* Re: [PATCH] Set TAR in t/Makefile and in t4116-apply-reverse.sh
From: Junio C Hamano @ 2008-07-25 18:18 UTC (permalink / raw)
To: Stephan Beyer; +Cc: Brandon Casey, git
In-Reply-To: <1217003860-10609-1-git-send-email-s-beyer@gmx.net>
Actually, 455a7f3 (More portability., 2005-09-30) introduced $TAR and it
is also used in t5000. cb34882 (fix t5000-tar-tree.sh when $TAR isn't
set, 2005-11-08) did the same fix you are adding, but I think both of
these fixes are in a wrong place.
I think we should do this instead. That's how SHELL_PATH is passed around
from build to all the test scripts already.
---
Makefile | 1 +
t/t5000-tar-tree.sh | 1 -
2 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
index b003e3e..1d14209 100644
--- a/Makefile
+++ b/Makefile
@@ -1212,6 +1212,7 @@ GIT-CFLAGS: .FORCE-GIT-CFLAGS
GIT-BUILD-OPTIONS: .FORCE-GIT-BUILD-OPTIONS
@echo SHELL_PATH=\''$(SHELL_PATH_SQ)'\' >$@
+ @echo TAR=\''$(subst ','\'',$(TAR))'\' >>$@
### Detect Tck/Tk interpreter path changes
ifndef NO_TCLTK
diff --git a/t/t5000-tar-tree.sh b/t/t5000-tar-tree.sh
index 9b0baac..5eb119e 100755
--- a/t/t5000-tar-tree.sh
+++ b/t/t5000-tar-tree.sh
@@ -25,7 +25,6 @@ commit id embedding:
'
. ./test-lib.sh
-TAR=${TAR:-tar}
UNZIP=${UNZIP:-unzip}
SUBSTFORMAT=%H%n
^ permalink raw reply related
* [PATCH] git-am: Mention --abort in usage string part of OPTIONS_SPEC
From: Stephan Beyer @ 2008-07-25 18:22 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Stephan Beyer
The three separate lines for --skip, --resolved and --abort
are merged into one so that it is easy to see that they're
alternative and related options.
Signed-off-by: Stephan Beyer <s-beyer@gmx.net>
---
I could've sworn this had already been in fcab40a38 (git am --abort)
but it wasn't. So here it is.
Regards.
git-am.sh | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/git-am.sh b/git-am.sh
index f4abd9d..6aa8192 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -6,8 +6,7 @@ SUBDIRECTORY_OK=Yes
OPTIONS_KEEPDASHDASH=
OPTIONS_SPEC="\
git am [options] [<mbox>|<Maildir>...]
-git am [options] --resolved
-git am [options] --skip
+git am [options] (--resolved | --skip | --abort)
--
d,dotest= (removed -- do not use)
i,interactive run interactively
--
1.6.0.rc0.106.g0f5bf
^ permalink raw reply related
* Re: [PATCH] Set TAR in t/Makefile and in t4116-apply-reverse.sh
From: Stephan Beyer @ 2008-07-25 18:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Brandon Casey, git
In-Reply-To: <7vvdytsu7n.fsf@gitster.siamese.dyndns.org>
Hi,
> diff --git a/Makefile b/Makefile
> index b003e3e..1d14209 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1212,6 +1212,7 @@ GIT-CFLAGS: .FORCE-GIT-CFLAGS
>
> GIT-BUILD-OPTIONS: .FORCE-GIT-BUILD-OPTIONS
> @echo SHELL_PATH=\''$(SHELL_PATH_SQ)'\' >$@
> + @echo TAR=\''$(subst ','\'',$(TAR))'\' >>$@
>
> ### Detect Tck/Tk interpreter path changes
> ifndef NO_TCLTK
But then TAR has to be set in test-lib.sh also, to be able to
invoke t5000 and t4116 directly, hasn't it?
Regards.
--
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F
^ permalink raw reply
* [PATCH] Remove references to git-fetch-pack from "git clone" documentation.
From: Steve Haslam @ 2008-07-25 18:37 UTC (permalink / raw)
To: git; +Cc: Steve Haslam
"git clone" no longer calls "git-fetch-pack", so the documentation is a bit
stale. Instead, state that the -u option is to be used when accessing a
repository over ssh.
Signed-off-by: Steve Haslam <shaslam@lastminute.com>
---
This is somewhat related to a patch I just sent; typically I forgot
about the documentation until after sending it.
Documentation/git-clone.txt | 9 ++++-----
1 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt
index 91efac9..26fd1b1 100644
--- a/Documentation/git-clone.txt
+++ b/Documentation/git-clone.txt
@@ -87,8 +87,8 @@ then the cloned repository will become corrupt.
--quiet::
-q::
- Operate quietly. This flag is passed to "rsync" and
- 'git-fetch-pack' commands when given.
+ Operate quietly. This flag is also passed to the `rsync'
+ command when given.
--no-checkout::
-n::
@@ -113,9 +113,8 @@ then the cloned repository will become corrupt.
--upload-pack <upload-pack>::
-u <upload-pack>::
- When given, and the repository to clone from is handled
- by 'git-fetch-pack', `--exec=<upload-pack>` is passed to
- the command to specify non-default path for the command
+ When given, and the repository to clone from is accessed
+ via ssh, this specifies a non-default path for the command
run on the other end.
--template=<template_directory>::
--
1.6.0.rc0.43.g1cd6
^ permalink raw reply related
* Re: [PATCH] Avoid warning when From: is encoded
From: Jeff King @ 2008-07-25 18:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Peter Valdemar Mørch, git
In-Reply-To: <7vhcadudmz.fsf@gitster.siamese.dyndns.org>
On Fri, Jul 25, 2008 at 09:33:56AM -0700, Junio C Hamano wrote:
> > In commit 0706bd19ef9b41e7519df2c73796ef93484272fd $1 is used from a regexp
> > without using () to set up $1. Later, when that value was used, it caused a
> > warning about a variable being undefined.
> >
> > Signed-off-by: Peter Valdemar Mørch <peter@morch.com>
>
> Thanks. The patch is obviously correct; I think you are fixing 8291db6
> (git-send-email: add charset header if we add encoded 'From', 2007-11-16),
> not 0706bd1 (send-email: specify content-type of --compose body,
> 2008-03-28).
>
> Will apply to maint and merge upwards.
Discussions about who can ACK this code aside, the original bogosity was
totally mine, so
Acked-by: Jeff King <peff@peff.net>
-Peff
^ permalink raw reply
* Re: Mailing lists, was Re: [RFC] Git User's Survey 2008
From: Junio C Hamano @ 2008-07-25 18:49 UTC (permalink / raw)
To: Shawn O. Pearce
Cc: Johannes Schindelin, Marek Zawirski, Jakub Narebski, git,
Stephan Beyer
In-Reply-To: <20080725172313.GE21117@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>> On Thu, 24 Jul 2008, Marek Zawirski wrote:
>>
>> > Junio C Hamano wrote:
>>
>> > > I am not sure how and where, but I think j/egit should also be
>> > > mentioned and/or asked about.
>> >
>> > There is no separate mailing list for j/egit, we just used private mails
>> > for some discussions/less important notifications.
>>
>> I hope not for too much, because this is one of the lessons of last year's
>> GSoC (and to a large degree this year's Gitorrent project): if you keep
>> the project too secret, nobody will know, and as a consequence nobody will
>> care.
>
> We've done most patch review discussions right here on git@vger,
> but yea, some stuff happens in private. I think what happens in
> private this year on egit is really just the standard mentor-student
> working relationship prior to posting patches for discussion.
Sorry for causing confusion in the discussion, but I was not talking about
"mailing list on e/jgit".
What I meant was that we might want to have a few more questions about
e/jgit as an independent entity in the survey, as it is a completely
different re-implementation of the same git theme.
^ permalink raw reply
* Re: [PATCH] Set TAR in t/Makefile and in t4116-apply-reverse.sh
From: Junio C Hamano @ 2008-07-25 18:54 UTC (permalink / raw)
To: Stephan Beyer; +Cc: Brandon Casey, git
In-Reply-To: <20080725182416.GG27172@leksak.fem-net>
Stephan Beyer <s-beyer@gmx.net> writes:
> Hi,
>
>> diff --git a/Makefile b/Makefile
>> index b003e3e..1d14209 100644
>> --- a/Makefile
>> +++ b/Makefile
>> @@ -1212,6 +1212,7 @@ GIT-CFLAGS: .FORCE-GIT-CFLAGS
>>
>> GIT-BUILD-OPTIONS: .FORCE-GIT-BUILD-OPTIONS
>> @echo SHELL_PATH=\''$(SHELL_PATH_SQ)'\' >$@
>> + @echo TAR=\''$(subst ','\'',$(TAR))'\' >>$@
>>
>> ### Detect Tck/Tk interpreter path changes
>> ifndef NO_TCLTK
>
> But then TAR has to be set in test-lib.sh also, to be able to
> invoke t5000 and t4116 directly, hasn't it?
Dosen't test-lib source GIT-BUILD-OPTIONS?
^ permalink raw reply
* Re: [PATCH] Set TAR in t/Makefile and in t4116-apply-reverse.sh
From: Stephan Beyer @ 2008-07-25 18:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Brandon Casey, git
In-Reply-To: <7vmyk5sska.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> Stephan Beyer <s-beyer@gmx.net> writes:
> >> diff --git a/Makefile b/Makefile
> >> index b003e3e..1d14209 100644
> >> --- a/Makefile
> >> +++ b/Makefile
> >> @@ -1212,6 +1212,7 @@ GIT-CFLAGS: .FORCE-GIT-CFLAGS
> >>
> >> GIT-BUILD-OPTIONS: .FORCE-GIT-BUILD-OPTIONS
> >> @echo SHELL_PATH=\''$(SHELL_PATH_SQ)'\' >$@
> >> + @echo TAR=\''$(subst ','\'',$(TAR))'\' >>$@
> >>
> >> ### Detect Tck/Tk interpreter path changes
> >> ifndef NO_TCLTK
> >
> > But then TAR has to be set in test-lib.sh also, to be able to
> > invoke t5000 and t4116 directly, hasn't it?
>
> Dosen't test-lib source GIT-BUILD-OPTIONS?
It does. Great, then.
Regards.
--
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F
^ permalink raw reply
* Re: git rebase to move a batch of patches onto the current branch
From: Daniel Barkalow @ 2008-07-25 19:16 UTC (permalink / raw)
To: Avery Pennarun; +Cc: Alex Riesen, Git Mailing List
In-Reply-To: <32541b130807241342h483169d7we955512879075161@mail.gmail.com>
On Thu, 24 Jul 2008, Avery Pennarun wrote:
> On 7/24/08, Alex Riesen <raa.lkml@gmail.com> wrote:
> > Avery Pennarun, Thu, Jul 24, 2008 22:16:06 +0200:
> > > On 7/24/08, Alex Riesen <raa.lkml@gmail.com> wrote:
> >
> > > > gcp3 ()
> > > > {
> > > > git format-patch -k --stdout --full-index "$@" | git am -k -3 --binary
> > > > }
> > >
> > > But that'll give up when there are conflicts, right? git-rebase lets
> > > me fix them in a nice way.
> >
> > No, it same as in rebase. You'll fix them and do "git am --resolved".
> > See manpage of git am.
>
> Hmm, cool.
>
> So that command isn't too easy to come upon by accident. If I wanted
> to submit a patch to make this process a bit more obvious, would it
> make sense to simply have git-cherry-pick call that sequence when you
> give it more than one commit?
Before terribly long, we'll have "git sequencer", which should be easy to
get to do the "rebase -i" thing with cherry-pick-style usage (somebody
would just need to write code to generate the correct series of pick
statements).
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* how about removing --exec-path?
From: Alex Riesen @ 2008-07-25 9:40 UTC (permalink / raw)
To: git
The thing has at least this problem: is not passed to upload-pack when
running fetch. So upload-pack, everything past it gets called either
from GIT_EXEC_PATH (which usually is not set) or from builtin exec
path (and that's annoying when debugging for instance index-pack).
The feature has a stable alternative ($GIT_EXEC_PATH) anyway.
Or maybe just replace the whole argv_exec_path handling with a plain
setenv("GIT_EXEC_PATH", exec_path, 1)?
^ permalink raw reply
* Re: [PATCH] Build configuration to skip ctime for modification test
From: Alex Riesen @ 2008-07-25 5:55 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Johannes Schindelin, Junio C Hamano, Johannes Sixt, git
In-Reply-To: <alpine.LFD.1.10.0807241854580.5249@nehalem.linux-foundation.org>
Linus Torvalds, Fri, Jul 25, 2008 04:00:29 +0200:
> On Wed, 23 Jul 2008, Alex Riesen wrote:
> >
> > It is not that it is broken. We just don't need it, because the st_mode
> > is not used, and the rest of inode information is not used anyway.
>
> That is NOT why git checks the ctime.
>
> Git checks the ctime not because it cares about the inode state being
> modified per se: since it can see that _directly_ - so why should it care
> about inode state like st_mode?
>
> No, git checks ctime because it in general tries to make it VERY VERY hard
> for people to try to "fake out" git and replace files from underneath it
> without git noticing.
>
> It's much easier and much more common for tools to restore 'mtime' when
> they do some operation on a file than it is for them to restore 'ctime'.
>
> For example, if you rsync files between two hosts, the '-t' flag will make
> rsync try to keep the mtimes in sync (and it's part of '-a', which is the
> common form that you'd use for rsync). So if you only look at mtime and
> size, you often miss the fact that the file has actually been messed with!
>
> Looking at ctime gets around a number of those things. Of course, it can
> cause git to be _too_ eager in thinking that a file is modified, and an
> example of that is the insane indexing that 'beagle' does, which actually
> modifies the files by adding inode extended attributes to them and thus
> changes ctime due to the indexing. But in general it's a lot better to be
> too careful than to miss the fact that somebody changed the file.
>
But, given the fact, that somewhere sometimes its very-very annoying
to have even one (un)changed file, something must be done about it.
Maybe just direct
# my .gitconfig for Windows machines with GDS
[core]
filemode = false
trustctime = false
logallrefupdates = false
[pack]
threads = 1
etc...
^ permalink raw reply
* Re: git rebase to move a batch of patches onto the current branch
From: Stephan Beyer @ 2008-07-25 19:25 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Avery Pennarun, Alex Riesen, Git Mailing List
In-Reply-To: <alpine.LNX.1.00.0807251509390.19665@iabervon.org>
Hi,
Daniel Barkalow wrote:
> > On 7/24/08, Alex Riesen <raa.lkml@gmail.com> wrote:
> > > Avery Pennarun, Thu, Jul 24, 2008 22:16:06 +0200:
> > > > On 7/24/08, Alex Riesen <raa.lkml@gmail.com> wrote:
> > >
> > > > > gcp3 ()
> > > > > {
> > > > > git format-patch -k --stdout --full-index "$@" | git am -k -3 --binary
> > > > > }
> > > >
> > > > But that'll give up when there are conflicts, right? git-rebase lets
> > > > me fix them in a nice way.
> > >
> > > No, it same as in rebase. You'll fix them and do "git am --resolved".
> > > See manpage of git am.
> >
> > Hmm, cool.
> >
> > So that command isn't too easy to come upon by accident. If I wanted
> > to submit a patch to make this process a bit more obvious, would it
> > make sense to simply have git-cherry-pick call that sequence when you
> > give it more than one commit?
>
> Before terribly long, we'll have "git sequencer", which should be easy to
> get to do the "rebase -i" thing with cherry-pick-style usage (somebody
> would just need to write code to generate the correct series of pick
> statements).
For simple cases this code could be something like:
git rev-list --reverse --cherry-pick --no-merges --first-parent <from>..<to> |
sed 's/^/pick /' | git sequencer
(At least this is what I use relatively often.)
But as long as git sequencer is not in official git, this is not an
option. :)
Regards,
Stephan
--
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F
^ permalink raw reply
* Re: [EGIT] Supported Eclipse version
From: Robin Rosenberg @ 2008-07-25 19:35 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Marek Zawirski, Jean-Frannnois Veillette, git
In-Reply-To: <20080725161652.GA21117@spearce.org>
fredagen den 25 juli 2008 18.16.52 skrev Shawn O. Pearce:
> Marek Zawirski <marek.zawirski@gmail.com> wrote:
> > Jean-François Veillette wrote:
> >>> Maybe some users (or developers) from mailing list can tell us about
> >>> their opinion?
> >>
> >> I think keeping comptability for one version behind the 'current'
> >> (still compatible 3.3 while 3.4 is the current) is a reasonable goal.
> >> 3.2 is relatively far behind, tools vendor had time to get up to date
> >> by now.
> >
> > Robin, Shawn, would you accept next patches using 3.3 API?
>
> Yes, we should be dropping support for 3.2 now and supporting only
> 3.3 and 3.4 going forward. 3.2 is ancient and anyone who is serious
> aboug using Git with Eclipse really should be on a more current
> version of the tools.
We already dropped 3.2 compatibility with the push/fetch support. That
was an accident, of course.
Support for 3.3 could also end ahead of schedule if we absolutely need
some feature that is only available in 3.4. We'll discuss that then, when/if
it happens. The plan is to support 3.3 until 3.5 is out (or even longer if
that requires no effort).
So much for intent. We reserve the right to change our minds or make mistakes
without notice.
-- robin
^ permalink raw reply
* Re: [PATCH] Set TAR in t/Makefile and in t4116-apply-reverse.sh
From: Junio C Hamano @ 2008-07-25 19:37 UTC (permalink / raw)
To: Stephan Beyer; +Cc: Brandon Casey, git
In-Reply-To: <20080725185818.GA13539@leksak.fem-net>
Stephan Beyer <s-beyer@gmx.net> writes:
> Junio C Hamano wrote:
>> Stephan Beyer <s-beyer@gmx.net> writes:
>> >> diff --git a/Makefile b/Makefile
>> >> index b003e3e..1d14209 100644
>> >> --- a/Makefile
>> >> +++ b/Makefile
>> >> @@ -1212,6 +1212,7 @@ GIT-CFLAGS: .FORCE-GIT-CFLAGS
>> >>
>> >> GIT-BUILD-OPTIONS: .FORCE-GIT-BUILD-OPTIONS
>> >> @echo SHELL_PATH=\''$(SHELL_PATH_SQ)'\' >$@
>> >> + @echo TAR=\''$(subst ','\'',$(TAR))'\' >>$@
>> >>
>> >> ### Detect Tck/Tk interpreter path changes
>> >> ifndef NO_TCLTK
>> >
>> > But then TAR has to be set in test-lib.sh also, to be able to
>> > invoke t5000 and t4116 directly, hasn't it?
>>
>> Dosen't test-lib source GIT-BUILD-OPTIONS?
>
> It does. Great, then.
Sorry, but not quite. The above shell construct is toooootally bogus.
We need this patch on top.
-- >8 --
[PATCH] Makefile: fix shell quoting
Makefile records paths to a few programs in GIT-BUILD-OPTIONS file. These
paths need to be quoted twice: once to protect specials from the shell
that runs the generated GIT-BUILD-OPTIONS file, and again to protect them
(and the first level of quoting itself) from the shell that runs the
"echo" inside the Makefile.
You can test this by trying:
$ ln -s /bin/tar "$HOME/Tes' program/tar"
$ make TAR="$HOME/Tes' program/tar" test
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Makefile | 7 +++++--
t/t5000-tar-tree.sh | 10 +++++-----
2 files changed, 10 insertions(+), 7 deletions(-)
diff --git a/Makefile b/Makefile
index 1d14209..f13184b 100644
--- a/Makefile
+++ b/Makefile
@@ -1210,9 +1210,12 @@ GIT-CFLAGS: .FORCE-GIT-CFLAGS
echo "$$FLAGS" >GIT-CFLAGS; \
fi
+# We need to apply sq twice, once to protect from the shell
+# that runs GIT-BUILD-OPTIONS, and then again to protect it
+# and the first level quoting from the shell that runs "echo".
GIT-BUILD-OPTIONS: .FORCE-GIT-BUILD-OPTIONS
- @echo SHELL_PATH=\''$(SHELL_PATH_SQ)'\' >$@
- @echo TAR=\''$(subst ','\'',$(TAR))'\' >>$@
+ @echo SHELL_PATH=\''$(subst ','\'',$(SHELL_PATH_SQ))'\' >$@
+ @echo TAR=\''$(subst ','\'',$(subst ','\'',$(TAR)))'\' >>$@
### Detect Tck/Tk interpreter path changes
ifndef NO_TCLTK
diff --git a/t/t5000-tar-tree.sh b/t/t5000-tar-tree.sh
index 5eb119e..87902f8 100755
--- a/t/t5000-tar-tree.sh
+++ b/t/t5000-tar-tree.sh
@@ -67,7 +67,7 @@ test_expect_success \
test_expect_success \
'validate file modification time' \
'mkdir extract &&
- $TAR xf b.tar -C extract a/a &&
+ "$TAR" xf b.tar -C extract a/a &&
perl -e '\''print((stat("extract/a/a"))[9], "\n")'\'' >b.mtime &&
echo "1117231200" >expected.mtime &&
diff expected.mtime b.mtime'
@@ -79,7 +79,7 @@ test_expect_success \
test_expect_success \
'extract tar archive' \
- '(cd b && $TAR xf -) <b.tar'
+ '(cd b && "$TAR" xf -) <b.tar'
test_expect_success \
'validate filenames' \
@@ -96,7 +96,7 @@ test_expect_success \
test_expect_success \
'extract tar archive with prefix' \
- '(cd c && $TAR xf -) <c.tar'
+ '(cd c && "$TAR" xf -) <c.tar'
test_expect_success \
'validate filenames with prefix' \
@@ -116,7 +116,7 @@ test_expect_success \
test_expect_success \
'extract substfiles' \
- '(mkdir f && cd f && $TAR xf -) <f.tar'
+ '(mkdir f && cd f && "$TAR" xf -) <f.tar'
test_expect_success \
'validate substfile contents' \
@@ -128,7 +128,7 @@ test_expect_success \
test_expect_success \
'extract substfiles from archive with prefix' \
- '(mkdir g && cd g && $TAR xf -) <g.tar'
+ '(mkdir g && cd g && "$TAR" xf -) <g.tar'
test_expect_success \
'validate substfile contents from archive with prefix' \
--
1.6.0.rc0.51.g51a9e
^ permalink raw reply related
* [JGIT PATCH 0/9] List commonly used (or recognized) commands
From: Shawn O. Pearce @ 2008-07-25 19:45 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
This series adds support to jgit to list commonly used subcommands
if the user just executes `jgit` with no subcommand requested:
$ jgit
jgit --git-dir GIT_DIR --help (-h) --show-stack-trace command [ARG ...]
The most commonly used commands are:
fetch Update remote refs from another repository
log View commit history
push Update remote repository from local refs
tag Create a tag
Commands inside of the pgm.debug package are automatically given
the debug- prefix, allowing debug-show-commands to be used to show
the command table.
Commands must be listed in the META-INF/services/org...TextBuiltin
file in order to be considered for execution. This means that we
must add (or remove) command class names from the listing each time
we introduce or remove a command line subcommand.
One advantage to this structure is additional commands can defined
in other packages, and are available so long as the classes are
reachable through the CLASSPATH. Since jgit.sh hardcodes the
CLASSPATH to only itself this is not fully supported yet, but does
open the door for users to extend jgit's command line support.
Shawn O. Pearce (9):
Switch jgit.pgm to J2SE-1.5 execution environment
Remove unnecessary duplicate if (help) test inside TextBuiltin
Create an optional documentation annotation for TextBuiltin
Create a lightweight registration wrapper for TextBuiltin
Create a catalog of CommandRefs for lookup and enumeration
Document some common commands with the new Command annotation
Include commonly used commands in main help output
Refactor SubcommandHandler to use CommandCatalog instead of
reflection
Add debug-show-commands to display the command table
org.spearce.jgit.pgm/.classpath | 2 +-
.../services/org.spearce.jgit.pgm.TextBuiltin | 14 ++
.../src/org/spearce/jgit/pgm/Command.java | 72 ++++++++
.../src/org/spearce/jgit/pgm/CommandCatalog.java | 188 ++++++++++++++++++++
.../src/org/spearce/jgit/pgm/CommandRef.java | 158 ++++++++++++++++
.../src/org/spearce/jgit/pgm/Fetch.java | 1 +
.../src/org/spearce/jgit/pgm/Log.java | 1 +
.../src/org/spearce/jgit/pgm/Main.java | 18 ++
.../src/org/spearce/jgit/pgm/Push.java | 1 +
.../src/org/spearce/jgit/pgm/Tag.java | 1 +
.../src/org/spearce/jgit/pgm/TextBuiltin.java | 17 +--
.../org/spearce/jgit/pgm/debug/ShowCommands.java | 78 ++++++++
.../spearce/jgit/pgm/opt/SubcommandHandler.java | 65 +------
13 files changed, 543 insertions(+), 73 deletions(-)
create mode 100644 org.spearce.jgit.pgm/src/META-INF/services/org.spearce.jgit.pgm.TextBuiltin
create mode 100644 org.spearce.jgit.pgm/src/org/spearce/jgit/pgm/Command.java
create mode 100644 org.spearce.jgit.pgm/src/org/spearce/jgit/pgm/CommandCatalog.java
create mode 100644 org.spearce.jgit.pgm/src/org/spearce/jgit/pgm/CommandRef.java
create mode 100644 org.spearce.jgit.pgm/src/org/spearce/jgit/pgm/debug/ShowCommands.java
^ permalink raw reply
* [JGIT PATCH 1/9] Switch jgit.pgm to J2SE-1.5 execution environment
From: Shawn O. Pearce @ 2008-07-25 19:45 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
In-Reply-To: <1217015167-4680-1-git-send-email-spearce@spearce.org>
We have been keeping the jgit library itself on Java 5, and the
jgit command line tools should also be on Java 5 and avoid using
any Java 6 APIs (for now). Not all of our target platforms have
a Java 6 virtual machine available out of the box.
Since the pgm project broke out of the library project our code
already conforms to Java 5 APIs, so we just have to switch the
build path settings.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
org.spearce.jgit.pgm/.classpath | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/org.spearce.jgit.pgm/.classpath b/org.spearce.jgit.pgm/.classpath
index cc861d2..50dd6d3 100644
--- a/org.spearce.jgit.pgm/.classpath
+++ b/org.spearce.jgit.pgm/.classpath
@@ -2,7 +2,7 @@
<classpath>
<classpathentry kind="src" path="src"/>
<classpathentry exported="true" kind="lib" path="lib/args4j-2.0.9.jar" sourcepath="lib/args4j-2.0.9.zip"/>
- <classpathentry exported="true" kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER"/>
+ <classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/J2SE-1.5"/>
<classpathentry combineaccessrules="false" exported="true" kind="src" path="/org.spearce.jgit"/>
<classpathentry kind="output" path="bin"/>
</classpath>
--
1.6.0.rc0.182.gb96c7
^ permalink raw reply related
* [JGIT PATCH 2/9] Remove unnecessary duplicate if (help) test inside TextBuiltin
From: Shawn O. Pearce @ 2008-07-25 19:46 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
In-Reply-To: <1217015167-4680-2-git-send-email-spearce@spearce.org>
This was caused by a copy-and-paste error as I borrowed the
global argument handling code in Main to help start writing
the command specific argument handling in TextBuiltin.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
.../src/org/spearce/jgit/pgm/TextBuiltin.java | 9 ++++-----
1 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/org.spearce.jgit.pgm/src/org/spearce/jgit/pgm/TextBuiltin.java b/org.spearce.jgit.pgm/src/org/spearce/jgit/pgm/TextBuiltin.java
index d02a0a2..e2eef84 100644
--- a/org.spearce.jgit.pgm/src/org/spearce/jgit/pgm/TextBuiltin.java
+++ b/org.spearce.jgit.pgm/src/org/spearce/jgit/pgm/TextBuiltin.java
@@ -145,11 +145,10 @@ public abstract class TextBuiltin {
clp.printSingleLineUsage(System.err);
System.err.println();
- if (help) {
- System.err.println();
- clp.printUsage(System.err);
- System.err.println();
- }
+ System.err.println();
+ clp.printUsage(System.err);
+ System.err.println();
+
System.exit(1);
}
--
1.6.0.rc0.182.gb96c7
^ permalink raw reply related
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