* Re: [Patch] Using 'perl' in *.sh
From: Yakov Lerner @ 2006-07-09 10:09 UTC (permalink / raw)
To: Alex Riesen; +Cc: Junio C Hamano, Michal Rokos, git
In-Reply-To: <20060709094630.GB5919@steel.home>
On 7/9/06, Alex Riesen <fork0@t-online.de> wrote:
> Junio C Hamano, Sat, Jul 08, 2006 20:27:37 +0200:
> > >
> > > some GIT's shell script are using bare 'perl' for perl invocation. It's
> > > causing me problems... I compile git with PERL_PATH set and I'd suggest to
> > > use it everywhere.
> > >
> > > So @@PERL@@ would be replaced with PERL_PATH_SQ instead.
> > >
> > > What do you think?
> >
> > Absolutely.
>
> Now imagine a non-posix system where an upgrade was made. Amongst
> other things perl was moved, i.e. from /opt/perl-5.8.8 to
> /usr/local/{bin,lib}. Suddenly git breaks.
Building new perl for sources never removed,
by itself, older perls on the system. Did it ever for you ?
How would installing new perl into new location
break git ? It would only break if you *remove*
old perl, not if you install new perl into new
location, no ?
Yakov
^ permalink raw reply
* [PATCH] change ent to tree in git-diff documentation
From: Matthias Lederhofer @ 2006-07-09 9:59 UTC (permalink / raw)
To: git, Junio C Hamano
---
I've sent this patch a while ago and did not get any feedback, so here
it is again.
This is quite confusing for someone new to git who is not familiar
with the vocabulary used with git. I don't think a man page is the
right place for riddles :)
Additionaly I changed two times 'is' to 'are', I hope this is correct.
Documentation/git-diff.txt | 18 +++++++++---------
1 files changed, 9 insertions(+), 9 deletions(-)
83ace740fdf1e064168f8438a6ad863986cf4832
diff --git a/Documentation/git-diff.txt b/Documentation/git-diff.txt
index 890931c..41d85cf 100644
--- a/Documentation/git-diff.txt
+++ b/Documentation/git-diff.txt
@@ -8,24 +8,24 @@ git-diff - Show changes between commits,
SYNOPSIS
--------
-'git-diff' [ --diff-options ] <ent>{0,2} [<path>...]
+'git-diff' [ --diff-options ] <tree-ish>{0,2} [<path>...]
DESCRIPTION
-----------
-Show changes between two ents, an ent and the working tree, an
-ent and the index file, or the index file and the working tree.
+Show changes between two trees, a tree and the working tree, a
+tree and the index file, or the index file and the working tree.
The combination of what is compared with what is determined by
-the number of ents given to the command.
+the number of trees given to the command.
-* When no <ent> is given, the working tree and the index
- file is compared, using `git-diff-files`.
+* When no <tree-ish> is given, the working tree and the index
+ file are compared, using `git-diff-files`.
-* When one <ent> is given, the working tree and the named
- tree is compared, using `git-diff-index`. The option
+* When one <tree-ish> is given, the working tree and the named
+ tree are compared, using `git-diff-index`. The option
`--cached` can be given to compare the index file and
the named tree.
-* When two <ent>s are given, these two trees are compared
+* When two <tree-ish>s are given, these two trees are compared
using `git-diff-tree`.
OPTIONS
--
1.3.1.g9af0
^ permalink raw reply related
* Re: [Patch] Using 'perl' in *.sh
From: Jan-Benedict Glaw @ 2006-07-09 9:51 UTC (permalink / raw)
To: Alex Riesen; +Cc: Junio C Hamano, Michal Rokos, git
In-Reply-To: <20060709094630.GB5919@steel.home>
[-- Attachment #1: Type: text/plain, Size: 1140 bytes --]
On Sun, 2006-07-09 11:46:30 +0200, Alex Riesen <fork0@t-online.de> wrote:
> Junio C Hamano, Sat, Jul 08, 2006 20:27:37 +0200:
> > >
> > > some GIT's shell script are using bare 'perl' for perl invocation. It's
> > > causing me problems... I compile git with PERL_PATH set and I'd suggest to
> > > use it everywhere.
> > >
> > > So @@PERL@@ would be replaced with PERL_PATH_SQ instead.
> > >
> > > What do you think?
> >
> > Absolutely.
>
> Now imagine a non-posix system where an upgrade was made. Amongst
> other things perl was moved, i.e. from /opt/perl-5.8.8 to
> /usr/local/{bin,lib}. Suddenly git breaks.
My personal oppinion is to call perl scripts as `perl foo.pl' and thus
let the user decide (by means of setting $PATH) which perl incarnation
she wants to use.
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 : [RFC] just an (stupid) idea when creating a new branch
From: moreau francis @ 2006-07-09 9:48 UTC (permalink / raw)
To: Pavel Roskin; +Cc: git
In-Reply-To: <1152415640.2103.10.camel@dv>
> Just for your information, this is already implemented by StGIT. For
> instance, .git/patches/master/description contains the description of
> the "master" branch.
well I'm using plain git for now. And it doesn't seem to be a high level
feature.
Another point to this would be to show this set of patch and its summary
threaded under a mailer. I use thunderbird, and it's possible to use threaded
view which is very convinient. I don't know how it works, but see the set of
patchs like:
[PATCH 0/3] Summary of the set
|
+ [PATCH 1/4] blababla
+ [PATCH 2/4] another useful commit
+ [PATCH 3/4] ...
would be great !
Francis
PS: please CC me when answering.
^ permalink raw reply
* Re: [Patch] Using 'perl' in *.sh
From: Alex Riesen @ 2006-07-09 9:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Michal Rokos, git
In-Reply-To: <7v3bdcq7dy.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano, Sat, Jul 08, 2006 20:27:37 +0200:
> >
> > some GIT's shell script are using bare 'perl' for perl invocation. It's
> > causing me problems... I compile git with PERL_PATH set and I'd suggest to
> > use it everywhere.
> >
> > So @@PERL@@ would be replaced with PERL_PATH_SQ instead.
> >
> > What do you think?
>
> Absolutely.
Now imagine a non-posix system where an upgrade was made. Amongst
other things perl was moved, i.e. from /opt/perl-5.8.8 to
/usr/local/{bin,lib}. Suddenly git breaks.
^ permalink raw reply
* [PATCH] gitweb: Send XHTML as 'application/xhtml+xml' where possible
From: Alp Toker @ 2006-07-09 9:41 UTC (permalink / raw)
To: git
"The 'text/html' media type [RFC2854] is primarily for HTML, not for
XHTML. In general, this media type is NOT suitable for XHTML."
This patch makes gitweb use content negotiation to conservatively send
pages as Content-Type 'application/xhtml+xml' when the user agent
explicitly claims to support it.
It falls back to 'text/html' even if the user agent claims to support
'application/xhtml+xml' by means of a glob in order to work around an
insidious Internet Explorer bug.
Signed-off-by: Alp Toker <alp@atoker.com>
---
gitweb/gitweb.cgi | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/gitweb/gitweb.cgi b/gitweb/gitweb.cgi
index 3e2790c..3206435 100755
--- a/gitweb/gitweb.cgi
+++ b/gitweb/gitweb.cgi
@@ -290,7 +290,8 @@ sub git_header_html {
}
}
}
- print $cgi->header(-type=>'text/html', -charset => 'utf-8', -status=> $status, -expires => $expires);
+ my $content_type = ($cgi->http('HTTP_ACCEPT') =~ m/(,|;|\s|^)application\/xhtml\+xml(,|;|\s|$)/ && $cgi->Accept('application/xhtml+xml') ne 0) ? 'application/xhtml+xml' : 'text/html';
+ print $cgi->header(-type=>$content_type, -charset => 'utf-8', -status=> $status, -expires => $expires);
print <<EOF;
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
@@ -298,7 +299,7 @@ sub git_header_html {
<!-- git web interface v$version, (C) 2005-2006, Kay Sievers <kay.sievers\@vrfy.org>, Christian Gierke -->
<!-- git core binaries version $git_version -->
<head>
-<meta http-equiv="content-type" content="text/html; charset=utf-8"/>
+<meta http-equiv="content-type" content="$content_type; charset=utf-8"/>
<meta name="robots" content="index, nofollow"/>
<title>$title</title>
<link rel="stylesheet" type="text/css" href="$stylesheet"/>
--
1.4.1.gbe4c7
^ permalink raw reply related
* [PATCH] Fix some doubled word typos
From: Alp Toker @ 2006-07-09 9:36 UTC (permalink / raw)
To: git; +Cc: Alp Toker
Signed-off-by: Alp Toker <alp@atoker.com>
---
Documentation/git-svn.txt | 2 +-
Documentation/urls.txt | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
index f7d3de4..7d86809 100644
--- a/Documentation/git-svn.txt
+++ b/Documentation/git-svn.txt
@@ -224,7 +224,7 @@ Merge tracking in Subversion is lacking
with Subversion is cumbersome as a result. git-svn completely forgoes
any automated merge/branch tracking on the Subversion side and leaves it
entirely up to the user on the git side. It's simply not worth it to do
-a useful translation when the the original signal is weak.
+a useful translation when the original signal is weak.
TRACKING MULTIPLE REPOSITORIES OR BRANCHES
------------------------------------------
diff --git a/Documentation/urls.txt b/Documentation/urls.txt
index 7477413..d60b371 100644
--- a/Documentation/urls.txt
+++ b/Documentation/urls.txt
@@ -47,7 +47,7 @@ Then such a short-hand is specified in p
<repository> without <refspec> parameters on the command
line, <refspec> specified on `Push:` lines or `Pull:`
lines are used for `git-push` and `git-fetch`/`git-pull`,
-respectively. Multiple `Push:` and and `Pull:` lines may
+respectively. Multiple `Push:` and `Pull:` lines may
be specified for additional branch mappings.
The name of a file in `$GIT_DIR/branches` directory can be
--
1.4.1.gbe4c7
^ permalink raw reply related
* [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
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