* Re: [PATCH/RFC] "git --less cmd" to page anywhere
From: Linus Torvalds @ 2006-06-07 0:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vodx5n8en.fsf_-_@assigned-by-dhcp.cox.net>
On Tue, 6 Jun 2006, Junio C Hamano wrote:
>
> This allows you to say:
>
> git --less diff v2.6.16-rc5..
I've seriously considered something like that, although you chose a pretty
strange - and long - flag.
I was thinking something like "git -p log -p" (the first "-p" is for
"paginate" - think "dir/p" in old DOS times, but we could claim it is for
"pager" so that people don't laugh at us)
Linus
^ permalink raw reply
* Re: [PATCH/RFC] "git --less cmd" to page anywhere
From: Petr Baudis @ 2006-06-07 0:08 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0606061703380.5498@g5.osdl.org>
Dear diary, on Wed, Jun 07, 2006 at 02:05:59AM CEST, I got a letter
where Linus Torvalds <torvalds@osdl.org> said that...
> On Tue, 6 Jun 2006, Junio C Hamano wrote:
> >
> > This allows you to say:
> >
> > git --less diff v2.6.16-rc5..
>
> I've seriously considered something like that, although you chose a pretty
> strange - and long - flag.
>
> I was thinking something like "git -p log -p" (the first "-p" is for
> "paginate" - think "dir/p" in old DOS times, but we could claim it is for
> "pager" so that people don't laugh at us)
Actually, you made a case in the misty past that cg-log should just
stuff things through a pager by default and I ended up finding that
extremely convenient - what is the reason git log does not do the same?
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
A person is just about as big as the things that make them angry.
^ permalink raw reply
* Re: Importing Mozilla CVS into git
From: Keith Packard @ 2006-06-07 0:12 UTC (permalink / raw)
To: Martin Langhoff; +Cc: keithp, Jon Smirl, git
In-Reply-To: <46a038f90606061257v569aefackc4920a20f2970b0f@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 993 bytes --]
On Wed, 2006-06-07 at 07:57 +1200, Martin Langhoff wrote:
> git-cvsimport has a memory leak that I've been chasing for a while and
> I'll eventually fix, so it should fit in 32MB comfortably. cvsps is
> memory bound, and will probably take quite a bit of work to fix that.
> However, I suspect we can make it a lot more efficient.
Yeah, parsecvs is a memory pig as well -- it builds a giant in-memory
representation of the entire project history using flat lists of files
for every revision, just like git used to do. Fixing that should make it
run in small amounts of memory; it only needs 40 bytes per file revision
for the raw data as it converts the cvs files to git objects as it reads
them, saving only the hash value in memory.
Not relying on cvsps has been a huge feature though; cvsps loses a
tremendous amount of data, along with making several gross and difficult
to fix errors in project history from several of my repositories.
--
keith.packard@intel.com
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH/RFC] "git --less cmd" to page anywhere
From: Linus Torvalds @ 2006-06-07 0:12 UTC (permalink / raw)
To: Petr Baudis; +Cc: Junio C Hamano, git
In-Reply-To: <20060607000816.GY10488@pasky.or.cz>
On Wed, 7 Jun 2006, Petr Baudis wrote:
>
> Actually, you made a case in the misty past that cg-log should just
> stuff things through a pager by default and I ended up finding that
> extremely convenient - what is the reason git log does not do the same?
"git log" does, "git diff" does not (and yeah, I just chose a bad example,
I meant "git -p diff -p")
For "git diff", pagination by default is definitely not the right thing to
do, but it's something you often end up wanting.
Linus
^ permalink raw reply
* [PATCH] Support for configurable git command aliases (v3)
From: Petr Baudis @ 2006-06-07 0:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
This patch adds support for configurable aliases for git commands -
"alias.WHATEVER = which ever" will kick in when you do "git WHATEVER"
and substitute WHATEVER with "which ever" (splitted to arguments at
whitespaces).
The second version does all the work in handle_aliases() which was
inspired by Johannes Schindelin's patch.
The third version does not expand aliases when called as 'git-something'
or when the $GIT_NO_ALIASES environment variable is set; that is now
done in git-sh-setup.sh. The documentation has been slightly expanded.
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
Documentation/config.txt | 12 +++++++++
Documentation/git.txt | 3 ++
git-sh-setup.sh | 2 +
git.c | 64 ++++++++++++++++++++++++++++++++++++++++++++--
4 files changed, 78 insertions(+), 3 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index c861c6c..071ff4e 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -91,6 +91,18 @@ core.warnAmbiguousRefs::
If true, git will warn you if the ref name you passed it is ambiguous
and might match multiple refs in the .git/refs/ tree. True by default.
+alias.*::
+ Command aliases for the gitlink:git[1] command wrapper - e.g.
+ after defining "alias.last = cat-file commit HEAD", the invocation
+ "git last" is equivalent to "git cat-file commit HEAD". You can
+ override even existing command names with aliases (you can use that
+ to define some default set of parameters for some command). However,
+ there is only a single level of alias expansion - the alias definition
+ is not searched for aliases anymore. Alias checking is disabled when
+ the "$GIT_NO_ALIASES" environment variable is set - you should
+ definitely do that if you call commands by the 'git' wrapper in your
+ scripts.
+
apply.whitespace::
Tells `git-apply` how to handle whitespaces, in the same way
as the '--whitespace' option. See gitlink:git-apply[1].
diff --git a/Documentation/git.txt b/Documentation/git.txt
index 24ca55d..e474bdf 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -21,6 +21,9 @@ link:everyday.html[Everyday Git] for a u
"man git-commandname" for documentation of each command. CVS users may
also want to read link:cvs-migration.html[CVS migration].
+The COMMAND is either a name of a Git command (see below) or an alias
+as defined in the configuration file (see gitlink:git-repo-config[1]).
+
OPTIONS
-------
--version::
diff --git a/git-sh-setup.sh b/git-sh-setup.sh
index d15747f..c56ae8c 100755
--- a/git-sh-setup.sh
+++ b/git-sh-setup.sh
@@ -49,3 +49,5 @@ then
else
GIT_DIR=$(git-rev-parse --git-dir) || exit
fi
+
+export GIT_NO_ALIASES=1
diff --git a/git.c b/git.c
index bc463c9..b85dafa 100644
--- a/git.c
+++ b/git.c
@@ -10,6 +10,7 @@ #include <limits.h>
#include <stdarg.h>
#include "git-compat-util.h"
#include "exec_cmd.h"
+#include "cache.h" /* setup_git_directory_gently() */
#include "builtin.h"
@@ -88,13 +89,66 @@ static void handle_internal_command(int
}
}
+static const char *cmd;
+static char *cmdalias;
+
+int git_alias_config(const char *var, const char *value)
+{
+ if (strncmp(var, "alias.", 6))
+ return 0;
+ var += /* strlen("alias.") */ 6;
+ if (!strcmp(var, cmd))
+ cmdalias = strdup(value);
+ return 0;
+}
+
+void handle_alias(int *argc, const char ***argv)
+{
+ /* XXX: We do a redundant git directory detection. */
+ int nongit = 0;
+ const char *subdir;
+ char *env = getenv("GIT_NO_ALIASES");
+
+ if (!env || !*env)
+ return;
+
+ subdir = setup_git_directory_gently(&nongit);
+ if (!nongit) {
+ git_config(git_alias_config);
+ if (cmdalias) {
+ /* More than the worst case: */
+ const char **argv2 = malloc((strlen(cmdalias) + *argc) * sizeof(char*));
+ int argc2 = 0, i = 1;
+
+ while (cmdalias && *cmdalias) {
+ argv2[argc2++] = strsep(&cmdalias, " \t");
+ if (cmdalias)
+ while (*cmdalias == ' ' || *cmdalias == '\t')
+ cmdalias++;
+ }
+ while (i < *argc) {
+ argv2[argc2++] = (*argv)[i++];
+ }
+ argv2[argc2] = NULL;
+ *argv = argv2;
+ *argc = argc2;
+ }
+ }
+
+ /* Go back so that the commands start with clean table */
+ if (subdir)
+ chdir(subdir);
+}
+
+
int main(int argc, const char **argv, char **envp)
{
- const char *cmd = argv[0];
- char *slash = strrchr(cmd, '/');
+ char *slash = strrchr(argv[0], '/');
char git_command[PATH_MAX + 1];
const char *exec_path = NULL;
+ cmd = argv[0];
+
/*
* Take the basename of argv[0] as the command
* name, and the dirname as the default exec_path
@@ -117,6 +171,10 @@ int main(int argc, const char **argv, ch
*
* So we just directly call the internal command handler, and
* die if that one cannot handle it.
+ *
+ * We also do not evaluate aliases in this case since git-log
+ * should never expand to something unpredictable (that is
+ * important e.g. for scripts).
*/
if (!strncmp(cmd, "git-", 4)) {
cmd += 4;
@@ -178,7 +236,7 @@ int main(int argc, const char **argv, ch
exec_path = git_exec_path();
prepend_to_path(exec_path, strlen(exec_path));
- /* See if it's an internal command */
+ handle_alias(&argc, &argv);
handle_internal_command(argc, argv, envp);
/* .. then try the external ones */
^ permalink raw reply related
* Re: [PATCH] Support for configurable git command aliases (v3)
From: Petr Baudis @ 2006-06-07 0:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20060607001638.5175.77792.stgit@machine.or.cz>
Dear diary, on Wed, Jun 07, 2006 at 02:16:38AM CEST, I got a letter
where Petr Baudis <pasky@suse.cz> said that...
> This patch adds support for configurable aliases for git commands -
> "alias.WHATEVER = which ever" will kick in when you do "git WHATEVER"
> and substitute WHATEVER with "which ever" (splitted to arguments at
> whitespaces).
>
> The second version does all the work in handle_aliases() which was
> inspired by Johannes Schindelin's patch.
>
> The third version does not expand aliases when called as 'git-something'
> or when the $GIT_NO_ALIASES environment variable is set; that is now
> done in git-sh-setup.sh. The documentation has been slightly expanded.
>
> Signed-off-by: Petr Baudis <pasky@suse.cz>
So, I chose the approach suggested by Linus, but I do not have a strong
preference and if Junio still wants, we can rather just disallow aliases
with the same name as builtins - I just think that it *might* be
practical to add some default options to the commands without relearning
your typing habits.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
A person is just about as big as the things that make them angry.
^ permalink raw reply
* Re: [PATCH] Support for configurable git command aliases (v3)
From: Junio C Hamano @ 2006-06-07 0:29 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060607001638.5175.77792.stgit@machine.or.cz>
I've already swallowed Johannes's patch that also takes good
parts from your patch (most importantly, the part to call
setup_git_directory_gently() so that things can work from a
subdirectory and still find the config) in "next", and I am
hoping to push it out by end of (my) tomorrow. So I'd
appreciate any improvements (including docs perhaps) on top of
that instead.
^ permalink raw reply
* Re: Importing Mozilla CVS into git
From: Jon Smirl @ 2006-06-07 0:40 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git
In-Reply-To: <9e4733910606060813r41037467u74235f7a9386c1e0@mail.gmail.com>
On 6/6/06, Jon Smirl <jonsmirl@gmail.com> wrote:
> On 6/6/06, Martin Langhoff <martin.langhoff@gmail.com> wrote:
> > On 6/3/06, Jon Smirl <jonsmirl@gmail.com> wrote:
> > > On 6/1/06, Jon Smirl <jonsmirl@gmail.com> wrote:
> > > > With the attached patch you can parse the entire Mozilla tree. The
> > > > tree has over 100,000 files in it and about 300 branches.
> > >
> > > I was a little low with these counts, more like 110,000 files and some
> > > parts of the tree have 1,000 branches. Total tree size is 3GB.
> >
> > I don't think it really has that many branches. If I am to believe
> > cvsps (which took 3GB to walk the history), it has some branches with
> > recursive loops in their ancestry (MANG_MATH_BRANCH and
> > SpiderMonkey140_BRANCH have eachother as ancestors!?), 197969 commits
> > and 796 branches.
My full import to svn just finished after a day and a half.
Here are the stats:
cvs2svn Statistics:
------------------
Total CVS Files: 99851
Total CVS Revisions: 948580
Total Unique Tags: 1505
Total Unique Branches: 1577
CVS Repos Size in KB: 2725843
Total SVN Commits: 205787
First Revision Date: Fri Mar 27 21:13:08 1998
Last Revision Date: Tue May 30 19:28:10 2006
------------------
Timings:
------------------
pass 1: 3602 seconds
pass 2: 227 seconds
pass 3: 66 seconds
pass 4: 1070 seconds
pass 8:124650 seconds
total: 124650 seconds
[jonsmirl@jonsmirl ~]$
[jonsmirl@jonsmirl svn]$ du -h
4.0K ./svntest/dav
12K ./svntest/locks
40K ./svntest/hooks
16K ./svntest/conf
7.4G ./svntest/db/revs
808M ./svntest/db/revprops
4.0K ./svntest/db/transactions
8.2G ./svntest/db
8.2G ./svntest
8.2G .
[jonsmirl@jonsmirl svn]$ find | wc
411607 411607 10891057
There are two directories that each contain about 205k files. 205K
files in a single directory is causing svn problems on Ext3.
Bottom line, cvs2svn import tool works quite well. Highest memory
consumption I saw was 100MB and it used 6GB of extra disk while
running plus space need by svn.
I don't know quite enough about git yet to replace the svn commands it
uses with git equivalents but if that were done I think most of the
cvs import problems would be solved. Obviously the svn team has put a
great deal of work into this program.
I don't think replacing the svn commands is very hard, I just haven't
figured out the right way to build branches with low-level git yet and
I don't know Python. I'll bet someone already familiar with git and
cvs import could convert it in a couple of hours.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Integrity check
From: Dave Jones @ 2006-06-07 0:58 UTC (permalink / raw)
To: Kenneth Johansson; +Cc: git
In-Reply-To: <pan.2006.06.06.22.46.26.518589@canit.se>
On Wed, Jun 07, 2006 at 12:46:27AM +0200, Kenneth Johansson wrote:
> *** glibc detected *** malloc(): memory corruption: 0x0a703e80 ***
The last time I saw one of these in git, it turned out to be
due to a bug in glibc. If you're using Fedora/RHEL, there are
updates available that fix this problem.
Dave
--
http://www.codemonkey.org.uk
^ permalink raw reply
* Re: [PATCH/RFC] "git --less cmd" to page anywhere
From: Martin Langhoff @ 2006-06-07 2:29 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Petr Baudis, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0606061711000.5498@g5.osdl.org>
On 6/7/06, Linus Torvalds <torvalds@osdl.org> wrote:
> For "git diff", pagination by default is definitely not the right thing to
> do, but it's something you often end up wanting.
Why is it not a good default? Unless I expect it to be shorter than
the terminal, I always tack "| less" after it. Except when I tack ">
foo.patch" and then the auto-pager knows what to do anyway.
cheers,
martin
^ permalink raw reply
* Re: [PATCH/RFC] "git --less cmd" to page anywhere
From: Linus Torvalds @ 2006-06-07 3:21 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Petr Baudis, Junio C Hamano, git
In-Reply-To: <46a038f90606061929i68073677i686a3c1934ed64b1@mail.gmail.com>
On Wed, 7 Jun 2006, Martin Langhoff wrote:
>
> Why is it not a good default? Unless I expect it to be shorter than
> the terminal, I always tack "| less" after it. Except when I tack ">
> foo.patch" and then the auto-pager knows what to do anyway.
I often tack "| less" after it in some situations, but in other situations
I _never_ do.
I often use "git diff" as a way to see that my tree is clean. Sure, I
could do "git status", but if it's not clean, it's usually something
small, so I want to know what I changed last. At that point, a default
pager would be very annoying.
The "more" behaviour (which only paginates unto the end) might work for
me (ie the "git diff" auto-pager would act like "more" or "less -EX")
I dunno.
Linus
^ permalink raw reply
* [PATCH] Refactor git_tcp_connect() functions a little.
From: Jon Loeliger @ 2006-06-07 3:58 UTC (permalink / raw)
To: git
Add client side sending of "\0host=%s\0" extended
arg for git native protocol, backwards compatibly.
Signed-off-by: Jon Loeliger <jdl@jdl.com>
---
connect.c | 42 ++++++++++++++++++++++++++++++++----------
1 files changed, 32 insertions(+), 10 deletions(-)
I've tested this against an "old" daemon, and my new daemon
running on jdl.com that understands the new host=%s parameter.
Both appear to work still.
However, I don't have a setup to test a proxy connection,
and I left FIXME: down there asking the question if it is
even needed in this case as well. I _think_ so, but I am
just not sure. (It should be a straight pass-through to
another git: native protocol, right?)
And if it is needed there too, do you want to refactor
these two packet_writes() for commonality again?
diff --git a/connect.c b/connect.c
index 54f7bf7..3fa890d 100644
--- a/connect.c
+++ b/connect.c
@@ -322,7 +322,10 @@ #define STR(s) STR_(s)
#ifndef NO_IPV6
-static int git_tcp_connect(int fd[2], const char *prog, char *host, char *path)
+/*
+ * Returns a connected socket() fd, or else die()s.
+ */
+static int git_tcp_connect_sock(char *host)
{
int sockfd = -1;
char *colon, *end;
@@ -356,7 +359,8 @@ static int git_tcp_connect(int fd[2], co
die("Unable to look up %s (%s)", host, gai_strerror(gai));
for (ai0 = ai; ai; ai = ai->ai_next) {
- sockfd = socket(ai->ai_family, ai->ai_socktype, ai->ai_protocol);
+ sockfd = socket(ai->ai_family,
+ ai->ai_socktype, ai->ai_protocol);
if (sockfd < 0)
continue;
if (connect(sockfd, ai->ai_addr, ai->ai_addrlen) < 0) {
@@ -372,15 +376,15 @@ static int git_tcp_connect(int fd[2], co
if (sockfd < 0)
die("unable to connect a socket (%s)", strerror(errno));
- fd[0] = sockfd;
- fd[1] = sockfd;
- packet_write(sockfd, "%s %s\n", prog, path);
- return 0;
+ return sockfd;
}
#else /* NO_IPV6 */
-static int git_tcp_connect(int fd[2], const char *prog, char *host, char *path)
+/*
+ * Returns a connected socket() fd, or else die()s.
+ */
+static int git_tcp_connect_sock(char *host)
{
int sockfd = -1;
char *colon, *end;
@@ -407,7 +411,6 @@ static int git_tcp_connect(int fd[2], co
port = colon + 1;
}
-
he = gethostbyname(host);
if (!he)
die("Unable to look up %s (%s)", host, hstrerror(h_errno));
@@ -441,13 +444,29 @@ static int git_tcp_connect(int fd[2], co
if (sockfd < 0)
die("unable to connect a socket (%s)", strerror(errno));
+ return sockfd;
+}
+
+#endif /* NO_IPV6 */
+
+
+static int git_tcp_connect(int fd[2],
+ const char *prog, char *host, char *path)
+{
+ int sockfd = git_tcp_connect_sock(host);
+
fd[0] = sockfd;
fd[1] = sockfd;
- packet_write(sockfd, "%s %s\n", prog, path);
+
+ /*
+ * Separate original protocol components prog and path
+ * from extended components with a NUL byte.
+ */
+ packet_write(sockfd, "%s %s%chost=%s%c", prog, path, 0, host, 0);
+
return 0;
}
-#endif /* NO_IPV6 */
static char *git_proxy_command = NULL;
static const char *rhost_name = NULL;
@@ -551,7 +570,10 @@ static int git_proxy_connect(int fd[2],
fd[1] = pipefd[1][1];
close(pipefd[0][1]);
close(pipefd[1][0]);
+
+ /* FIXME: Does this need %chost=%s%c tacked on here too? */
packet_write(fd[1], "%s %s\n", prog, path);
+
return pid;
}
--
1.4.0.rc1.ga6a5-dirty
^ permalink raw reply related
* Re: [PATCH] Refactor git_tcp_connect() functions a little.
From: Junio C Hamano @ 2006-06-07 4:53 UTC (permalink / raw)
To: Jon Loeliger; +Cc: git
In-Reply-To: <E1FnpBp-00043u-Uc@jdl.com>
Jon Loeliger <jdl@jdl.com> writes:
> Add client side sending of "\0host=%s\0" extended
> arg for git native protocol, backwards compatibly.
>
> Signed-off-by: Jon Loeliger <jdl@jdl.com>
> ---
> connect.c | 42 ++++++++++++++++++++++++++++++++----------
> 1 files changed, 32 insertions(+), 10 deletions(-)
>
> I've tested this against an "old" daemon, and my new daemon
> running on jdl.com that understands the new host=%s parameter.
> Both appear to work still.
Thanks.
> However, I don't have a setup to test a proxy connection,
> and I left FIXME: down there asking the question if it is
> even needed in this case as well. I _think_ so, but I am
> just not sure. (It should be a straight pass-through to
> another git: native protocol, right?)
I think so.
> And if it is needed there too, do you want to refactor
> these two packet_writes() for commonality again?
Let me munge that part and push it out. I've tested it lightly
both with and without proxy. My proxy was a single liner shell
script:
nc -o /var/tmp/nc.log localhost 9418
whose dump started with this nice request packet:
> 00000000 30 30 35 62 67 69 74 2d 75 70 6c 6f 61 64 2d 70 # 005bgit-upload-p
> 00000010 61 63 6b 20 2f 6f 70 74 2f 70 61 63 6b 72 61 74 # ack /opt/packrat
> 00000020 2f 70 6c 61 79 70 65 6e 2f 70 75 62 6c 69 63 2f # /playpen/public/
> 00000030 69 6e 2d 70 6c 61 63 65 2f 67 69 74 2f 67 69 74 # in-place/git/git
> 00000040 2e 6a 75 6e 69 6f 00 68 6f 73 74 3d 6c 6f 63 61 # .junio.host=loca
> 00000050 6c 68 6f 73 74 3a 34 34 33 33 00 # lhost:4433.
for a request "peek-remote git://localhost:4433/opt/.../git.junio".
I suspect that a real git proxy, if somebody ever writes one,
would read the first outgoing packet reads the request
(including this host= stuff) and connect to the true destination
intelligently after sending out a modified request packet.
Takers?
^ permalink raw reply
* [PATCH] http-fetch: fix possible segfault
From: Nick Hengeveld @ 2006-06-07 5:22 UTC (permalink / raw)
To: git
Initialize an object request's slot to a safe value. A non-NULL value
can cause a segfault if the request is aborted before it starts.
Signed-off-by: Nick Hengeveld <nickh@reactrix.com>
---
http-fetch.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/http-fetch.c b/http-fetch.c
index 661c909..d3602b7 100644
--- a/http-fetch.c
+++ b/http-fetch.c
@@ -399,6 +399,7 @@ void prefetch(unsigned char *sha1)
snprintf(newreq->filename, sizeof(newreq->filename), "%s", filename);
snprintf(newreq->tmpfile, sizeof(newreq->tmpfile),
"%s.temp", filename);
+ newreq->slot = NULL;
newreq->next = NULL;
if (object_queue_head == NULL) {
--
1.4.0.rc1.gf75c7-dirty
^ permalink raw reply related
* http-fetch segfault fix?
From: Junio C Hamano @ 2006-06-07 5:35 UTC (permalink / raw)
To: Pavel Roskin; +Cc: git, Nick Hengeveld
In-Reply-To: <1149619097.25298.6.camel@dv>
Pavel Roskin <proski@gnu.org> writes:
> It's a different backtrace this time. abort_object_request() has this code:
>
> if (obj_req->slot) {
> release_active_slot(obj_req->slot);
> obj_req->slot = NULL;
> }
>
> Apparently just because obj_req->slot is not NULL doesn't mean it's a
> valid pointer. I'm going to use Valgrind now.
Nick's one-liner to explicitly initialize newreq->slot to NULL
looks obviously correct to me. Does it fix this problem for
you?
^ permalink raw reply
* Re: http-fetch segfault fix?
From: Pavel Roskin @ 2006-06-07 5:41 UTC (permalink / raw)
To: git; +Cc: Nick Hengeveld
In-Reply-To: <7vlks9le8b.fsf_-_@assigned-by-dhcp.cox.net>
On Tue, 2006-06-06 at 22:35 -0700, Junio C Hamano wrote:
> Pavel Roskin <proski@gnu.org> writes:
>
> > It's a different backtrace this time. abort_object_request() has this code:
> >
> > if (obj_req->slot) {
> > release_active_slot(obj_req->slot);
> > obj_req->slot = NULL;
> > }
> >
> > Apparently just because obj_req->slot is not NULL doesn't mean it's a
> > valid pointer. I'm going to use Valgrind now.
>
> Nick's one-liner to explicitly initialize newreq->slot to NULL
> looks obviously correct to me. Does it fix this problem for
> you?
I'm going to leave the tests running overnight, both with and without
USE_CURL_MULTI.
The Valgrind diagnostics confirms that obj_req->slot is not initialized
(as opposed to being a pointer to a freed area or something else):
==27182== Conditional jump or move depends on uninitialised value(s)
==27182== at 0x4070EA: abort_object_request (http-fetch.c:1059)
==27182== by 0x4071CE: fetch_object (http-fetch.c:1078)
==27182== by 0x4073EC: fetch (http-fetch.c:1126)
==27182== by 0x403125: loop (fetch.c:180)
==27182== by 0x403369: pull (fetch.c:248)
==27182== by 0x407A13: main (http-fetch.c:1271)
Line 1059 is:
if (obj_req->slot) {
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: http-fetch segfault fix?
From: Junio C Hamano @ 2006-06-07 5:58 UTC (permalink / raw)
To: Pavel Roskin; +Cc: git, Nick Hengeveld
In-Reply-To: <1149658914.5648.5.camel@dv>
Pavel Roskin <proski@gnu.org> writes:
> The Valgrind diagnostics confirms that obj_req->slot is not initialized
> (as opposed to being a pointer to a freed area or something else):
>
> ==27182== Conditional jump or move depends on uninitialised value(s)
> ==27182== at 0x4070EA: abort_object_request (http-fetch.c:1059)
> ==27182== by 0x4071CE: fetch_object (http-fetch.c:1078)
> ==27182== by 0x4073EC: fetch (http-fetch.c:1126)
> ==27182== by 0x403125: loop (fetch.c:180)
> ==27182== by 0x403369: pull (fetch.c:248)
> ==27182== by 0x407A13: main (http-fetch.c:1271)
>
> Line 1059 is:
> if (obj_req->slot) {
Thanks. That is indeed a very good sign.
^ permalink raw reply
* Re: [PATCH 0/27] Documentation: Spelling fixes
From: Andreas Ericsson @ 2006-06-07 8:53 UTC (permalink / raw)
To: Nikolai Weibull; +Cc: Junio C Hamano, Horst.H.von.Brand, git
In-Reply-To: <dbfc82860606050948t5c952f65m364a455e0e83ec8@mail.gmail.com>
Nikolai Weibull wrote:
> On 6/5/06, Andreas Ericsson <ae@op5.se> wrote:
>
>> Nikolai Weibull wrote:
>> > On 6/4/06, Junio C Hamano <junkio@cox.net> wrote:
>> >
>> >> Most do not seem to be typoes, depending on where you learned
>> >> the language (XYZour vs XYZor; ok, Ok, and OK; ie vs i.e.).
>> >
>> > Where do you write "ie" instead of "i.e."?
>> >
>>
>> Mailing lists, online conversations, tech docs written in code
>> editors...
>
>
> Do you mean that code editors usually don't let you enter a dot into
> the buffer, or what?
>
No, I mean that people are lazy when writing online and for an audience
that broadly share the same sort of text-digesting mind, so they don't
bother with the dots.
>> Compare with online'ish abbrevs (afaict, iirc, imo, fyi).
>
>
> That's hardly the same thing.
Why not? Both are examples of one-letter-per-word abbreviations.
> Most people would upcase AFAICT, IIRC,
> IMO, and FYI.
>
True, but both forms are common enough. I guess I'm one of the lazier
ones, since I regularly use lower-case.
> I wouldn't group "i.e." with such abbreviations in any case. (Hehe.)
>
I fail to see why not. I also fail to care very much, so feel free not
to respond. ;)
>
>> When each character of the abbrev defines one complete word dots are
>> just prettiness-noise, their presence or absence decided by the gravity
>> of the meaning ("R.I.P." vs "ie"). Obviously, correctness never hurts
>> but this is, on two accounts, punktknulleri.
>
>
> Considering that people don't want to get stuck on trying to
> understand what the word "ie" is supposed to mean in a manual page
> they're trying to understand what some command does (this happened to
> me), I really think that fucking with the dots is called for.
>
> Anyway, the general guidelines recommended by "The Chicago Manual of
> Style" are:
>
> Use periods with abbreviations that appear in lowercase letters; use
> no periods with abbreviations that appear in full capitals or small
> capitals, whether two letters or more.
>
> One possible solution is to expand "i.e." to "that is" (or something
> equally befitting) and "e.g." to "for example", "such as", or similar.
>
This is most likely the best solution as it's easier for foreign readers
with limited proficiency in reading english and english abbreviations
borrowed from latin, as they don't make sense if you try to put in
english words matching the abbreviation, dots or no dots. This gave me
quite a headache when I was twelve and tried to install Linux for the
first time :)
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Importing Mozilla CVS into git
From: Igor Bukanov @ 2006-06-07 9:02 UTC (permalink / raw)
To: Jon Smirl; +Cc: Pavel Roskin, Shawn Pearce, Keith Packard, git
In-Reply-To: <9e4733910606012144p5f4fda26sdc2de2cc77b71fe7@mail.gmail.com>
On 6/2/06, Jon Smirl <jonsmirl@gmail.com> wrote:
> On 6/2/06, Pavel Roskin <proski@gnu.org> wrote:
> > Dependency on Cygwin, Perl and Python is too much. Windows is becoming
> > a legacy system in some circles, and it may run on legacy hardware. Yet
> > it's irreplaceable as a testing platform for many projects.
>
> 80% of Mozilla commiters are running Windows. Some are OS bilingual
> but many are not.
Mozilla build system on Windows requires Cygwin and there are 198 Perl
files in Firefox tree. So it is only Python that can be problematic.
Regards, Igor
^ permalink raw reply
* [PATCH] Some doc typo fixes
From: Francis Daly @ 2006-06-07 12:56 UTC (permalink / raw)
To: git
All should be clear enough, except perhaps committish / commitish.
I just kept the more-used one within the current docs.
Signed-off-by: Francis Daly <francis@daoine.org>
---
271f459c2fec6898d913bbc040a71be067e0d009
Documentation/config.txt | 6 +++---
Documentation/cvs-migration.txt | 2 +-
Documentation/everyday.txt | 2 +-
Documentation/git-check-ref-format.txt | 2 +-
Documentation/git-describe.txt | 2 +-
Documentation/git-name-rev.txt | 2 +-
Documentation/git-p4import.txt | 2 +-
Documentation/git-read-tree.txt | 2 +-
Documentation/hooks.txt | 2 +-
Documentation/tutorial.txt | 2 +-
10 files changed, 12 insertions(+), 12 deletions(-)
271f459c2fec6898d913bbc040a71be067e0d009
diff --git a/Documentation/config.txt b/Documentation/config.txt
index c861c6c..4ce7867 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -113,12 +113,12 @@ gitcvs.logfile::
http.sslVerify::
Whether to verify the SSL certificate when fetching or pushing
- over HTTPS. Can be overriden by the 'GIT_SSL_NO_VERIFY' environment
+ over HTTPS. Can be overridden by the 'GIT_SSL_NO_VERIFY' environment
variable.
http.sslCert::
File containing the SSL certificate when fetching or pushing
- over HTTPS. Can be overriden by the 'GIT_SSL_CERT' environment
+ over HTTPS. Can be overridden by the 'GIT_SSL_CERT' environment
variable.
http.sslKey::
@@ -133,7 +133,7 @@ http.sslCAInfo::
http.sslCAPath::
Path containing files with the CA certificates to verify the peer
- with when fetching or pushing over HTTPS. Can be overriden
+ with when fetching or pushing over HTTPS. Can be overridden
by the 'GIT_SSL_CAPATH' environment variable.
http.maxRequests::
diff --git a/Documentation/cvs-migration.txt b/Documentation/cvs-migration.txt
index 826d089..1fbca83 100644
--- a/Documentation/cvs-migration.txt
+++ b/Documentation/cvs-migration.txt
@@ -106,7 +106,7 @@ Make sure committers have a umask of at
they create are writable and searchable by other group members.
Suppose this repository is now set up in /pub/repo.git on the host
-foo.com. Then as an individual commiter you can clone the shared
+foo.com. Then as an individual committer you can clone the shared
repository:
------------------------------------------------
diff --git a/Documentation/everyday.txt b/Documentation/everyday.txt
index 6745ab5..b935c18 100644
--- a/Documentation/everyday.txt
+++ b/Documentation/everyday.txt
@@ -45,7 +45,7 @@ Everybody uses these commands to feed an
* gitlink:git-fsck-objects[1] to validate the repository.
- * gitlink:git-prune[1] to garbage collect crufts in the
+ * gitlink:git-prune[1] to garbage collect cruft in the
repository.
* gitlink:git-repack[1] to pack loose objects for efficiency.
diff --git a/Documentation/git-check-ref-format.txt b/Documentation/git-check-ref-format.txt
index 3ea720d..cb9c162 100644
--- a/Documentation/git-check-ref-format.txt
+++ b/Documentation/git-check-ref-format.txt
@@ -20,7 +20,7 @@ a tag is stored under `$GIT_DIR/refs/tag
imposes the following rules on how refs are named:
. It could be named hierarchically (i.e. separated with slash
- `/`), but each of its component cannot begin with a dot `.`;
+ `/`), but each of its components cannot begin with a dot `.`;
. It cannot have two consecutive dots `..` anywhere;
diff --git a/Documentation/git-describe.txt b/Documentation/git-describe.txt
index 7a253ea..7cc14b7 100644
--- a/Documentation/git-describe.txt
+++ b/Documentation/git-describe.txt
@@ -21,7 +21,7 @@ object name of the commit.
OPTIONS
-------
<committish>::
- The object name of the comittish.
+ The object name of the committish.
--all::
Instead of using only the annotated tags, use any ref
diff --git a/Documentation/git-name-rev.txt b/Documentation/git-name-rev.txt
index ffaa004..39a1434 100644
--- a/Documentation/git-name-rev.txt
+++ b/Documentation/git-name-rev.txt
@@ -8,7 +8,7 @@ git-name-rev - Find symbolic names for g
SYNOPSIS
--------
-'git-name-rev' [--tags] ( --all | --stdin | <commitish>... )
+'git-name-rev' [--tags] ( --all | --stdin | <committish>... )
DESCRIPTION
-----------
diff --git a/Documentation/git-p4import.txt b/Documentation/git-p4import.txt
index b8ff1e9..c198ff2 100644
--- a/Documentation/git-p4import.txt
+++ b/Documentation/git-p4import.txt
@@ -128,7 +128,7 @@ Therefore after the import you can use g
Perforce number, eg. git show p4/327.
The tag associated with the HEAD commit is also how `git-p4import`
-determines if their are new changes to incrementally import from the
+determines if there are new changes to incrementally import from the
Perforce repository.
If you import from a repository with many thousands of changes
diff --git a/Documentation/git-read-tree.txt b/Documentation/git-read-tree.txt
index 02c7e99..d894f53 100644
--- a/Documentation/git-read-tree.txt
+++ b/Documentation/git-read-tree.txt
@@ -257,7 +257,7 @@ file that does not match stage 2.
This is done to prevent you from losing your work-in-progress
changes, and mixing your random changes in an unrelated merge
commit. To illustrate, suppose you start from what has been
-commited last to your repository:
+committed last to your repository:
----------------
$ JC=`git-rev-parse --verify "HEAD^0"`
diff --git a/Documentation/hooks.txt b/Documentation/hooks.txt
index e3dde39..898b4aa 100644
--- a/Documentation/hooks.txt
+++ b/Documentation/hooks.txt
@@ -100,7 +100,7 @@ update
This hook is invoked by `git-receive-pack` on the remote repository,
which is happens when a `git push` is done on a local repository.
Just before updating the ref on the remote repository, the update hook
-is invoked. It's exit status determines the success or failure of
+is invoked. Its exit status determines the success or failure of
the ref update.
The hook executes once for each ref to be updated, and takes
diff --git a/Documentation/tutorial.txt b/Documentation/tutorial.txt
index db56312..554ee0a 100644
--- a/Documentation/tutorial.txt
+++ b/Documentation/tutorial.txt
@@ -357,7 +357,7 @@ names. For example:
$ git branch stable v2.5 # start a new branch named "stable" based
# at v2.5
$ git reset --hard HEAD^ # reset your current branch and working
- # directory its state at HEAD^
+ # directory to its state at HEAD^
-------------------------------------
Be careful with that last command: in addition to losing any changes
--
1.3.3.g63df-dirty
--
Francis Daly francis@daoine.org
^ permalink raw reply related
* Re: http-fetch segfault fix?
From: Pavel Roskin @ 2006-06-07 14:29 UTC (permalink / raw)
To: git; +Cc: Nick Hengeveld
In-Reply-To: <7vhd2xld77.fsf@assigned-by-dhcp.cox.net>
On Tue, 2006-06-06 at 22:58 -0700, Junio C Hamano wrote:
> Pavel Roskin <proski@gnu.org> writes:
>
> > The Valgrind diagnostics confirms that obj_req->slot is not initialized
> > (as opposed to being a pointer to a freed area or something else):
> >
> > ==27182== Conditional jump or move depends on uninitialised value(s)
> > ==27182== at 0x4070EA: abort_object_request (http-fetch.c:1059)
> > ==27182== by 0x4071CE: fetch_object (http-fetch.c:1078)
> > ==27182== by 0x4073EC: fetch (http-fetch.c:1126)
> > ==27182== by 0x403125: loop (fetch.c:180)
> > ==27182== by 0x403369: pull (fetch.c:248)
> > ==27182== by 0x407A13: main (http-fetch.c:1271)
> >
> > Line 1059 is:
> > if (obj_req->slot) {
>
> Thanks. That is indeed a very good sign.
Both git-clone instances (with and without USE_CURL_MULTI) have
completed successfully on http://www.denx.de/git/linux-2.6-denx.git
Nick, thank you for fixing this bug!
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: Importing Mozilla CVS into git
From: Pavel Roskin @ 2006-06-07 15:21 UTC (permalink / raw)
To: Igor Bukanov; +Cc: Jon Smirl, Shawn Pearce, Keith Packard, git
In-Reply-To: <df0b33100606070202w581ff581i435056f0fbc197f8@mail.gmail.com>
On Wed, 2006-06-07 at 11:02 +0200, Igor Bukanov wrote:
> On 6/2/06, Jon Smirl <jonsmirl@gmail.com> wrote:
> > On 6/2/06, Pavel Roskin <proski@gnu.org> wrote:
> > > Dependency on Cygwin, Perl and Python is too much. Windows is becoming
> > > a legacy system in some circles, and it may run on legacy hardware. Yet
> > > it's irreplaceable as a testing platform for many projects.
> >
> > 80% of Mozilla commiters are running Windows. Some are OS bilingual
> > but many are not.
>
> Mozilla build system on Windows requires Cygwin and there are 198 Perl
> files in Firefox tree. So it is only Python that can be problematic.
Then maybe the existing 3 python files in git (I'm not counting
compat/subprocess.py) could be converted to Perl? Perl would be great
as the "common denominator" for interpreted languages.
Search for "python to perl" translator lead me to Perthon:
http://perthon.sourceforge.net/
But Perthon needs work. My attempt to run it on git-p4import.py failed:
$ perl -I `pwd`/lib perthon.pl git-p4import.py
Can't coerce array into hash at lib/Perthon/PerthonImpl.pm line 15420.
It may be a fun project for somebody who wants to learn Perl and Python.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: Importing Mozilla CVS into git
From: Jon Smirl @ 2006-06-07 15:30 UTC (permalink / raw)
To: Igor Bukanov; +Cc: Pavel Roskin, Shawn Pearce, Keith Packard, git
In-Reply-To: <df0b33100606070202w581ff581i435056f0fbc197f8@mail.gmail.com>
On 6/7/06, Igor Bukanov <igor.bukanov@gmail.com> wrote:
> On 6/2/06, Jon Smirl <jonsmirl@gmail.com> wrote:
> > On 6/2/06, Pavel Roskin <proski@gnu.org> wrote:
> > > Dependency on Cygwin, Perl and Python is too much. Windows is becoming
> > > a legacy system in some circles, and it may run on legacy hardware. Yet
> > > it's irreplaceable as a testing platform for many projects.
> >
> > 80% of Mozilla commiters are running Windows. Some are OS bilingual
> > but many are not.
>
> Mozilla build system on Windows requires Cygwin and there are 198 Perl
> files in Firefox tree. So it is only Python that can be problematic.
Other people have sent me mail saying this may not be as big as
problem as was thought, only documentation people on WIndows may be an
issues.
>
> Regards, Igor
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: http-fetch segfault fix?
From: Nick Hengeveld @ 2006-06-07 15:32 UTC (permalink / raw)
To: Pavel Roskin; +Cc: git
In-Reply-To: <1149690584.19551.2.camel@dv>
On Wed, Jun 07, 2006 at 10:29:44AM -0400, Pavel Roskin wrote:
> Both git-clone instances (with and without USE_CURL_MULTI) have
> completed successfully on http://www.denx.de/git/linux-2.6-denx.git
>
> Nick, thank you for fixing this bug!
Whew... I look forward to working on something other than fixing
segfaults.
--
For a successful technology, reality must take precedence over public
relations, for nature cannot be fooled.
^ permalink raw reply
* Re: Importing Mozilla CVS into git
From: Jakub Narebski @ 2006-06-07 15:58 UTC (permalink / raw)
To: git
In-Reply-To: <9e4733910606070830g24a08771i1a332552a95283d1@mail.gmail.com>
Jon Smirl wrote:
> On 6/7/06, Igor Bukanov <igor.bukanov@gmail.com> wrote:
>> On 6/2/06, Jon Smirl <jonsmirl@gmail.com> wrote:
>>> On 6/2/06, Pavel Roskin <proski@gnu.org> wrote:
>>>> Dependency on Cygwin, Perl and Python is too much. Windows is becoming
>>>> a legacy system in some circles, and it may run on legacy hardware. Yet
>>>> it's irreplaceable as a testing platform for many projects.
>>>
>>> 80% of Mozilla commiters are running Windows. Some are OS bilingual
>>> but many are not.
>>
>> Mozilla build system on Windows requires Cygwin and there are 198 Perl
>> files in Firefox tree. So it is only Python that can be problematic.
>
> Other people have sent me mail saying this may not be as big as
> problem as was thought, only documentation people on WIndows may be an
> issues.
With 1.4.0 there should be tar files of documentation. For now, one can use
html and man branches of git.git repository: see the INSTALL file and/or
http://git.or.cz/gitwiki/GitDocumentation
--
Jakub Narebski
Warsaw, Poland
^ 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