* Re: Translations [of Documentation] in Git release?
From: Jakub Narebski @ 2009-01-26 12:31 UTC (permalink / raw)
To: Dill; +Cc: git
In-Reply-To: <60646ee10901250941s34f7accem1b74fc201e895a41@mail.gmail.com>
Dill <sarpulhu@gmail.com> writes:
> Is there a plan to include translations of the Documentation within
> Git or should they exist outside of the project?
First, you should have mention that you are talking about translating
_Documentation_, because there are at least three areas which can be
translated:
* GUI (gtik and git-gui), which is being done
* Documentation, which leads to translated manpages and HTML docs
* git command messages (but only porcelain, as scripts parse
git command output)
Second, the problem with translating Documentation is twofold. There
is fundamental problem with translated documentation becoming out of
sync (stale) unless you have people ready to follow changes to main
documentation. This is less of a problem with GUI messages, as they
change less frequently, there are shorter, and there is less volume of
them.
And there is technical problem of how to organize translations. With
GUI translations we just use gettext conventions. I don't know any
such convention for docs: there is suffix convention used by Apache to
serve var language files (filename.txt.de, filename.txt.ja.euc-jp),
and there is gettext-like convention of separate directories used by
manpages (en/filename.txt, ja/filename.txt). And there is question
where to put untranslated original... And to enhance Makefile to put
translations in correct place. And possibly alter RPM .spec file to
put translations in separate packages.
So I am not sure if translated documentation should be not maintained
out of tree...
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] contrib git-resurrect: find traces of a branch name and resurrect it
From: Thomas Rast @ 2009-01-26 11:54 UTC (permalink / raw)
To: Boyd Stephen Smith Jr.; +Cc: git, Junio C Hamano, Johannes Schindelin
In-Reply-To: <200901231500.23182.bss@iguanasuicide.net>
[-- Attachment #1: Type: text/plain, Size: 1817 bytes --]
Hi Stephen,
Sorry for the long delay. I'm going to roll a v2 with two small
fixes. After that it's all yours ;-)
Boyd Stephen Smith Jr. wrote:
[...]
> 6. Try to resurrect branch from origin/pu, get local version I just deleted.
> 7. delete reflog for that branch
> 8. Try to resurrect branch from origin/pu, get local version I merged into
> master at some point.
> 9. Add new option.
>
> So, I added a couple of options locally: --only-merges, so it would only look
> at the first line of commit logs, ignoring my local reflogs entirely;
> and --revisions, to specify arguments to pass to rev-list so it wouldn't even
> see my local merges (I passed 'origin/pu origin/next').
>
> Yeah, my usage might be abusage, but it worked for me. :)
I'm fine with adding such an option, but I still wonder what was wrong
with the original scheme of asking 'git rev-list -1' for the newest
commit. I thought rev-list always listed by date, so that command
should always pick the newest candidate commit from all candidates
selected. Do you have an example where that breaks? Or did you just
have a use-case in which you wanted something other than the newest
candidate?
> In my local version, which I was going to try and clean up over the weekend, I
> was going to support both, by borrowing refspec syntax from fetch/push.
> Specifically. Resurrecting 'js/notes' as 'pu/js/notes' would look like:
> git-resurrect -H js/notes:pu/js/notes
>
> Would you object to a patch that dropped -b in favor of the refspec syntax?
No, that would be fine by me.
> There seems to be some needless redundancy between USAGE and OPTIONS_SPEC.
>
> Would you object to a patch that used $USAGE inside OPTIONS_SPEC?
Also a good idea.
--
Thomas Rast
trast@{inf,student}.ethz.ch
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [PATCH v2] contrib git-resurrect: find traces of a branch name and resurrect it
From: Thomas Rast @ 2009-01-26 12:40 UTC (permalink / raw)
To: Boyd Stephen Smith Jr.; +Cc: git, Junio C Hamano, Johannes Schindelin
In-Reply-To: <200901261254.39360.trast@student.ethz.ch>
Add a tool 'git-resurrect.sh <branch>' that tries to find traces of
the <branch> in the HEAD reflog and, optionally, all merge commits in
the repository. It can then resurrect the branch, pointing it at the
most recent of all candidate commits found.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
Fixed the -h to upper-case in the short options summaries, and removed
a stray 'q' in the default assignment of new_name.
contrib/git-resurrect.sh | 140 ++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 140 insertions(+), 0 deletions(-)
create mode 100755 contrib/git-resurrect.sh
diff --git a/contrib/git-resurrect.sh b/contrib/git-resurrect.sh
new file mode 100755
index 0000000..3c1c946
--- /dev/null
+++ b/contrib/git-resurrect.sh
@@ -0,0 +1,140 @@
+#!/bin/sh
+
+USAGE="[-H] [-r] [-m] [-t] [-n] [-b <newname>] <name>"
+LONG_USAGE="git-resurrect attempts to find traces of a branch tip
+called <name>, and tries to resurrect it. Currently, the reflog is
+searched for checkout messages, and with -r also merge messages. With
+-m and -t, the history of all refs is scanned for Merge <name> into
+other/Merge <other> into <name> (respectively) commit subjects, which
+is rather slow but allows you to resurrect other people's topic
+branches."
+
+OPTIONS_SPEC="\
+git resurrect [-H] [-r] [-m] [-t] [-n] [-b <newname>] <name>
+--
+b,branch= save branch as <newname> instead of <name>
+H,try-hard same as -r -m -t
+r,reflog-merges scan for merges recorded in reflog
+m,merges scan for merges into other branches (slow)
+t,merge-targets scan for merges of other branches into <name>
+n,dry-run don't recreate the branch"
+
+. git-sh-setup
+cd_to_toplevel
+
+search_reflog () {
+ sed -n 's~^\([^ ]*\) .*\tcheckout: moving from '"$1"' .*~\1~p' \
+ < .git/logs/HEAD
+}
+
+search_reflog_merges () {
+ sed -n 's~^[^ ]* \([^ ]*\) .*\tmerge '"$1"':~\1~p' \
+ < .git/logs/HEAD
+}
+
+search_merges () {
+ git rev-list --pretty=tformat:"%h %p:%s" --all |
+ grep "Merge branch.*'$branch'.*into" |
+ while read sha rest; do
+ parents="$(echo "$rest" | cut -d: -f1)"
+ case "$parents" in
+ *' '*' '*)
+ warn "$branch took part in octopus merge $sha"
+ warn "check manually!"
+ ;;
+ *' '*)
+ echo "$parents" | cut -d' ' -f2
+ ;;
+ esac
+ done
+}
+
+search_merge_targets () {
+ git rev-list --pretty=tformat:"%h %s" --all |
+ grep "Merge branch '[^']*' into $branch$" |
+ cut -d' ' -f1
+}
+
+dry_run=
+scan_reflog_merges=
+scan_merges=
+scan_merge_targets=
+new_name=
+
+while test "$#" != 0; do
+ case "$1" in
+ -b|--branch)
+ shift
+ new_name="$1"
+ ;;
+ -n|--dry-run)
+ dry_run=t
+ ;;
+ -m|--merges)
+ scan_merges=t
+ ;;
+ -r|--reflog_merges)
+ scan_reflog_merges=t
+ ;;
+ -t|--merge-targets)
+ scan_merge_targets=t
+ ;;
+ -H|--try-hard)
+ scan_reflog_merges=t
+ scan_merges=t
+ scan_merge_targets=t
+ ;;
+ --)
+ shift
+ break
+ ;;
+ *)
+ usage
+ ;;
+ esac
+ shift
+done
+
+test "$#" = 1 || usage
+
+branch="$1"
+test -z "$new_name" && new_name="$branch"
+
+candidates="$(search_reflog $1)"
+if test ! -z "$scan_reflog_merges"; then
+ candidates="$candidates $(search_reflog_merges $1)"
+fi
+if test ! -z "$scan_merges"; then
+ candidates="$candidates $(search_merges $1)"
+fi
+if test ! -z "$scan_merge_targets"; then
+ candidates="$candidates $(search_merge_targets $1)"
+fi
+
+candidates="$(git rev-parse $candidates | sort -u)"
+
+if test -z "$candidates"; then
+ hint=
+ test "z$scan_merges$scan_reflog_merges$scan_merge_targets" != "zttt" \
+ && hint="(maybe try again with -H)"
+ die "no candidates for $branch found" $hint
+fi
+
+echo "** Candidates for $branch **"
+for cmt in $candidates; do
+ git --no-pager log --pretty=oneline --abbrev-commit -1 $cmt
+done
+
+newest="$(git rev-list -1 $candidates)"
+if test ! -z "$dry_run"; then
+ printf "Most recent: "
+ git --no-pager log -1 --pretty=tformat:"%h %s" $newest
+elif ! git rev-parse --verify --quiet $new_name >/dev/null; then
+ printf "** Restoring $new_name to "
+ git --no-pager log -1 --pretty=tformat:"%h %s" $newest
+ git branch $new_name $newest
+else
+ printf "Most recent: "
+ git --no-pager log -1 --pretty=tformat:"%h %s" $newest
+ echo "** $new_name already exists, doing nothing"
+fi
--
1.6.1.469.g6f3d5
^ permalink raw reply related
* [PATCHv2] gitweb: make static files accessible with PATH_INFO
From: Giuseppe Bilotta @ 2009-01-26 12:45 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Junio C Hamano, Giuseppe Bilotta
When PATH_INFO is defined, static files such as the defalt CSS or the
shortcut icon are not accessible beyond the summary page (e.g. in
shortlog or commit view).
Fix this by adding a <base> tag pointing to the script base URL.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
It's sick that $cgi->url() has no way to print the script base url
without path_info information (or that, if it has, it's very well
hidden).
gitweb/gitweb.perl | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 931db4f..910da35 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -2901,6 +2901,14 @@ sub git_header_html {
<meta name="robots" content="index, nofollow"/>
<title>$title</title>
EOF
+# the stylesheet, favicon etc urls won't work correctly with path_info unless we set the appropriate base URL
+ if ($ENV{'PATH_INFO'}) {
+ my $base = $my_uri;
+ my $sname = $ENV{'SCRIPT_NAME'};
+ $base =~ s,\Q$sname\E$,,;
+ $base .= "/";
+ print "<base href=\"$base\"/>\n";
+ }
# print out each stylesheet that exist
if (defined $stylesheet) {
#provides backwards capability for those people who define style sheet in a config file
--
1.5.6.5
^ permalink raw reply related
* Re: Translations [of Documentation] in Git release?
From: Peter Krefting @ 2009-01-26 13:27 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Dill, Git Mailing List
In-Reply-To: <m3hc3mxn9d.fsf@localhost.localdomain>
Jakub Narebski:
> With GUI translations we just use gettext conventions. I don't know
> any such convention for docs:
There is a lot of documentation being translated using PO files. po4a -
http://po4a.alioth.debian.org/ - is a nice starting point for that.
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* Re: Translations [of Documentation] in Git release?
From: Miklos Vajna @ 2009-01-26 13:34 UTC (permalink / raw)
To: Peter Krefting; +Cc: Jakub Narebski, Dill, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0901261426350.7798@ds9.cixit.se>
[-- Attachment #1: Type: text/plain, Size: 426 bytes --]
On Mon, Jan 26, 2009 at 02:27:17PM +0100, Peter Krefting <peter@softwolves.pp.se> wrote:
> There is a lot of documentation being translated using PO files. po4a -
> http://po4a.alioth.debian.org/ - is a nice starting point for that.
Actually it supports asciidoc files as well, but only the CVS version,
so probably the po4a version installed on most machines (as a distro
package) is not capable of managing asciidoc files.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [PATCH] Allow format-patch to create patches for merges
From: Nathan W. Panike @ 2009-01-26 14:04 UTC (permalink / raw)
To: git; +Cc: Nathan W. Panike, Johannes.Schindelin, gitster, aspotashev
The behavior for git format-patch is to ignore merge commits, producing an
empty patch. The code does not allow the user to change this behavior. This
patch changes that behavior by allowing the user to specify -c or -m at the
command line to produce a patch for a merge commit.
---
Hi:
I am sure there are good reasons for the current behavior of format-patch, but
it seems to me that if the user explicitly wants to produce a patch for a merge
commit, he should be allowed to do so. If merge_commit represents a merge,
then this patch allows the user to issue the command
git format-patch -m -1 $merge_commit
or
git format-patch -c -1 $merge_commit
and actually produce a patch. The current behavior is that neither command
will produce a patch. With or without the patch applied, the command
git format-patch -1 $merge_commit
does not produce a patch when merge_commit is a merge. Thus the patch does not
change the default behavior of ignoring merges, at least by the limited testing
I have done.
Thanks for your consideration.
Nathan Panike
builtin-log.c | 4 ----
1 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/builtin-log.c b/builtin-log.c
index 2ae39af..ea4729d 100644
--- a/builtin-log.c
+++ b/builtin-log.c
@@ -994,10 +994,6 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix)
continue;
}
- /* ignore merges */
- if (commit->parents && commit->parents->next)
- continue;
-
if (ignore_if_in_upstream &&
has_commit_patch_id(commit, &ids))
continue;
--
1.6.1.1.GIT
^ permalink raw reply related
* [PATCH 2/3] Make has_commit non-static
From: Jake Goulding @ 2009-01-26 14:13 UTC (permalink / raw)
To: git; +Cc: gitster, Jake Goulding
In-Reply-To: <1232979205-17161-1-git-send-email-goulding@vivisimo.com>
Moving has_commit from branch to a common location in preparation for
using it in tag. Renaming it to commit_has_any_in_commit_list to be
more unique.
Signed-off-by: Jake Goulding <goulding@vivisimo.com>
---
Function renamed to less-generic name as suggested by Junio.
builtin-branch.c | 20 +++-----------------
commit.c | 16 ++++++++++++++++
commit.h | 1 +
3 files changed, 20 insertions(+), 17 deletions(-)
diff --git a/builtin-branch.c b/builtin-branch.c
index 82d6fb2..a30ef76 100644
--- a/builtin-branch.c
+++ b/builtin-branch.c
@@ -193,21 +193,6 @@ struct ref_list {
int kinds;
};
-static int has_commit(struct commit *commit, struct commit_list *with_commit)
-{
- if (!with_commit)
- return 1;
- while (with_commit) {
- struct commit *other;
-
- other = with_commit->item;
- with_commit = with_commit->next;
- if (in_merge_bases(other, &commit, 1))
- return 1;
- }
- return 0;
-}
-
static int append_ref(const char *refname, const unsigned char *sha1, int flags, void *cb_data)
{
struct ref_list *ref_list = (struct ref_list*)(cb_data);
@@ -231,7 +216,7 @@ static int append_ref(const char *refname, const unsigned char *sha1, int flags,
return error("branch '%s' does not point at a commit", refname);
/* Filter with with_commit if specified */
- if (!has_commit(commit, ref_list->with_commit))
+ if (!commit_has_any_in_commit_list(commit, ref_list->with_commit))
return 0;
/* Don't add types the caller doesn't want */
@@ -401,7 +386,8 @@ static void print_ref_list(int kinds, int detached, int verbose, int abbrev, str
qsort(ref_list.list, ref_list.index, sizeof(struct ref_item), ref_cmp);
detached = (detached && (kinds & REF_LOCAL_BRANCH));
- if (detached && head_commit && has_commit(head_commit, with_commit)) {
+ if (detached && head_commit &&
+ commit_has_any_in_commit_list(head_commit, with_commit)) {
struct ref_item item;
item.name = xstrdup("(no branch)");
item.kind = REF_LOCAL_BRANCH;
diff --git a/commit.c b/commit.c
index c99db16..97c8a8a 100644
--- a/commit.c
+++ b/commit.c
@@ -705,6 +705,22 @@ struct commit_list *get_merge_bases(struct commit *one, struct commit *two,
return get_merge_bases_many(one, 1, &two, cleanup);
}
+int commit_has_any_in_commit_list(struct commit *commit,
+ struct commit_list *with_commit)
+{
+ if (!with_commit)
+ return 1;
+ while (with_commit) {
+ struct commit *other;
+
+ other = with_commit->item;
+ with_commit = with_commit->next;
+ if (in_merge_bases(other, &commit, 1))
+ return 1;
+ }
+ return 0;
+}
+
int in_merge_bases(struct commit *commit, struct commit **reference, int num)
{
struct commit_list *bases, *b;
diff --git a/commit.h b/commit.h
index 3a7b06a..4084102 100644
--- a/commit.h
+++ b/commit.h
@@ -133,6 +133,7 @@ extern int is_repository_shallow(void);
extern struct commit_list *get_shallow_commits(struct object_array *heads,
int depth, int shallow_flag, int not_shallow_flag);
+int commit_has_any_in_commit_list(struct commit *, struct commit_list *);
int in_merge_bases(struct commit *, struct commit **, int);
extern int interactive_add(int argc, const char **argv, const char *prefix);
--
1.6.0.6
^ permalink raw reply related
* [PATCH 3/3] Add --contains flag to git tag
From: Jake Goulding @ 2009-01-26 14:13 UTC (permalink / raw)
To: git; +Cc: gitster, Jake Goulding
In-Reply-To: <1232979205-17161-2-git-send-email-goulding@vivisimo.com>
This functions similar to git branch --contains - it will show all
tags that contain the specified commit. Indeed, it uses the same
lookup mechanisms as git branch.
Also adding documentation and tests for new option.
Signed-off-by: Jake Goulding <goulding@vivisimo.com>
---
Updated error semantics as suggested by Junio.
Documentation/git-tag.txt | 5 ++-
builtin-tag.c | 30 +++++++++++-
t/t7004-tag.sh | 115 +++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 147 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-tag.txt b/Documentation/git-tag.txt
index e44f543..533d18b 100644
--- a/Documentation/git-tag.txt
+++ b/Documentation/git-tag.txt
@@ -12,7 +12,7 @@ SYNOPSIS
'git tag' [-a | -s | -u <key-id>] [-f] [-m <msg> | -F <file>]
<name> [<commit> | <object>]
'git tag' -d <name>...
-'git tag' [-n[<num>]] -l [<pattern>]
+'git tag' [-n[<num>]] -l [--contains <commit>] [<pattern>]
'git tag' -v <name>...
DESCRIPTION
@@ -68,6 +68,9 @@ OPTIONS
List tags with names that match the given pattern (or all if no pattern is given).
Typing "git tag" without arguments, also lists all tags.
+--contains <commit>::
+ Only list tags which contain the specified commit.
+
-m <msg>::
Use the given tag message (instead of prompting).
If multiple `-m` options are given, their values are
diff --git a/builtin-tag.c b/builtin-tag.c
index a398499..17082de 100644
--- a/builtin-tag.c
+++ b/builtin-tag.c
@@ -26,6 +26,7 @@ static char signingkey[1000];
struct tag_filter {
const char *pattern;
int lines;
+ struct commit_list *with_commit;
};
#define PGP_SIGNATURE "-----BEGIN PGP SIGNATURE-----"
@@ -42,6 +43,17 @@ static int show_reference(const char *refname, const unsigned char *sha1,
char *buf, *sp, *eol;
size_t len;
+ if (filter->with_commit) {
+ struct commit *commit;
+
+ commit = lookup_commit_reference_gently(sha1, 1);
+ if (!commit)
+ return 0;
+ if (!commit_has_any_in_commit_list(commit,
+ filter->with_commit))
+ return 0;
+ }
+
if (!filter->lines) {
printf("%s\n", refname);
return 0;
@@ -79,7 +91,8 @@ static int show_reference(const char *refname, const unsigned char *sha1,
return 0;
}
-static int list_tags(const char *pattern, int lines)
+static int list_tags(const char *pattern, int lines,
+ struct commit_list *with_commit)
{
struct tag_filter filter;
@@ -88,6 +101,7 @@ static int list_tags(const char *pattern, int lines)
filter.pattern = pattern;
filter.lines = lines;
+ filter.with_commit = with_commit;
for_each_tag_ref(show_reference, (void *) &filter);
@@ -360,6 +374,7 @@ int cmd_tag(int argc, const char **argv, const char *prefix)
list = 0, delete = 0, verify = 0;
const char *msgfile = NULL, *keyid = NULL;
struct msg_arg msg = { 0, STRBUF_INIT };
+ struct commit_list *with_commit = NULL;
struct option options[] = {
OPT_BOOLEAN('l', NULL, &list, "list tag names"),
{ OPTION_INTEGER, 'n', NULL, &lines, NULL,
@@ -378,6 +393,14 @@ int cmd_tag(int argc, const char **argv, const char *prefix)
OPT_STRING('u', NULL, &keyid, "key-id",
"use another key to sign the tag"),
OPT_BOOLEAN('f', NULL, &force, "replace the tag if exists"),
+
+ OPT_GROUP("Tag listing options"),
+ {
+ OPTION_CALLBACK, 0, "contains", &with_commit, "commit",
+ "print only tags that contain the commit",
+ PARSE_OPT_LASTARG_DEFAULT,
+ parse_opt_with_commit, (intptr_t)"HEAD",
+ },
OPT_END()
};
@@ -402,9 +425,12 @@ int cmd_tag(int argc, const char **argv, const char *prefix)
if (list + delete + verify > 1)
usage_with_options(git_tag_usage, options);
if (list)
- return list_tags(argv[0], lines == -1 ? 0 : lines);
+ return list_tags(argv[0], lines == -1 ? 0 : lines,
+ with_commit);
if (lines != -1)
die("-n option is only allowed with -l.");
+ if (with_commit)
+ die("--contains option is only allowed with -l.");
if (delete)
return for_each_tag_name(argv, delete_tag);
if (verify)
diff --git a/t/t7004-tag.sh b/t/t7004-tag.sh
index f377fea..69501e2 100755
--- a/t/t7004-tag.sh
+++ b/t/t7004-tag.sh
@@ -1090,6 +1090,121 @@ test_expect_success 'filename for the message is relative to cwd' '
git cat-file tag tag-from-subdir-2 | grep "in sub directory"
'
+# create a few more commits to test --contains
+
+hash1=$(git rev-parse HEAD)
+
+test_expect_success 'creating second commit and tag' '
+ echo foo-2.0 >foo &&
+ git add foo &&
+ git commit -m second
+ git tag v2.0
+'
+
+hash2=$(git rev-parse HEAD)
+
+test_expect_success 'creating third commit without tag' '
+ echo foo-dev >foo &&
+ git add foo &&
+ git commit -m third
+'
+
+hash3=$(git rev-parse HEAD)
+
+# simple linear checks of --continue
+
+cat > expected <<EOF
+v0.2.1
+v1.0
+v1.0.1
+v1.1.3
+v2.0
+EOF
+
+test_expect_success 'checking that first commit is in all tags (hash)' "
+ git tag -l --contains $hash1 v* >actual
+ test_cmp expected actual
+"
+
+# other ways of specifying the commit
+test_expect_success 'checking that first commit is in all tags (tag)' "
+ git tag -l --contains v1.0 v* >actual
+ test_cmp expected actual
+"
+
+test_expect_success 'checking that first commit is in all tags (relative)' "
+ git tag -l --contains HEAD~2 v* >actual
+ test_cmp expected actual
+"
+
+cat > expected <<EOF
+v2.0
+EOF
+
+test_expect_success 'checking that second commit only has one tag' "
+ git tag -l --contains $hash2 v* >actual
+ test_cmp expected actual
+"
+
+
+cat > expected <<EOF
+EOF
+
+test_expect_success 'checking that third commit has no tags' "
+ git tag -l --contains $hash3 v* >actual
+ test_cmp expected actual
+"
+
+# how about a simple merge?
+
+test_expect_success 'creating simple branch' '
+ git branch stable v2.0 &&
+ git checkout stable &&
+ echo foo-3.0 > foo &&
+ git commit foo -m fourth
+ git tag v3.0
+'
+
+hash4=$(git rev-parse HEAD)
+
+cat > expected <<EOF
+v3.0
+EOF
+
+test_expect_success 'checking that branch head only has one tag' "
+ git tag -l --contains $hash4 v* >actual
+ test_cmp expected actual
+"
+
+test_expect_success 'merging original branch into this branch' '
+ git merge --strategy=ours master &&
+ git tag v4.0
+'
+
+cat > expected <<EOF
+v4.0
+EOF
+
+test_expect_success 'checking that original branch head has one tag now' "
+ git tag -l --contains $hash3 v* >actual
+ test_cmp expected actual
+"
+
+cat > expected <<EOF
+v0.2.1
+v1.0
+v1.0.1
+v1.1.3
+v2.0
+v3.0
+v4.0
+EOF
+
+test_expect_success 'checking that initial commit is in all tags' "
+ git tag -l --contains $hash1 v* >actual
+ test_cmp expected actual
+"
+
# mixing modes and options:
test_expect_success 'mixing incompatibles modes and options is forbidden' '
--
1.6.0.6
^ permalink raw reply related
* [PATCH 1/3] Make opt_parse_with_commit non-static
From: Jake Goulding @ 2009-01-26 14:13 UTC (permalink / raw)
To: git; +Cc: gitster, Jake Goulding
Moving opt_parse_with_commit from branch to a common location in
preparation for using it in tag. Renamed it to correspond to naming
convention of other option parsing functions.
Signed-off-by: Jake Goulding <goulding@vivisimo.com>
---
builtin-branch.c | 20 ++------------------
parse-options.c | 17 +++++++++++++++++
parse-options.h | 1 +
3 files changed, 20 insertions(+), 18 deletions(-)
diff --git a/builtin-branch.c b/builtin-branch.c
index 02fa38f..82d6fb2 100644
--- a/builtin-branch.c
+++ b/builtin-branch.c
@@ -466,22 +466,6 @@ static void rename_branch(const char *oldname, const char *newname, int force)
strbuf_release(&newsection);
}
-static int opt_parse_with_commit(const struct option *opt, const char *arg, int unset)
-{
- unsigned char sha1[20];
- struct commit *commit;
-
- if (!arg)
- return -1;
- if (get_sha1(arg, sha1))
- die("malformed object name %s", arg);
- commit = lookup_commit_reference(sha1);
- if (!commit)
- die("no such commit %s", arg);
- commit_list_insert(commit, opt->value);
- return 0;
-}
-
static int opt_parse_merge_filter(const struct option *opt, const char *arg, int unset)
{
merge_filter = ((opt->long_name[0] == 'n')
@@ -517,13 +501,13 @@ int cmd_branch(int argc, const char **argv, const char *prefix)
OPTION_CALLBACK, 0, "contains", &with_commit, "commit",
"print only branches that contain the commit",
PARSE_OPT_LASTARG_DEFAULT,
- opt_parse_with_commit, (intptr_t)"HEAD",
+ parse_opt_with_commit, (intptr_t)"HEAD",
},
{
OPTION_CALLBACK, 0, "with", &with_commit, "commit",
"print only branches that contain the commit",
PARSE_OPT_HIDDEN | PARSE_OPT_LASTARG_DEFAULT,
- opt_parse_with_commit, (intptr_t) "HEAD",
+ parse_opt_with_commit, (intptr_t) "HEAD",
},
OPT__ABBREV(&abbrev),
diff --git a/parse-options.c b/parse-options.c
index 9eb55cc..4c5d09d 100644
--- a/parse-options.c
+++ b/parse-options.c
@@ -1,6 +1,7 @@
#include "git-compat-util.h"
#include "parse-options.h"
#include "cache.h"
+#include "commit.h"
#define OPT_SHORT 1
#define OPT_UNSET 2
@@ -506,6 +507,22 @@ int parse_opt_verbosity_cb(const struct option *opt, const char *arg,
return 0;
}
+int parse_opt_with_commit(const struct option *opt, const char *arg, int unset)
+{
+ unsigned char sha1[20];
+ struct commit *commit;
+
+ if (!arg)
+ return -1;
+ if (get_sha1(arg, sha1))
+ return error("malformed object name %s", arg);
+ commit = lookup_commit_reference(sha1);
+ if (!commit)
+ return error("no such commit %s", arg);
+ commit_list_insert(commit, opt->value);
+ return 0;
+}
+
/*
* This should really be OPTION_FILENAME type as a part of
* parse_options that take prefix to do this while parsing.
diff --git a/parse-options.h b/parse-options.h
index 034162e..9122905 100644
--- a/parse-options.h
+++ b/parse-options.h
@@ -151,6 +151,7 @@ extern int parse_options_end(struct parse_opt_ctx_t *ctx);
extern int parse_opt_abbrev_cb(const struct option *, const char *, int);
extern int parse_opt_approxidate_cb(const struct option *, const char *, int);
extern int parse_opt_verbosity_cb(const struct option *, const char *, int);
+extern int parse_opt_with_commit(const struct option *, const char *, int);
#define OPT__VERBOSE(var) OPT_BOOLEAN('v', "verbose", (var), "be verbose")
#define OPT__QUIET(var) OPT_BOOLEAN('q', "quiet", (var), "be quiet")
--
1.6.0.6
^ permalink raw reply related
* rerere: how to remove an erroneous resolution?
From: SZEDER Gábor @ 2009-01-26 14:42 UTC (permalink / raw)
To: git
Hi,
some time ago I mistakenly resolved a merge conflict incorrectly. Of
course, rerere noted the erroneous conflict resolution, and whenever
the same merge conflict occurs rerere offers me that erroneous
conflict resolution, even though I correct it each time.
So, the question is how could I make rerere forget that particular
merge conflict resolution? Is it at all possible?
Thanks,
Gábor
^ permalink raw reply
* Re: rerere: how to remove an erroneous resolution?
From: SZEDER Gábor @ 2009-01-26 15:13 UTC (permalink / raw)
To: git
In-Reply-To: <20090126144239.GA494@neumann>
On Mon, Jan 26, 2009 at 03:42:39PM +0100, SZEDER Gábor wrote:
> some time ago I mistakenly resolved a merge conflict incorrectly. Of
> course, rerere noted the erroneous conflict resolution, and whenever
> the same merge conflict occurs rerere offers me that erroneous
> conflict resolution, even though I correct it each time.
>
> So, the question is how could I make rerere forget that particular
> merge conflict resolution? Is it at all possible?
Ok, I should have investigated a little longer before sending that
email.
I thought that .git/rr-cache contains some kind of sha1-named objects,
and did not realize that those are indeed directories with just
plaintext pre- and postimage files in it. So, after some grepping I
could identify the sought conflict resolution fairly easily, and
correct it.
Best,
Gábor
^ permalink raw reply
* Re: backwards compatibility, was Re: [PATCH v1 1/3] Introduce config variable "diff.primer"
From: Jay Soffian @ 2009-01-26 15:29 UTC (permalink / raw)
To: Jeff King; +Cc: Johannes Schindelin, Keith Cascio, Junio C Hamano, git
In-Reply-To: <20090126111605.GB19993@coredump.intra.peff.net>
On Mon, Jan 26, 2009 at 6:16 AM, Jeff King <peff@peff.net> wrote:
> I don't want to break existing setups, either. But at some point you
> have to say "this is porcelain, so don't rely on there not being any
> user-triggered effects in its behavior". If porcelain is cast in stone,
> then what is the point in differentiating plumbing from porcelain?
>
> And when the line is blurred (as I think it is in several places)
Aside, AIX has commands that are run both directly or via smit (a
curses-based interface). When smit calls the commands, it passes a
switch to let said commands know that they are being run from smit.
e.g.:
-J
This flag is used when the installp command is executed from the
System Management Interface Tool (SMIT) menus.
Perhaps adding such a concept to those git commands which can be used
in both porcelain and plumbing contexts would be useful for git.
j.
^ permalink raw reply
* Re: Translations [of Documentation] in Git release?
From: Jakub Narebski @ 2009-01-26 15:31 UTC (permalink / raw)
To: Peter Krefting; +Cc: Dill, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0901261426350.7798@ds9.cixit.se>
On Mon, 26 Jan 2009, Peter Krefting wrote:
> Jakub Narebski wrote:
>
> > With GUI translations we just use gettext conventions. I don't know
> > any such convention for docs:
>
> There is a lot of documentation being translated using PO files. po4a -
> http://po4a.alioth.debian.org/ - is a nice starting point for that.
I'm not sure if XLIFF wouldn't be better format to use to translate
_documents_. Gettext was meant to translate, I think, not very long
messages in programs.
Also I am not sure how much support this idea has. True, in last Git
User's Survey[1] 63% to 76% wanted (parts of) Documentation... but that
was out of 325 people who answered this question, with 3236 responses
to survey in total, so numbers are more like 6% - 8%.
[1] http://git.or.cz/gitwiki/GitSurvey2008
[2] http://translate.sourceforge.net/wiki/
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] Allow format-patch to create patches for merges
From: Johannes Schindelin @ 2009-01-26 15:36 UTC (permalink / raw)
To: Nathan W. Panike; +Cc: git, gitster, aspotashev
In-Reply-To: <1232978650-7008-1-git-send-email-nathan.panike@gmail.com>
Hi,
On Mon, 26 Jan 2009, Nathan W. Panike wrote:
> The behavior for git format-patch is to ignore merge commits, producing
> an empty patch. The code does not allow the user to change this
> behavior. This patch changes that behavior by allowing the user to
> specify -c or -m at the command line to produce a patch for a merge
> commit.
Your patch is almost perfect, except that you
- lack an explanation when this makes sense (format-patch is commonly used
for mail-based patch queues, and only -m 1 would make sense there, and
only if you run format-patch with --first-parent),
- did not add your Sign-off :-)
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 2/3] Make has_commit non-static
From: Johannes Schindelin @ 2009-01-26 15:38 UTC (permalink / raw)
To: Jake Goulding; +Cc: git, gitster
In-Reply-To: <1232979205-17161-2-git-send-email-goulding@vivisimo.com>
Hi,
On Mon, 26 Jan 2009, Jake Goulding wrote:
> Moving has_commit from branch to a common location in preparation for
> using it in tag. Renaming it to commit_has_any_in_commit_list to be more
> unique.
I feel like bike-shedding for a change, and I'd also like to prove that
not all Germans like long names:
is_ancestor_of_any()
Hmm?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] mergetool: respect autocrlf by using checkout-index
From: Hannu Koivisto @ 2009-01-26 16:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Charles Bailey, git, Theodore Tso
In-Reply-To: <7v1vuuvt11.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Charles Bailey <charles@hashpling.org> writes:
>
>> Previously, git mergetool used cat-file which does not perform git to
>> worktree conversion. This changes mergetool to use git checkout-index
>> instead which means that the temporary files used for mergetool use the
>> correct line endings for the platform.
>>
>> Signed-off-by: Charles Bailey <charles@hashpling.org>
>
> Sounds like the right thing to do and from a cursory review it looks Ok to
> me.
>
> But I do not use mergetool myself, so an Ack from Ted and a Thanks from
> whoever reported the breakage would be encouraging ;-).
I apologize for not being able to test this earlier and I'm
certainly thankful for the patch, although admittedly I reported
the issue mainly to help improve git, not because mergetool is part
of my normal use of git (that may change when I find time to study it
and see if I can easily add ediff support to it in addition to
emerge).
Now that I tried the patch, I observed that while the stage2 and
stage3 temporary files have CRLF line endings, the merge result
buffer/file has LF line endings. I'm again using Cygwin git,
mergetool -t emerge and native Windows Emacs. So when I quit the
mergetool, I get
...
Hit return to start merge resolution tool (emerge):
warning: LF will be replaced by CRLF in kala.txt
warning: LF will be replaced by CRLF in kala.txt
and indeed hexdump proves that the file in my worktree now has LF
line endings even though it had CRLF line endings before invoking
mergetool.
I wonder why I didn't notice this the first time. I can certainly
reproduce it now without Charles' patch as well so I suppose this
is a separate issue and the patch does what it is supposed to do.
--
Hannu
^ permalink raw reply
* Re: Heads up: major rebase -i -p rework coming up
From: Marc Branchaud @ 2009-01-26 16:21 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Junio C Hamano, Stephan Beyer, git, Stephen Haberman, spearce,
Thomas Rast, Björn Steinbrink
In-Reply-To: <alpine.DEB.1.00.0901242156320.14855@racer>
I'm sorry, but I just don't understand the purpose of 'was E' (or
whatever syntax) in the merge command. Why is there a need to refer to
E at all? The only reason I can think of is to replicate E's commit
message. Am I missing something?
Come to think of it, what if the user wants to edit a merge commit's
message? Should there be an 'editmerge' command?
M.
Johannes Schindelin wrote:
>
>> - Why do you need "merge D' was E"? Shouldn't "pick E" be able to
>> notice that E is a merge and decompose it into "merge D' was E"
>> internally?
>>
>> This one I am somewhat complaining, unless your answer is "because
>> this way the user could drop some parents from the merge in the
>> editor".
>
> Not only that; the user could use this to fix mismerges, i.e. by replacing
> a SHA-1 with the SHA-1 (or indeed, a short name, unless it is "was") of
> the branch that she _actually_ wanted to merge with.
>
>> And if your answer is that, then my next question will be "if that is
>> the case, can the user be expected to easily find out which commit
>> each parent SHA-1 refers to, without having more hint on the 'merge'
>> insn line?"
>
> Nope.
>
> In most cases, however, that should be plenty enough:
>
> merge 9383af1' was f39d50a Merge branch 'mh/unify-color' into next
>
> The user does not have to guess much what 9383af1 might refer to.
^ permalink raw reply
* Re: Translations [of Documentation] in Git release?
From: Mike Hommey @ 2009-01-26 16:23 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Peter Krefting, Dill, Git Mailing List
In-Reply-To: <200901261631.18157.jnareb@gmail.com>
On Mon, Jan 26, 2009 at 04:31:17PM +0100, Jakub Narebski wrote:
> On Mon, 26 Jan 2009, Peter Krefting wrote:
> > Jakub Narebski wrote:
> >
> > > With GUI translations we just use gettext conventions. I don't know
> > > any such convention for docs:
> >
> > There is a lot of documentation being translated using PO files. po4a -
> > http://po4a.alioth.debian.org/ - is a nice starting point for that.
>
> I'm not sure if XLIFF wouldn't be better format to use to translate
> _documents_. Gettext was meant to translate, I think, not very long
> messages in programs.
>
> Also I am not sure how much support this idea has. True, in last Git
> User's Survey[1] 63% to 76% wanted (parts of) Documentation... but that
> was out of 325 people who answered this question, with 3236 responses
> to survey in total, so numbers are more like 6% - 8%.
On the other hand, the people who would really need the translations
didn't answer the survey at all, since they couldn't read it.
Mike
^ permalink raw reply
* [PATCH] make: By default, remove -pthread on Darwin (it is included by cstdlib).
From: Ted Pavlic @ 2009-01-26 16:26 UTC (permalink / raw)
To: gitster; +Cc: git, Ted Pavlic
As discussed in
http://lists.apple.com/archives/Unix-porting/2005/Mar/msg00019.html
the Mac OS X C standard library is always thread safe and always
includes the pthread library. So explicitly using -pthread causes an
'unrecognized option' compiler warning.
This patch clears PTHREAD_LIBS by default. However, if
FORCE_DARWIN_PTHREAD_LIBS is defined, then PTHREAD_LIBS will be set as
before.
Signed-off-by: Ted Pavlic <ted@tedpavlic.com>
---
Makefile | 12 ++++++++++++
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/Makefile b/Makefile
index b4d9cb4..30764af 100644
--- a/Makefile
+++ b/Makefile
@@ -70,6 +70,15 @@ all::
# specify your own (or DarwinPort's) include directories and
# library directories by defining CFLAGS and LDFLAGS appropriately.
#
+#
+# Define FORCE_DARWIN_PTHREAD_LIBS if you are building on Darwin/Mac OS
+# X and want PTHREAD_LIBS to be set. On Mac OS X, all components of the
+# C standard library that are defined to be thread safe by the POSIX
+# standard already include the pthread library. Hence, the -pthread
+# option is redundant and will generate an 'unrecognized option'
+# warning. So PTHREAD_LIBS will be cleared unless
+# FORCE_DARWIN_PTHREAD_LIBS is set.
+#
# Define PPC_SHA1 environment variable when running make to make use of
# a bundled SHA1 routine optimized for PowerPC.
#
@@ -817,6 +826,9 @@ ifeq ($(uname_S),Darwin)
BASIC_LDFLAGS += -L/opt/local/lib
endif
endif
+ ifndef FORCE_DARWIN_PTHREAD_LIBS
+ PTHREAD_LIBS =
+ endif
endif
ifndef CC_LD_DYNPATH
--
1.6.1.213.g28da8
^ permalink raw reply related
* Re: [PATCH] Allow format-patch to create patches for merges
From: Nathan W. Panike @ 2009-01-26 16:27 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0901261604420.25749@intel-tinevez-2-302>
On Mon, Jan 26, 2009 at 9:36 AM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Mon, 26 Jan 2009, Nathan W. Panike wrote:
>
>> The behavior for git format-patch is to ignore merge commits, producing
>> an empty patch. The code does not allow the user to change this
>> behavior. This patch changes that behavior by allowing the user to
>> specify -c or -m at the command line to produce a patch for a merge
>> commit.
>
> Your patch is almost perfect, except that you
>
> - lack an explanation when this makes sense (format-patch is commonly used
> for mail-based patch queues, and only -m 1 would make sense there, and
> only if you run format-patch with --first-parent),
>
I think I have an unusual workflow where my patch makes sense,
although it probably does not for the vast majority of git users. I
regularly use 3 machines: S, L, and H. I keep my work synchronized by
using git. Normally, I fetch from S to L or to H, depending on which
machine I am working on at the moment. I also push from L or H to S.
I sporadically lose connectivity to S, so I have a hook in the repo on
S to send a backup email to me on mail server M, which has a more
reliable connection. This email also serves as a reminder when I
have moved from one machine to another with a degree of latency; and I
can use the mail queue on M to recreate most of my state, if I cannot
fetch from S. In this workflow, I would really like git to create a
patch, even in the merge case, and I think I want to see that it was a
merge.
What I do not want to see is an empty patch when a non-trivial change
has occurred, which is the way it works now.
Also, I think I must be issuing the wrong command, as when I do
git format-patch --first-parent --stdout -1 $merge_commit
there is no data, with or without my patch.
> - did not add your Sign-off :-)
Oops. Thanks for the catch.
>
> Ciao,
> Dscho
>
>
^ permalink raw reply
* Hosting from Windows XP.
From: Tim Visher @ 2009-01-26 16:27 UTC (permalink / raw)
To: git
Hello Everyone,
I'm trying to get git set up for my company. We're stuck using
Windows for the foreseeable future so for now I have to host the
central integration repository out of a Windows box. I figured the
easiest way to do this, short of installing cygwin, would be to do a
simple msysgit install and then run git daemon with the relevant repo
copied over onto the server. Then devs could track that repo.
However, it appears that msysgit does not install git daemon.
I may totally be missing something here, but I don't know what. Short
of the question is, how do I host a repo out of Windows?
Thanks in advance!
--
In Christ,
Timmy V.
http://burningones.com/
http://five.sentenc.es/ - Spend less time on e-mail
^ permalink raw reply
* Re: [PATCH] mergetool: respect autocrlf by using checkout-index
From: Charles Bailey @ 2009-01-26 16:31 UTC (permalink / raw)
To: Hannu Koivisto; +Cc: Junio C Hamano, git, Theodore Tso
In-Reply-To: <83skn6doxm.fsf@kalahari.s2.org>
On Mon, Jan 26, 2009 at 06:15:01PM +0200, Hannu Koivisto wrote:
>
> Now that I tried the patch, I observed that while the stage2 and
> stage3 temporary files have CRLF line endings, the merge result
> buffer/file has LF line endings. I'm again using Cygwin git,
> mergetool -t emerge and native Windows Emacs. So when I quit the
> mergetool, I get
>
> ...
> Hit return to start merge resolution tool (emerge):
> warning: LF will be replaced by CRLF in kala.txt
> warning: LF will be replaced by CRLF in kala.txt
>
> and indeed hexdump proves that the file in my worktree now has LF
> line endings even though it had CRLF line endings before invoking
> mergetool.
>
> I wonder why I didn't notice this the first time. I can certainly
> reproduce it now without Charles' patch as well so I suppose this
> is a separate issue and the patch does what it is supposed to do.
mergetool doesn't touch the destination file, it just asks the merge
tool to overwrite it.
I suspect that the LF endings in the file is due to the fact that in
builtin-merge-file.c, the file is opened (fopen) in binary mode
("wb"), but xdl_merge terminates all lines with a raw '\n'.
The obvious fix would be to change fopen in builtin-file-merge.c to
use "w" instead, but this doesn't work in a number of scenarios. In
particular, it is wrong for repositories on windows with core.autocrlf
set to false, and would not fix non-windows repositories with
core.autocrlf set to true.
Currently, I've no idea as to what the solution should be.
--
Charles Bailey
http://ccgi.hashpling.plus.com/blog/
^ permalink raw reply
* Re: Hosting from Windows XP.
From: Shawn O. Pearce @ 2009-01-26 16:31 UTC (permalink / raw)
To: Tim Visher; +Cc: git
In-Reply-To: <c115fd3c0901260827ge5e4b29w871b345da2373f6b@mail.gmail.com>
Tim Visher <tim.visher@gmail.com> wrote:
> I'm trying to get git set up for my company. We're stuck using
> Windows for the foreseeable future so for now I have to host the
> central integration repository out of a Windows box. I figured the
> easiest way to do this, short of installing cygwin, would be to do a
> simple msysgit install and then run git daemon with the relevant repo
> copied over onto the server. Then devs could track that repo.
> However, it appears that msysgit does not install git daemon.
git-daemon isn't ported yet, due to its heavy reliance on POSIX
behavior during fork+exec.
> I may totally be missing something here, but I don't know what. Short
> of the question is, how do I host a repo out of Windows?
I think your options are limited to:
- Use Cygwin
- Use a virtual machine running Linux with git inside it
- Use JGit and its daemon
--
Shawn.
^ permalink raw reply
* [PATCH (update)] make: By default, remove -pthread on Darwin (it is included by cstdlib).
From: Ted Pavlic @ 2009-01-26 16:33 UTC (permalink / raw)
To: gitster; +Cc: git, Ted Pavlic
In-Reply-To: <1232987160-5635-1-git-send-email-ted@tedpavlic.com>
As discussed in
http://lists.apple.com/archives/Unix-porting/2005/Mar/msg00019.html
the Mac OS X C standard library is always thread safe and always
includes the pthread library. So explicitly using -pthread causes an
'unrecognized option' compiler warning.
This patch clears PTHREAD_LIBS by default. However, if
FORCE_DARWIN_PTHREAD_LIBS is defined, then PTHREAD_LIBS will be set as
before.
Signed-off-by: Ted Pavlic <ted@tedpavlic.com>
---
This update adds the documentation comment in the Makefile to
configure.ac as well.
Makefile | 11 +++++++++++
configure.ac | 8 ++++++++
2 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/Makefile b/Makefile
index b4d9cb4..86f0a66 100644
--- a/Makefile
+++ b/Makefile
@@ -70,6 +70,14 @@ all::
# specify your own (or DarwinPort's) include directories and
# library directories by defining CFLAGS and LDFLAGS appropriately.
#
+# Define FORCE_DARWIN_PTHREAD_LIBS if you are building on Darwin/Mac OS
+# X and want PTHREAD_LIBS to be set. On Mac OS X, all components of the
+# C standard library that are defined to be thread safe by the POSIX
+# standard already include the pthread library. Hence, the -pthread
+# option is redundant and will generate an 'unrecognized option'
+# warning. So PTHREAD_LIBS will be cleared unless
+# FORCE_DARWIN_PTHREAD_LIBS is set.
+#
# Define PPC_SHA1 environment variable when running make to make use of
# a bundled SHA1 routine optimized for PowerPC.
#
@@ -817,6 +825,9 @@ ifeq ($(uname_S),Darwin)
BASIC_LDFLAGS += -L/opt/local/lib
endif
endif
+ ifndef FORCE_DARWIN_PTHREAD_LIBS
+ PTHREAD_LIBS =
+ endif
endif
ifndef CC_LD_DYNPATH
diff --git a/configure.ac b/configure.ac
index 082a03d..a53d97c 100644
--- a/configure.ac
+++ b/configure.ac
@@ -578,6 +578,14 @@ GIT_PARSE_WITH(expat))
# specify your own (or DarwinPort's) include directories and
# library directories by defining CFLAGS and LDFLAGS appropriately.
#
+# Define FORCE_DARWIN_PTHREAD_LIBS if you are building on Darwin/Mac OS
+# X and want PTHREAD_LIBS to be set. On Mac OS X, all components of the
+# C standard library that are defined to be thread safe by the POSIX
+# standard already include the pthread library. Hence, the -pthread
+# option is redundant and will generate an 'unrecognized option'
+# warning. So PTHREAD_LIBS will be cleared unless
+# FORCE_DARWIN_PTHREAD_LIBS is set.
+#
# Define NO_MMAP if you want to avoid mmap.
#
# Define NO_ICONV if your libc does not properly support iconv.
--
1.6.1.213.g28da8
^ 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