* 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
* Re: Importing Mozilla CVS into git
From: Linus Torvalds @ 2006-06-07 16:17 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e66t2v$6hb$1@sea.gmane.org>
On Wed, 7 Jun 2006, Jakub Narebski wrote:
> > 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
I think you misunderstood.
My guess is that it's the _mozilla_ documentation people that don't
necessarily have cygwin and perl, because they don't work with the normal
build.
Ie there are people who can write user documentation, without them having
any clue - or caring about - build systems.
Linus
^ permalink raw reply
* Re: [PATCH] Some doc typo fixes
From: Junio C Hamano @ 2006-06-07 16:48 UTC (permalink / raw)
To: Francis Daly; +Cc: git
In-Reply-To: <20060607125644.GT29682@craic.sysops.org>
Francis Daly <francis@daoine.org> writes:
> All should be clear enough, except perhaps committish / commitish.
> I just kept the more-used one within the current docs.
Thanks. I am not a native, and this is very much appreciated.
> . 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 `.`;
I am not sure; shouldn't the wording be "each of <plural>" to mean
"there are/can be more than one, and you look at them one by one
and make sure the condition holds for each of them" (oops,
that's cyclic explanation and I failed to paraphrase it without
using "each of")???
All the others look good. Thanks.
^ permalink raw reply
* [PATCH] Off-by-one error in get_path_prefix(), found by Valgrind
From: Pavel Roskin @ 2006-06-07 17:01 UTC (permalink / raw)
To: git
From: Pavel Roskin <proski@gnu.org>
Signed-off-by: Pavel Roskin <proski@gnu.org>
---
builtin-tar-tree.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/builtin-tar-tree.c b/builtin-tar-tree.c
index 5f740cf..05da1f2 100644
--- a/builtin-tar-tree.c
+++ b/builtin-tar-tree.c
@@ -166,8 +166,8 @@ static unsigned int ustar_header_chksum(
static int get_path_prefix(const struct strbuf *path, int maxlen)
{
int i = path->len;
- if (i > maxlen)
- i = maxlen;
+ if (i >= maxlen)
+ i = maxlen - 1;
while (i > 0 && path->buf[i] != '/')
i--;
return i;
^ permalink raw reply related
* Re: [PATCH] Some doc typo fixes
From: Junio C Hamano @ 2006-06-07 17:07 UTC (permalink / raw)
To: Francis Daly; +Cc: git
In-Reply-To: <7v1wu0lxnd.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Francis Daly <francis@daoine.org> writes:
>
>> All should be clear enough, except perhaps committish / commitish.
>> I just kept the more-used one within the current docs.
>
> Thanks. I am not a native, and this is very much appreciated.
>
>> . 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 `.`;
>
> I am not sure; ...
Sheesh, I was reading the diff backwards. Sorry.
> All the others look good. Thanks.
All of them look obviously correct, it wasn't just obvious to me
without enough caffeine.
Sorry for the noise.
^ permalink raw reply
* Re: [PATCH] Some doc typo fixes
From: Francis Daly @ 2006-06-07 17:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwtbshp3d.fsf@assigned-by-dhcp.cox.net>
On Wed, Jun 07, 2006 at 10:07:02AM -0700, Junio C Hamano wrote:
> Junio C Hamano <junkio@cox.net> writes:
> > Francis Daly <francis@daoine.org> writes:
> > Thanks. I am not a native, and this is very much appreciated.
You're welcome.
> >> . 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 `.`;
> >
> > I am not sure; ...
>
> Sheesh, I was reading the diff backwards. Sorry.
No worries. I had a head-scratching moment, and suspect that the whole
stanza could be better phrased. If only there was someone who didn't
already know what it means, they could suggest which phrasing makes
it clear...
How about rewriting it as
It can include slash `/` for hierarchical (directory) grouping, but no
slash-separated component can begin with a dot `.`;
?
"can" instead of "could" fits the later parts, and it removes the
possessive and reverses the negative for something that (to my mind)
scans better.
Cheers,
f
--
Francis Daly francis@daoine.org
^ permalink raw reply
* Re: [PATCH] Off-by-one error in get_path_prefix(), found by Valgrind
From: Rene Scharfe @ 2006-06-07 18:05 UTC (permalink / raw)
To: Pavel Roskin, Junio C Hamano; +Cc: git
In-Reply-To: <20060607170140.13372.64613.stgit@dv.roinet.com>
On Wed, Jun 07, 2006 at 01:01:40PM -0400, Pavel Roskin wrote:
> From: Pavel Roskin <proski@gnu.org>
>
> Signed-off-by: Pavel Roskin <proski@gnu.org>
> ---
>
> builtin-tar-tree.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/builtin-tar-tree.c b/builtin-tar-tree.c
> index 5f740cf..05da1f2 100644
> --- a/builtin-tar-tree.c
> +++ b/builtin-tar-tree.c
> @@ -166,8 +166,8 @@ static unsigned int ustar_header_chksum(
> static int get_path_prefix(const struct strbuf *path, int maxlen)
> {
> int i = path->len;
> - if (i > maxlen)
> - i = maxlen;
> + if (i >= maxlen)
> + i = maxlen - 1;
> while (i > 0 && path->buf[i] != '/')
> i--;
> return i;
Argh, yes. Thanks, Pavel! However, the other branch is incorrect, too:
accessing path->buf[path->len] is wrong, even if it's within the buffer.
In order to use a length variable to point to the end of some string we
need to subtract 1. *sigh* So, how about this one instead?
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
diff --git a/builtin-tar-tree.c b/builtin-tar-tree.c
index 5f740cf..7663b9b 100644
--- a/builtin-tar-tree.c
+++ b/builtin-tar-tree.c
@@ -168,8 +168,9 @@ static int get_path_prefix(const struct
int i = path->len;
if (i > maxlen)
i = maxlen;
- while (i > 0 && path->buf[i] != '/')
+ do {
i--;
+ } while (i > 0 && path->buf[i] != '/');
return i;
}
^ permalink raw reply related
* Re: Importing Mozilla CVS into git
From: Martin Langhoff @ 2006-06-07 18:29 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Jakub Narebski, git
In-Reply-To: <Pine.LNX.4.64.0606070915220.5498@g5.osdl.org>
On 6/8/06, Linus Torvalds <torvalds@osdl.org> wrote:
> My guess is that it's the _mozilla_ documentation people that don't
> necessarily have cygwin and perl, because they don't work with the normal
> build.
>
> Ie there are people who can write user documentation, without them having
> any clue - or caring about - build systems.
Which means that git-cvsserver can probably help them -- I don't think
documentation people (and translators, graphic artists, etc) need all
the git smarts. A simplistic TortoiseCVS + git-cvsserver should fit
their usage...
cheers,
martin
^ permalink raw reply
* [PATCH] Misc doc improvements
From: Jonas Fonseca @ 2006-06-07 18:32 UTC (permalink / raw)
To: Junio C Hamano, git
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
---
Documentation/git-apply.txt | 2 +-
Documentation/git-shortlog.txt | 19 ++++++++++++++++---
Documentation/glossary.txt | 7 +++++++
3 files changed, 24 insertions(+), 4 deletions(-)
diff --git a/Documentation/git-apply.txt b/Documentation/git-apply.txt
index 9cc7c74..2ff7494 100644
--- a/Documentation/git-apply.txt
+++ b/Documentation/git-apply.txt
@@ -76,7 +76,7 @@ OPTIONS
-C<n>::
Ensure at least <n> lines of surrounding context match before
and after each change. When fewer lines of surrounding
- context exist they all most match. By default no context is
+ context exist they all must match. By default no context is
ever ignored.
--apply::
diff --git a/Documentation/git-shortlog.txt b/Documentation/git-shortlog.txt
index 54fb922..0dbd3b2 100644
--- a/Documentation/git-shortlog.txt
+++ b/Documentation/git-shortlog.txt
@@ -5,7 +5,6 @@ NAME
----
git-shortlog - Summarize 'git log' output
-
SYNOPSIS
--------
git-log --pretty=short | 'git-shortlog'
@@ -13,8 +12,22 @@ git-log --pretty=short | 'git-shortlog'
DESCRIPTION
-----------
Summarizes 'git log' output in a format suitable for inclusion
-in release announcements.
-
+in release announcements. Each commit will be grouped by author
+the first line of the commit message will be shown.
+
+Additionally, "[PATCH]" will be stripped from the commit description.
+
+FILES
+-----
+'.mailcap'::
+ If this file exists, it will be used for mapping author email
+ addresses to a real author name. One mapping per line, first
+ the author name followed by the email address enclosed by
+ '<' and '>'. Use hash '#' for comments. Example:
+
+ # Keep alphabetized
+ Adam Morrow <adam@localhost.localdomain>
+ Eve Jones <eve@laptop.(none)>
Author
------
diff --git a/Documentation/glossary.txt b/Documentation/glossary.txt
index 39c90ad..879c708 100644
--- a/Documentation/glossary.txt
+++ b/Documentation/glossary.txt
@@ -109,6 +109,13 @@ file system::
git archive::
Synonym for repository (for arch people).
+grafts::
+ Grafts enables two otherwise different lines of development to be
+ joined together by recording fake ancestry information for commits.
+ This way you can make git pretend the set of parents a commit
+ has is different from what was recorded when the commit was created.
+ Configured via the `.git/info/grafts` file.
+
hash::
In git's context, synonym to object name.
--
1.4.0.rc1.gfd4c-dirty
--
Jonas Fonseca
^ permalink raw reply related
* Re: [PATCH] Off-by-one error in get_path_prefix(), found by Valgrind
From: Pavel Roskin @ 2006-06-07 18:33 UTC (permalink / raw)
To: Rene Scharfe; +Cc: git
In-Reply-To: <20060607180543.GA26638@lsrfire.ath.cx>
On Wed, 2006-06-07 at 20:05 +0200, Rene Scharfe wrote:
> Argh, yes. Thanks, Pavel!
Actually, thanks to Julian Seward for Valgrind.
> However, the other branch is incorrect, too:
> accessing path->buf[path->len] is wrong, even if it's within the buffer.
> In order to use a length variable to point to the end of some string we
> need to subtract 1. *sigh* So, how about this one instead?
Fine with me. Thank you for noticing!
--
Regards,
Pavel Roskin
^ permalink raw reply
* [PATCH] Document git aliases support
From: Petr Baudis @ 2006-06-07 18:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
This patch ports and modifies appropriately the git aliases documentation
from my patch, shall it rest in peace.
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
Documentation/config.txt | 7 +++++++
Documentation/git.txt | 3 +++
2 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index c861c6c..ad9ec3e 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -91,6 +91,13 @@ 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 cannot
+ override even existing command names with aliases. Arguments are
+ split by spaces, the usual shell quoting and escaping is supported.
+
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::
^ permalink raw reply related
* [PATCH] Document git aliases support
From: Petr Baudis @ 2006-06-07 18:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
This patch ports and modifies appropriately the git aliases documentation
from my patch, shall it rest in peace.
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
Documentation/config.txt | 7 +++++++
Documentation/git.txt | 3 +++
2 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index c861c6c..ad9ec3e 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -91,6 +91,13 @@ 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 cannot
+ override even existing command names with aliases. Arguments are
+ split by spaces, the usual shell quoting and escaping is supported.
+
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::
^ permalink raw reply related
* Re: [PATCH] Misc doc improvements
From: Jakub Narebski @ 2006-06-07 18:46 UTC (permalink / raw)
To: git
In-Reply-To: <20060607183233.GA21448@diku.dk>
Jonas Fonseca wrote:
> +grafts::
> + Grafts enables two otherwise different lines of development to be
> + joined together by recording fake ancestry information for commits.
> + This way you can make git pretend the set of parents a commit
> + has is different from what was recorded when the commit was created.
> + Configured via the `.git/info/grafts` file.
Actually, grafts are used to "fake" (or change) parents (ancestry) of an
existing commit. It can be used both to add parents (e.g. joining roots of
"current" repository with historical one), or remove parents (e.g. to
shorten (cauterize) history like in the "shalllow clone" idea).
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* Re: [PATCH] Off-by-one error in get_path_prefix(), found by Valgrind
From: Junio C Hamano @ 2006-06-07 18:47 UTC (permalink / raw)
To: Pavel Roskin, Rene Scharfe; +Cc: git
In-Reply-To: <1149705204.11931.3.camel@dv>
Pavel Roskin <proski@gnu.org> writes:
> On Wed, 2006-06-07 at 20:05 +0200, Rene Scharfe wrote:
>> Argh, yes. Thanks, Pavel!
>
> Actually, thanks to Julian Seward for Valgrind.
>
>> However, the other branch is incorrect, too:
>> accessing path->buf[path->len] is wrong, even if it's within the buffer.
>> In order to use a length variable to point to the end of some string we
>> need to subtract 1. *sigh* So, how about this one instead?
>
> Fine with me. Thank you for noticing!
Thanks both. Applied.
^ permalink raw reply
* Re: [PATCH] Document git aliases support
From: Junio C Hamano @ 2006-06-07 18:58 UTC (permalink / raw)
To: git
In-Reply-To: <20060607184350.31338.46653.stgit@machine.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> Documentation/config.txt | 7 +++++++
> Documentation/git.txt | 3 +++
> 2 files changed, 10 insertions(+), 0 deletions(-)
Thanks.
> diff --git a/Documentation/config.txt b/Documentation/config.txt
> index c861c6c..ad9ec3e 100644
> --- a/Documentation/config.txt
> +++ b/Documentation/config.txt
> @@ -91,6 +91,13 @@ 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 cannot
> + override even existing command names with aliases. Arguments are
> + split by spaces, the usual shell quoting and escaping is supported.
> +
"even"? How about: "alias that hides existing command names are
not used to avoid confusion"?
^ permalink raw reply
* Re: [PATCH] Misc doc improvements
From: Francis Daly @ 2006-06-07 18:59 UTC (permalink / raw)
To: git
Jonas Fonseca wrote:
> +FILES
> +-----
> +'.mailcap'::
s/cap/map/
.mailcap is for something else.
f
--
Francis Daly francis@daoine.org
^ permalink raw reply
* [PATCH] Document git-ls-tree --fullname
From: Jonas Fonseca @ 2006-06-07 19:46 UTC (permalink / raw)
To: Junio C Hamano, git
Additionally, reformat synopsis and remove stub notice.
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
---
diff --git a/Documentation/git-ls-tree.txt b/Documentation/git-ls-tree.txt
index 018c401..7e072b5 100644
--- a/Documentation/git-ls-tree.txt
+++ b/Documentation/git-ls-tree.txt
@@ -8,9 +8,10 @@ git-ls-tree - Lists the contents of a tr
SYNOPSIS
--------
+[verse]
'git-ls-tree' [-d] [-r] [-t] [-z]
- [--name-only] [--name-status] [--full-name] [--abbrev=[<n>]]
- <tree-ish> [paths...]
+ [--name-only] [--name-status] [--full-name] [--abbrev=[<n>]]
+ <tree-ish> [paths...]
DESCRIPTION
-----------
@@ -47,6 +48,10 @@ OPTIONS
lines, show only handful hexdigits prefix.
Non default number of digits can be specified with --abbrev=<n>.
+--full-name::
+ Instead of showing the path names relative the current working
+ directory, show the full path names.
+
paths::
When paths are given, show them (note that this isn't really raw
pathnames, but rather a list of patterns to match). Otherwise
@@ -72,8 +77,6 @@ Documentation
Documentation by David Greaves, Junio C Hamano and the git-list
<git@vger.kernel.org>.
-This manual page is a stub. You can help the git documentation by expanding it.
-
GIT
---
Part of the gitlink:git[7] suite
--
Jonas Fonseca
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox