* [PATCH 3/3] verify-pack --stat-only: show histogram without verifying
From: Junio C Hamano @ 2009-08-08 3:36 UTC (permalink / raw)
To: git
In-Reply-To: <1249702594-7815-2-git-send-email-gitster@pobox.com>
When this option is given, the command does not verify the pack contents,
but shows the delta chain histogram. If used with --verbose, the usual
list of objects is also shown.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Documentation/git-verify-pack.txt | 8 +++++-
builtin-verify-pack.c | 49 +++++++++++++++++++++++++------------
2 files changed, 40 insertions(+), 17 deletions(-)
diff --git a/Documentation/git-verify-pack.txt b/Documentation/git-verify-pack.txt
index d791a80..97f7f91 100644
--- a/Documentation/git-verify-pack.txt
+++ b/Documentation/git-verify-pack.txt
@@ -25,7 +25,13 @@ OPTIONS
-v::
--verbose::
After verifying the pack, show list of objects contained
- in the pack.
+ in the pack and a histogram of delta chain length.
+
+-s::
+--stat-only::
+ Do not verify the pack contents; only show the histogram of delta
+ chain length. With `--verbose`, list of objects is also shown.
+
\--::
Do not interpret any more arguments as options.
diff --git a/builtin-verify-pack.c b/builtin-verify-pack.c
index b5bd28e..b6079ae 100644
--- a/builtin-verify-pack.c
+++ b/builtin-verify-pack.c
@@ -6,10 +6,14 @@
#define MAX_CHAIN 50
-static void show_pack_info(struct packed_git *p)
+#define VERIFY_PACK_VERBOSE 01
+#define VERIFY_PACK_STAT_ONLY 02
+
+static void show_pack_info(struct packed_git *p, unsigned int flags)
{
uint32_t nr_objects, i;
int cnt;
+ int stat_only = flags & VERIFY_PACK_STAT_ONLY;
unsigned long chain_histogram[MAX_CHAIN+1], baseobjects;
nr_objects = p->num_objects;
@@ -32,16 +36,19 @@ static void show_pack_info(struct packed_git *p)
type = packed_object_info_detail(p, offset, &size, &store_size,
&delta_chain_length,
base_sha1);
- printf("%s ", sha1_to_hex(sha1));
+ if (!stat_only)
+ printf("%s ", sha1_to_hex(sha1));
if (!delta_chain_length) {
- printf("%-6s %lu %lu %"PRIuMAX"\n",
- type, size, store_size, (uintmax_t)offset);
+ if (!stat_only)
+ printf("%-6s %lu %lu %"PRIuMAX"\n",
+ type, size, store_size, (uintmax_t)offset);
baseobjects++;
}
else {
- printf("%-6s %lu %lu %"PRIuMAX" %u %s\n",
- type, size, store_size, (uintmax_t)offset,
- delta_chain_length, sha1_to_hex(base_sha1));
+ if (!stat_only)
+ printf("%-6s %lu %lu %"PRIuMAX" %u %s\n",
+ type, size, store_size, (uintmax_t)offset,
+ delta_chain_length, sha1_to_hex(base_sha1));
if (delta_chain_length <= MAX_CHAIN)
chain_histogram[delta_chain_length]++;
else
@@ -66,10 +73,12 @@ static void show_pack_info(struct packed_git *p)
chain_histogram[0] > 1 ? "s" : "");
}
-static int verify_one_pack(const char *path, int verbose)
+static int verify_one_pack(const char *path, unsigned int flags)
{
char arg[PATH_MAX];
int len;
+ int verbose = flags & VERIFY_PACK_VERBOSE;
+ int stat_only = flags & VERIFY_PACK_STAT_ONLY;
struct packed_git *pack;
int err;
@@ -105,14 +114,19 @@ static int verify_one_pack(const char *path, int verbose)
return error("packfile %s not found.", arg);
install_packed_git(pack);
- err = verify_pack(pack);
- if (verbose) {
+ if (!stat_only)
+ err = verify_pack(pack);
+ else
+ err = open_pack_index(pack);
+
+ if (verbose || stat_only) {
if (err)
printf("%s: bad\n", pack->pack_name);
else {
- show_pack_info(pack);
- printf("%s: ok\n", pack->pack_name);
+ show_pack_info(pack, flags);
+ if (!stat_only)
+ printf("%s: ok\n", pack->pack_name);
}
}
@@ -120,17 +134,20 @@ static int verify_one_pack(const char *path, int verbose)
}
static const char * const verify_pack_usage[] = {
- "git verify-pack [-v|--verbose] <pack>...",
+ "git verify-pack [-v|--verbose] [-s|--stat-only] <pack>...",
NULL
};
int cmd_verify_pack(int argc, const char **argv, const char *prefix)
{
int err = 0;
- int verbose = 0;
+ unsigned int flags = 0;
int i;
const struct option verify_pack_options[] = {
- OPT__VERBOSE(&verbose),
+ OPT_BIT('v', "verbose", &flags, "verbose",
+ VERIFY_PACK_VERBOSE),
+ OPT_BIT('s', "stat-only", &flags, "show statistics only",
+ VERIFY_PACK_STAT_ONLY),
OPT_END()
};
@@ -140,7 +157,7 @@ int cmd_verify_pack(int argc, const char **argv, const char *prefix)
if (argc < 1)
usage_with_options(verify_pack_usage, verify_pack_options);
for (i = 0; i < argc; i++) {
- if (verify_one_pack(argv[i], verbose))
+ if (verify_one_pack(argv[i], flags))
err = 1;
discard_revindex();
}
--
1.6.4.151.g786db
^ permalink raw reply related
* [PATCH 2/3] verify-pack -v: do not report "chain length 0"
From: Junio C Hamano @ 2009-08-08 3:36 UTC (permalink / raw)
To: git
In-Reply-To: <1249702594-7815-1-git-send-email-gitster@pobox.com>
When making a histogram of delta chain length in the pack, the program
collects number of objects whose delta depth exceeds the MAX_CHAIN limit
in histogram[0], and showed it as the number of items that exceeds the
limit correctly. HOWEVER, it also showed the same number labeled as
"chain length = 0".
In fact, we are not showing the number of objects whose chain length is
zero, i.e. the base objects. Correct this.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
builtin-verify-pack.c | 27 +++++++++++++++++++--------
1 files changed, 19 insertions(+), 8 deletions(-)
diff --git a/builtin-verify-pack.c b/builtin-verify-pack.c
index ebd6dff..b5bd28e 100644
--- a/builtin-verify-pack.c
+++ b/builtin-verify-pack.c
@@ -8,10 +8,13 @@
static void show_pack_info(struct packed_git *p)
{
- uint32_t nr_objects, i, chain_histogram[MAX_CHAIN+1];
+ uint32_t nr_objects, i;
+ int cnt;
+ unsigned long chain_histogram[MAX_CHAIN+1], baseobjects;
nr_objects = p->num_objects;
memset(chain_histogram, 0, sizeof(chain_histogram));
+ baseobjects = 0;
for (i = 0; i < nr_objects; i++) {
const unsigned char *sha1;
@@ -30,9 +33,11 @@ static void show_pack_info(struct packed_git *p)
&delta_chain_length,
base_sha1);
printf("%s ", sha1_to_hex(sha1));
- if (!delta_chain_length)
+ if (!delta_chain_length) {
printf("%-6s %lu %lu %"PRIuMAX"\n",
type, size, store_size, (uintmax_t)offset);
+ baseobjects++;
+ }
else {
printf("%-6s %lu %lu %"PRIuMAX" %u %s\n",
type, size, store_size, (uintmax_t)offset,
@@ -44,15 +49,21 @@ static void show_pack_info(struct packed_git *p)
}
}
- for (i = 0; i <= MAX_CHAIN; i++) {
- if (!chain_histogram[i])
+ if (baseobjects)
+ printf("non delta: %lu object%s\n",
+ baseobjects, baseobjects > 1 ? "s" : "");
+
+ for (cnt = 1; cnt <= MAX_CHAIN; cnt++) {
+ if (!chain_histogram[cnt])
continue;
- printf("chain length = %"PRIu32": %"PRIu32" object%s\n", i,
- chain_histogram[i], chain_histogram[i] > 1 ? "s" : "");
+ printf("chain length = %d: %lu object%s\n", cnt,
+ chain_histogram[cnt],
+ chain_histogram[cnt] > 1 ? "s" : "");
}
if (chain_histogram[0])
- printf("chain length > %d: %"PRIu32" object%s\n", MAX_CHAIN,
- chain_histogram[0], chain_histogram[0] > 1 ? "s" : "");
+ printf("chain length > %d: %lu object%s\n", MAX_CHAIN,
+ chain_histogram[0],
+ chain_histogram[0] > 1 ? "s" : "");
}
static int verify_one_pack(const char *path, int verbose)
--
1.6.4.151.g786db
^ permalink raw reply related
* [PATCH 1/3] t5510: harden the way verify-pack is used
From: Junio C Hamano @ 2009-08-08 3:36 UTC (permalink / raw)
To: git
The test ignored the exit status from verify pack command, and also relied
on not seeing any delta chain statistics.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
t/t5510-fetch.sh | 11 ++++++++---
1 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/t/t5510-fetch.sh b/t/t5510-fetch.sh
index bee3424..d13c806 100755
--- a/t/t5510-fetch.sh
+++ b/t/t5510-fetch.sh
@@ -9,6 +9,11 @@ test_description='Per branch config variables affects "git fetch".
D=`pwd`
+test_bundle_object_count () {
+ git verify-pack -v "$1" >verify.out &&
+ test "$2" = $(grep '^[0-9a-f]\{40\} ' verify.out | wc -l)
+}
+
test_expect_success setup '
echo >file original &&
git add file &&
@@ -146,6 +151,7 @@ test_expect_success 'unbundle 1' '
test_must_fail git fetch "$D/bundle1" master:master
'
+
test_expect_success 'bundle 1 has only 3 files ' '
cd "$D" &&
(
@@ -156,8 +162,7 @@ test_expect_success 'bundle 1 has only 3 files ' '
cat
) <bundle1 >bundle.pack &&
git index-pack bundle.pack &&
- verify=$(git verify-pack -v bundle.pack) &&
- test 4 = $(echo "$verify" | wc -l)
+ test_bundle_object_count bundle.pack 3
'
test_expect_success 'unbundle 2' '
@@ -180,7 +185,7 @@ test_expect_success 'bundle does not prerequisite objects' '
cat
) <bundle3 >bundle.pack &&
git index-pack bundle.pack &&
- test 4 = $(git verify-pack -v bundle.pack | wc -l)
+ test_bundle_object_count bundle.pack 3
'
test_expect_success 'bundle should be able to create a full history' '
--
1.6.4.151.g786db
^ permalink raw reply related
* Re: [ANNOUNCE] tortoisegit 0.9.1.0
From: Frank Li @ 2009-08-08 3:31 UTC (permalink / raw)
To: Sverre Rabbelier
Cc: John Tapsell, Johannes Schindelin, Tim Harper, git,
tortoisegit-dev, tortoisegit-users, tortoisegit-announce,
tortoisegit
In-Reply-To: <fabb9a1e0908070924gda3fb09k21d5585083a4c6c1@mail.gmail.com>
TortoiseGit.DLL that explorer plug-in is not biggest problem.
The biggest problem is TortoiseProc.exe, which is inclued all GUI,
such commit, diff, log view...
TortoiseGit.Dll just launch TortoiseProc.exe to do actuall operation.
git-cheetah just is equal TortoiseGit.DLL.
2009/8/8 Sverre Rabbelier <srabbelier@gmail.com>:
> Heya,
>
> On Thu, Aug 6, 2009 at 23:48, John Tapsell<johnflux@gmail.com> wrote:
>> How hard would it be to port this to KDE?
>
> Impossible.
>
>> What would be involved?
>
> Port all Windows specific code; instead, you should have a look at
> git-cheetah, which aims to do the same thing, only platform agnostic.
>
> --
> Cheers,
>
> Sverre Rabbelier
>
^ permalink raw reply
* Re: [PATCH 0/5] Suggested for PU: revision caching system to significantly speed up packing/walking
From: Junio C Hamano @ 2009-08-08 3:11 UTC (permalink / raw)
To: Nick Edelen
Cc: Nicolas Pitre, Johannes Schindelin, Sam Vilain, Michael J Gruber,
Jeff King, Shawn O. Pearce, Andreas Ericsson, Christian Couder,
git@vger.kernel.org
In-Reply-To: <c77435a80908071553m6f7d5298p5ea68b9386198b3f@mail.gmail.com>
Nick Edelen <sirnot@gmail.com> writes:
> By the way, what would be the best way of posting a revised patchset?
> Should I just reply to my older posts, or make new ones?
That depends primarily on how heavily the patches needed to change in
response to review comments, but until the series lands in 'next', you
would typically send updated series as a replacement, not incremental.
Many people seemed to be interested in the series and had a volume of
comments on it. I suspect the updated series would be quite different
from the original, so for the next round I would suspect it would be best
to start anew, marking them as [PATCH N/M (v2)], in a fresh thread. It
would help reviewers if you said "this corresponds to [PATCH 3/5] in the
original series, with the following improvements based on X and Y's
comments" after the three-dash line.
^ permalink raw reply
* Re: [PATCH 0/5] Suggested for PU: revision caching system to significantly speed up packing/walking
From: Jeff King @ 2009-08-08 2:50 UTC (permalink / raw)
To: Nick Edelen
Cc: Junio C Hamano, Nicolas Pitre, Johannes Schindelin, Sam Vilain,
Michael J Gruber, Shawn O. Pearce, Andreas Ericsson,
Christian Couder, git@vger.kernel.org
In-Reply-To: <7vzlabp7e4.fsf@alter.siamese.dyndns.org>
On Fri, Aug 07, 2009 at 03:48:51PM -0700, Junio C Hamano wrote:
> > The cache file for all of the linux repository (as of a few weeks ago)
> > is around 42MB, without names. The names would probably add 2 or 3 MB
> > on top of that. That's probably about as big as I'd want to get,
>
> Hmm. .git/objects/ as of today is about 482M here, so we are talking
> about roughly 10% overhead?
IIRC from previous discussions, kernel.org's main performance problem is
I/O, not CPU. Are there any provisions for sharing rev-caches between
similar repositories, as we already do for objects?
-Peff
^ permalink raw reply
* Re: git gc expanding packed data?
From: Andreas Schwab @ 2009-08-08 1:11 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Hin-Tak Leung, git
Nicolas Pitre <nico@cam.org> writes:
> It appears that the git installation serving clone requests for
> git://gcc.gnu.org/git/gcc.git generates lots of unreferenced objects. I
> just cloned it and the pack I was sent contains 1383356 objects (can be
> determined with 'git show-index < .git/objects/pack/*.idx | wc -l').
> However, there are only 978501 actually referenced objects in that
> cloned repository ( 'git rev-list --all --objects | wc -l'). That makes
> for 404855 useless objects in the cloned repository.
Those objects are not useless. They are referenced by the remote refs
on the remote side, which are not fetched by default. If you clone a
mirror of the repository you'll see no unreferenced objects.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* git ssl error
From: Caleb Adam Haye @ 2009-08-08 0:45 UTC (permalink / raw)
To: git
I'm having trouble using git over SSL.
git clone https://myserver.com/git/my-project.git
Initialized empty Git repository in /Users/username/my-project/.git/
fatal: https://myserver.com/git/my-project.git/info/refs download
error - SSL certificate problem, verify that the CA cert is OK.
Details:
error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate
verify failed
The SSL Checker (http://www.sslshopper.com/ssl-checker.html) seems to
think everying is fine w/ the SSL config.
I think the problem is that I need to install the ca-certificates
locally, but i think i have done that... not sure if it's done
correctly though
Please help
--
Caleb Adam Haye
caleb@firecollective.com
The information contained in this message is confidential and intended
only for the use of the individual or entity named above, and may be
privileged. Any unauthorized review, use, disclosure, or distribution
is prohibited. If you are not the intended recipient, please reply to
the sender immediately, stating that you have received the message in
error, then please delete this e-mail. Thank you.
^ permalink raw reply
* Re: [PATCH 0/5] Suggested for PU: revision caching system to significantly speed up packing/walking
From: Nick Edelen @ 2009-08-07 22:53 UTC (permalink / raw)
To: Junio C Hamano
Cc: Nicolas Pitre, Johannes Schindelin, Sam Vilain, Michael J Gruber,
Jeff King, Shawn O. Pearce, Andreas Ericsson, Christian Couder,
git@vger.kernel.org
In-Reply-To: <7vzlabp7e4.fsf@alter.siamese.dyndns.org>
> Hmm. .git/objects/ as of today is about 482M here, so we are talking
> about roughly 10% overhead?
Yes, that sounds about right. The cache file for git's repository is
3MB, and my repo (partly packed) is ~35MB.
By the way, what would be the best way of posting a revised patchset?
Should I just reply to my older posts, or make new ones?
^ permalink raw reply
* Re: [PATCH 0/5] Suggested for PU: revision caching system to significantly speed up packing/walking
From: Junio C Hamano @ 2009-08-07 22:48 UTC (permalink / raw)
To: Nick Edelen
Cc: Nicolas Pitre, Johannes Schindelin, Sam Vilain, Michael J Gruber,
Junio C Hamano, Jeff King, Shawn O. Pearce, Andreas Ericsson,
Christian Couder, git@vger.kernel.org
In-Reply-To: <c77435a80908071502y48d14a38h79eec14a1be8c6fb@mail.gmail.com>
Nick Edelen <sirnot@gmail.com> writes:
> The cache file for all of the linux repository (as of a few weeks ago)
> is around 42MB, without names. The names would probably add 2 or 3 MB
> on top of that. That's probably about as big as I'd want to get,
Hmm. .git/objects/ as of today is about 482M here, so we are talking
about roughly 10% overhead?
^ permalink raw reply
* Re: [PATCH 0/5] Suggested for PU: revision caching system to significantly speed up packing/walking
From: Nick Edelen @ 2009-08-07 22:02 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Johannes Schindelin, Sam Vilain, Michael J Gruber, Junio C Hamano,
Jeff King, Shawn O. Pearce, Andreas Ericsson, Christian Couder,
git@vger.kernel.org
In-Reply-To: <alpine.LFD.2.00.0908071029580.16073@xanadu.home>
> I don't know about the size of the rev cache on disk yet (I asked Nick
> about that) nor do I really know how this cache is implemented.
The cache file for all of the linux repository (as of a few weeks ago)
is around 42MB, without names. The names would probably add 2 or 3 MB
on top of that. That's probably about as big as I'd want to get, as
the whole slice (minus the name list) is mapped to memory (then again
bigger might be ok; I'm not an expert on mem mapping). The rev-cache
command fuse provides functionality to ignore certain cache sizes,
which was geared towards preventing overly large slices.
^ permalink raw reply
* Re: [PATCH 1/5] revision caching documentation: man page and technical discussion
From: Sam Vilain @ 2009-08-07 21:58 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Rogan Dawes, Nick Edelen, Junio C Hamano, Jeff King,
Shawn O. Pearce, Andreas Ericsson, Christian Couder,
git@vger.kernel.org
In-Reply-To: <alpine.DEB.1.00.0908071419590.8306@pacific.mpi-cbg.de>
On Fri, 2009-08-07 at 14:20 +0200, Johannes Schindelin wrote:
> > I think the word he had in mind was "coalesce".
> As Git users typically have a quite good idea what a "merge" is, I'd
> prefer that word anyway.
I don't like that so much, given that "merge" has quite a specific
meaning. But not really that fussed. In this case it's more like a
'gc' or 'repack'; an internal reshuffle of an index to make it a single
one and not many.
Sam
^ permalink raw reply
* Re: [PATCH] Make 'submodule update' honor the 'update' setting in .gitmodules.
From: Junio C Hamano @ 2009-08-07 21:54 UTC (permalink / raw)
To: Mikhail Glushenkov; +Cc: git
In-Reply-To: <1249530977-17501-1-git-send-email-foldr@codedgers.com>
Mikhail Glushenkov <foldr@codedgers.com> writes:
> Make the 'submodule update' command honor the 'submodule.$path.update' setting
> in .gitmodules unless this setting is overridden in '.git/config' or with
> --rebase/--merge options.
I haven't been involved in recent updates to "git submodule", but the
change in this patch feels somewhat wrong.
The contents of in-tree .gitmodules are meant to be consulted to only
prime the settings in .git/config, and after that they are never used
without user's explicit concent (e.g. "sync"). At least that is the way I
understand how the current "git submodule" command is designed.
This change actively breaks the pattern. It makes sense to set up values
for "submodule.*.update" when the defaults suggested by the project are
copied out of .gitmodules to prime .git/config upon "submodule init", but
not at runtime in "update" command like this.
I am puzzled. What problem are you trying to solve?
"submodule init" seems to already copy "update" setting from .gitmodules
to .git/config. At least, it seems to have a code to try to do so.
Perhaps you would want to (1) add the "submodule.*.update" to the set of
configurations to be copied upon "sync", not just URL? and (2) add a way
to allow users to inspect how values in .git/config and .gitmodules are
different, and update .git/config with selected values, possibly in an
interactive manner?
^ permalink raw reply
* Re: Problem compiling git-1.6.4 on OpenServer 6.0
From: Brandon Casey @ 2009-08-07 21:36 UTC (permalink / raw)
To: Boyd Lynn Gerber; +Cc: Git List
In-Reply-To: <alpine.LNX.2.00.0908071523550.13290@suse104.zenez.com>
Boyd Lynn Gerber wrote:
> On Fri, 7 Aug 2009, Brandon Casey wrote:
>> Boyd Lynn Gerber wrote:
>>> I just tried to compile the latest git and I get this error.
>>>
>>> CC builtin-pack-objects.o
>>> UX:acomp: ERROR: "builtin-pack-objects.c", line 1602: integral constant
>>> expression expected
>>> gmake: *** [builtin-pack-objects.o] Error 1
>>>
>>> I will look into it when I have a bit more time, but this is a heads up.
>>
>> Did you set THREADED_DELTA_SEARCH=1 when you compiled? That could be the
>> problem.
>>
>> Line 1602 of builtin-pack-objects.c is wrapped in #ifdef
>> THREADED_DELTA_SEARCH,
>> so it is only compiled if THREADED_DELTA_SEARCH has been set. Also,
>> it's not
>> a new line, it has been around since 2007.
>
> Removing it and the -pthread allows it to build. I am now running the
> tests. The I need to find out why it is being set.
Did you run configure? which generates a config.mak.autogen file?
There were some changes related to pthreads in configure.ac in March,
and another back in Nov 2008. Specifically commits 1973b0d7, and
d937c374.
-brandon
^ permalink raw reply
* Re: Problem compiling git-1.6.4 on OpenServer 6.0
From: Boyd Lynn Gerber @ 2009-08-07 21:25 UTC (permalink / raw)
To: Brandon Casey; +Cc: Git List
In-Reply-To: <cY-iS6BS6knyjPKeVQI3ZIsIw3A3y5VK1oW-MNzUUztRn8CbeqRdew@cipher.nrlssc.navy.mil>
On Fri, 7 Aug 2009, Brandon Casey wrote:
> Boyd Lynn Gerber wrote:
>> I just tried to compile the latest git and I get this error.
>>
>> CC builtin-pack-objects.o
>> UX:acomp: ERROR: "builtin-pack-objects.c", line 1602: integral constant
>> expression expected
>> gmake: *** [builtin-pack-objects.o] Error 1
>>
>> I will look into it when I have a bit more time, but this is a heads up.
>
> Did you set THREADED_DELTA_SEARCH=1 when you compiled? That could be the
> problem.
>
> Line 1602 of builtin-pack-objects.c is wrapped in #ifdef THREADED_DELTA_SEARCH,
> so it is only compiled if THREADED_DELTA_SEARCH has been set. Also, it's not
> a new line, it has been around since 2007.
Removing it and the -pthread allows it to build. I am now running the
tests. The I need to find out why it is being set.
Thanks,
--
Boyd Gerber <gerberb@zenez.com> 801 849-0213
ZENEZ 1042 East Fort Union #135, Midvale Utah 84047
^ permalink raw reply
* Re: [PATCH 2/2 (v2)] reset: make the output more user-friendly.
From: Junio C Hamano @ 2009-08-07 21:20 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <1249676676-5051-2-git-send-email-Matthieu.Moy@imag.fr>
Matthieu Moy <Matthieu.Moy@imag.fr> writes:
> cat > expect << EOF
> -file2: locally modified
> +Unstaged changes after reset:
> +M file2
It simply feels backwards when plumbing output says something in human
language (e.g. "needs update") while Porcelain output spits out a cryptic
M or U. If the goal is human-readability and user-friendliness, shouldn't
we rather say:
Path with local modifications:
file2
or something?
^ permalink raw reply
* Re: Problem compiling git-1.6.4 on OpenServer 6.0
From: Boyd Lynn Gerber @ 2009-08-07 21:15 UTC (permalink / raw)
To: Brandon Casey; +Cc: Git List
In-Reply-To: <cY-iS6BS6knyjPKeVQI3ZIsIw3A3y5VK1oW-MNzUUztRn8CbeqRdew@cipher.nrlssc.navy.mil>
On Fri, 7 Aug 2009, Brandon Casey wrote:
> Boyd Lynn Gerber wrote:
>>
>> I just tried to compile the latest git and I get this error.
>>
>> CC builtin-pack-objects.o
>> UX:acomp: ERROR: "builtin-pack-objects.c",
>> line 1602: integral constant expression expected gmake: ***
>> [builtin-pack-objects.o] Error 1
>>
>> I will look into it when I have a bit more time, but this is a heads up.
>
> Did you set THREADED_DELTA_SEARCH=1 when you compiled? That could be
> the problem.
>
> Line 1602 of builtin-pack-objects.c is wrapped in #ifdef THREADED_DELTA_SEARCH,
> so it is only compiled if THREADED_DELTA_SEARCH has been set. Also, it's not
> a new line, it has been around since 2007.
Yes, that is the problem it was set. The OS has kernel threads and all
must be accessed by -Kthread and no -pthread when linking.
Thanks for the hnt...
--
Boyd Gerber <gerberb@zenez.com> 801 849-0213
ZENEZ 1042 East Fort Union #135, Midvale Utah 84047
^ permalink raw reply
* Re: Problem compiling git-1.6.4 on OpenServer 6.0
From: Brandon Casey @ 2009-08-07 20:53 UTC (permalink / raw)
To: Boyd Lynn Gerber; +Cc: Git List
In-Reply-To: <alpine.LNX.2.00.0908071326250.13290@suse104.zenez.com>
Boyd Lynn Gerber wrote:
> Hello,
>
> I just tried to compile the latest git and I get this error.
>
> CC builtin-pack-objects.o
> UX:acomp: ERROR: "builtin-pack-objects.c", line 1602: integral constant
> expression expected
> gmake: *** [builtin-pack-objects.o] Error 1
>
> I will look into it when I have a bit more time, but this is a heads up.
Did you set THREADED_DELTA_SEARCH=1 when you compiled? That could be the
problem.
Line 1602 of builtin-pack-objects.c is wrapped in #ifdef THREADED_DELTA_SEARCH,
so it is only compiled if THREADED_DELTA_SEARCH has been set. Also, it's not
a new line, it has been around since 2007.
-brandon
^ permalink raw reply
* [PATCH 2/4] sequencer: add "--fast-forward" option to "git sequencer--helper"
From: Christian Couder @ 2009-08-07 20:40 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Johannes Schindelin, Stephan Beyer, Daniel Barkalow,
Jakub Narebski
This new option uses the "do_fast_forward()" function to perform
a fast forward.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
builtin-sequencer--helper.c | 16 ++++++++++++----
1 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/builtin-sequencer--helper.c b/builtin-sequencer--helper.c
index 0cd7e98..bd72f65 100644
--- a/builtin-sequencer--helper.c
+++ b/builtin-sequencer--helper.c
@@ -19,6 +19,7 @@ static unsigned char head_sha1[20];
static const char * const git_sequencer_helper_usage[] = {
"git sequencer--helper --make-patch <commit>",
"git sequencer--helper --reset-hard <commit> <reflog-msg> <verbosity>",
+ "git sequencer--helper --fast-forward <commit> <reflog-msg> <verbosity>",
NULL
};
@@ -218,11 +219,14 @@ int cmd_sequencer__helper(int argc, const char **argv, const char *prefix)
{
char *patch_commit = NULL;
char *reset_commit = NULL;
+ char *ff_commit = NULL;
struct option options[] = {
OPT_STRING(0, "make-patch", &patch_commit, "commit",
"create a patch from commit"),
OPT_STRING(0, "reset-hard", &reset_commit, "commit",
"reset to commit"),
+ OPT_STRING(0, "fast-forward", &ff_commit, "commit",
+ "fast forward to commit"),
OPT_END()
};
@@ -239,15 +243,16 @@ int cmd_sequencer__helper(int argc, const char **argv, const char *prefix)
return 0;
}
- if (reset_commit) {
+ if (ff_commit || reset_commit) {
unsigned char sha1[20];
+ char *commit = ff_commit ? ff_commit : reset_commit;
if (argc != 2)
usage_with_options(git_sequencer_helper_usage,
options);
- if (get_sha1(reset_commit, sha1)) {
- error("Could not find '%s'", reset_commit);
+ if (get_sha1(commit, sha1)) {
+ error("Could not find '%s'", commit);
return 1;
}
@@ -258,7 +263,10 @@ int cmd_sequencer__helper(int argc, const char **argv, const char *prefix)
return 1;
}
- return reset_almost_hard(sha1);
+ if (ff_commit)
+ return do_fast_forward(sha1);
+ else
+ return reset_almost_hard(sha1);
}
usage_with_options(git_sequencer_helper_usage, options);
--
1.6.4.209.g16b77
^ permalink raw reply related
* [PATCH 1/4] sequencer: add "do_fast_forward()" to perform a fast forward
From: Christian Couder @ 2009-08-07 20:40 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Johannes Schindelin, Stephan Beyer, Daniel Barkalow,
Jakub Narebski
From: Stephan Beyer <s-beyer@gmx.net>
This code is taken from the sequencer GSoC project:
git://repo.or.cz/git/sbeyer.git
(commit e7b8dab0c2a73ade92017a52bb1405ea1534ef20)
but the messages have been changed to be the same as those
displayed by git-rebase--interactive.sh.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
builtin-sequencer--helper.c | 9 +++++++++
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/builtin-sequencer--helper.c b/builtin-sequencer--helper.c
index be030bc..0cd7e98 100644
--- a/builtin-sequencer--helper.c
+++ b/builtin-sequencer--helper.c
@@ -171,6 +171,15 @@ static struct commit *get_commit(const char *arg)
return lookup_commit_reference(sha1);
}
+static int do_fast_forward(const unsigned char *sha)
+{
+ if (reset_almost_hard(sha))
+ return error("Cannot fast forward to %s", sha1_to_hex(sha));
+ if (verbosity > 1)
+ printf("Fast forward to %s\n", sha1_to_hex(sha));
+ return 0;
+}
+
static int set_verbosity(int verbose)
{
char tmp[] = "0";
--
1.6.4.209.g16b77
^ permalink raw reply related
* [PATCH 4/4] rebase -i: use "git sequencer--helper --fast-forward"
From: Christian Couder @ 2009-08-07 20:40 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Johannes Schindelin, Stephan Beyer, Daniel Barkalow,
Jakub Narebski
when fast forwarding.
Note that in the first hunk of this patch, there was this line:
test "a$1" = a-n && output git reset --soft $current_sha1
but the test always failed.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
The test "a$1" = a-n fails because if "$1" is set to "-n"
then "$no_ff" is set to "t" above by:
case "$1" in -n) sha1=$2; no_ff=t ;; *) sha1=$1 ;; esac
and that means that:
test "$no_ff$current_sha1" = "$parent_sha1"
will fail.
But maybe I missed something. Otherwise I can send a patch
for master to remove the dead code.
git-rebase--interactive.sh | 11 +++--------
1 files changed, 3 insertions(+), 8 deletions(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index 0041994..7651fd6 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -154,11 +154,8 @@ pick_one () {
die "Could not get the parent of $sha1"
current_sha1=$(git rev-parse --verify HEAD)
if test "$no_ff$current_sha1" = "$parent_sha1"; then
- git sequencer--helper --reset-hard $sha1 \
+ git sequencer--helper --fast-forward $sha1 \
"$GIT_REFLOG_ACTION" "$VERBOSE"
- test "a$1" = a-n && output git reset --soft $current_sha1
- sha1=$(git rev-parse --short $sha1)
- output warn Fast forward to $sha1
else
output git cherry-pick "$@"
fi
@@ -238,10 +235,8 @@ pick_one_preserving_merges () {
done
case $fast_forward in
t)
- output warn "Fast forward to $sha1"
- git sequencer--helper --reset-hard $sha1 \
- "$GIT_REFLOG_ACTION" "$VERBOSE" ||
- die "Cannot fast forward to $sha1"
+ git sequencer--helper --fast-forward $sha1 \
+ "$GIT_REFLOG_ACTION" "$VERBOSE" || exit
;;
f)
first_parent=$(expr "$new_parents" : ' \([^ ]*\)')
--
1.6.4.209.g16b77
^ permalink raw reply related
* [PATCH 3/4] sequencer: let "git sequencer--helper" callers set "allow_dirty"
From: Christian Couder @ 2009-08-07 20:40 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Johannes Schindelin, Stephan Beyer, Daniel Barkalow,
Jakub Narebski
This flag can be set when using --reset-hard or --fast-forward, and
in this case changes in the work tree will be kept.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
builtin-sequencer--helper.c | 11 ++++++++---
1 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/builtin-sequencer--helper.c b/builtin-sequencer--helper.c
index bd72f65..71a7fef 100644
--- a/builtin-sequencer--helper.c
+++ b/builtin-sequencer--helper.c
@@ -18,8 +18,10 @@ static unsigned char head_sha1[20];
static const char * const git_sequencer_helper_usage[] = {
"git sequencer--helper --make-patch <commit>",
- "git sequencer--helper --reset-hard <commit> <reflog-msg> <verbosity>",
- "git sequencer--helper --fast-forward <commit> <reflog-msg> <verbosity>",
+ "git sequencer--helper --reset-hard <commit> <reflog-msg> "
+ "<verbosity> [<allow-dirty>]",
+ "git sequencer--helper --fast-forward <commit> <reflog-msg> "
+ "<verbosity> [<allow-dirty>]",
NULL
};
@@ -247,7 +249,7 @@ int cmd_sequencer__helper(int argc, const char **argv, const char *prefix)
unsigned char sha1[20];
char *commit = ff_commit ? ff_commit : reset_commit;
- if (argc != 2)
+ if (argc != 2 && argc != 3)
usage_with_options(git_sequencer_helper_usage,
options);
@@ -263,6 +265,9 @@ int cmd_sequencer__helper(int argc, const char **argv, const char *prefix)
return 1;
}
+ if (argc == 3 && *argv[2] && strcmp(argv[2], "0"))
+ allow_dirty = 1;
+
if (ff_commit)
return do_fast_forward(sha1);
else
--
1.6.4.209.g16b77
^ permalink raw reply related
* Re: [PATCH] gitweb: parse_commit_text encoding fix
From: Jakub Narebski @ 2009-08-07 20:31 UTC (permalink / raw)
To: Zoltán Füzesi; +Cc: Junio C Hamano, git
In-Reply-To: <9ab80d150908060115q4b56b2e5xb327e09cda7e2b7a@mail.gmail.com>
On Thu, 6 Aug 2009, Zoltán Füzesi wrote:
> 2009/8/4 Junio C Hamano <gitster@pobox.com>:
> >
> > Thanks, Zoltán.
> >
> > We should be able to set up a script that scrapes the output to test this
> > kind of thing. We may not want to have a test pattern that matches too
> > strictly for the current structure and appearance of the output
> > (e.g. counting nested <div>s, presentation styles and such), but if we can
> > robustly scrape off HTML tags (e.g. "elinks -dump") and check the
> > remaining payload, it might be enough.
> >
> > Jakub what do you think? I suspect that scraping approach may turn out to
> > be too fragile for tests to be worth doing, but I am just throwing out a
> > thought.
> >
>
> This issue comes out when chop_and_escape_str function is called with
> a non-ascii string (like my name :)) without before calling to_utf8 on
> it. "author_name" and "committer_name" are two examples, and
> "author_name" shows up with bad encoding in HTML.
>
> Example from one of my repos (little piece from shortlog output):
> <td class="author"><span title="Füzesi Zoltán">Füzesi Zoltán</span></td>
> After applying the patch:
> <td class="author">Füzesi Zoltán</td>
>
> This is an "old" (seen in 1.5.6 version too) and (I think) minor issue.
> I haven't spent time on thinking how a test script could show this yet.
> Waiting for Jakub's reaction.
Oh, so the problem is not only to just have correct output (for example
"Füzesi Zoltán" somewhere on HTML page produced by gitweb), but also do
not have incorrect output (for example "Füzesi Zoltán").
I think it would be better to leave t9500-gitweb-standalone-no-errors.sh
to be only about no Perl errors and no Perl warnings. So I'd rather
have test checking if gitweb handles non US-ASCII in output correctly
in a separate test, e.g. t9501-gitweb-standalone-i18n.sh. That would
mean extracting gitweb_init() and gitweb_run() (and perhaps also
gitweb_check_prereq() or something) into common file t/lib-gitweb.sh
We would check e.g. if "startáąend" is present in output (correct output),
and whether extracting "start[^ ]*end" produces only "startáąend" (no
incorrect output).
As for gitweb, we should make sure that everything is stored in Perl
variables and Perl structures _after_ treating with to_utf8(). This
would require some cleanup of the code, and having such test would
help to check if we didn't introduce any regressions.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] push: point to 'git pull' and 'git push --force' in case of non-fast forward
From: Matthieu Moy @ 2009-08-07 20:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vd477v17r.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> I actually do not think it is appropriate to teach --force in an example
> that involves more than one person (iow, in the context of the example in
> my patch).
Right, that is the point. A more accurate example would be "oops, I
rewrote history after a push, shall I still push it?". But your
proposal is already long, let's not over-document it.
--
Matthieu
^ permalink raw reply
* [PATCH 1/2] Rename REFRESH_SAY_CHANGED to REFRESH_IN_PORCELAIN.
From: Matthieu Moy @ 2009-08-07 20:24 UTC (permalink / raw)
To: git, gitster; +Cc: Matthieu Moy
In-Reply-To: <7vvdl0kau4.fsf@alter.siamese.dyndns.org>
The change in the output is going to become more general than just saying
"changed", so let's make the variable name more general too.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
---
builtin-add.c | 2 +-
builtin-reset.c | 4 ++--
cache.h | 2 +-
read-cache.c | 2 +-
4 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/builtin-add.c b/builtin-add.c
index 581a2a1..a325bc9 100644
--- a/builtin-add.c
+++ b/builtin-add.c
@@ -105,7 +105,7 @@ static void refresh(int verbose, const char **pathspec)
for (specs = 0; pathspec[specs]; specs++)
/* nothing */;
seen = xcalloc(specs, 1);
- refresh_index(&the_index, verbose ? REFRESH_SAY_CHANGED : REFRESH_QUIET,
+ refresh_index(&the_index, verbose ? REFRESH_IN_PORCELAIN : REFRESH_QUIET,
pathspec, seen);
for (i = 0; i < specs; i++) {
if (!seen[i])
diff --git a/builtin-reset.c b/builtin-reset.c
index 5fa1789..ddf68d5 100644
--- a/builtin-reset.c
+++ b/builtin-reset.c
@@ -261,7 +261,7 @@ int cmd_reset(int argc, const char **argv, const char *prefix)
die("Cannot do %s reset with paths.",
reset_type_names[reset_type]);
return read_from_tree(prefix, argv + i, sha1,
- quiet ? REFRESH_QUIET : REFRESH_SAY_CHANGED);
+ quiet ? REFRESH_QUIET : REFRESH_IN_PORCELAIN);
}
if (reset_type == NONE)
reset_type = MIXED; /* by default */
@@ -302,7 +302,7 @@ int cmd_reset(int argc, const char **argv, const char *prefix)
break;
case MIXED: /* Report what has not been updated. */
update_index_refresh(0, NULL,
- quiet ? REFRESH_QUIET : REFRESH_SAY_CHANGED);
+ quiet ? REFRESH_QUIET : REFRESH_IN_PORCELAIN);
break;
}
diff --git a/cache.h b/cache.h
index e6c7f33..a2f2923 100644
--- a/cache.h
+++ b/cache.h
@@ -473,7 +473,7 @@ extern void fill_stat_cache_info(struct cache_entry *ce, struct stat *st);
#define REFRESH_QUIET 0x0004 /* be quiet about it */
#define REFRESH_IGNORE_MISSING 0x0008 /* ignore non-existent */
#define REFRESH_IGNORE_SUBMODULES 0x0010 /* ignore submodules */
-#define REFRESH_SAY_CHANGED 0x0020 /* say "changed" not "needs update" */
+#define REFRESH_IN_PORCELAIN 0x0020 /* user friendly output, not "needs update" */
extern int refresh_index(struct index_state *, unsigned int flags, const char **pathspec, char *seen);
struct lock_file {
diff --git a/read-cache.c b/read-cache.c
index 4e3e272..f1aff81 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -1077,7 +1077,7 @@ int refresh_index(struct index_state *istate, unsigned int flags, const char **p
unsigned int options = really ? CE_MATCH_IGNORE_VALID : 0;
const char *needs_update_message;
- needs_update_message = ((flags & REFRESH_SAY_CHANGED)
+ needs_update_message = ((flags & REFRESH_IN_PORCELAIN)
? "locally modified" : "needs update");
for (i = 0; i < istate->cache_nr; i++) {
struct cache_entry *ce, *new;
--
1.6.4.62.g39c83.dirty
^ 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