* [PATCH] Fix typos involving the word 'commit'
From: Alp Toker @ 2006-07-09 9:36 UTC (permalink / raw)
To: git; +Cc: Alp Toker
In-Reply-To: <11524377844177-git-send-email-alp@atoker.com>
Signed-off-by: Alp Toker <alp@atoker.com>
---
Documentation/git-cvsexportcommit.txt | 2 +-
refs.c | 12 ++++++------
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/Documentation/git-cvsexportcommit.txt b/Documentation/git-cvsexportcommit.txt
index 56bd3e5..27ac72d 100644
--- a/Documentation/git-cvsexportcommit.txt
+++ b/Documentation/git-cvsexportcommit.txt
@@ -8,7 +8,7 @@ git-cvsexportcommit - Export a commit to
SYNOPSIS
--------
-'git-cvsexportcommmit' [-h] [-v] [-c] [-p] [-f] [-m msgprefix] [PARENTCOMMIT] COMMITID
+'git-cvsexportcommit' [-h] [-v] [-c] [-p] [-f] [-m msgprefix] [PARENTCOMMIT] COMMITID
DESCRIPTION
diff --git a/refs.c b/refs.c
index 713ca46..2d9c1dc 100644
--- a/refs.c
+++ b/refs.c
@@ -362,7 +362,7 @@ static int log_ref_write(struct ref_lock
int logfd, written, oflags = O_APPEND | O_WRONLY;
unsigned maxlen, len;
char *logrec;
- const char *comitter;
+ const char *committer;
if (log_all_ref_updates) {
if (safe_create_leading_directories(lock->log_file) < 0)
@@ -380,23 +380,23 @@ static int log_ref_write(struct ref_lock
}
setup_ident();
- comitter = git_committer_info(1);
+ committer = git_committer_info(1);
if (msg) {
- maxlen = strlen(comitter) + strlen(msg) + 2*40 + 5;
+ maxlen = strlen(committer) + strlen(msg) + 2*40 + 5;
logrec = xmalloc(maxlen);
len = snprintf(logrec, maxlen, "%s %s %s\t%s\n",
sha1_to_hex(lock->old_sha1),
sha1_to_hex(sha1),
- comitter,
+ committer,
msg);
}
else {
- maxlen = strlen(comitter) + 2*40 + 4;
+ maxlen = strlen(committer) + 2*40 + 4;
logrec = xmalloc(maxlen);
len = snprintf(logrec, maxlen, "%s %s %s\n",
sha1_to_hex(lock->old_sha1),
sha1_to_hex(sha1),
- comitter);
+ committer);
}
written = len <= maxlen ? write(logfd, logrec, len) : -1;
free(logrec);
--
1.4.1.gbe4c7
^ permalink raw reply related
* Re: [RFC/PATCH 3] Copy description of build configuration variables to configure.ac
From: Junio C Hamano @ 2006-07-09 8:21 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <11523928361444-git-send-email-jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> Copy description of build configuration variables from the commentary
> in the top Makefile (from 'next' branch) to configure.ac, splitting
> them into "autoconf" sections.
I do not see much point in this -- they will become out of sync.
Eventually when all the --with-* and --enable-* stuff are
implemented, you can ask the generated configure what options
are supported, so I do not think this would help the end user
either. In other words it is strictly for supporting
developers. I think you are better off making a list of
supported and yet to be supported ones in the comment in
configure.ac, and when you want to see if the list got stale
over time, grep for '^# Define' from the Makefile and match them
up.
^ permalink raw reply
* Re: [PATCH] Assorted typo fixes
From: Pavel Roskin @ 2006-07-09 7:45 UTC (permalink / raw)
To: git
In-Reply-To: <1152430563.6603.5.camel@dv>
On Sun, 2006-07-09 at 03:36 -0400, Pavel Roskin wrote:
> Assorted typo fixes
>
> Signed-off-by: Pavel Roskin <proski@gnu.org>
>
> ---
> This is for "next". "interopability" didn't make it to "master" yet.
Sorry, it got "wrapped". Resending with StGIT now.
--
Regards,
Pavel Roskin
^ permalink raw reply
* [PATCH] Assorted typo fixes
From: Pavel Roskin @ 2006-07-09 7:44 UTC (permalink / raw)
To: git
From: Pavel Roskin <proski@gnu.org>
---
Documentation/SubmittingPatches | 2 +-
Documentation/cvs-migration.txt | 2 +-
Documentation/git-diff-files.txt | 2 +-
Documentation/git-init-db.txt | 2 +-
Documentation/git-mailsplit.txt | 2 +-
Documentation/git-merge.txt | 2 +-
Documentation/git-p4import.txt | 4 ++--
Documentation/git-pack-redundant.txt | 2 +-
Documentation/git-push.txt | 2 +-
Documentation/git-repo-config.txt | 4 ++--
Documentation/git-rev-list.txt | 2 +-
Documentation/git-tools.txt | 2 +-
Documentation/git-upload-tar.txt | 2 +-
Documentation/git.txt | 2 +-
Documentation/howto/isolate-bugs-with-bisect.txt | 2 +-
.../howto/rebase-from-internal-branch.txt | 2 +-
Documentation/technical/pack-heuristics.txt | 8 ++++----
INSTALL | 4 ++--
Makefile | 6 +++---
git-cvsserver.perl | 14 +++++++-------
server-info.c | 2 +-
21 files changed, 35 insertions(+), 35 deletions(-)
diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
index 8601949..90722c2 100644
--- a/Documentation/SubmittingPatches
+++ b/Documentation/SubmittingPatches
@@ -49,7 +49,7 @@ People on the git mailing list need to b
comment on the changes you are submitting. It is important for
a developer to be able to "quote" your changes, using standard
e-mail tools, so that they may comment on specific portions of
-your code. For this reason, all patches should be submited
+your code. For this reason, all patches should be submitted
"inline". WARNING: Be wary of your MUAs word-wrap
corrupting your patch. Do not cut-n-paste your patch; you can
lose tabs that way if you are not careful.
diff --git a/Documentation/cvs-migration.txt b/Documentation/cvs-migration.txt
index 1fbca83..d2b0bd3 100644
--- a/Documentation/cvs-migration.txt
+++ b/Documentation/cvs-migration.txt
@@ -93,7 +93,7 @@ machine where the repository is hosted.
full shell on the machine, there is a restricted shell which only allows
users to do git pushes and pulls; see gitlink:git-shell[1].
-Put all the committers should in the same group, and make the repository
+Put all the committers in the same group, and make the repository
writable by that group:
------------------------------------------------
diff --git a/Documentation/git-diff-files.txt b/Documentation/git-diff-files.txt
index 481b8b3..7248b35 100644
--- a/Documentation/git-diff-files.txt
+++ b/Documentation/git-diff-files.txt
@@ -37,7 +37,7 @@ omit diff output for unmerged entries an
commit with these flags.
-q::
- Remain silent even on nonexisting files
+ Remain silent even on nonexistent files
Output format
-------------
diff --git a/Documentation/git-init-db.txt b/Documentation/git-init-db.txt
index 8a150d8..0a4fc14 100644
--- a/Documentation/git-init-db.txt
+++ b/Documentation/git-init-db.txt
@@ -25,7 +25,7 @@ DESCRIPTION
-----------
This command creates an empty git repository - basically a `.git` directory
with subdirectories for `objects`, `refs/heads`, `refs/tags`, and
-templated files.
+template files.
An initial `HEAD` file that references the HEAD of the master branch
is also created.
diff --git a/Documentation/git-mailsplit.txt b/Documentation/git-mailsplit.txt
index 209e36b..5a17801 100644
--- a/Documentation/git-mailsplit.txt
+++ b/Documentation/git-mailsplit.txt
@@ -25,7 +25,7 @@ OPTIONS
-b::
If any file doesn't begin with a From line, assume it is a
- single mail message instead of signalling error.
+ single mail message instead of signaling error.
-d<prec>::
Instead of the default 4 digits with leading zeros,
diff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt
index 4ce799b..bebf30a 100644
--- a/Documentation/git-merge.txt
+++ b/Documentation/git-merge.txt
@@ -83,7 +83,7 @@ your local modifications interfere with
stops before touching anything.
So in the above two "failed merge" case, you do not have to
-worry about lossage of data --- you simply were not ready to do
+worry about loss of data --- you simply were not ready to do
a merge, so no merge happened at all. You may want to finish
whatever you were in the middle of doing, and retry the same
pull after you are done and ready.
diff --git a/Documentation/git-p4import.txt b/Documentation/git-p4import.txt
index 0858e5e..ee9e8fa 100644
--- a/Documentation/git-p4import.txt
+++ b/Documentation/git-p4import.txt
@@ -128,7 +128,7 @@ Tags
A git tag of the form p4/xx is created for every change imported from
the Perforce repository where xx is the Perforce changeset number.
Therefore after the import you can use git to access any commit by its
-Perforce number, eg. git show p4/327.
+Perforce number, e.g. git show p4/327.
The tag associated with the HEAD commit is also how `git-p4import`
determines if there are new changes to incrementally import from the
@@ -143,7 +143,7 @@ may delete the tags.
Notes
-----
-You can interrupt the import (eg. ctrl-c) at any time and restart it
+You can interrupt the import (e.g. ctrl-c) at any time and restart it
without worry.
Author information is automatically determined by querying the
diff --git a/Documentation/git-pack-redundant.txt b/Documentation/git-pack-redundant.txt
index 8fb0659..7d54b17 100644
--- a/Documentation/git-pack-redundant.txt
+++ b/Documentation/git-pack-redundant.txt
@@ -29,7 +29,7 @@ OPTIONS
--all::
- Processes all packs. Any filenames on the commandline are ignored.
+ Processes all packs. Any filenames on the command line are ignored.
--alt-odb::
Don't require objects present in packs from alternate object
diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index d5b5ca1..56afd64 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -67,7 +67,7 @@ Some short-cut notations are also suppor
-f, \--force::
Usually, the command refuses to update a remote ref that is
- not a descendent of the local ref used to overwrite it.
+ not a descendant of the local ref used to overwrite it.
This flag disables the check. This can cause the
remote repository to lose commits; use it with care.
diff --git a/Documentation/git-repo-config.txt b/Documentation/git-repo-config.txt
index cc72fa9..8a1ab61 100644
--- a/Documentation/git-repo-config.txt
+++ b/Documentation/git-repo-config.txt
@@ -120,8 +120,8 @@ you can set the filemode to true with
% git repo-config core.filemode true
------------
-The hypothetic proxy command entries actually have a postfix to discern
-to what URL they apply. Here is how to change the entry for kernel.org
+The hypothetical proxy command entries actually have a postfix to discern
+what URL they apply to. Here is how to change the entry for kernel.org
to "ssh".
------------
diff --git a/Documentation/git-rev-list.txt b/Documentation/git-rev-list.txt
index 6c370e1..e220842 100644
--- a/Documentation/git-rev-list.txt
+++ b/Documentation/git-rev-list.txt
@@ -64,7 +64,7 @@ OPTIONS
--objects-edge::
Similar to `--objects`, but also print the IDs of
- excluded commits refixed with a `-` character. This is
+ excluded commits prefixed with a `-` character. This is
used by `git-pack-objects` to build 'thin' pack, which
records objects in deltified form based on objects
contained in these excluded commits to reduce network
diff --git a/Documentation/git-tools.txt b/Documentation/git-tools.txt
index d79523f..0914cbb 100644
--- a/Documentation/git-tools.txt
+++ b/Documentation/git-tools.txt
@@ -42,7 +42,7 @@ History Viewers
- *gitk* (shipped with git-core)
- gitk is a simple TK GUI for browsing history of GIT repositories easily.
+ gitk is a simple Tk GUI for browsing history of GIT repositories easily.
- *gitview* (contrib/)
diff --git a/Documentation/git-upload-tar.txt b/Documentation/git-upload-tar.txt
index a1019a0..394af62 100644
--- a/Documentation/git-upload-tar.txt
+++ b/Documentation/git-upload-tar.txt
@@ -17,7 +17,7 @@ to the other end over the git protocol.
This command is usually not invoked directly by the end user.
The UI for the protocol is on the 'git-tar-tree' side, and the
-program pair is meant to be used to get a tar achive from a
+program pair is meant to be used to get a tar archive from a
remote repository.
diff --git a/Documentation/git.txt b/Documentation/git.txt
index 51f20c6..d00cc3e 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -478,7 +478,7 @@ Configuration Mechanism
Starting from 0.99.9 (actually mid 0.99.8.GIT), `.git/config` file
is used to hold per-repository configuration options. It is a
-simple text file modelled after `.ini` format familiar to some
+simple text file modeled after `.ini` format familiar to some
people. Here is an example:
------------
diff --git a/Documentation/howto/isolate-bugs-with-bisect.txt b/Documentation/howto/isolate-bugs-with-bisect.txt
index edbcd4c..926bbdc 100644
--- a/Documentation/howto/isolate-bugs-with-bisect.txt
+++ b/Documentation/howto/isolate-bugs-with-bisect.txt
@@ -28,7 +28,7 @@ Then do
and at this point "git bisect" will churn for a while, and tell you what
the mid-point between those two commits are, and check that state out as
-the head of the bew "bisect" branch.
+the head of the new "bisect" branch.
Compile and reboot.
diff --git a/Documentation/howto/rebase-from-internal-branch.txt b/Documentation/howto/rebase-from-internal-branch.txt
index c2d4a91..fcd64e9 100644
--- a/Documentation/howto/rebase-from-internal-branch.txt
+++ b/Documentation/howto/rebase-from-internal-branch.txt
@@ -124,7 +124,7 @@ up your changes, along with other change
The two commits #2' and #3' in the above picture record the same
changes your e-mail submission for #2 and #3 contained, but
-probably with the new sign-off line added by the upsteam
+probably with the new sign-off line added by the upstream
maintainer and definitely with different committer and ancestry
information, they are different objects from #2 and #3 commits.
diff --git a/Documentation/technical/pack-heuristics.txt b/Documentation/technical/pack-heuristics.txt
index 9aadd5c..103eb5d 100644
--- a/Documentation/technical/pack-heuristics.txt
+++ b/Documentation/technical/pack-heuristics.txt
@@ -73,7 +73,7 @@ The traditional insight:
<pasky> yes
-And Bable-like confusion flowed.
+And Babel-like confusion flowed.
<njs`> oh, hmm, and I'm not sure what this sliding window means either
@@ -257,7 +257,7 @@ proclaim it a non-issue. Good style too
(type, basename, size)).
Then we walk through this list, and calculate a delta of
- each object against the last n (tunable paramater) objects,
+ each object against the last n (tunable parameter) objects,
and pick the smallest of these deltas.
Vastly simplified, but the essence is there!
@@ -395,7 +395,7 @@ used as setup for a later optimization,
do "object name->location in packfile" translation.
<njs`> I'm assuming the real win for delta-ing large->small is
- more homogenous statistics for gzip to run over?
+ more homogeneous statistics for gzip to run over?
(You have to put the bytes in one place or another, but
putting them in a larger blob wins on compression)
@@ -448,7 +448,7 @@ design options, etc.
Bugs happen, but they are "simple" bugs. And bugs that
actually get some object store detail wrong are almost always
- so obious that they never go anywhere.
+ so obvious that they never go anywhere.
<njs`> Yeah.
diff --git a/INSTALL b/INSTALL
index 4e8f883..4cf7e67 100644
--- a/INSTALL
+++ b/INSTALL
@@ -57,7 +57,7 @@ Issues of note:
- "libcurl" and "curl" executable. git-http-fetch and
git-fetch use them. If you do not use http
- transfer, you are probabaly OK if you do not have
+ transfer, you are probably OK if you do not have
them.
- expat library; git-http-push uses it for remote lock
@@ -82,7 +82,7 @@ Issues of note:
git, and if you only use git to track other peoples work you'll
never notice the lack of it.
- - "wish", the TCL/Tk windowing shell is used in gitk to show the
+ - "wish", the Tcl/Tk windowing shell is used in gitk to show the
history graphically
- "ssh" is used to push and pull over the net
diff --git a/Makefile b/Makefile
index 8d429a0..fd35dbe 100644
--- a/Makefile
+++ b/Makefile
@@ -28,7 +28,7 @@ #
# Define NO_SYMLINK_HEAD if you never want .git/HEAD to be a symbolic link.
# Enable it on Windows. By default, symrefs are still used.
#
-# Define NO_SVN_TESTS if you want to skip time-consuming SVN interopability
+# Define NO_SVN_TESTS if you want to skip time-consuming SVN interoperability
# tests. These tests take up a significant amount of the total test time
# but are not needed unless you plan to talk to SVN repos.
#
@@ -67,7 +67,7 @@ #
# Define NO_ACCURATE_DIFF if your diff program at least sometimes misses
# a missing newline at the end of the file.
#
-# Define NO_PYTHON if you want to loose all benefits of the recursive merge.
+# Define NO_PYTHON if you want to lose all benefits of the recursive merge.
#
# Define COLLISION_CHECK below if you believe that SHA1's
# 1461501637330902918203684832716283019655932542976 hashes do not give you
@@ -492,7 +492,7 @@ ifdef NO_ACCURATE_DIFF
BASIC_CFLAGS += -DNO_ACCURATE_DIFF
endif
-# Shell quote (do not use $(call) to accomodate ancient setups);
+# Shell quote (do not use $(call) to accommodate ancient setups);
SHA1_HEADER_SQ = $(subst ','\'',$(SHA1_HEADER))
diff --git a/git-cvsserver.perl b/git-cvsserver.perl
index 5ccca4f..c30ef70 100755
--- a/git-cvsserver.perl
+++ b/git-cvsserver.perl
@@ -779,7 +779,7 @@ sub req_update
#$log->debug("update state : " . Dumper($state));
- # foreach file specified on the commandline ...
+ # foreach file specified on the command line ...
foreach my $filename ( @{$state->{args}} )
{
$filename = filecleanup($filename);
@@ -1031,7 +1031,7 @@ sub req_ci
my @committedfiles = ();
- # foreach file specified on the commandline ...
+ # foreach file specified on the command line ...
foreach my $filename ( @{$state->{args}} )
{
my $committedfile = $filename;
@@ -1145,7 +1145,7 @@ sub req_ci
$updater->update();
- # foreach file specified on the commandline ...
+ # foreach file specified on the command line ...
foreach my $filename ( @committedfiles )
{
$filename = filecleanup($filename);
@@ -1190,7 +1190,7 @@ sub req_status
# if no files were specified, we need to work out what files we should be providing status on ...
argsfromdir($updater);
- # foreach file specified on the commandline ...
+ # foreach file specified on the command line ...
foreach my $filename ( @{$state->{args}} )
{
$filename = filecleanup($filename);
@@ -1291,7 +1291,7 @@ sub req_diff
# if no files were specified, we need to work out what files we should be providing status on ...
argsfromdir($updater);
- # foreach file specified on the commandline ...
+ # foreach file specified on the command line ...
foreach my $filename ( @{$state->{args}} )
{
$filename = filecleanup($filename);
@@ -1433,7 +1433,7 @@ sub req_log
# if no files were specified, we need to work out what files we should be providing status on ...
argsfromdir($updater);
- # foreach file specified on the commandline ...
+ # foreach file specified on the command line ...
foreach my $filename ( @{$state->{args}} )
{
$filename = filecleanup($filename);
@@ -1519,7 +1519,7 @@ sub req_annotate
chdir $tmpdir;
- # foreach file specified on the commandline ...
+ # foreach file specified on the command line ...
foreach my $filename ( @{$state->{args}} )
{
$filename = filecleanup($filename);
diff --git a/server-info.c b/server-info.c
index 0eb5132..fdfe05a 100644
--- a/server-info.c
+++ b/server-info.c
@@ -94,7 +94,7 @@ static int read_pack_info_file(const cha
fp = fopen(infofile, "r");
if (!fp)
- return 1; /* nonexisting is not an error. */
+ return 1; /* nonexistent is not an error. */
while (fgets(line, sizeof(line), fp)) {
int len = strlen(line);
^ permalink raw reply related
* [PATCH] Assorted typo fixes
From: Pavel Roskin @ 2006-07-09 7:36 UTC (permalink / raw)
To: git
Assorted typo fixes
Signed-off-by: Pavel Roskin <proski@gnu.org>
---
This is for "next". "interopability" didn't make it to "master" yet.
Documentation/SubmittingPatches | 2 +-
Documentation/cvs-migration.txt | 2 +-
Documentation/git-diff-files.txt | 2 +-
Documentation/git-init-db.txt | 2 +-
Documentation/git-mailsplit.txt | 2 +-
Documentation/git-merge.txt | 2 +-
Documentation/git-p4import.txt | 4 ++--
Documentation/git-pack-redundant.txt | 2 +-
Documentation/git-push.txt | 2 +-
Documentation/git-repo-config.txt | 4 ++--
Documentation/git-rev-list.txt | 2 +-
Documentation/git-tools.txt | 2 +-
Documentation/git-upload-tar.txt | 2 +-
Documentation/git.txt | 2 +-
Documentation/howto/isolate-bugs-with-bisect.txt | 2 +-
.../howto/rebase-from-internal-branch.txt | 2 +-
Documentation/technical/pack-heuristics.txt | 8 ++++----
INSTALL | 4 ++--
Makefile | 6 +++---
git-cvsserver.perl | 14
+++++++-------
server-info.c | 2 +-
21 files changed, 35 insertions(+), 35 deletions(-)
diff --git a/Documentation/SubmittingPatches
b/Documentation/SubmittingPatches
index 8601949..90722c2 100644
--- a/Documentation/SubmittingPatches
+++ b/Documentation/SubmittingPatches
@@ -49,7 +49,7 @@ People on the git mailing list need to b
comment on the changes you are submitting. It is important for
a developer to be able to "quote" your changes, using standard
e-mail tools, so that they may comment on specific portions of
-your code. For this reason, all patches should be submited
+your code. For this reason, all patches should be submitted
"inline". WARNING: Be wary of your MUAs word-wrap
corrupting your patch. Do not cut-n-paste your patch; you can
lose tabs that way if you are not careful.
diff --git a/Documentation/cvs-migration.txt
b/Documentation/cvs-migration.txt
index 1fbca83..d2b0bd3 100644
--- a/Documentation/cvs-migration.txt
+++ b/Documentation/cvs-migration.txt
@@ -93,7 +93,7 @@ machine where the repository is hosted.
full shell on the machine, there is a restricted shell which only
allows
users to do git pushes and pulls; see gitlink:git-shell[1].
-Put all the committers should in the same group, and make the
repository
+Put all the committers in the same group, and make the repository
writable by that group:
------------------------------------------------
diff --git a/Documentation/git-diff-files.txt
b/Documentation/git-diff-files.txt
index 481b8b3..7248b35 100644
--- a/Documentation/git-diff-files.txt
+++ b/Documentation/git-diff-files.txt
@@ -37,7 +37,7 @@ omit diff output for unmerged entries an
commit with these flags.
-q::
- Remain silent even on nonexisting files
+ Remain silent even on nonexistent files
Output format
-------------
diff --git a/Documentation/git-init-db.txt
b/Documentation/git-init-db.txt
index 8a150d8..0a4fc14 100644
--- a/Documentation/git-init-db.txt
+++ b/Documentation/git-init-db.txt
@@ -25,7 +25,7 @@ DESCRIPTION
-----------
This command creates an empty git repository - basically a `.git`
directory
with subdirectories for `objects`, `refs/heads`, `refs/tags`, and
-templated files.
+template files.
An initial `HEAD` file that references the HEAD of the master branch
is also created.
diff --git a/Documentation/git-mailsplit.txt
b/Documentation/git-mailsplit.txt
index 209e36b..5a17801 100644
--- a/Documentation/git-mailsplit.txt
+++ b/Documentation/git-mailsplit.txt
@@ -25,7 +25,7 @@ OPTIONS
-b::
If any file doesn't begin with a From line, assume it is a
- single mail message instead of signalling error.
+ single mail message instead of signaling error.
-d<prec>::
Instead of the default 4 digits with leading zeros,
diff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt
index 4ce799b..bebf30a 100644
--- a/Documentation/git-merge.txt
+++ b/Documentation/git-merge.txt
@@ -83,7 +83,7 @@ your local modifications interfere with
stops before touching anything.
So in the above two "failed merge" case, you do not have to
-worry about lossage of data --- you simply were not ready to do
+worry about loss of data --- you simply were not ready to do
a merge, so no merge happened at all. You may want to finish
whatever you were in the middle of doing, and retry the same
pull after you are done and ready.
diff --git a/Documentation/git-p4import.txt
b/Documentation/git-p4import.txt
index 0858e5e..ee9e8fa 100644
--- a/Documentation/git-p4import.txt
+++ b/Documentation/git-p4import.txt
@@ -128,7 +128,7 @@ Tags
A git tag of the form p4/xx is created for every change imported from
the Perforce repository where xx is the Perforce changeset number.
Therefore after the import you can use git to access any commit by its
-Perforce number, eg. git show p4/327.
+Perforce number, e.g. git show p4/327.
The tag associated with the HEAD commit is also how `git-p4import`
determines if there are new changes to incrementally import from the
@@ -143,7 +143,7 @@ may delete the tags.
Notes
-----
-You can interrupt the import (eg. ctrl-c) at any time and restart it
+You can interrupt the import (e.g. ctrl-c) at any time and restart it
without worry.
Author information is automatically determined by querying the
diff --git a/Documentation/git-pack-redundant.txt
b/Documentation/git-pack-redundant.txt
index 8fb0659..7d54b17 100644
--- a/Documentation/git-pack-redundant.txt
+++ b/Documentation/git-pack-redundant.txt
@@ -29,7 +29,7 @@ OPTIONS
--all::
- Processes all packs. Any filenames on the commandline are ignored.
+ Processes all packs. Any filenames on the command line are ignored.
--alt-odb::
Don't require objects present in packs from alternate object
diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index d5b5ca1..56afd64 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -67,7 +67,7 @@ Some short-cut notations are also suppor
-f, \--force::
Usually, the command refuses to update a remote ref that is
- not a descendent of the local ref used to overwrite it.
+ not a descendant of the local ref used to overwrite it.
This flag disables the check. This can cause the
remote repository to lose commits; use it with care.
diff --git a/Documentation/git-repo-config.txt
b/Documentation/git-repo-config.txt
index cc72fa9..8a1ab61 100644
--- a/Documentation/git-repo-config.txt
+++ b/Documentation/git-repo-config.txt
@@ -120,8 +120,8 @@ you can set the filemode to true with
% git repo-config core.filemode true
------------
-The hypothetic proxy command entries actually have a postfix to discern
-to what URL they apply. Here is how to change the entry for kernel.org
+The hypothetical proxy command entries actually have a postfix to
discern
+what URL they apply to. Here is how to change the entry for kernel.org
to "ssh".
------------
diff --git a/Documentation/git-rev-list.txt
b/Documentation/git-rev-list.txt
index 6c370e1..e220842 100644
--- a/Documentation/git-rev-list.txt
+++ b/Documentation/git-rev-list.txt
@@ -64,7 +64,7 @@ OPTIONS
--objects-edge::
Similar to `--objects`, but also print the IDs of
- excluded commits refixed with a `-` character. This is
+ excluded commits prefixed with a `-` character. This is
used by `git-pack-objects` to build 'thin' pack, which
records objects in deltified form based on objects
contained in these excluded commits to reduce network
diff --git a/Documentation/git-tools.txt b/Documentation/git-tools.txt
index d79523f..0914cbb 100644
--- a/Documentation/git-tools.txt
+++ b/Documentation/git-tools.txt
@@ -42,7 +42,7 @@ History Viewers
- *gitk* (shipped with git-core)
- gitk is a simple TK GUI for browsing history of GIT repositories
easily.
+ gitk is a simple Tk GUI for browsing history of GIT repositories
easily.
- *gitview* (contrib/)
diff --git a/Documentation/git-upload-tar.txt
b/Documentation/git-upload-tar.txt
index a1019a0..394af62 100644
--- a/Documentation/git-upload-tar.txt
+++ b/Documentation/git-upload-tar.txt
@@ -17,7 +17,7 @@ to the other end over the git protocol.
This command is usually not invoked directly by the end user.
The UI for the protocol is on the 'git-tar-tree' side, and the
-program pair is meant to be used to get a tar achive from a
+program pair is meant to be used to get a tar archive from a
remote repository.
diff --git a/Documentation/git.txt b/Documentation/git.txt
index 51f20c6..d00cc3e 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -478,7 +478,7 @@ Configuration Mechanism
Starting from 0.99.9 (actually mid 0.99.8.GIT), `.git/config` file
is used to hold per-repository configuration options. It is a
-simple text file modelled after `.ini` format familiar to some
+simple text file modeled after `.ini` format familiar to some
people. Here is an example:
------------
diff --git a/Documentation/howto/isolate-bugs-with-bisect.txt
b/Documentation/howto/isolate-bugs-with-bisect.txt
index edbcd4c..926bbdc 100644
--- a/Documentation/howto/isolate-bugs-with-bisect.txt
+++ b/Documentation/howto/isolate-bugs-with-bisect.txt
@@ -28,7 +28,7 @@ Then do
and at this point "git bisect" will churn for a while, and tell you
what
the mid-point between those two commits are, and check that state out
as
-the head of the bew "bisect" branch.
+the head of the new "bisect" branch.
Compile and reboot.
diff --git a/Documentation/howto/rebase-from-internal-branch.txt
b/Documentation/howto/rebase-from-internal-branch.txt
index c2d4a91..fcd64e9 100644
--- a/Documentation/howto/rebase-from-internal-branch.txt
+++ b/Documentation/howto/rebase-from-internal-branch.txt
@@ -124,7 +124,7 @@ up your changes, along with other change
The two commits #2' and #3' in the above picture record the same
changes your e-mail submission for #2 and #3 contained, but
-probably with the new sign-off line added by the upsteam
+probably with the new sign-off line added by the upstream
maintainer and definitely with different committer and ancestry
information, they are different objects from #2 and #3 commits.
diff --git a/Documentation/technical/pack-heuristics.txt
b/Documentation/technical/pack-heuristics.txt
index 9aadd5c..103eb5d 100644
--- a/Documentation/technical/pack-heuristics.txt
+++ b/Documentation/technical/pack-heuristics.txt
@@ -73,7 +73,7 @@ The traditional insight:
<pasky> yes
-And Bable-like confusion flowed.
+And Babel-like confusion flowed.
<njs`> oh, hmm, and I'm not sure what this sliding window means
either
@@ -257,7 +257,7 @@ proclaim it a non-issue. Good style too
(type, basename, size)).
Then we walk through this list, and calculate a delta of
- each object against the last n (tunable paramater) objects,
+ each object against the last n (tunable parameter) objects,
and pick the smallest of these deltas.
Vastly simplified, but the essence is there!
@@ -395,7 +395,7 @@ used as setup for a later optimization,
do "object name->location in packfile" translation.
<njs`> I'm assuming the real win for delta-ing large->small is
- more homogenous statistics for gzip to run over?
+ more homogeneous statistics for gzip to run over?
(You have to put the bytes in one place or another, but
putting them in a larger blob wins on compression)
@@ -448,7 +448,7 @@ design options, etc.
Bugs happen, but they are "simple" bugs. And bugs that
actually get some object store detail wrong are almost always
- so obious that they never go anywhere.
+ so obvious that they never go anywhere.
<njs`> Yeah.
diff --git a/INSTALL b/INSTALL
index 4e8f883..4cf7e67 100644
--- a/INSTALL
+++ b/INSTALL
@@ -57,7 +57,7 @@ Issues of note:
- "libcurl" and "curl" executable. git-http-fetch and
git-fetch use them. If you do not use http
- transfer, you are probabaly OK if you do not have
+ transfer, you are probably OK if you do not have
them.
- expat library; git-http-push uses it for remote lock
@@ -82,7 +82,7 @@ Issues of note:
git, and if you only use git to track other peoples work you'll
never notice the lack of it.
- - "wish", the TCL/Tk windowing shell is used in gitk to show
the
+ - "wish", the Tcl/Tk windowing shell is used in gitk to show
the
history graphically
- "ssh" is used to push and pull over the net
diff --git a/Makefile b/Makefile
index 8d429a0..fd35dbe 100644
--- a/Makefile
+++ b/Makefile
@@ -28,7 +28,7 @@ #
# Define NO_SYMLINK_HEAD if you never want .git/HEAD to be a symbolic
link.
# Enable it on Windows. By default, symrefs are still used.
#
-# Define NO_SVN_TESTS if you want to skip time-consuming SVN
interopability
+# Define NO_SVN_TESTS if you want to skip time-consuming SVN
interoperability
# tests. These tests take up a significant amount of the total test
time
# but are not needed unless you plan to talk to SVN repos.
#
@@ -67,7 +67,7 @@ #
# Define NO_ACCURATE_DIFF if your diff program at least sometimes
misses
# a missing newline at the end of the file.
#
-# Define NO_PYTHON if you want to loose all benefits of the recursive
merge.
+# Define NO_PYTHON if you want to lose all benefits of the recursive
merge.
#
# Define COLLISION_CHECK below if you believe that SHA1's
# 1461501637330902918203684832716283019655932542976 hashes do not give
you
@@ -492,7 +492,7 @@ ifdef NO_ACCURATE_DIFF
BASIC_CFLAGS += -DNO_ACCURATE_DIFF
endif
-# Shell quote (do not use $(call) to accomodate ancient setups);
+# Shell quote (do not use $(call) to accommodate ancient setups);
SHA1_HEADER_SQ = $(subst ','\'',$(SHA1_HEADER))
diff --git a/git-cvsserver.perl b/git-cvsserver.perl
index 5ccca4f..c30ef70 100755
--- a/git-cvsserver.perl
+++ b/git-cvsserver.perl
@@ -779,7 +779,7 @@ sub req_update
#$log->debug("update state : " . Dumper($state));
- # foreach file specified on the commandline ...
+ # foreach file specified on the command line ...
foreach my $filename ( @{$state->{args}} )
{
$filename = filecleanup($filename);
@@ -1031,7 +1031,7 @@ sub req_ci
my @committedfiles = ();
- # foreach file specified on the commandline ...
+ # foreach file specified on the command line ...
foreach my $filename ( @{$state->{args}} )
{
my $committedfile = $filename;
@@ -1145,7 +1145,7 @@ sub req_ci
$updater->update();
- # foreach file specified on the commandline ...
+ # foreach file specified on the command line ...
foreach my $filename ( @committedfiles )
{
$filename = filecleanup($filename);
@@ -1190,7 +1190,7 @@ sub req_status
# if no files were specified, we need to work out what files we
should be providing status on ...
argsfromdir($updater);
- # foreach file specified on the commandline ...
+ # foreach file specified on the command line ...
foreach my $filename ( @{$state->{args}} )
{
$filename = filecleanup($filename);
@@ -1291,7 +1291,7 @@ sub req_diff
# if no files were specified, we need to work out what files we
should be providing status on ...
argsfromdir($updater);
- # foreach file specified on the commandline ...
+ # foreach file specified on the command line ...
foreach my $filename ( @{$state->{args}} )
{
$filename = filecleanup($filename);
@@ -1433,7 +1433,7 @@ sub req_log
# if no files were specified, we need to work out what files we
should be providing status on ...
argsfromdir($updater);
- # foreach file specified on the commandline ...
+ # foreach file specified on the command line ...
foreach my $filename ( @{$state->{args}} )
{
$filename = filecleanup($filename);
@@ -1519,7 +1519,7 @@ sub req_annotate
chdir $tmpdir;
- # foreach file specified on the commandline ...
+ # foreach file specified on the command line ...
foreach my $filename ( @{$state->{args}} )
{
$filename = filecleanup($filename);
diff --git a/server-info.c b/server-info.c
index 0eb5132..fdfe05a 100644
--- a/server-info.c
+++ b/server-info.c
@@ -94,7 +94,7 @@ static int read_pack_info_file(const cha
fp = fopen(infofile, "r");
if (!fp)
- return 1; /* nonexisting is not an error. */
+ return 1; /* nonexistent is not an error. */
while (fgets(line, sizeof(line), fp)) {
int len = strlen(line);
--
Regards,
Pavel Roskin
^ permalink raw reply related
* Re: [WIP] Status update on merge-recursive in C
From: Junio C Hamano @ 2006-07-09 7:34 UTC (permalink / raw)
To: Pavel Roskin; +Cc: git
In-Reply-To: <1152421230.2103.31.camel@dv>
Pavel Roskin <proski@gnu.org> writes:
> Why do you list "recur" twice in all_strategies in the git-merge.sh?
> The second "recur" should probably be "recursive".
> ...
> Test for Python in the git-rebase.sh is probably wrong. "recur" doesn't
> need Python - that's the whole point. In fact, if I build git with
> NO_PYTHON, TEST fails in t3401-rebase-partial.sh
I noticed them as well but I understand that is why the patch is
marked as WIP. I do not mind these details much at this point
yet.
I think it may make sense, during the development, to make
git-merge.sh notice an environment GIT_USE_RECUR_FOR_RECURSIVE
and have it automatically use git-merge-recur when the user and
scripts ask for recursive. A preliminary patch (but it was
tested) is attached.
> I tries to run sparse of the C files, and it complains about two things
> - variable declarations in the middle of the code (allowed by c99 but
> not by ANSI C) and incomplete function declarations (no "void"). It's
> not C++, let's stick to the C standards.
I run, from time to time, with pedantic set of options (that is,
-O2 -Werror -ansi -pedantic -std=c99 -D_XOPEN_SOURCE=500 -D_BSD_SOURCE
) just for fun, and noticed these problems as well, but left
them as they are, because I think Johannaes/Alex team would want
to update the TODO items first and I felt fixing these up at
this point would give me unnecessary conflicts to resolve.
> I'm attaching a patch that fixes everything except variable
> declarations. There are so many of them that it could be done once the
> code stabilizes a bit.
Exactly.
-- >8 --
recur vs recursive: help testing without touching too many stuff.
During git-merge-recur development, you could set an environment
variable GIT_USE_RECUR_FOR_RECURSIVE to use WIP recur in place
of the recursive strategy.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
diff --git a/TEST b/TEST
index d530983..7286e2a 100755
--- a/TEST
+++ b/TEST
@@ -1,10 +1,14 @@
#!/bin/sh -x
+
cd t || exit
-./t3400-rebase.sh "$@" && \
-./t6020-merge-df.sh "$@" && \
-./t3401-rebase-partial.sh "$@" && \
-./t6021-merge-criss-cross.sh "$@" && \
-./t3402-rebase-merge.sh "$@" && \
-./t6022-merge-rename.sh "$@" && \
-./t6010-merge-base.sh "$@" && \
+GIT_USE_RECUR_FOR_RECURSIVE=LetsTryIt
+export GIT_USE_RECUR_FOR_RECURSIVE
+
+./t3400-rebase.sh "$@" &&
+./t6020-merge-df.sh "$@" &&
+./t3401-rebase-partial.sh "$@" &&
+./t6021-merge-criss-cross.sh "$@" &&
+./t3402-rebase-merge.sh "$@" &&
+./t6022-merge-rename.sh "$@" &&
+./t6010-merge-base.sh "$@" &&
:
diff --git a/git-merge.sh b/git-merge.sh
index b26ca14..9b68115 100755
--- a/git-merge.sh
+++ b/git-merge.sh
@@ -9,8 +9,13 @@ USAGE='[-n] [--no-commit] [--squash] [-s
LF='
'
-all_strategies='recur recur octopus resolve stupid ours'
-default_twohead_strategies='recur'
+all_strategies='recursive recur octopus resolve stupid ours'
+case "${GIT_USE_RECUR_FOR_RECURSIVE}" in
+'')
+ default_twohead_strategies=recursive ;;
+?*)
+ default_twohead_strategies=recur ;;
+esac
default_octopus_strategies='octopus'
no_trivial_merge_strategies='ours'
use_strategies=
@@ -110,6 +115,10 @@ do
strategy="$2"
shift ;;
esac
+ case "$strategy,${GIT_USE_RECUR_FOR_RECURSIVE}" in
+ recursive,?*)
+ strategy=recur ;;
+ esac
case " $all_strategies " in
*" $strategy "*)
use_strategies="$use_strategies$strategy " ;;
diff --git a/git-rebase.sh b/git-rebase.sh
index 2a4c8c8..8c5da72 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -35,7 +35,13 @@ If you would prefer to skip this patch,
To restore the original branch and stop rebasing run \"git rebase --abort\".
"
unset newbase
-strategy=recur
+case "${GIT_USE_RECUR_FOR_RECURSIVE}" in
+'')
+ strategy=recursive ;;
+?*)
+ strategy=recur ;;
+esac
+
do_merge=
dotest=$GIT_DIR/.dotest-merge
prec=4
@@ -198,6 +204,11 @@ do
shift
done
+case "$strategy,${GIT_USE_RECUR_FOR_RECURSIVE}" in
+recursive,?*)
+ strategy=recur ;;
+esac
+
# Make sure we do not have .dotest
if test -z "$do_merge"
then
@@ -292,7 +303,7 @@ then
exit $?
fi
-if test "@@NO_PYTHON@@" && test "$strategy" = "recur"
+if test "@@NO_PYTHON@@" && test "$strategy" = "recursive"
then
die 'The recursive merge strategy currently relies on Python,
which this installation of git was not configured with. Please consider
diff --git a/t/t3402-rebase-merge.sh b/t/t3402-rebase-merge.sh
index b70e177..d34c6cf 100755
--- a/t/t3402-rebase-merge.sh
+++ b/t/t3402-rebase-merge.sh
@@ -51,7 +51,7 @@ test_expect_success setup '
'
test_expect_success 'reference merge' '
- git merge -s recur "reference merge" HEAD master
+ git merge -s recursive "reference merge" HEAD master
'
test_expect_success rebase '
^ permalink raw reply related
* Re: [PATCH] Remove more gcc extension usage.
From: Jan-Benedict Glaw @ 2006-07-09 7:31 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Junio C Hamano, git
In-Reply-To: <20060708190327.GA17763@spearce.org>
[-- Attachment #1: Type: text/plain, Size: 2785 bytes --]
On Sat, 2006-07-08 15:03:27 -0400, Shawn Pearce <spearce@spearce.org> wrote:
> Junio C Hamano <junkio@cox.net> wrote:
> > Shawn Pearce <spearce@spearce.org> writes:
> >
> > > Removing these last remaining extension uses allows GIT to compile
> > > with the Sun C compiler rather then gcc. This can be handy when
> > > you are trying to compile GIT on a Solaris system that seems to
> > > have a total lack of GNU utilities.
> >
> > Two points.
> >
> > - Aren't the constructs you ripped out not GCC extension,
> > rather proper ISO C99?
>
> Hmm. I'm not sure actually. I don't do much C hacking these days
> so I haven't kept current with what C99 has and doesn't. I just
> know that these small changes made the core plumbing build and run
> fine on Solaris with only GNU make being present. I didn't even
> attempt to use the higher level Poreclainish shell script commands.
Yes, that's valid C99. So Sun ships a compiler conforming to old
standards only, or which is configured to do so.
> Monday I'll look to see if there's an option that can be given to
> the Solaris compiler to make it accept these constructs. Maybe a
> simple CFLAGS change in my config.mak would resolve what this patch
> was trying to do.
Thanks.
> > - Our Makefile is pretty GNU already. I think people have
> > pointed out and ripped out bashisms from our shell scripts,
> > but I would not be surprised if the default Sun /bin/sh does
> > not understand POSIXy features some of them use.
>
> I realize that. Asking someone to compile GNU make in their home
> directory before they build GIT to their home directory isn't a
> big deal (took me all of 30 seconds to download the latest and
> ./configure&&make install it). Asking someone to download and
> compile binutils and gcc because their local site manager won't
> install them for you is another matter entirely...
AFAIK, relying on the '#!/bin/sh' thing is, from the POSIX point of
view, just plain wrong. IIRC, the '#!' thing even doesn't need to be
implemented! POSIX tells you to call scripts with their interpreters,
for a reason. /bin/sh needn't be POSIX compliant, but the first shell
found in the $PATH has to. So for what it's worth, shell scripts
should be called like `sh foo.sh', and if we narrow to expect the `#!'
to work, we'd better call it like `#!/usr/bin/env sh' to get the $PATH
`sh' and not /bin/sh .
MfG, JBG
--
Jan-Benedict Glaw jbglaw@lug-owl.de . +49-172-7608481 _ O _
"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg _ _ O
für einen Freien Staat voll Freier Bürger" | im Internet! | im Irak! O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 1/1] Disable color detection during format-patch
From: Junio C Hamano @ 2006-07-09 6:59 UTC (permalink / raw)
To: Ryan Anderson; +Cc: git
In-Reply-To: <11524265013620-git-send-email-ryan@michonline.com>
Obviously correct -- thanks.
^ permalink raw reply
* Re: [RFC] just an (stupid) idea when creating a new branch
From: Marco Costalba @ 2006-07-09 6:54 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e8p8pj$jk3$2@sea.gmane.org>
On 7/8/06, Jakub Narebski <jnareb@gmail.com> wrote:
> moreau francis wrote:
>
> > Hi GIT folks.
> >
> > I'm a complete newbie on git development so excuse me if
> > this idea is completely stupid.
> >
> > Would it be possible to let the user stick a short explanation
> > on what a branch is supposed to implement during its creation.
>
> It would be possible when/if branch and remotes config would migrate
> to .git/config. Currently too many I think relies on refs/heads being
> simple sha1 of "top" commit.
>
It is possible to add a message (and more) to a tag creating a tag
object. FWIK this is not allowed for the other refs.
Why there is this (artifical?) difference between tags and the other
kind of refs?
Marco
^ permalink raw reply
* Fw: We can work together now! They have a good offer.
From: Clayton Maldonado @ 2006-07-09 6:51 UTC (permalink / raw)
To: git
Good day Git!.!
How are you? I hope you are fine. I missed you so much honey. I have been thinking about our last meeting so much and I’ll
never forget all the fun we had together that month.
About me all the same, same town same city same job hheheh all the same I am bored and I cant wait to visit u next year.
Almost nothing has changed between us; my hart is waiting for you.
By the way, do you remember that distributor of art, who helped me selling different items, yes, that ones I was reselling
to Artists and Collectors.
Their Comicion to our money-bags!! They want to sell their antiques at the Art Market in Australia. But they have some
reasons for not opening a branch in Australia for the moment. Maybe next year, this means that I can move to Sydney very
soon.
The only thing I can say is that I’ve worked with this company for a long time and they are really the best bosses I ever
had in my life, you know all the time I have in my life for my activities and also They never let me down. I am completely
satisfied with their assistance in all work matters.
In short they are searching for people for distant-work. This job will take only couple of hours a day, but the salary is
rather acceptable, 300-400 dollars weekly.
They asked me to help them in finding any bulletin boards. I know that you work with different kinds of announcements and
may be you can advice something. Or may be you know a couple of honest people who need some work. The requirements to
candidate are not too high, he should be an honest person able to work with PC- Know about Internet- and some other office
tools, you know, like Word Excel MSN, etc.
So if you have someone in mind, say them to write to info@tollisltdsupport.com
PS. By the way, you promised me to call and didn’t keep it. It’s no good forgetting your old and faithful friend. I’ll always be glad to here from you,
Remember me to your mates,
Love you Heepss,
Colin Holder
Sun, 9 Jul 2006 14:51:55 +0800
boast
bandwagon
cheap
croatia
alameda
^ permalink raw reply
* [PATCH 1/1] Disable color detection during format-patch
From: Ryan Anderson @ 2006-07-09 6:28 UTC (permalink / raw)
To: junkio; +Cc: git, Ryan Anderson
Signed-off-by: Ryan Anderson <ryan@michonline.com>
---
builtin-log.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/builtin-log.c b/builtin-log.c
index 698b71e..0aeeaa4 100644
--- a/builtin-log.c
+++ b/builtin-log.c
@@ -105,6 +105,9 @@ static int git_format_config(const char
strcat(extra_headers, value);
return 0;
}
+ if (!strcmp(var, "diff.color")) {
+ return 0;
+ }
return git_diff_config(var, value);
}
--
1.4.1.gc473b-dirty
^ permalink raw reply related
* [RFC+PATCH 1/1] Move SCM interoperability tools into scm/
From: Ryan Anderson @ 2006-07-09 6:17 UTC (permalink / raw)
To: git; +Cc: Ryan Anderson
Signed-off-by: Ryan Anderson <ryan@michonline.com>
---
This is the first in a series to categorize the source tree a little bit more
than it is currently.
I figured I'd start with something innocuous, like the SCM interoperability
tools.
One thing I don't really like is that I had to duplicate the Perl build rule
in the subdirectory Makefile, effectively, to restructure it and leave the
built files in the root. If we can deprecate "run from the source tree",
this can go away. (That requires fixing up a lot of tests, but it's
straightforward, at least.)
So, flame away!
Makefile | 10 ++++++----
scm/Makefile | 20 ++++++++++++++++++++
git-archimport.perl => scm/git-archimport.perl | 0
.../git-cvsexportcommit.perl | 0
git-cvsimport.perl => scm/git-cvsimport.perl | 0
git-cvsserver.perl => scm/git-cvsserver.perl | 0
git-p4import.py => scm/git-p4import.py | 0
git-send-email.perl => scm/git-send-email.perl | 0
git-svnimport.perl => scm/git-svnimport.perl | 0
9 files changed, 26 insertions(+), 4 deletions(-)
diff --git a/Makefile b/Makefile
index 202f261..e7f5b48 100644
--- a/Makefile
+++ b/Makefile
@@ -130,11 +130,10 @@ SCRIPT_SH = \
git-lost-found.sh git-quiltimport.sh
SCRIPT_PERL = \
- git-archimport.perl git-cvsimport.perl git-relink.perl \
+ git-relink.perl \
git-shortlog.perl git-rerere.perl \
- git-annotate.perl git-cvsserver.perl \
- git-svnimport.perl git-mv.perl git-cvsexportcommit.perl \
- git-send-email.perl
+ git-annotate.perl \
+ git-mv.perl
SCRIPT_PYTHON = \
git-merge-recursive.py
@@ -176,6 +175,9 @@ BUILT_INS = git-log$X git-whatchanged$X
git-diff-index$X git-diff-stages$X git-diff-tree$X git-cat-file$X \
git-fmt-merge-msg$X
+
+include scm/Makefile
+
# what 'all' will build and 'install' will install, in gitexecdir
ALL_PROGRAMS = $(PROGRAMS) $(SIMPLE_PROGRAMS) $(SCRIPTS)
diff --git a/scm/Makefile b/scm/Makefile
new file mode 100644
index 0000000..0ce205b
--- /dev/null
+++ b/scm/Makefile
@@ -0,0 +1,20 @@
+
+SCM_PERL_BASE = \
+ git-archimport.perl \
+ git-cvsimport.perl \
+ git-cvsexportcommit.perl \
+ git-cvsserver.perl \
+ git-svnimport.perl \
+ git-send-email.perl
+
+SCRIPTS+=$(patsubst %.perl,%,$(SCM_PERL_BASE))
+
+$(patsubst %.perl,%,$(SCM_PERL_BASE)) : % : scm/%.perl
+ rm -f $@ $@+
+ sed -e '1s|#!.*perl|#!$(PERL_PATH_SQ)|' \
+ -e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' \
+ $^ >$@+
+ chmod +x $@+
+ mv $@+ $@
+
+
diff --git a/git-archimport.perl b/scm/git-archimport.perl
similarity index 100%
rename from git-archimport.perl
rename to scm/git-archimport.perl
diff --git a/git-cvsexportcommit.perl b/scm/git-cvsexportcommit.perl
similarity index 100%
rename from git-cvsexportcommit.perl
rename to scm/git-cvsexportcommit.perl
diff --git a/git-cvsimport.perl b/scm/git-cvsimport.perl
similarity index 100%
rename from git-cvsimport.perl
rename to scm/git-cvsimport.perl
diff --git a/git-cvsserver.perl b/scm/git-cvsserver.perl
similarity index 100%
rename from git-cvsserver.perl
rename to scm/git-cvsserver.perl
diff --git a/git-p4import.py b/scm/git-p4import.py
similarity index 100%
rename from git-p4import.py
rename to scm/git-p4import.py
diff --git a/git-send-email.perl b/scm/git-send-email.perl
similarity index 100%
rename from git-send-email.perl
rename to scm/git-send-email.perl
diff --git a/git-svnimport.perl b/scm/git-svnimport.perl
similarity index 100%
rename from git-svnimport.perl
rename to scm/git-svnimport.perl
--
1.4.1.gc473b-dirty
^ permalink raw reply related
* Re: [WIP] Status update on merge-recursive in C
From: Pavel Roskin @ 2006-07-09 5:00 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0607081840280.29667@wbgn013.biozentrum.uni-wuerzburg.de>
Hello, Dscho!
On Sat, 2006-07-08 at 18:42 +0200, Johannes Schindelin wrote:
> This is just an update for people being interested. Alex and me were
> busy with that project for a few days now. While it has progressed nicely,
> there are quite a couple TODOs in merge-recursive.c, just search for "TODO".
That's great. Just a few notes regarding the patch.
Why do you list "recur" twice in all_strategies in the git-merge.sh?
The second "recur" should probably be "recursive".
Test for Python in the git-rebase.sh is probably wrong. "recur" doesn't
need Python - that's the whole point. In fact, if I build git with
NO_PYTHON, TEST fails in t3401-rebase-partial.sh
Apart from that, the tests pass on i386, x86_64 and PowerPC, all running
Fedora Core 5.
I tries to run sparse of the C files, and it complains about two things
- variable declarations in the middle of the code (allowed by c99 but
not by ANSI C) and incomplete function declarations (no "void"). It's
not C++, let's stick to the C standards.
I'm attaching a patch that fixes everything except variable
declarations. There are so many of them that it could be done once the
code stabilizes a bit.
It would be great to have a patch that actually removes the old
"recursive" and makes the new strategy "recursive". I understand it's
the plan, right?
---
git-merge.sh | 2 +-
git-rebase.sh | 2 +-
merge-recursive.c | 9 +++++----
read-cache.c | 2 +-
4 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/git-merge.sh b/git-merge.sh
index b26ca14..240e5ee 100755
--- a/git-merge.sh
+++ b/git-merge.sh
@@ -9,7 +9,7 @@ USAGE='[-n] [--no-commit] [--squash] [-s
LF='
'
-all_strategies='recur recur octopus resolve stupid ours'
+all_strategies='recur recursive octopus resolve stupid ours'
default_twohead_strategies='recur'
default_octopus_strategies='octopus'
no_trivial_merge_strategies='ours'
diff --git a/git-rebase.sh b/git-rebase.sh
index 5d4c7d2..6472970 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -292,7 +292,7 @@ then
exit $?
fi
-if test "@@NO_PYTHON@@" && test "$strategy" = "recur"
+if test "@@NO_PYTHON@@" && test "$strategy" = "recursive"
then
die 'The recursive merge strategy currently relies on Python,
which this installation of git was not configured with. Please
consider
diff --git a/merge-recursive.c b/merge-recursive.c
index 07a2b38..1cae804 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -61,7 +61,8 @@ static void show_ce_entry(const char *ta
fputc('\n', stderr);
}
-static void ls_files() {
+static void ls_files(void)
+{
int i;
for (i = 0; i < active_nr; i++) {
struct cache_entry *ce = active_cache[i];
@@ -207,7 +208,7 @@ static const char *original_index_file;
static const char *temporary_index_file;
static int cache_dirty = 0;
-static int flush_cache()
+static int flush_cache(void)
{
/* flush temporary index */
struct lock_file *lock = xcalloc(1, sizeof(struct lock_file));
@@ -331,7 +332,7 @@ #endif
/*
* TODO: this can be streamlined by refactoring builtin-write-tree.c
*/
-static struct tree *git_write_tree()
+static struct tree *git_write_tree(void)
{
#if 0
fprintf(stderr, "GIT_INDEX_FILE='%s' git-write-tree\n",
@@ -467,7 +468,7 @@ static void free_index_entries(struct pa
* Create a dictionary mapping file names to CacheEntry objects. The
* dictionary contains one entry for every path with a non-zero stage
entry.
*/
-static struct path_list *get_unmerged()
+static struct path_list *get_unmerged(void)
{
struct path_list *unmerged = xcalloc(1, sizeof(struct path_list));
int i;
diff --git a/read-cache.c b/read-cache.c
index f6e1b70..0ef89a9 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -797,7 +797,7 @@ unmap:
die("index file corrupt");
}
-int discard_cache()
+int discard_cache(void)
{
int ret;
--
Regards,
Pavel Roskin
^ permalink raw reply related
* Re: [RFC] just an (stupid) idea when creating a new branch
From: Pavel Roskin @ 2006-07-09 3:27 UTC (permalink / raw)
To: moreau francis; +Cc: git
In-Reply-To: <20060708155547.73054.qmail@web25814.mail.ukl.yahoo.com>
Hello!
On Sat, 2006-07-08 at 15:55 +0000, moreau francis wrote:
> Hi GIT folks.
>
> I'm a complete newbie on git development so excuse me if
> this idea is completely stupid.
>
> Would it be possible to let the user stick a short explanation
> on what a branch is supposed to implement during its creation.
Just for your information, this is already implemented by StGIT. For
instance, .git/patches/master/description contains the description of
the "master" branch.
If you run "stg branch --list", the branch descriptions will be listed.
I'm not aware of any commands to change the description.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: RFH: refactor read-tree
From: Linus Torvalds @ 2006-07-09 3:15 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0607090015250.29667@wbgn013.biozentrum.uni-wuerzburg.de>
On Sun, 9 Jul 2006, Johannes Schindelin wrote:
>
> I also played a little with git-merge-tree, because it seems so much
> simpler and easier to refactor. But there is a problem: Either I call it
> the wrong way, or it does not yet work correctly: I tried
>
> git-merge-tree $(git-merge-base branch1 branch2) branch1 branch2
>
> with what is in 'next'. But it only showed the _new_ files, not the
> modified ones.
What git-merge-tree does is to show the _difference_ to "branch1".
So if the result of the merge would be totally identical to "branch1",
then git-merge-tree should be totally silent.
The basic idea is that "branch1" should be your current branch, and it
obviously is also expected to match (more or less) the current index. So
you can do a merge by
- reading in "branch1" into the index:
GIT_INDEX_FILE=.git/tmp-index git-read-tree -m branch1
- doing a "git-merge-tree $base $branch1 $branch2"
- using the _result_ of "git-merge-tree" to modify the index you just
read in.
- write out the end result as the result of the merge.
And yes, I agree 100% that "git-read-tree" has become an unholy mess. I
looked at it, and I think it's unfixable. I considered re-writing it from
scratch, at least for some specific cases, but I couldn't bring myself to
do it.
Linus
^ permalink raw reply
* Re: [PATCH] gitweb.cgi: Use File::MMagic; "a=blob" action knows the blob/file type
From: Luben Tuikov @ 2006-07-09 1:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vzmfksjpe.fsf@assigned-by-dhcp.cox.net>
--- Junio C Hamano <junkio@cox.net> wrote:
> Luben Tuikov <ltuikov@yahoo.com> writes:
>
> > Use File::MMagic to determine the MIME type of a blob/file.
> > The variable magic_mime_file holds the location of the
> > "magic.mime" file, usually "/usr/share/file/magic.mime".
> > If not defined, the magic numbers internally stored in the
> > File::MMagic module are used.
>
> I am sorry to ask you this, but would you mind redoing this
> patch without File::MMagic bits?
Yeah, no problem, will do.
> I think giving "a=blob" an
> ability to automatically switch to git_blob_plain is a good
> addition (as is your earlier patch to give a direct link to
> reach blob_plain from the list), so let's have that part in
> first.
Ok.
> I haven't applied your earlier one but it will appear in
> "next" shortly.
Ok.
> Existing filename based mimetypes_guess should be a lot cheaper
> than exploding a blob and feeding it to File::MMagic. I was
> hoping File::MMagic to be used when we cannot guess the content
> type that way (i.e. when mimetypes_guess returns undef or
> application/octet-stream).
The MIME guessing is used in git_blob_plain(), where the blob
is already exploded, since a file descriptor is passed to the MIME
guessing routines.
Initially I tried using the already opened file descriptor to
the blob, but File::MMagic v1.27 always returns "text/plain"
on that. I was astounded by this and a 5 line perl script
using that same module confirmed my suspicion that the module
or "seek" is broken in perl or in FileHandle. I.e.
checktype_filename() succeeds, but checktype_filehandle()
always returns "text/plain".
Had simply reading the file descriptor succeeded, then we'd not
need to explode blobs in $git_temp.
The other reason I decided to completely go with File::MMagic is
that if I'm going to use it to decide the mime type after
the default method didn't succeed, why not forget the default
method and just use File::MMagic in general -- seemed like a logical
simplification.
> Since the repository owner can correct misidentification by the
> standard /etc/mime.types by supplying a custom per-repository
> $mimetypes_file (modulo that the current implementation of
> mimetype_guess_file does not allow it if the file does not have
> an extension that is specific enough), File::MMagic might be an
> overkill, especially if used in the way this patch does. To
> allow finer grained differentiation that cannot be done with
> file extensions alone (e.g. some files may have .dat extension
> but one can be VCD mpeg wrapped in RIFF, and another can be a
> Z-machine story file), it might be simpler to allow the
> repository owner to specify full $file_name for such an ambiguous
> file in their custom $mimetypes_file, and try to match it in
> mimetype_guess_file sub. That way we may not even need to use
> File::MMagic.
This is true, but I wonder how many people are going to go and
create their own mime.type files. Most of the time people would
do minimal gitweb.cgi changes not even specifying $mimetypes_file
nor even $magic_mime_file.
> Are there cases where only $hash is given without $file_name?
> If so we may need to fall back on File::MMagic in such a case
> after all, but get_blob_mimetype sub copies the whole blob to a
> temporary file to work around a problem with version 1.27 you
> state in the comment -- this is way too much (and nobody seems
> to clean up the tempfile). Looking at magic.mime, I suspect we
> might be able to get away with the first 4k bytes or so at most
> (the largest offset except iso9660 image is "Biff5" appearing at
> 2114 to signal an Excel spreadsheet).
I was hoping that tmpwatch(8) would clean up the blobs in Linux/UNIX.
But we can also delete them after the lookup. Anothing thing is that
getting a blob isn't that often and when it happens, after the MIME
lookup it is already in the pagecache.
Luben
^ permalink raw reply
* What *have* I done?
From: Nix @ 2006-07-08 22:48 UTC (permalink / raw)
To: git
I am just a git newbie, still reliant on cogito 0.17.3 for most things
(cogito has a couple of cherry-picked patches from the head for
faster cg-seek and for support of lightweight tags.)
I tried my first conflicted cherry-pick a while back; resolved the
conflict, committed, ran git-update-index over the conflicted file as
git-cherry-pick requested, yet now the branch the cherry-pick was done
to seems to be oddly `half-stuck'.
Here's an example:
loki 590 /usr/packages/linux/linux% cg-status -g
Heads:
R 2.6.17-stable 4f9619cdd90ac846fa0ca6e9e8a9d87a0d6b4f57
esperi-guest 764415bf7dc0388d9974218fb71b3c63f19f3828
master 578997683c8d788f80f7a11fc27fcdf66ac8fd9f
R origin 120bda20c6f64b32e8bfbdd7b34feafaa5f5332e
v2.6.17 e519ad6612b8ab69cbf45b59dda45f88cada41f2
>x86-host e2a9e65e9d5f7e76dbe0a8fdd0f1356266146c22
loki 591 /usr/packages/linux/linux% cg-diff
loki 592 /usr/packages/linux/linux% cg-switch v2.6.17
Switching to branch v2.6.17...
Now one would expect that after switching, I'd have no uncommitted
changes, right, since I had none before switching and they shouldn't
appear out of thin air? You'd be wrong:
loki 593 /usr/packages/linux/linux% cg-diff | diffstat
b/Makefile | 4 +-
b/arch/sparc64/Makefile | 15 +++----
b/arch/sparc64/kernel/Makefile | 2 -
b/arch/um/kernel/dyn.lds.S | 1
b/kernel/pid.c | 2 -
b/scripts/kconfig/Makefile | 7 ++-
b/usr/gen_init_cpio.c | 2 -
usr/init | 79 -----------------------------------------
usr/initramfs | 45 -----------------------
9 files changed, 15 insertions(+), 142 deletions(-)
Those miraculously materialized uncommitted changes are the *reverse* of
every commit I made after that failed cherry-pick! (If I switch branches
back, or run `cg-seek', it tries to take these `uncommitted local
changes' with me, with amusing results.)
So, has it forgotten what the branch head is? No: cg-log reports correct
data, cg-reset works fine:
loki 594 /usr/packages/linux/linux% cg-reset
loki 595 /usr/packages/linux/linux% cg-diff
loki 596 /usr/packages/linux/linux%
So, um, what on earth has gone wrong and how do I fix it? (If you need
more info, just ask!)
^ permalink raw reply
* RFH: refactor read-tree
From: Johannes Schindelin @ 2006-07-08 22:28 UTC (permalink / raw)
To: git
Hi,
the last thing to do with merge-recursive to speed it up, would be to
avoid reading/writing the cache all the time.
Unfortunately, builtin-read-tree.c grew into a pretty big monster, with so
many different options which completely change behaviour.
So, how should I go about it? Should I make a struct a la diff_options to
hold the options to unpack_trees? Where should it go?
I also played a little with git-merge-tree, because it seems so much
simpler and easier to refactor. But there is a problem: Either I call it
the wrong way, or it does not yet work correctly: I tried
git-merge-tree $(git-merge-base branch1 branch2) branch1 branch2
with what is in 'next'. But it only showed the _new_ files, not the
modified ones.
Help, please?
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC] just an (stupid) idea when creating a new branch
From: Johannes Schindelin @ 2006-07-08 22:15 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e8p8pj$jk3$2@sea.gmane.org>
Hi,
On Sat, 8 Jul 2006, Jakub Narebski wrote:
> moreau francis wrote:
>
> > Hi GIT folks.
> >
> > I'm a complete newbie on git development so excuse me if
> > this idea is completely stupid.
> >
> > Would it be possible to let the user stick a short explanation
> > on what a branch is supposed to implement during its creation.
>
> It would be possible when/if branch and remotes config would migrate
> to .git/config. Currently too many I think relies on refs/heads being
> simple sha1 of "top" commit.
But it does not need a change of existing practice at all! Just add the
information provided by --topic as branch."pathname".description to the
config. And make format-patch aware of that.
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC] just an (stupid) idea when creating a new branch
From: Jakub Narebski @ 2006-07-08 21:41 UTC (permalink / raw)
To: git
In-Reply-To: <20060708155547.73054.qmail@web25814.mail.ukl.yahoo.com>
moreau francis wrote:
> Hi GIT folks.
>
> I'm a complete newbie on git development so excuse me if
> this idea is completely stupid.
>
> Would it be possible to let the user stick a short explanation
> on what a branch is supposed to implement during its creation.
It would be possible when/if branch and remotes config would migrate
to .git/config. Currently too many I think relies on refs/heads being
simple sha1 of "top" commit.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: What's in git.git
From: Jakub Narebski @ 2006-07-08 21:28 UTC (permalink / raw)
To: git
In-Reply-To: <7vlkr5szi2.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> I hope further patches to this series will be added soon to
> autodetect the following in our Makefile (from "pu"):
I have just (re)sent series of patches adding autodetection
of building options via autoconf generated configure.
> NO_D_INO_IN_DIRENT
> NO_D_TYPE_IN_DIRENT
> NO_STRCASESTR
> NO_STRLCPY
> NO_SETENV
> NO_SOCKADDR_STORAGE
Done.
> USE_PIC
To be written by somebody better versed in autoconf.
> NEEDS_SSL_WITH_CRYPTO
> NEEDS_LIBICONV
> NEEDS_SOCKET
Needs checking.
> WITH_OWN_SUBPROCESS_PY
> NO_IPV6
> NO_ICONV
Needs explanation, and probably custom test.
> These are not something you can change without replacing libc
> (or installed Python) wholesale, so autodetection would be
> always correct.
>
> Also the following would be nice if autodetection worked for
> most of the users with ./configure command line override:
>
> CC
> AR
> TAR
Done, I think
> INSTALL
Needs lightweight install-sh script. If I remember correctly someone
provided such script because of lack of install on some exotic
architecture. Easily provided.
> SHELL_PATH
> PERL_PATH
> PYTHON_PATH
To be done using --with-shell=PATH, --with-perl=PATH,
--with-python=PATH, easily.
> BASIC_CFLAGS mostly for -I include paths
> BASIC_LDFLAGS mostly for -L library paths
> ALL_LDFLAGS
I don't know how to do this (for now), probably quite easy.
> NO_OPENSSL
> MOZILLA_SHA1
> PPC_SHA1
> ARM_SHA1
> NO_CURL
> NO_EXPAT
> CURLDIR
> OPENSSLDIR
> ICONVDIR
> EXPATDIR (we do not have one, but I think it should be there
> to allow -lexpat installed elsewhere just like
> we have CURLDIR and OPENSSLDIR)
Should be done in next series of patches... provided I'd have enough
free time for this...
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* [PATCH 9] configure.ac vertical whitespace usage cleanup
From: Jakub Narebski @ 2006-07-08 21:07 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
In-Reply-To: <11523928372070-git-send-email-jnareb@gmail.com>
configure.ac | 29 +++++++++++++++--------------
1 files changed, 15 insertions(+), 14 deletions(-)
diff --git a/configure.ac b/configure.ac
index 56e765f..acea6ce 100644
--- a/configure.ac
+++ b/configure.ac
@@ -23,41 +23,41 @@ AC_DEFUN([GIT_CONF_APPEND_LINE],
## Checks for programs.
AC_MSG_NOTICE([CHECKS for programs])
-
+#
AC_PROG_CC
#AC_PROG_INSTALL # needs install-sh or install.sh in sources
AC_CHECK_TOOL(AR, ar, :)
AC_CHECK_PROGS(TAR, [gtar tar])
-
+#
# Define NO_PYTHON if you want to loose all benefits of the recursive merge.
## Checks for libraries.
AC_MSG_NOTICE([CHECKS for libraries])
-
+#
# Define NO_OPENSSL environment variable if you do not have OpenSSL.
# Define NEEDS_SSL_WITH_CRYPTO if you need -lcrypto with -lssl (Darwin).
AC_CHECK_LIB([ssl], [SHA1_Init],[],
[AC_CHECK_LIB([crypto], [SHA1_INIT],
GIT_CONF_APPEND_LINE(NEEDS_SSL_WITH_CRYPTO=YesPlease),
GIT_CONF_APPEND_LINE(NO_OPENSSL=YesPlease))])
-
+#
# Define NO_CURL if you do not have curl installed. git-http-pull and
# git-http-push are not built, and you cannot use http:// and https://
# transports.
AC_CHECK_LIB([curl], [curl_global_init],[],
GIT_CONF_APPEND_LINE(NO_CURL=YesPlease))
-
+#
# Define NO_EXPAT if you do not have expat installed. git-http-push is
# not built, and you cannot push using http:// and https:// transports.
AC_CHECK_LIB([expat], [XML_ParserCreate],[],
GIT_CONF_APPEND_LINE(NO_EXPAT=YesPlease))
-
+#
# Define NEEDS_LIBICONV if linking with libc is not enough (Darwin).
AC_CHECK_LIB([c], [iconv],[],
[AC_CHECK_LIB([iconv],[iconv],
GIT_CONF_APPEND_LINE(NEEDS_LIBICONV=YesPlease),[])])
-
+#
# Define NEEDS_SOCKET if linking with libc is not enough (SunOS,
# Patrick Mauritz).
AC_CHECK_LIB([c], [socket],[],
@@ -70,18 +70,18 @@ ## Checks for header files.
## Checks for typedefs, structures, and compiler characteristics.
AC_MSG_NOTICE([CHECKS for typedefs, structures, and compiler characteristics])
-
+#
# Define NO_D_INO_IN_DIRENT if you don't have d_ino in your struct dirent.
AC_CHECK_MEMBER(struct dirent.d_ino,[],
GIT_CONF_APPEND_LINE(NO_D_INO_IN_DIRENT=YesPlease),
[#include <dirent.h>])
-
+#
# Define NO_D_TYPE_IN_DIRENT if your platform defines DT_UNKNOWN but lacks
# d_type in struct dirent (latest Cygwin -- will be fixed soonish).
AC_CHECK_MEMBER(struct dirent.d_type,[],
GIT_CONF_APPEND_LINE(NO_D_TYPE_IN_DIRENT=YesPlease),
[#include <dirent.h>])
-
+#
# Define NO_SOCKADDR_STORAGE if your platform does not have struct
# sockaddr_storage.
AC_CHECK_TYPE(struct sockaddr_storage,[],
@@ -92,19 +92,19 @@ GIT_CONF_APPEND_LINE(NO_SOCKADDR_STORAGE
## Checks for library functions.
## (in default C library and libraries checked by AC_CHECK_LIB)
AC_MSG_NOTICE([CHECKS for library functions])
-
+#
# Define NO_STRCASESTR if you don't have strcasestr.
AC_CHECK_FUNC(strcasestr,[],
GIT_CONF_APPEND_LINE(NO_STRCASESTR=YesPlease))
-
+#
# Define NO_STRLCPY if you don't have strlcpy.
AC_CHECK_FUNC(strlcpy,[],
GIT_CONF_APPEND_LINE(NO_STRLCPY=YesPlease))
-
+#
# Define NO_SETENV if you don't have setenv in the C library.
AC_CHECK_FUNC(setenv,[],
GIT_CONF_APPEND_LINE(NO_SETENV=YesPlease))
-
+#
# Define NO_MMAP if you want to avoid mmap.
#
# Define NO_IPV6 if you lack IPv6 support and getaddrinfo().
@@ -178,5 +178,6 @@ ## Output files
AC_CONFIG_FILES(["${config_file}":"${config_in}":"${config_append}"])
AC_OUTPUT
+
## Cleanup
rm -f "${config_append}"
--
1.4.0
^ permalink raw reply related
* Re: Comment on this series of patches (PATCH 2-9)
From: Junio C Hamano @ 2006-07-08 21:20 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <11523928383501-git-send-email-jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> This concludes easiest part of autodetecting compile configuration
> using autoconf generated configure script. Patches needs revision by
> somebody better versed in autoconf than me.
Thanks. Will take a look.
> About needing autoconf to build git:
>
> 1. Currently using autoconf is totally optional, so one can compile
> git as one used to earlier.
This should stay this way, at least for now and probably even
after merging this into "master" someday (we need to get this in
"next" first).
> 2. configure script generated by autoconf can be treated exactly the
> same like html and man documentation generated by asciidoc: use
> separate 'configure' branch to store current version of configure
> script, and add autogeneration of configure script to the same hook
> like generating html and man documentation.
Actually my gut feeling on this is eventually (read: when the
autoconfiguration is stable enough) we would want to do this the
other way around --- keep only the generated configure script
for public consumption, and interested parties can check out
autoconf branch to hack on configure.ac and friends when needed.
But we haven't reached that point yet, so we will see.
^ permalink raw reply
* Re: [PATCH] Replace sed with perl when setting up perl scripts.
From: Junio C Hamano @ 2006-07-08 21:11 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <20060708193717.GA17905@spearce.org>
Please try the replacement patch I sent to the list earlier in
response to Johannes's patch to the same problem.
^ permalink raw reply
* Comment on this series of patches (PATCH 2-9)
From: Jakub Narebski @ 2006-07-08 21:07 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
In-Reply-To: <11523928383518-git-send-email-jnareb@gmail.com>
This concludes easiest part of autodetecting compile configuration
using autoconf generated configure script. Patches needs revision by
somebody better versed in autoconf than me.
Autodetection TODO:
* check for Python (NO_PYTHON) and it's version (WITH_OWN_SUBPROCESS_PY)
or just "own subprocess.py"
* check for "IPv6 support" and getaddrinfo() (NO_IPV6), latter can be
easily done in autoconf
* check for "proper iconv support" (NO_ICONV), probably custom check.
* check for USE_PIC, NO_SYMLINK_HEAD and NO_ACCURATE_DIFF, all
needing custom tests.
* use XXX_SHA1 when NO_OPENSSL, with XXX according to the architecture
git is compiled for.
Next planned are series of patches allowing to select optional
build features and packages from configure script... if somebody else
wouldn't do it (hint, hint).
About needing autoconf to build git:
1. Currently using autoconf is totally optional, so one can compile
git as one used to earlier. This results in non-autoconf conventions
in configure.ac
2. configure script generated by autoconf can be treated exactly the
same like html and man documentation generated by asciidoc: use
separate 'configure' branch to store current version of configure
script, and add autogeneration of configure script to the same hook
like generating html and man documentation.
--
Jakub Narebski
ShadeHawk on #git
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox