* Re: git hang with corrupted .pack
From: Sverre Rabbelier @ 2009-10-20 15:23 UTC (permalink / raw)
To: Alex Riesen
Cc: Junio C Hamano, Nicolas Pitre, Shawn O. Pearce, Andy Isaacson,
git
In-Reply-To: <81b0412b0910200814v269e91fbkd7841308685e1c54@mail.gmail.com>
Heya,
On Tue, Oct 20, 2009 at 10:14, Alex Riesen <raa.lkml@gmail.com> wrote:
> - buffer = xmalloc(size + 1);
> + buffer = xmalloc(size + 8);
> - stream.avail_out = size;
> + stream.avail_out = size + 8;
That seems wrong at first glance, you go from '+1' to '+8' on the
first part, and then from '+0' to '+8' in the second part, am I
missing something obvious?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: git hang with corrupted .pack
From: Alex Riesen @ 2009-10-20 15:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nicolas Pitre, Shawn O. Pearce, Andy Isaacson, git
In-Reply-To: <7vbpk985t1.fsf@alter.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 1963 bytes --]
On Thu, Oct 15, 2009 at 09:39, Junio C Hamano <gitster@pobox.com> wrote:
> Nicolas Pitre <nico@fluxnic.net> writes:
>
>> I confirm this test without the fix reproduces the infinite loop (and
>> does stall the test suite).
>
> Thanks, both of you.
I seem to have problems with this change (on Cygwin). Sometimes
accessing an object in a pack fails in unpack_compressed_entry.
When it happens, both avail_in and avail_out of the stream are 0,
and the reported status is Z_BUF_ERROR.
Output with the second attached patch:
error: *** inflate error: 0x862380 size=1256, avail_in=0 (was 697),
avail_out=0 (was 1256)
error: *** unpack_compressed_entry failed
error: failed to read object 3296766eb5531ef051ae392114de5d75556f5613
at offset 2620741 from
.git/objects/pack/pack-996206790aaefbf4d34c86b3ff546bb924546b7c.pack
fatal: object 3296766eb5531ef051ae392114de5d75556f5613 is corrupted
I cannot reproduce the problem on a normal system (a 64bit, reasonably modern
Linux in my case). An attempt to use an upgraded zlib on this cygwin system was
not successful, there was an updated library, but a clean recompile didn't
change anything.
I worked the case around by allocating a bit more than uncompressed data need.
In case someone else also sees the problem, below is how. The size of the
overallocation is arbitrary.
diff --git a/sha1_file.c b/sha1_file.c
index 4cc8939..66c2519 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -1585,11 +1585,11 @@ static void *unpack_compressed_entry(struct
packed_git *p,
z_stream stream;
unsigned char *buffer, *in;
- buffer = xmalloc(size + 1);
- buffer[size] = 0;
+ buffer = xmalloc(size + 8);
+ memset(buffer + size, 0, 8);
memset(&stream, 0, sizeof(stream));
stream.next_out = buffer;
- stream.avail_out = size;
+ stream.avail_out = size + 8;
git_inflate_init(&stream);
do {
--
1.6.5.59.g000dd
The problematic repo is a little big to post (it's my cygwin-git repo),
I'll have to find hosting for it first.
[-- Attachment #2: 0001-Workaround-inflate-sometimes-failing-to-unpack-data.diff --]
[-- Type: application/octet-stream, Size: 1341 bytes --]
From 643fdf50e4343c3ce3a4b99183dba8d35a10c877 Mon Sep 17 00:00:00 2001
From: Alex Riesen <raa.lkml@gmail.com>
Date: Tue, 20 Oct 2009 16:42:26 +0200
Subject: [PATCH 1/2] Workaround inflate sometimes fails to unpack data
When it happens, zlib stream's avail_in and avail_out are 0, the returned
status is Z_BUF_ERROR. The values weren't 0 before calling inflate.
error: *** inflate error: 0x862380 size=1256, avail_in=0 (was 697), avail_out=0 (was 1256)
error: *** unpack_compressed_entry failed
error: failed to read object 3296766eb5531ef051ae392114de5d75556f5613 at offset 2620741 from .git/objects/pack/pack-996206790aaefbf4d34c86b3ff546bb924546b7c.pack
fatal: object 3296766eb5531ef051ae392114de5d75556f5613 is corrupted
---
sha1_file.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/sha1_file.c b/sha1_file.c
index 4cc8939..66c2519 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -1585,11 +1585,11 @@ static void *unpack_compressed_entry(struct packed_git *p,
z_stream stream;
unsigned char *buffer, *in;
- buffer = xmalloc(size + 1);
- buffer[size] = 0;
+ buffer = xmalloc(size + 8);
+ memset(buffer + size, 0, 8);
memset(&stream, 0, sizeof(stream));
stream.next_out = buffer;
- stream.avail_out = size;
+ stream.avail_out = size + 8;
git_inflate_init(&stream);
do {
--
1.6.5.59.g000dd
[-- Attachment #3: 0002-Debugging-strange-failure-in-zlibs-inflate.diff --]
[-- Type: application/octet-stream, Size: 1910 bytes --]
From fc5b47d953f171d7591349acad9a23d3ec683ce9 Mon Sep 17 00:00:00 2001
From: Alex Riesen <raa.lkml@gmail.com>
Date: Tue, 20 Oct 2009 15:53:33 +0200
Subject: [PATCH 2/2] Debugging strange failure in zlibs inflate
---
sha1_file.c | 18 ++++++++++++++++++
1 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/sha1_file.c b/sha1_file.c
index 66c2519..1bf240e 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -1594,10 +1594,24 @@ static void *unpack_compressed_entry(struct packed_git *p,
git_inflate_init(&stream);
do {
in = use_pack(p, w_curs, curpos, &stream.avail_in);
+ unsigned prev_ain = stream.avail_in;
+ unsigned prev_aout = stream.avail_out;
+ if (!stream.avail_in)
+ error("*** avail_in=0, inflate will fail!");
+ if (!stream.avail_out)
+ error("*** avail_out=0, inflate will fail!");
stream.next_in = in;
st = git_inflate(&stream, Z_FINISH);
if (st == Z_BUF_ERROR && (stream.avail_in || !stream.avail_out))
+ {
+ error("*** inflate error: %p size=%lu, "
+ "avail_in=%d (was %u), "
+ "avail_out=%d (was %u)",
+ buffer, size,
+ stream.avail_in, prev_ain,
+ stream.avail_out, prev_aout);
break;
+ }
curpos += stream.next_in - in;
} while (st == Z_OK || st == Z_BUF_ERROR);
git_inflate_end(&stream);
@@ -1654,6 +1668,8 @@ static void *cache_or_unpack_entry(struct packed_git *p, off_t base_offset,
delta_base_cached -= ent->size;
} else {
ret = xmemdupz(ent->data, ent->size);
+ if (!ret)
+ fprintf(stderr, "*** no memory\n");
}
*type = ent->type;
*base_size = ent->size;
@@ -1815,6 +1831,8 @@ void *unpack_entry(struct packed_git *p, off_t obj_offset,
case OBJ_BLOB:
case OBJ_TAG:
data = unpack_compressed_entry(p, &w_curs, curpos, *sizep);
+ if (!data)
+ error("*** unpack_compressed_entry failed");
break;
default:
data = NULL;
--
1.6.5.59.g000dd
^ permalink raw reply related
* Re: Documentation video for svn-git
From: Wesley J. Landaker @ 2009-10-20 15:04 UTC (permalink / raw)
To: jamesmikedupont@googlemail.com; +Cc: git
In-Reply-To: <ee9cc730910200734t66cfe15emd7314ae443e6ac1c@mail.gmail.com>
On Tuesday 20 October 2009 08:34:21 jamesmikedupont@googlemail.com wrote:
> The purpose is that it will reach more people on youtube,
> and people who are lazy can just listen to the video
> and not everyone has screen reader software available to them at all
> times. I learn alot listening to espeak...
Fair enough. I just wasn't sure if I was missing a huge use case here. =)
^ permalink raw reply
* Update working copy on push without touching several files
From: Alex Amiryan @ 2009-10-20 14:43 UTC (permalink / raw)
To: git
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello. I am a web site developer. My team is developing web sites
locally using git. Online versions of websites are maintained with git
too. I need to have working copy of my remote git repository (online
version of the site) updated by git push (which I do locally). The
problem is that I have some files there (like database config) that have
to be different from local ones and they must not be updated on git
push. I have made "git update-index --assume-unchanged
incs/config.db.php" but they are not being updated only when I do "git
pull" remotely. I have used some post-update hooks which I found on the
net, but they all do "git reset --hard HEAD" which restores my config
files. Can you please help me to write post-update hook which updates
remote working copy but doesn't touch my assume-unchanged marked files.
- --
Alex Amiryan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAkrdzHMACgkQ1KOfm1RDUTH3eQCgsEy+349Q/BnqLyl+6uQcZ871
lZgAn38ZlB4r5Utdt9PbxH/oCCIU2cjM
=2FQ/
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: Documentation video for svn-git
From: jamesmikedupont @ 2009-10-20 14:34 UTC (permalink / raw)
To: Wesley J. Landaker; +Cc: git
In-Reply-To: <200910200820.18986.wjl@icecavern.net>
The purpose is that it will reach more people on youtube,
and people who are lazy can just listen to the video
and not everyone has screen reader software available to them at all times.
I learn alot listening to espeak...
mike
On Tue, Oct 20, 2009 at 4:20 PM, Wesley J. Landaker <wjl@icecavern.net> wrote:
> On Tuesday 20 October 2009 00:30:49 jamesmikedupont@googlemail.com wrote:
>> I have created a computer reading of Sam's svn-git text :
>>
>> http://www.archive.org/details/SvnGitVideo
>>
>> It runs 1.5 hours.
>>
>> I can also do other texts, also the source is checked in to create
>> them yourselves.
>> https://code.launchpad.net/~jamesmikedupont/introspectorreader/wikipedia-
>>strategy
>
> I'm definite fan free software text-to-speech software. (I know espeak when
> I hear it!). But I have to ask: besides being a cool technology demo, what
> is the use case for this? How is this better/different than, for instance,
> just using a screen-reader on-the-fly?
>
^ permalink raw reply
* [PATCH v2] new --dirty option for git describe
From: Jean Privat @ 2009-10-20 14:27 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Shawn O. Pearce
In-Reply-To: <1255800990-7806-1-git-send-email-jean@pryen.org>
With the --dirty option, git describe works on HEAD but append "-dirty"
if the working tree is dirty. If the working tree is clean, nothing
is appended.
$ git describe --dirty
v1.6.5-15-gc274db7
$ echo >> Makefile
$ git describe --dirty
v1.6.5-15-gc274db7-dirty
--dirty can also be used to specify what is append if the working
tree is dirty.
$ git describe --dirty=.mod
v1.6.5-15-gc274db7.mod
Many build scripts use `git describe` to produce a version number based
on the description of HEAD (on which is based the working tree) + saying
that if the working tree is dirty or no.
This patch helps the writing of such scripts since `git describe --dirty`
do directly the intended thing.
Alternatives specifications:
1 Describe the working tree by default and describe HEAD only if "HEAD"
is explicitly specified
Pro: does the right thing by default (both for users and for scripts)
Pro: is coherent with other git commands that works on the working tree
by default
Con: breaks existing scripts (since the world is not ideal)
2 Use --worktree instead of --dirty
Pro: does what it says: "git describe --worktree" will describe the
working three
Con: is incoherent with other commands that do not require a --worktree
option to work on the working tree
Con: unusable with an optional value: "git describe --worktree=.mod"
is quite unintuitive.
3 Use --dirty as in this patch
Pro: make sense to specify an optional value (what the dirty mark is)
Pro: do not have any of the big cons of previous alternatives
* does not break scripts
* is not inconsistent with other git commands
Pro: has an easy fallback to alternative 1 if the world become suddenly
ideal, or at least allows some kind of future transition plan if
people *really* bother:
1- ask that scripts use either "git describe HEAD" or
"git describe --dirty" (no more "git describe")
2- change default
Once the transition is done, the role of the --dirty option will
just be the way to specify an alternative mark (and a noop if alone)
Signed-off-by: Jean Privat <jean@pryen.org>
---
I tried to integrate the points of view of both Junio and Shawn.
However, I am not sure that what I propose is the right solution.
-J-
---
Documentation/git-describe.txt | 6 ++++++
builtin-describe.c | 25 ++++++++++++++++++++++++-
t/t6120-describe.sh | 15 +++++++++++++++
3 files changed, 45 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-describe.txt b/Documentation/git-describe.txt
index b231dbb..5253d86 100644
--- a/Documentation/git-describe.txt
+++ b/Documentation/git-describe.txt
@@ -9,6 +9,7 @@ git-describe - Show the most recent tag that is
reachable from a commit
SYNOPSIS
--------
'git describe' [--all] [--tags] [--contains] [--abbrev=<n>] <committish>...
+'git describe' [--all] [--tags] [--contains] [--abbrev=<n>] --dirty[=<mark>]
DESCRIPTION
-----------
@@ -27,6 +28,11 @@ OPTIONS
<committish>...::
Committish object names to describe.
+--dirty[=<mark>]::
+ Describe the working tree.
+ It means describe HEAD and appends <mark> (`-dirty` by
+ default) if the working tree is dirty.
+
--all::
Instead of using only the annotated tags, use any ref
found in `.git/refs/`. This option enables matching
diff --git a/builtin-describe.c b/builtin-describe.c
index df67a73..84af981 100644
--- a/builtin-describe.c
+++ b/builtin-describe.c
@@ -5,12 +5,14 @@
#include "builtin.h"
#include "exec_cmd.h"
#include "parse-options.h"
+#include "diff.h"
#define SEEN (1u<<0)
#define MAX_TAGS (FLAG_BITS - 1)
static const char * const describe_usage[] = {
"git describe [options] <committish>*",
+ "git describe [options] --dirty",
NULL
};
@@ -23,6 +25,13 @@ static int max_candidates = 10;
static int found_names;
static const char *pattern;
static int always;
+static const char *dirty;
+
+/* diff-index command arguments to check if working tree is dirty. */
+static const char *diff_index_args[] = {
+ "diff-index", "--quiet", "HEAD", "--", NULL
+};
+
struct commit_name {
struct tag *tag;
@@ -208,6 +217,8 @@ static void describe(const char *arg, int last_one)
display_name(n);
if (longformat)
show_suffix(0, n->tag ? n->tag->tagged->sha1 : sha1);
+ if (dirty)
+ printf("%s", dirty);
printf("\n");
return;
}
@@ -265,7 +276,10 @@ static void describe(const char *arg, int last_one)
if (!match_cnt) {
const unsigned char *sha1 = cmit->object.sha1;
if (always) {
- printf("%s\n", find_unique_abbrev(sha1, abbrev));
+ printf("%s", find_unique_abbrev(sha1, abbrev));
+ if (dirty)
+ printf("%s", dirty);
+ printf("\n");
return;
}
die("cannot describe '%s'", sha1_to_hex(sha1));
@@ -300,6 +314,8 @@ static void describe(const char *arg, int last_one)
display_name(all_matches[0].name);
if (abbrev)
show_suffix(all_matches[0].depth, cmit->object.sha1);
+ if (dirty)
+ printf("%s", dirty);
printf("\n");
if (!last_one)
@@ -324,6 +340,9 @@ int cmd_describe(int argc, const char **argv,
const char *prefix)
"only consider tags matching <pattern>"),
OPT_BOOLEAN(0, "always", &always,
"show abbreviated commit object as fallback"),
+ {OPTION_STRING, 0, "dirty", &dirty, "mark",
+ "append <mark> on dirty working tree (default: \"-dirty\")",
+ PARSE_OPT_OPTARG, NULL, "-dirty"},
OPT_END(),
};
@@ -360,7 +379,11 @@ int cmd_describe(int argc, const char **argv,
const char *prefix)
}
if (argc == 0) {
+ if (dirty && !cmd_diff_index(ARRAY_SIZE(diff_index_args) - 1,
diff_index_args, prefix))
+ dirty = NULL;
describe("HEAD", 1);
+ } else if (dirty) {
+ die("--dirty is incompatible with committishes");
} else {
while (argc-- > 0) {
describe(*argv++, argc == 0);
diff --git a/t/t6120-describe.sh b/t/t6120-describe.sh
index 8c7e081..ee38f34 100755
--- a/t/t6120-describe.sh
+++ b/t/t6120-describe.sh
@@ -123,6 +123,21 @@ test_expect_success 'rename tag Q back to A' '
test_expect_success 'pack tag refs' 'git pack-refs'
check_describe A-* HEAD
+check_describe "A-*[0-9a-f]" --dirty
+
+test_expect_success 'set-up dirty working tree' '
+ echo >>file
+'
+
+check_describe "A-*[0-9a-f]-dirty" --dirty
+
+check_describe "A-*[0-9a-f].mod" --dirty=.mod
+
+test_expect_success 'describe --dirty HEAD' '
+ git describe --dirty HEAD
+ test $? != 0
+'
+
test_expect_success 'set-up matching pattern tests' '
git tag -a -m test-annotated test-annotated &&
echo >>file &&
--
1.6.5
^ permalink raw reply related
* Re: [PATCH v2] new --dirty option for git describe
From: Jean Privat @ 2009-10-20 14:31 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Shawn O. Pearce
In-Reply-To: <dffdbd190910200727r30e161ffka0b3cf764be26cd8@mail.gmail.com>
> --- a/Documentation/git-describe.txt
> +++ b/Documentation/git-describe.txt
> @@ -9,6 +9,7 @@ git-describe - Show the most recent tag that is
> reachable from a commit
%#$@!&&@ !!!
I followed instructions from Documentation/SubmittingPatches about
sending patches trought gmail imap, it did not seem to work.
I will resend with git-send-email (and try on something else that
git@vger.kernel.org)
Sorry for that.
-J
^ permalink raw reply
* Re: Documentation video for svn-git
From: Wesley J. Landaker @ 2009-10-20 14:20 UTC (permalink / raw)
To: jamesmikedupont@googlemail.com; +Cc: git
In-Reply-To: <ee9cc730910192330i6c593143w5f35a7a1f66810a1@mail.gmail.com>
On Tuesday 20 October 2009 00:30:49 jamesmikedupont@googlemail.com wrote:
> I have created a computer reading of Sam's svn-git text :
>
> http://www.archive.org/details/SvnGitVideo
>
> It runs 1.5 hours.
>
> I can also do other texts, also the source is checked in to create
> them yourselves.
> https://code.launchpad.net/~jamesmikedupont/introspectorreader/wikipedia-
>strategy
I'm definite fan free software text-to-speech software. (I know espeak when
I hear it!). But I have to ask: besides being a cool technology demo, what
is the use case for this? How is this better/different than, for instance,
just using a screen-reader on-the-fly?
^ permalink raw reply
* Re: Git rebase using "wrong" commit
From: Thomas Rast @ 2009-10-20 13:21 UTC (permalink / raw)
To: Philip Allison; +Cc: git, Thomas Adam
In-Reply-To: <1256037982.7122.31.camel@gridbug.soton.smoothwall.net>
Philip Allison wrote:
> Please find attached a working copy of the repository, just before any
> attempted rebase.
[...]
> bug/2 has, effectively, been merged into master; bug/1 has not; hence,
> there is not (on master) any equivalent change to that which was made to
> resolve the conflict.
Ok, so I gather the (simplified) history looks like
*------A (master)
\\__ \
\ \ \
B--M1--M2 (topic)
where A and B conflict, so M2 is nontrivial. B is the *second* parent
to M1, which I originally thought would affect the 'rebase -p', but it
doesn't; see below. (You're talking about bug/2, but the repository
shows bug/2 == master, so there are only two branches involved.)
> Occasionally, we want to release some bug fixes, but not others. IOW,
> when integration/bug-fixes comes to be rebased onto master, we wish to
> preserve some of the topic branch merges, but not others. This usually
> works fine, but an issue has cropped up where there is a conflict
> between two fixes, and only one of the two bug fixes has been released;
> now, when we come to perform the rebase, it is not working as desired.
The inherent difficulty with doing a rebase here is, what about the
merges? By definition, git-rebase needs to somehow "rebuild" the
commits, as defined by the changes they do, on the new base.
There are several ways how merges can be rebased, and you tried some:
* Not at all; discard the merges. The result would be
*---A (master)
\
\
B' (topic)
B' will differ substantially from B because there will be a (rebase)
conflict. This is the normal mode of operation, as you noticed:
> "git rebase -i master" output (whilst on HEAD of integration/bug-fixes):
>
> -----
> pick b17a93c Fix file 1
>
> # Rebase cd8273f..9f79ca3 onto cd8273f
> -----
* Attempt to rebuild merges; this is the -p flag. Assume for a second
that you have a different history
*---A (master)
\
\
C---M2 (topic2)
/
*
where M2 is a merge with some other branch. 'git rebase -i -p
master topic2' will attempt to build
*---A (master)
\
\
C---M2 (topic2)
/
*
Going back to your scenario, this means building
*------A--. (master)
\ \ \
\ \ \
B-----M1--M2 (topic)
Now there appears to be some bug with rebase -p, because it insists
that there is no work at all to do (the buffer is just 'noop').
However, rebase -p is known to be somewhat ill-defined and broken.
I think that in this case, what actually happens is that the merge
from master to topic confuses the initialisation of $REWRITTEN in
# line 668
for c in $(git merge-base --all $HEAD $UPSTREAM)
do
echo $ONTO > "$REWRITTEN"/$c || die "blah"
done
because suddenly the merge-base is A, meaning that the later test
# line 712
for p in $(git rev-list --parents -1 $sha1 | cut -d' ' -s -f2-)
do
if test -f "$REWRITTEN"/$p -a \( $p != $ONTO -o $sha1 = $first_after_upstream \)
fails for all commits except M2. So what's *actually* rewritten is
M2; but doing so is pointless in rebase's eyes, because it assumes
the topic will be based on master eventually, so merging master into
it is a no-op. Hence there is nothing to do.
> The "-m" and "-p" options to rebase don't seem to be helping. I have
> tried getting rebase to "pick 2bc19f9" via -i, but that isn't working
> either:
-m means something entirely different, namely that git-rebase should
use an (internal) merge instead of format-patch|am, which has some
advantages but a big speed disadvantage. This doesn't matter for
rebase -i as it never uses format-patch|am.
As for manually picking merge commits, that fails because you're just
trying to fool git-cherry-pick into doing something it can't.
> We have a specific branch (integration/bug-fixes) which is under
> continual rebase, shared amongst several developers.
[...]
> At the moment I don't know where to go from here, short of manually
> recreating the branch as I want it, which I am loathe to do.
Note that there is no real reason to rebase continually unless you
want to kick out flawed topics or old versions of branches. For
example, git.git only rebases 'next' immediately after a release.
Furthermore, even if you go for the 'pu' model which is rebuilt all
the time, you can automate this with a script. There is one in the
'todo' branch of git.git, called PU.
(I myself just use a list of topics I want merged, and a simple 'git
merge $topic' loop.)
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: [PATCH] blame: make sure that the last line ends in an LF
From: Sverre Rabbelier @ 2009-10-20 13:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git List, Johannes Schindelin
In-Reply-To: <7vbpk2sg6m.fsf@alter.siamese.dyndns.org>
Heya,
On Tue, Oct 20, 2009 at 02:00, Junio C Hamano <gitster@pobox.com> wrote:
> (2) Do the right thing, by coming up with a notation to show that the
> final line is incomplete, perhaps similar to "\No newline ..."
> notation used by "diff".
What about 'git blame -p', can we just go about changing the format like that?
For purpose of the discussion below let's assume we squash in the following:
-- <8 --
diff --git a/builtin-blame.c b/builtin-blame.c
index dd16b22..cf492a0 100644
--- a/builtin-blame.c
+++ b/builtin-blame.c
@@ -1606,7 +1606,7 @@ static void emit_porcelain(struct scoreboard
*sb, struct blame_entry *ent)
}
if (sb->final_buf_size && cp[-1] != '\n')
- putchar('\n');
+ printf("\n\\ No newline at end of file\n");
}
static void emit_other(struct scoreboard *sb, struct blame_entry *ent, int opt)
@@ -1672,7 +1672,7 @@ static void emit_other(struct scoreboard *sb,
struct blame_entry *ent, int opt)
}
if (sb->final_buf_size && cp[-1] != '\n')
- putchar('\n');
+ printf("\n\\ No newline at end of file\n");
}
static void output(struct scoreboard *sb, int option)
--
-- <8 --
> Does the code assign blame
> correctly around the last line of the original blob?
Yes, it does, when there is no trailing newline an extra "\ No newline
at end of file" is printed, but the last line is still attributed
correctly.
> What if an older
> version ended with an incomplete line and a later version changed the line
> (without adding the terminating LF)?
Nothing changes, the blame on that last line is attributed correctly
and the "\ No newline at end of file" is printed.
> What if a later version changed the
> line and added the terminating LF?
The trailing "\ No newline at end of file" is no longer printed and
the last line is correctly attributed to the commit that added the
trailing LF.
> What if a later version only added the
> terminating LF and did nothing else? Are these three cases handled
> correctly?
Same as above.
> After thinking issues like the above, I read the patch and I see it does
> not take neither approach. That makes me feel nervous.
Reading your reply I see that if you care about the presence (or
absence) of a trailing newline the current patch would be problematic,
as it makes it impossible to see in the blame output whether there was
a trailing newline or not.
> By tweaking only the output routine you _might_ be getting correct output,
> but even then it looks to me like the end result is working correctly not
> by design but by accident. IOW, the patch may be better than nothing, but
> somehow it just feels like it is papering over the real issue than being a
> proper fix.
>
> Or am I worrying too much?
No, I think your concerns are valid, we should go with (2) and DTRT.
Does the updated patch address your concerns? If so I can send a new
version.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply related
* Re: [PATCH] Use faster byte swapping when compiling with MSVC
From: Erik Faye-Lund @ 2009-10-20 12:44 UTC (permalink / raw)
To: Ludvig Strigeus; +Cc: git
In-Reply-To: <loom.20091020T141138-782@post.gmane.org>
On Tue, Oct 20, 2009 at 2:20 PM, Ludvig Strigeus <ludde@spotify.com> wrote:
> unsigned long (as used by _byteswap_ulong) is 64 bits on x64, right? Then it
> doesn't make sense to use _byteswap_ulong to swap 32-bit quantities (assuming
> that's what bswap32 does) would it?
No, unsigned long is 32bit on x64 on Windows.
--->8---
#include <stdio.h>
#include <stdlib.h>
int main(int argc, char *argv[])
{
printf("sizeof(void *) = %d\n", sizeof(void *));
printf("sizeof(unsigned long) = %d\n", sizeof(unsigned long));
return 0;
}
--->8---
sizeof(void *) = 8
sizeof(unsigned long) = 4
--
Erik "kusma" Faye-Lund
^ permalink raw reply
* Re: [PATCH] Use faster byte swapping when compiling with MSVC
From: Ludvig Strigeus @ 2009-10-20 12:20 UTC (permalink / raw)
To: git
In-Reply-To: <hbi4mt$tjt$1@ger.gmane.org>
Sebastian Schuberth <sschuberth <at> gmail.com> writes:
>
> When compiling with MSVC on x86-compatible, use an intrinsic for byte swapping.
> In contrast to the GCC path, we do not prefer inline assembly here as it is not
> supported for the x64 platform.
>
>
> +#elif defined(_MSC_VER) && (defined(_M_IX86) || defined(_M_X64))
> +
> +#include <stdlib.h>
> +
> +#define bswap32(x) _byteswap_ulong(x)
> +
> +#endif
unsigned long (as used by _byteswap_ulong) is 64 bits on x64, right? Then it
doesn't make sense to use _byteswap_ulong to swap 32-bit quantities (assuming
that's what bswap32 does) would it?
/Ludde
^ permalink raw reply
* Git rebase using "wrong" commit
From: Philip Allison @ 2009-10-20 11:26 UTC (permalink / raw)
To: git; +Cc: Thomas Adam, Philip Allison
[-- Attachment #1.1: Type: text/plain, Size: 3511 bytes --]
Hello all,
We have a specific branch (integration/bug-fixes) which is under
continual rebase, shared amongst several developers. The tracked
instances have "branch.integration/bug-fixes.rebase true" and
"branch.integration/bug-fixes.mergeoptions --no-ff" - this is working
well. Individual developers merge their topic branches (in this case
bug fixes) into integration/bug-fixes and push it out.
Occasionally, we want to release some bug fixes, but not others. IOW,
when integration/bug-fixes comes to be rebased onto master, we wish to
preserve some of the topic branch merges, but not others. This usually
works fine, but an issue has cropped up where there is a conflict
between two fixes, and only one of the two bug fixes has been released;
now, when we come to perform the rebase, it is not working as desired.
Output of "git log --first-parent master..integration/bug-fixes":
-----
commit 9f79ca3928d645435d1608e22297dacd2be94e3b
Merge: 2bc19f9 cd8273f
Author: Philip Allison <philip.allison@smoothwall.net>
Date: Tue Oct 20 10:11:06 2009 +0100
Merge branch 'bug/2' into integration/bug-fixes
* bug/2:
Unify format of files 1, 2 and 3
Conflicts:
file1
commit 2bc19f9af94e03e06fbe5a1034820c606d13c3d3
Merge: c785da2 b17a93c
Author: Philip Allison <philip.allison@smoothwall.net>
Date: Tue Oct 20 10:07:37 2009 +0100
Merge branch 'bug/1' into integration/bug-fixes
* bug/1:
Fix file 1
-----
bug/2 has, effectively, been merged into master; bug/1 has not; hence,
there is not (on master) any equivalent change to that which was made to
resolve the conflict.
"git rebase -i master" output (whilst on HEAD of integration/bug-fixes):
-----
pick b17a93c Fix file 1
# Rebase cd8273f..9f79ca3 onto cd8273f
-----
The trouble here is that b17a93c is the head of bug/1 - the rebase has
picked up the changes from that branch and is trying to apply them as a
fast-forward commit in the newly rebased integration/bug-fixes, instead
of trying to rebase the *merge* of bug/1 (i.e. 2bc19f9).
The "-m" and "-p" options to rebase don't seem to be helping. I have
tried getting rebase to "pick 2bc19f9" via -i, but that isn't working
either:
-----
fatal: Commit 2bc19f9af94e03e06fbe5a1034820c606d13c3d3 is a merge but no
-m option was given.
Could not apply 2bc19f9...
-----
Interestingly, rebase does *not* seem to be trying to recreate 9f79ca3
(or its second parent), which is the problem I was originally expecting
to run into.
At the moment I don't know where to go from here, short of manually
recreating the branch as I want it, which I am loathe to do. Ideas and
suggestions much appreciated.
Please find attached a working copy of the repository, just before any
attempted rebase.
Regards
--
Philip Allison
Senior Developer
SmoothWall Ltd
1 John Charles Way
Leeds LS12 6QA
United Kingdom
1 800 959 3760 (USA, Canada and North America)
0870 1 999 500 (United Kingdom)
+44 870 1 999 500 (All other countries)
SmoothWall is registered in England: 4298247
This email and any attachments transmitted with it are confidential
to the intended recipient(s) and may not be communicated to any
other person or published by any means without the permission of
SmoothWall Limited. Any opinions stated in this message are solely
those of the author. See: http://smoothwall.net/company/email.php
for the full text of this notice.
[-- Attachment #1.2: repo.tar.gz --]
[-- Type: application/x-compressed-tar, Size: 15095 bytes --]
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: ".dirty" suffix when building git from the source code
From: Santi Béjar @ 2009-10-20 12:06 UTC (permalink / raw)
To: bamakhrama; +Cc: Git
In-Reply-To: <40378e40910200459i14b06002k1b805936e39b5022@mail.gmail.com>
On Tue, Oct 20, 2009 at 1:59 PM, Mohamed Bamakhrama
<bamakhrama@gmail.com> wrote:
> Hi all,
>
> I have cloned the git repository and built the v1.6.4.4 tag. The
> compilation went OK and I got the tool up and running. However, when I
> generate patches, I see that the tool comments the patches with
> "1.6.4.4.dirty".
>
> My question is: what is the meaning of the ".dirty" suffix?
It says that the git source code was modified when git was compiled.
HTH,
Santi
^ permalink raw reply
* Re: git fsck not identifying corrupted packs
From: Matthieu Moy @ 2009-10-20 11:56 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Alex Riesen, Junio C Hamano, Johannes Sixt, Sergio Callegari, git
In-Reply-To: <alpine.DEB.1.00.0910201221250.4985@pacific.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Hi,
>
> On Tue, 20 Oct 2009, Alex Riesen wrote:
>
>> On Tue, Oct 20, 2009 at 08:45, Junio C Hamano <gitster@pobox.com> wrote:
>> > Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
>> >>> It probably is also a good idea to add a "--loose" option that does what
>> >>> "fsck" currently does without "--full". It is a good name
>>
>> --no-full works
>
> It works. Technically. For human users, though, --loose-objects-only
> (with a shortcut "--loose") would be better.
OTOH, the advantage of "--no-full" is that it's compatible with
existing Git versions. If I learn Git 1.6.6 with --no-full, and use it
in a script, then my stript works also with older Gits.
But anyway, I think very few people are actually interested in "git
--no-full" (or call it whatever you like), so I don't think this is
very important.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* ".dirty" suffix when building git from the source code
From: Mohamed Bamakhrama @ 2009-10-20 11:59 UTC (permalink / raw)
To: Git
Hi all,
I have cloned the git repository and built the v1.6.4.4 tag. The
compilation went OK and I got the tool up and running. However, when I
generate patches, I see that the tool comments the patches with
"1.6.4.4.dirty".
My question is: what is the meaning of the ".dirty" suffix?
Thanks in advance.
Best Regards,
Mohamed
^ permalink raw reply
* Re: Potentially dangerous behavior of git gc
From: Sergio @ 2009-10-20 11:40 UTC (permalink / raw)
To: git
In-Reply-To: <20091019112153.GX6115@genesis.frugalware.org>
Miklos Vajna <vmiklos <at> frugalware.org> writes:
>
> On Mon, Oct 19, 2009 at 08:04:58AM +0000, Sergio Callegari
<sergio.callegari <at> gmail.com> wrote:
> > With this when the alternate info of A is finally updated, A is broken,
missing
> > many references and not having a head anymore.
> >
> > Would it be better to have git gc not to take dangerous actions on
potentially
> > problematic repos?
>
> Such repos are usually created using git clone -s. See the NOTE of the
> manpage under the -s option, probably you want to use git repack -a
> after git clone.
>
Thanks, unfortunately, that was not really my point. But I now see that I
cannot create a test case to reproduce my issue. Briefly what happened to
me is the following
1) Create repo A
2) Clone with -s A into B
3) Do some work in B, being happy of maintaining the alternate
4) At some point, move A elsewhere
5) Do a couple of things in B, including a git gc, before realizing that
moving A had created problems to B
6) Rush to make A reachable by B again by updating the info/alternates
file in B
7) Realize that in spite of 6) B is gone... no more ref/heads/master, git
thinks that this is a new empty repo.
And certainly the fault was of some of the "two things" done in 5). At the
beginning I thought that the blame was of git gc, but I see that I cannot
reproduce the situation at all with test cases.
So I will give up for now... I'll get back to it if I ever have a similar
problem. Once more, sorry for the noise.
Sergio
^ permalink raw reply
* Re: denying branch creation in a shared repository
From: Sitaram Chamarty @ 2009-10-20 11:24 UTC (permalink / raw)
To: Mohit Aron; +Cc: git
In-Reply-To: <ee22b09e0910190943x51d48c09sdc50d941d643358d@mail.gmail.com>
On Mon, Oct 19, 2009 at 10:13 PM, Mohit Aron <mohit.aron@gmail.com> wrote:
>>
>> That was the main reason I wrote gitolite
>> (http://github.com/sitaramc/gitolite), though now it does a heck of a
>> lot more than just that.
>>
>
> That's great. You might want to consider making it a deb package
> that's available from one of the Ubuntu/Debian repositories. An apt
> search on Ubuntu 9.10 doesn't reveal it. I usually shy away from
> installing software on my machines that is not automatically managed.
There are a couple of answers to this:
(1) I'm not really a debian guy, and definitely not ubuntu. My distro
of choice for nearly 10 years has been Mandriva :-)
(2) gitolite's second reason for existence [after the one in this
thread] is the need to install something on machines where you do
*not* have root, can't create another user, etc etc. There was a
Solaris 9 on which I couldn't install python-setuptools, and so no
gitosis :-(
Regardless of all that, someone is working on it...
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=550817
I respect your inclination to shy away; I do the same for pretty much
everything except git itself and one or two others.
But if you don't mind looking through the documentation (browse it
directly on github; it'll render the markdown properly, though the
plain text is quite readable too), you may be able to better decide if
you want to use it despite this limitation.
Regards,
Sita
^ permalink raw reply
* [PATCH] import-tars: Add support for tarballs compressed with lzma, xz
From: Ingmar Vanhassel @ 2009-10-20 10:29 UTC (permalink / raw)
To: git
Cc: Johannes Schindelin, Shawn O. Pearce, Peter Krefting,
Junio C Hamano, Ingmar Vanhassel
In-Reply-To: <alpine.DEB.1.00.0910201155260.4985@pacific.mpi-cbg.de>
Also handle the extensions .tlz and .txz, aliases for .tar.lzma and
.tar.xz respectively.
Signed-off-by: Ingmar Vanhassel <ingmar@exherbo.org>
---
contrib/fast-import/import-tars.perl | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
> Nice! Maybe you want to mention in the commit message that it handles
> also .txz and .tlz, for convenience. (I was looking specifically for that
> support in the patch, fully prepared to suggest to add it...)
Right, thanks!
diff --git a/contrib/fast-import/import-tars.perl b/contrib/fast-import/import-tars.perl
index 7001862..95438e1 100755
--- a/contrib/fast-import/import-tars.perl
+++ b/contrib/fast-import/import-tars.perl
@@ -20,7 +20,7 @@ use Getopt::Long;
my $metaext = '';
-die "usage: import-tars [--metainfo=extension] *.tar.{gz,bz2,Z}\n"
+die "usage: import-tars [--metainfo=extension] *.tar.{gz,bz2,lzma,xz,Z}\n"
unless GetOptions('metainfo=s' => \$metaext) && @ARGV;
my $branch_name = 'import-tars';
@@ -49,6 +49,9 @@ foreach my $tar_file (@ARGV)
} elsif ($tar_name =~ s/\.tar\.Z$//) {
open(I, '-|', 'uncompress', '-c', $tar_file)
or die "Unable to uncompress -c $tar_file: $!\n";
+ } elsif ($tar_name =~ s/\.(tar\.(lzma|xz)|(tlz|txz))$//) {
+ open(I, '-|', 'xz', '-dc', $tar_file)
+ or die "Unable to xz -dc $tar_file: $!\n";
} elsif ($tar_name =~ s/\.tar$//) {
open(I, $tar_file) or die "Unable to open $tar_file: $!\n";
} else {
--
1.6.5.1
^ permalink raw reply related
* Re: git fsck not identifying corrupted packs
From: Johannes Schindelin @ 2009-10-20 10:22 UTC (permalink / raw)
To: Alex Riesen
Cc: Junio C Hamano, Matthieu Moy, Johannes Sixt, Sergio Callegari,
git
In-Reply-To: <81b0412b0910200225g47220cc9wa2e82290a853c85d@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 698 bytes --]
Hi,
On Tue, 20 Oct 2009, Alex Riesen wrote:
> On Tue, Oct 20, 2009 at 08:45, Junio C Hamano <gitster@pobox.com> wrote:
> > Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
> >>> It probably is also a good idea to add a "--loose" option that does what
> >>> "fsck" currently does without "--full". It is a good name
> >>
> >> +1 too.
> >
> > Actually, I changed my mind. I do not think this so big that we need to
> > wait for a major version bump. Why not shoot for 1.6.6?
>
> --no-full works
It works. Technically. For human users, though, --loose-objects-only
(with a shortcut "--loose") would be better.
Disclaimer: this email was written by a bot and is valid without signature
^ permalink raw reply
* Re: [PATCH] import-tars: Add support for tarballs compressed with lzma, xz
From: Johannes Schindelin @ 2009-10-20 9:56 UTC (permalink / raw)
To: Ingmar Vanhassel; +Cc: git, Shawn O. Pearce, Peter Krefting, Junio C Hamano
In-Reply-To: <1256029177-22503-1-git-send-email-ingmar@exherbo.org>
Hi,
On Tue, 20 Oct 2009, Ingmar Vanhassel wrote:
> Signed-off-by: Ingmar Vanhassel <ingmar@exherbo.org>
Nice! Maybe you want to mention in the commit message that it handles
also .txz and .tlz, for convenience. (I was looking specifically for that
support in the patch, fully prepared to suggest to add it...)
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Use faster byte swapping when compiling with MSVC
From: Johannes Schindelin @ 2009-10-20 9:53 UTC (permalink / raw)
To: Sebastian Schuberth
Cc: Junio C Hamano, git, Marius Storm-Olsen, Johannes Sixt
In-Reply-To: <bdca99240910200156x48511478w9eaa2239eb8342b4@mail.gmail.com>
Hi,
On Tue, 20 Oct 2009, Sebastian Schuberth wrote:
> On Tue, Oct 20, 2009 at 09:04, Junio C Hamano <gitster@pobox.com> wrote:
>
> >> When compiling with MSVC on x86-compatible, use an intrinsic for byte
> >> swapping. In contrast to the GCC path, we do not prefer inline
> >> assembly here as it is not supported for the x64 platform.
> >>
> >> Signed-off-by: Sebastian Schuberth <sschuberth@gmail.com>
> >
> > Unlike the other one this is not Acked by Marius, Dscho, or J6t;
> > should I pick this up myself, or should I wait to be fed by one of
> > msysgit people?
>
> Well, in fact I am one of the msysgit poeple, although I mostly worked
> on the installer until now. In general, I like my patches to be
> reviewed, but this one is rather uncritical, I guess. So it's up to you,
> Junio, I'm perfectly OK with waiting for an ACK.
Apart from the fact that I do not have MSVC (and I don't want it, either),
there is another strong reason why I think Sebastian does not need ACKs or
SOBs on MSVC patches: he has plenty of experience as a maintainer of a
rather big (commercial) software that has to compile on Windows, MacOSX
and several Unix-type OSes (and it is known that Sebastian is a Windows
guy).
So I would trust Sebastian's patches (at least when it comes to MSVC)
without even reviewing them.
Ciao,
Dscho
^ permalink raw reply
* Re: Which dates 'git log --since= --after=' compare?
From: Daniel @ 2009-10-20 9:35 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20091020083703.GA14740@coredump.intra.peff.net>
Jeff King <peff@peff.net> wrote:
> On Mon, Oct 19, 2009 at 12:01:49PM +0200, Daniel wrote:
>
> > I can see that 'git log --since= --after=' compares commit's dates,
> > not author's dates.How can I limit commits by Author's date?
>
> AFAIK, there is currently no way to do it with a simple option. In fact,
> we don't even parse the author date when doing revision limiting.
>
> So it would need a patch, but the "obvious" solution of just parsing and
> storing the author date in a "struct commit" might not be acceptable; as
> I recall, some performance tuning went into keeping the per-commit
> memory footprint as small as possible, which had a noticeable speed
> benefit (I'm not saying it couldn't be done, but care needs to be taken
> in that regard).
>
> If it's not something you need to do often, I'd consider something like:
>
> git log --format='%H %at' |
> perl -ane '
> BEGIN {
> use DateTime::Format::Natural;
> $max_age = DateTime::Format::Natural->new->parse_datetime(
> "last friday"
> )->epoch;
> }
> print $F[0], "\n" if $F[1] < $max_age;
> '
>
> Of course that's awful to type, and it will be much slower than git
> doing the revision limiting itself.
>
> -Peff
Thanks.
^ permalink raw reply
* Re: git fsck not identifying corrupted packs
From: Alex Riesen @ 2009-10-20 9:25 UTC (permalink / raw)
To: Junio C Hamano
Cc: Matthieu Moy, Johannes Schindelin, Johannes Sixt,
Sergio Callegari, git
In-Reply-To: <7vfx9esgvt.fsf@alter.siamese.dyndns.org>
On Tue, Oct 20, 2009 at 08:45, Junio C Hamano <gitster@pobox.com> wrote:
> Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
>>> It probably is also a good idea to add a "--loose" option that does what
>>> "fsck" currently does without "--full". It is a good name
>>
>> +1 too.
>
> Actually, I changed my mind. I do not think this so big that we need to
> wait for a major version bump. Why not shoot for 1.6.6?
--no-full works
^ permalink raw reply
* [PATCH] Makefile: set PERL_PATH and SHELL_PATH unconditionally
From: Matt Kraai @ 2009-10-20 9:06 UTC (permalink / raw)
To: git, gitster; +Cc: Matt Kraai
In-Reply-To: <7vr5syshat.fsf@alter.siamese.dyndns.org>
Do not check whether PERL_PATH and SHELL_PATH are undefined before
setting their default values. This prevents them from being set via
environment variables.
Signed-off-by: Matt Kraai <kraai@ftbfs.org>
---
On Mon, Oct 19, 2009 at 11:36:26PM -0700, Junio C Hamano wrote:
> Matt Kraai <kraai@ftbfs.org> writes:
>
> > The top-level Makefile currently contains
> >
> >> ifndef SHELL_PATH
> >> SHELL_PATH = /bin/sh
> >> endif
> >> ifndef PERL_PATH
> >> PERL_PATH = /usr/bin/perl
> >> endif
> >
> > The checks are only necessary if these variables need to be overridden
> > by environment variables, not just via the make command line. Is this
> > the case?
>
> It may not have been the original intention, but the above would mean that
> some people may have learned to run "SHELL_PATH=/bin/ksh make" and
> changing it would break things for them, no?
Yes, that's what I was concerned about. This appears to be possible
for PERL_PATH on all platforms and for SHELL_PATH on platforms other
than SCO UnixWare, SunOS, and IRIX.
> I do not think changing them is bad per-se, but we would need to add extra
> warnings in the release note to explain this change, that's all. This
> would only affect people who build from the source (including distro
> people) so it is not really a big deal.
I hope this patch is OK.
Documentation/RelNotes-1.6.6.txt | 3 +++
Makefile | 8 ++------
2 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/Documentation/RelNotes-1.6.6.txt b/Documentation/RelNotes-1.6.6.txt
index 5f1fecb..bfda14c 100644
--- a/Documentation/RelNotes-1.6.6.txt
+++ b/Documentation/RelNotes-1.6.6.txt
@@ -58,3 +58,6 @@ release, unless otherwise noted.
whitespace attribute). The 'trailing-space' whitespace error class has
become a short-hand to cover both of these and there is no behaviour
change for existing set-ups.
+
+ * PERL_PATH and SHELL_PATH may not be overridden using environment
+ variables during the build.
diff --git a/Makefile b/Makefile
index 42b7d60..5bac305 100644
--- a/Makefile
+++ b/Makefile
@@ -392,12 +392,8 @@ ALL_PROGRAMS = $(PROGRAMS) $(SCRIPTS)
OTHER_PROGRAMS = git$X
# Set paths to tools early so that they can be used for version tests.
-ifndef SHELL_PATH
- SHELL_PATH = /bin/sh
-endif
-ifndef PERL_PATH
- PERL_PATH = /usr/bin/perl
-endif
+SHELL_PATH = /bin/sh
+PERL_PATH = /usr/bin/perl
export PERL_PATH
--
1.6.5
^ 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