* Re: [PATCH v2] Detailed diagnosis when parsing an object name fails.
From: Junio C Hamano @ 2009-12-03 20:37 UTC (permalink / raw)
To: y; +Cc: git, Matthieu Moy
In-Reply-To: <1259784061-25143-1-git-send-email-y>
y@imag.fr writes:
> diff --git a/cache.h b/cache.h
> index 0e69384..5c8cb5f 100644
> --- a/cache.h
> +++ b/cache.h
> @@ -708,7 +708,11 @@ static inline unsigned int hexval(unsigned char c)
> #define DEFAULT_ABBREV 7
>
> extern int get_sha1(const char *str, unsigned char *sha1);
> -extern int get_sha1_with_mode(const char *str, unsigned char *sha1, unsigned *mode);
> +static inline get_sha1_with_mode(const char *str, unsigned char *sha1, unsigned *mode)
> +{
> + return get_sha1_with_mode_1(str, sha1, mode, 0, NULL);
> +}
> +extern int get_sha1_with_mode_1(const char *str, unsigned char *sha1, unsigned *mode, int fatal, const char *prefix);
Do I understand correctly that "fatal" here is the same as "!gently"
elsewhere in the API?
> diff --git a/sha1_name.c b/sha1_name.c
> index 44bb62d..030e2ac 100644
> --- a/sha1_name.c
> +++ b/sha1_name.c
> @@ -804,7 +804,77 @@ int get_sha1(const char *name, unsigned char *sha1)
> return get_sha1_with_mode(name, sha1, &unused);
> }
>
> -int get_sha1_with_mode(const char *name, unsigned char *sha1, unsigned *mode)
> +static void diagnose_invalid_sha1_path(const char *prefix,
> + const char *filename,
> + const char *tree_sha1,
> + const char *object_name)
> +{
> + struct stat st;
> + unsigned char sha1[20];
> + unsigned mode;
> +
> + if (!prefix)
> + prefix = "";
> +
> + if (!lstat(filename, &st))
> + die("Path '%s' exists on disk, but not in '%s'.",
> + filename, object_name);
> + if (errno == ENOENT || errno == ENOTDIR) {
> + char *fullname = malloc(strlen(filename)
> + + strlen(prefix) + 1);
> + strcpy(fullname, prefix);
> + strcat(fullname, filename);
What if malloc fails here (and elsewhere in your patch)?
> + if (!get_tree_entry(tree_sha1, fullname,
> + sha1, &mode)) {
> + die("Path '%s' exists, but not '%s'.\n"
> + "Did you mean '%s:%s'?",
> + fullname,
> + filename,
> + object_name,
> + fullname);
> + }
> + die("Path '%s' does not exist in '%s'",
> + filename, object_name);
> + }
> +}
> +
> +static void diagnose_invalid_index_path(int stage,
> + const char *prefix,
> + const char *filename)
> +{
> + struct stat st;
> +
> + if (!prefix)
> + prefix = "";
> +
> + if (!lstat(filename, &st))
> + die("Path '%s' exists on disk, but not in the index.", filename);
> + if (errno == ENOENT || errno == ENOTDIR) {
> + struct cache_entry *ce;
> + int pos;
> + int namelen = strlen(filename) + strlen(prefix);
> + char *fullname = malloc(namelen + 1);
> + strcpy(fullname, prefix);
> + strcat(fullname, filename);
> + pos = cache_name_pos(fullname, namelen);
> + if (pos < 0)
> + pos = -pos - 1;
> + ce = active_cache[pos];
> + if (ce_namelen(ce) == namelen &&
> + !memcmp(ce->name, fullname, namelen))
> + die("Path '%s' is in the index, but not '%s'.\n"
> + "Did you mean ':%d:%s'?",
> + fullname, filename,
> + stage, fullname);
What happens if the user asked for ":2:Makefile" while in directory "t/",
and there is ":1:t/Makefile" but not ":2:t/Makefile" in the index?
What should happen if the user asked for ":2:t/Makefile" in such a case?
> @@ -850,6 +920,8 @@ int get_sha1_with_mode(const char *name, unsigned char *sha1, unsigned *mode)
> }
> pos++;
> }
> + if (fatal)
> + diagnose_invalid_index_path(stage, prefix, cp);
> return -1;
> }
> for (cp = name, bracket_depth = 0; *cp; cp++) {
> @@ -862,9 +934,24 @@ int get_sha1_with_mode(const char *name, unsigned char *sha1, unsigned *mode)
> }
> if (*cp == ':') {
> unsigned char tree_sha1[20];
> - if (!get_sha1_1(name, cp-name, tree_sha1))
> - return get_tree_entry(tree_sha1, cp+1, sha1,
> - mode);
> + char *object_name;
> + if (fatal) {
> + object_name = malloc(cp-name+1);
Where is this freed?
Instead of doing a leaky allocation, it may make sense to pass the tree
object name as <const char *, size_t> pair, and print it with "%.*s" in
the error reporting codepath. After all, object_name is used only for
that purpose in diagnose_invalid_sha1_path(), no?
> + strncpy(object_name, name, cp-name);
> + object_name[cp-name] = '\0';
> + }
> + if (!get_sha1_1(name, cp-name, tree_sha1)) {
> + const char *filename = cp+1;
> + ret = get_tree_entry(tree_sha1, filename, sha1, mode);
> + if (fatal)
> + diagnose_invalid_sha1_path(prefix, filename,
> + tree_sha1, object_name);
> +
> + return ret;
> + } else {
> + if (fatal)
> + die("Invalid object name '%s'.", object_name);
> + }
> }
> return ret;
> }
> diff --git a/t/t1506-rev-parse-diagnosis.sh b/t/t1506-rev-parse-diagnosis.sh
> new file mode 100755
> index 0000000..8112d56
> --- /dev/null
> +++ b/t/t1506-rev-parse-diagnosis.sh
> @@ -0,0 +1,67 @@
> +#!/bin/sh
> +
> +test_description='test git rev-parse diagnosis for invalid argument'
> +
> +exec </dev/null
> +
> +. ./test-lib.sh
> +
> +HASH_file=
> +
> +test_expect_success 'set up basic repo' '
> + echo one > file.txt &&
> + mkdir subdir &&
> + echo two > subdir/file.txt &&
> + echo three > subdir/file2.txt &&
> + git add . &&
> + git commit -m init &&
> + echo four > index-only.txt &&
> + git add index-only.txt &&
> + echo five > disk-only.txt
> +'
> +
> +test_expect_success 'correct file objects' '
> + HASH_file=$(git rev-parse HEAD:file.txt) &&
> + git rev-parse HEAD:subdir/file.txt &&
> + git rev-parse :index-only.txt &&
> + cd subdir &&
> + git rev-parse HEAD:file.txt &&
> + git rev-parse HEAD:subdir/file2.txt &&
> + test $HASH_file = $(git rev-parse HEAD:file.txt) &&
> + test $HASH_file = $(git rev-parse :file.txt) &&
> + test $HASH_file = $(git rev-parse :0:file.txt) &&
> + cd ..
> +'
Please make it a habit of not doing "cd" without forcing a subprocess
using (). If 'rev-parse HEAD:file.txt' fails after "cd subdir", the next
test will start running from that directory.
> +test_expect_success 'incorrect revision id' '
> + test_must_fail git rev-parse foobar:file.txt 2>&1 |
> + grep "Invalid object name '"'"'foobar'"'"'." &&
It always is better to write this in separate steps, because exit status
of the upstream of pipe is discarded by the shell.
If you expect an error exit and want to make sure a particular error
message is given, do this:
test_must_fail git rev-parse foobar:file.txt 2>error &&
grep "Invalid ..." error
If you expect an error exit and want to make sure an incorrect error
message is not produced, do this:
test_must_fail git rev-parse foobar:file.txt 2>error &&
! grep "Invalid ..." error
^ permalink raw reply
* Re: [ANNOUNCE] Git 1.6.5.4
From: Todd Zullinger @ 2009-12-03 20:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Michael J Gruber, Andreas Schwab, git
In-Reply-To: <7viqco54xh.fsf@alter.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 1211 bytes --]
Junio C Hamano wrote:
> I did the second one after seeing that both my Debian box and the
> k.org machine that manpages tarballs are made (FC11 IIRC) had that
> option, and my impression has been that it usually is safe to say
> "even Debian has it, and there wouldn't be many things older than
> that distro", but that is apparently not true.
Heh, that surely used to be a very good rule of thumb. Perhaps these
days a rule of whichever is older Debian stable or current RHEL/CentOS
would suffice?
> Either we require 0.0.20 or we revert the tip one on this topic. I
> think the latter is a safe thing to do.
That sounds good to me. I'd like to get the EPEL builds for
RHEL/CentOS updated sometime soon, as they're currently still on
1.5.5.6 and that lacks too many of the great improvements in newer git
releases. Not having to patch for building the docs is one less thing
to worry about.
--
Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Rowe's Rule: The odds are five to six that the light at the end of the
tunnel is the headlight of an oncoming train.
-- Paul Dickson
[-- Attachment #2: Type: application/pgp-signature, Size: 542 bytes --]
^ permalink raw reply
* Re: installation problems with version 1.6.5.4
From: Todd Zullinger @ 2009-12-03 20:22 UTC (permalink / raw)
To: Oliver Kullmann; +Cc: git
In-Reply-To: <20091203200921.GA29478@cs-wsok.swansea.ac.uk>
[-- Attachment #1: Type: text/plain, Size: 553 bytes --]
Oliver Kullmann wrote:
> I get when installing 1.6.5.4
>
> GEN technical/api-index.txt
> ASCIIDOC technical/api-index.html
> ASCIIDOC git-add.xml
> XMLTO git-add.1
> xmlto: unrecognised option `--stringparam'
See http://thread.gmane.org/gmane.linux.kernel/921919/focus=134449 and
follow-ups.
--
Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Fleas can be taught nearly anything that a Congressman can.
-- Mark Twain
[-- Attachment #2: Type: application/pgp-signature, Size: 542 bytes --]
^ permalink raw reply
* [PATCH] cvsserver: make the output of 'update' more compatible with cvs.
From: Sergei Organov @ 2009-12-03 20:12 UTC (permalink / raw)
To: git; +Cc: gitster
Native cvs update outputs the string "cvs update: Updating <DIR>" for
every directory it processes (to stderr). This is used, e.g., by emacs
pcl-cvs to split files by directory. This commit implements this
feature in cvsserver.
---
git-cvsserver.perl | 12 ++++++++++++
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/git-cvsserver.perl b/git-cvsserver.perl
index 6dc45f5..5994951 100755
--- a/git-cvsserver.perl
+++ b/git-cvsserver.perl
@@ -981,10 +981,22 @@ sub req_update
#$log->debug("update state : " . Dumper($state));
+ my $last_dirname = "///";
+
# foreach file specified on the command line ...
foreach my $filename ( @{$state->{args}} )
{
$filename = filecleanup($filename);
+ my $cur_dirname = dirname($filename);
+ if ( $cur_dirname ne $last_dirname )
+ {
+ $last_dirname = $cur_dirname;
+ if ( $cur_dirname eq "" )
+ {
+ $cur_dirname = ".";
+ }
+ print "E cvs update: Updating $cur_dirname\n";
+ }
$log->debug("Processing file $filename");
--
1.6.6.rc0.67.g68b144.dirty
^ permalink raw reply related
* installation problems with version 1.6.5.4
From: Oliver Kullmann @ 2009-12-03 20:09 UTC (permalink / raw)
To: git
Hi,
I get when installing 1.6.5.4
GEN technical/api-index.txt
ASCIIDOC technical/api-index.html
ASCIIDOC git-add.xml
XMLTO git-add.1
xmlto: unrecognised option `--stringparam'
usage: xmlto [OPTION]... FORMAT XML
OPTIONs are:
-v verbose output (-vv for very verbose)
-x stylesheet use the specified stylesheet instead of choosing one
-m fragment use the XSL fragment to customize the stylesheet
-o directory put output in the specified directory instead of
the current working directory
-p postprocopts pass option to postprocessor
--extensions turn on stylesheet extensions for this tool chain
--searchpath colon-separated list of fallback directories
--skip-validation
do not attempt to validate the input before processing
where
> xmlto --version
xmlto version 0.0.18
Couldn't find something on versions of xmlto required?
Oliver
^ permalink raw reply
* Re: [RFC PATCH 4/8] Support remote helpers implementing smart transports
From: Shawn O. Pearce @ 2009-12-03 19:42 UTC (permalink / raw)
To: Ilari Liusvaara; +Cc: git
In-Reply-To: <20091202201008.GB11301@Knoppix>
Ilari Liusvaara <ilari.liusvaara@elisanet.fi> wrote:
> On Wed, Dec 02, 2009 at 09:04:57AM -0800, Shawn O. Pearce wrote:
> > Modify transport-helper.c to allow pushing TRANS_OPT_UPLOADPACK and
> > TRANS_OPT_RECEIVEPACK down into the helper via the option capability.
>
> NAK. Modified _process_connect_or_invoke (now _process_connect) to pass
> new option that appiles to connecting all subprotocols (if needed).
...
> And from helper POV, all subprotocols should appear identical from
> layer 6 POV so it doesn't make sense to diffrentiate between path
> for upload-pack and receive-pack (or upload-archive!).
That may be true, but the remote.origin.uploadpack and
remote.origin.receivepack configuration options exist
and are passed through as these option uploadpack and
option receivepack callbacks.
If you want to pass through a single option with the remote program
name, you need to do that immediately before the connect invoke
occurs, and instead buffer the two different configuration options
in the struct transport. I think that would make the series messier
than it is.
--
Shawn.
^ permalink raw reply
* Re: [StGit PATCH v2 3/6] stg mail: make __send_message do more
From: Alex Chiang @ 2009-12-03 19:30 UTC (permalink / raw)
To: Karl Wiberg; +Cc: catalin.marinas, git
In-Reply-To: <b8197bcb0912012303i3bd1061fhdb391de096996a27@mail.gmail.com>
* Karl Wiberg <kha@treskal.com>:
> Just pointing out a couple of Python tricks you might've wanted to
> use. No need to update the patch, though.
>
> On Wed, Dec 2, 2009 at 1:46 AM, Alex Chiang <achiang@hp.com> wrote:
>
> > + (patch_nr, total_nr) = (args[1], args[2])
>
> Can be written as
>
> (patch_nr, total_nr) = args[1:3]
Thanks, I did it this way.
> or, if args[2] is the last element of the list (which it isn't in this
> case?),
>
> (patch_nr, total_nr) = args[1:]
No, ref_id is the last arg, so that won't work.
> > + for (p, n) in zip(patches, range(1, total_nr + 1)):
> > + msg_id = __send_message('patch', tmpl, options, p, n, total_nr, ref_id)
>
> Can be written as
>
> for (n, p) in enumerate(patches):
>
> if you use n + 1 instead of n in the loop body.
That is a little cleaner, but I decided to keep it as zip(). Why?
Because using n + 1 in the loop body will push that line past 80
columns. ;)
It's also the original code (albeit with a simple variable
rename).
I know this isn't the kernel, and that there are plenty of other
lines that are 80+ characters, but if you can keep it short, why
not?
Thanks,
/ac
^ permalink raw reply
* Re: [StGit PATCH v2 1/6] stg mail: Refactor __send_message and friends
From: Alex Chiang @ 2009-12-03 19:27 UTC (permalink / raw)
To: Karl Wiberg; +Cc: catalin.marinas, git
In-Reply-To: <b8197bcb0912012253l399bb542sab141021e7ff6353@mail.gmail.com>
* Karl Wiberg <kha@treskal.com>:
> On Wed, Dec 2, 2009 at 1:46 AM, Alex Chiang <achiang@hp.com> wrote:
>
> > + if (smtppassword and not smtpuser):
> > + raise Exception('SMTP password supplied, username needed')
> > + if (smtpusetls and not smtpuser):
> > + raise Exception('SMTP over TLS requested, username needed')
> > + if (smtpuser and not smtppassword):
> > + smtppassword = getpass.getpass("Please enter SMTP password: ")
>
> Sorry if I confused you with my earlier explanation; I only meant that
> you should use the _form_ "raise Exception('message')", not that you
> should change the exception type from CmdException to Exception. If
> you try to trigger these errors, I think you'll find that in the case
> of CmdException, StGit will print just the message and exit with an
> error; whereas for straight Exception, it'll print the full backtrace
> as well under the assumption that it's a program bug.
Ah, ok. Will update.
/ac
^ permalink raw reply
* Re: [StGit PATCH v2 0/6] add support for git send-email
From: Alex Chiang @ 2009-12-03 19:27 UTC (permalink / raw)
To: Karl Wiberg; +Cc: catalin.marinas, git
In-Reply-To: <b8197bcb0912012246n3b83866cjb93654effc000242@mail.gmail.com>
* Karl Wiberg <kha@treskal.com>:
> On Wed, Dec 2, 2009 at 1:46 AM, Alex Chiang <achiang@hp.com> wrote:
> > The upshot is that in stg mail, --git and --mbox don't interact
> > well, and the resulting mbox file will lack the recipients. This
> > might be fixed in the future if we teach git send-email how to
> > generate mbox files, but then we introduce a versioning problem.
>
> One wild idea: git send-email's --smtp-server flag will accept the
> (full) path of a sendmail program; writing such a program, just
> capable enough to receive the outgoing emails and dumping them to a
> file, should be easy. Another option would be a program that speaks
> just enough SMTP to accept the mails. (Incidentally, these two would
> be useful in testing stg mail even without the --git option.)
Hm, I think this is getting to be a bit of overkill. I could see
adding --mbox support to git send-email as being a better use of
time (IMO).
> I fully understand if you'd rather get on with scratching your actual
> itch, though ...
:)
> > So let's just accept this wart for now, and say, if you want an mbox
> > file generated, don't use --git. That seems reasonable to me.
>
> Sure.
Thanks,
/ac
^ permalink raw reply
* Running commands in wrong environment
From: Marinescu Paul dan @ 2009-12-03 19:19 UTC (permalink / raw)
To: git@vger.kernel.org
git's start_command (run_command.c) executes a command (e.g. hook) but does not verify that it has properly set up the environment. It seems that in the unlikely case where putenv (run_command.c:117) fails, the command may have undesirable effects e.g. GIT_INDEX_FILE should have been set (interactive pre-commit hooks) but the default index will be used instead. It would be safer not to run the command but just exit in that case.
^ permalink raw reply
* [RFC PATCH 2/2] MSVC: Fix an "incompatible pointer types" compiler warning
From: Ramsay Jones @ 2009-12-03 18:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Marius Storm-Olsen, Johannes Sixt, GIT Mailing-list
In particular, the following warning is issued while compiling
compat/msvc.c:
...mingw.c(223) : warning C4133: 'function' : incompatible \
types - from '_stati64 *' to '_stat64 *'
which relates to a call of _fstati64() in the mingw_fstat()
function definition.
This is caused by various layers of macro magic and attempts to
avoid macro redefinition compiler warnings. For example, the call
to _fstati64() mentioned above is actually a call to _fstat64(),
since macro _USE_32BIT_TIME_T is not defined, and expects a pointer
to a struct _stat64 rather than the struct _stati64 which is passed
to mingw_fstat().
The definition of struct _stati64 given in compat/msvc.h had the
same "shape" as the definition of struct _stat64, so the call to
_fstat64() does not actually cause any runtime errors, but the
structure types are indeed incompatible. Also, the "shape" of
struct _stati64 changes, depending on the _USE_32BIT_TIME_T
macro, since the time_t type is defined as either __time64_t or
__time32_t.
When _USE_32BIT_TIME_T is defined, the call to _fstati64() is
actually a call to _fstat32i64() and expects a struct _stat32i64
pointer parameter. (struct _stati64 would again have the same
"shape" as struct _stat32i64).
The _USE_32BIT_TIME_T macro, along with all of the additional
structure type definitions, function definitions, and overloading
macro magic was introduced in msvc 2005.
In order to avoid the compiler warning, we use the appropriate
structure type names (and function names) from the msvc headers.
This allows us to compile with -D_USE_32BIT_TIME_T if necessary.
Note that the original mingw code should work with an msvc/sdk
prior to 2005. We attempt to detect this by checking for _stati64
being defined as a macro and, if not defined, conditionally
compiling the original code.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
---
The first version of this patch was much simpler; the diffstat showed
a net decrease of 15 lines of code! The extra fat comes from additions
to the compat/mingw.h file. The original change looked like this (along
with the identical change to compat/msvc.h):
@@ -175,13 +175,21 @@ int mingw_getpagesize(void);
* mingw_fstat() instead of fstat() on Windows.
*/
#define off_t off64_t
-#define stat _stati64
#define lseek _lseeki64
+#if defined(_MSC_VER)
+#define stat _stat64
+#else
+#define stat _stati64
+#endif
int mingw_lstat(const char *file_name, struct stat *buf);
int mingw_fstat(int fd, struct stat *buf);
#define fstat mingw_fstat
#define lstat mingw_lstat
+#if defined(_MSC_VER)
+#define _stat64(x,y) mingw_lstat(x,y)
+#else
#define _stati64(x,y) mingw_lstat(x,y)
+#endif
int mingw_utime(const char *file_name, const struct utimbuf *times);
#define utime mingw_utime
This works with my version of msvc/sdk, provided we have no need to compile
with -D_USE_32BIT_TIME_T. (I was a little concerned when I noticed that the
time_t type was 64-bits; I checked a few of the obvious places to see if this
causes any breakage, but didn't find any).
Also, I added the "&& defined(_stati64)" in the hope that it would work with
older msvc/sdk versions.
The reason for the RFC is:
- maybe we don't need the flexibility of compiling with/without the 32-bit
time_t definition (which *works* BTW) and can revert to the original patch?
- I *think* this will work with older msvc, but I can't test it!
- I've tried to be careful not to break the MinGW build, but again I can't
test it. (I will be shocked if I have ;-)
ATB,
Ramsay Jones
compat/mingw.h | 27 ++++++++++++++++++++++++++-
compat/msvc.h | 25 +------------------------
2 files changed, 27 insertions(+), 25 deletions(-)
diff --git a/compat/mingw.h b/compat/mingw.h
index 5b5258b..98d233b 100644
--- a/compat/mingw.h
+++ b/compat/mingw.h
@@ -175,14 +175,39 @@ int mingw_getpagesize(void);
* mingw_fstat() instead of fstat() on Windows.
*/
#define off_t off64_t
-#define stat _stati64
#define lseek _lseeki64
+
+#if defined(_MSC_VER) && defined(_stati64)
+
+# if defined(_USE_32BIT_TIME_T)
+# define stat _stat32i64
+# else
+# define stat _stat64
+# endif
+
+ int mingw_lstat(const char *file_name, struct stat *buf);
+ int mingw_fstat(int fd, struct stat *buf);
+
+# define fstat mingw_fstat
+# define lstat mingw_lstat
+
+# if defined(_USE_32BIT_TIME_T)
+# define _stat32i64(x,y) mingw_lstat(x,y)
+# else
+# define _stat64(x,y) mingw_lstat(x,y)
+# endif
+
+#else /* !defined(_MSC_VER) || !defined(_stati64) */
+
+#define stat _stati64
int mingw_lstat(const char *file_name, struct stat *buf);
int mingw_fstat(int fd, struct stat *buf);
#define fstat mingw_fstat
#define lstat mingw_lstat
#define _stati64(x,y) mingw_lstat(x,y)
+#endif
+
int mingw_utime(const char *file_name, const struct utimbuf *times);
#define utime mingw_utime
diff --git a/compat/msvc.h b/compat/msvc.h
index 9c753a5..c099fe0 100644
--- a/compat/msvc.h
+++ b/compat/msvc.h
@@ -21,30 +21,7 @@ static __inline int strcasecmp (const char *s1, const char *s2)
}
#undef ERROR
-#undef stat
-#undef _stati64
+
#include "compat/mingw.h"
-#undef stat
-#define stat _stati64
-#define _stat64(x,y) mingw_lstat(x,y)
-/*
- Even though _stati64 is normally just defined at _stat64
- on Windows, we specify it here as a proper struct to avoid
- compiler warnings about macro redefinition due to magic in
- mingw.h. Struct taken from ReactOS (GNU GPL license).
-*/
-struct _stati64 {
- _dev_t st_dev;
- _ino_t st_ino;
- unsigned short st_mode;
- short st_nlink;
- short st_uid;
- short st_gid;
- _dev_t st_rdev;
- __int64 st_size;
- time_t st_atime;
- time_t st_mtime;
- time_t st_ctime;
-};
#endif
--
1.6.5
^ permalink raw reply related
* Re: [LIBGIT2 PATCH] git_odb_open ckeck for valid path to database
From: Ramsay Jones @ 2009-12-03 18:54 UTC (permalink / raw)
To: Esben Mose Hansen; +Cc: ae, git
In-Reply-To: <200911301037.53512.kde@mosehansen.dk>
Esben Mose Hansen wrote:
> On Tuesday 10 November 2009 22:07:04 Esben Mose Hansen wrote:
>> On Monday 09 November 2009 20:16:15 Ramsay Jones wrote:
>>
>> I have made 2 new patchsets: One
>
> Did these get lost in transit? Or am I going about it in the wrong way? :)
Oh, sorry, I didn't notice that this was sent to me! *ahem*
(I thought/expected them to be addressed to Andreas)
Maybe you could resend the first patch, inline rather than as an attachment,
addressed to Andreas (ae@op5.com) so that he can comment on them (or commit
them).
ATB,
Ramsay Jones
^ permalink raw reply
* [PATCH 1/2] Makefile: Add a target to generate C preprocessor output files
From: Ramsay Jones @ 2009-12-03 18:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Marius Storm-Olsen, Johannes Sixt, GIT Mailing-list
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
---
Whilst fixing an msvc compiler warning (see patch #2), I needed to
look at the output of the c-preprocessor; maybe other people will
find it useful.
ATB,
Ramsay Jones
Makefile | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
index 1092589..6c9e8a8 100644
--- a/Makefile
+++ b/Makefile
@@ -1527,6 +1527,8 @@ git.o git.spec \
$(patsubst %.perl,%,$(SCRIPT_PERL)) \
: GIT-VERSION-FILE
+%.i: %.c .ALWAYS
+ $(QUIET_CC)$(CC) -E $(ALL_CFLAGS) $< >$*.i
%.o: %.c GIT-CFLAGS
$(QUIET_CC)$(CC) -o $*.o -c $(ALL_CFLAGS) $<
%.s: %.c GIT-CFLAGS
@@ -1863,7 +1865,7 @@ endif
.PHONY: all install clean strip
.PHONY: shell_compatibility_test please_set_SHELL_PATH_to_a_more_modern_shell
.PHONY: .FORCE-GIT-VERSION-FILE TAGS tags cscope .FORCE-GIT-CFLAGS
-.PHONY: .FORCE-GIT-BUILD-OPTIONS
+.PHONY: .FORCE-GIT-BUILD-OPTIONS .ALWAYS
### Check documentation
#
--
1.6.5
^ permalink raw reply related
* [PATCH 2/2] t9001: use older Getopt::Long boolean prefix '--no' rather than '--no-'
From: Brandon Casey @ 2009-12-03 17:52 UTC (permalink / raw)
To: gitster; +Cc: git, Brandon Casey
In-Reply-To: <cQVSAldE71QbE653CpBd7qjd43g8URlxW7WO99KN4T0njgcXAbpAJQhTbfLeU5wxWrW84lsFVZE@cipher.nrlssc.navy.mil>
From: Brandon Casey <drafnel@gmail.com>
The '--no-chain-reply-to' option is a Getopt::Long boolean option. The
'--no-' prefix (as in --no-chain-reply-to) for boolean options is not
supported in Getopt::Long version 2.32 which was released with Perl 5.8.0.
This version only supports '--no' as in '--nochain-reply-to'. More recent
versions of Getopt::Long, such as version 2.34, support either prefix. So
use the older form in the tests.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
---
t/t9001-send-email.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh
index fb51ab3..752adaa 100755
--- a/t/t9001-send-email.sh
+++ b/t/t9001-send-email.sh
@@ -827,7 +827,7 @@ test_expect_success 'no warning with an explicit --no-chain-reply-to' '
--dry-run \
--from="Example <nobody@example.com>" \
--to=nobody@example.com \
- --no-chain-reply-to \
+ --nochain-reply-to \
outdir/000?-*.patch 2>errors >out &&
! grep "no-chain-reply-to" errors
'
--
1.6.5.3
^ permalink raw reply related
* [PATCH 1/2] t4201: use ISO8859-1 rather than ISO-8859-1
From: Brandon Casey @ 2009-12-03 17:52 UTC (permalink / raw)
To: gitster; +Cc: git, Brandon Casey
From: Brandon Casey <drafnel@gmail.com>
Some ancient platforms do not have an extensive list of alternate names for
character encodings. For example, Solaris 7 and IRIX 6.5 do not know that
ISO-8859-1 is the same as ISO8859-1. Modern platforms do know this, so use
the older name.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
---
t/t4201-shortlog.sh | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/t/t4201-shortlog.sh b/t/t4201-shortlog.sh
index dd818f6..a01e55b 100755
--- a/t/t4201-shortlog.sh
+++ b/t/t4201-shortlog.sh
@@ -53,7 +53,7 @@ GIT_DIR=non-existing git shortlog -w < log > out
test_expect_success 'shortlog from non-git directory' 'test_cmp expect out'
iconvfromutf8toiso88591() {
- printf "%s" "$*" | iconv -f UTF-8 -t ISO-8859-1
+ printf "%s" "$*" | iconv -f UTF-8 -t ISO8859-1
}
DSCHO="Jöhännës \"Dschö\" Schindëlin"
@@ -72,7 +72,7 @@ test_expect_success 'shortlog encoding' '
git config --unset i18n.commitencoding &&
echo 2 > a1 &&
git commit --quiet -m "$MSG1" --author="$DSCHOE" a1 &&
- git config i18n.commitencoding "ISO-8859-1" &&
+ git config i18n.commitencoding "ISO8859-1" &&
echo 3 > a1 &&
git commit --quiet -m "$(iconvfromutf8toiso88591 "$MSG2")" \
--author="$(iconvfromutf8toiso88591 "$DSCHOE")" a1 &&
--
1.6.5.3
^ permalink raw reply related
* Re: [ANNOUNCE] Git 1.6.5.4
From: Junio C Hamano @ 2009-12-03 17:43 UTC (permalink / raw)
To: Todd Zullinger; +Cc: Michael J Gruber, Andreas Schwab, Junio C Hamano, git
In-Reply-To: <20091203150323.GI23717@inocybe.localdomain>
Todd Zullinger <tmz@pobox.com> writes:
> Michael J Gruber wrote:
>>>> Andreas Schwab venit, vidit, dixit 03.12.2009 13:03:
>>> xmlto version 0.0.18
> [...]
>> Now that predates Git quite a bit (2004-01-21)...
>> I think we can require at least 0.0.20, which is in Debian Lenny and
>> Fedora 9, for example. I think that should have it. (I'm not sure, they
>> don't use a proper vcs ;) ).
>
> xmlto-0.0.18 is what's in RHEL/CentOS 5. It would be nice to be able
> to build git docs there, which works pretty well in general (I
> believe).
>
> I built 1.6.6.rc1 on CentOS 5.4 last night with Junio's first patch
> for this, which only called --stringparam if MAN_BASE_URL was set.
I did the second one after seeing that both my Debian box and the k.org
machine that manpages tarballs are made (FC11 IIRC) had that option, and
my impression has been that it usually is safe to say "even Debian has it,
and there wouldn't be many things older than that distro", but that is
apparently not true.
Either we require 0.0.20 or we revert the tip one on this topic. I think
the latter is a safe thing to do.
Thanks for a quick report and analysis.
^ permalink raw reply
* Re: git gsoc money
From: Junio C Hamano @ 2009-12-03 17:32 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20091203052220.GA22582@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> As a result of our participation in the Summer of Code project last
> summer and this summer, Google gave the git community some money. Most
> of that money went to defraying travel costs to the SoC mentor summit
> and the GitTogether, both last year and this year.
I have never been actively involved in SoC mentoring so my suggestion
shouldn't count too much, but the SFC route sounds like a very reasonable
option to me. Travel fund helped me a lot to attend last year's
GitTogether, and it would be very handy to have such a community fund to
cover part of costs when git people need to appear in events and
conferences for the benefit of git community as a whole.
^ permalink raw reply
* Re: Git documentation consistency
From: Marko Kreen @ 2009-12-03 16:22 UTC (permalink / raw)
To: The Git Mailing List
In-Reply-To: <m1NG61U-000kn4C@most.weird.com>
On 12/3/09, Greg A. Woods <woods@planix.com> wrote:
> At Wed, 02 Dec 2009 17:34:01 -0800, Junio C Hamano <gitster@pobox.com> wrote:
> Subject: Re: Git documentation consistency
> > I think you are showing ignorance here, as -? is *not* even close to
> > standard, nor even widely used practice at all.
>
> I think I should know something about Unix command line and option
> parsers, having used them for some 25 years or so now. In fact I've
> used most every kind of unix that ever was, and I've worked on the
> source to more than a few.
'?' is what getopt(3) is supposed to return for unknown options.
--
marko
^ permalink raw reply
* Re: git gsoc money
From: Shawn O. Pearce @ 2009-12-03 15:39 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20091203052220.GA22582@coredump.intra.peff.net>
Jeff King <peff@peff.net> wrote:
> However, we still have about $500 USD remaining.
>
> Some possibilities are:
>
> 1. Become an affiliated project of an organization like The Software
> Freedom Conservancy or Software in the Public Interest.
Try to join the Software Freedom Conservancy and retain the funds
for Git's use? Maybe you can slide in before the Dec 31st deadline.
I know a few users of Git have said they can't contribute code, but
they would like to throw $25-50 towards a developer to say thank you.
This would give them an easier vehicle to do that.
I'm not saying we should actively seek donations, we have virtually
no expenses and don't need them.
But we do sometimes have these GitTogether things, or one of us is
going to a Linux Plumbers conference or something to give a talk
promoting Git. Having $500 from a handful of donations available
to defray Git related travel costs for some of our more active
developers is more useful than having a user send something from
an Amazon wish list [1][2].
At worst, if we collect a bunch of money and realize "Oh, wait,
we have like $8000 USD and we haven't spent any of it in the past
5 years!" we can have the SFC do a big donation to FSF or something
and say "thanks for GCC!".
If joining the SFC proves too difficult, just donate the $500 to
the FSF. That's what we did the first year we were in GSoC.
[1] At least, to me. My apartment isn't big enough for the crap
I already own, I don't need more crap shipped to it.
[2] This remark is due to a user on #git the other week wondering
why I don't have an Amazon wish list, as he wanted to send me
something to thank me for some feature I wrote eons ago.
--
Shawn.
^ permalink raw reply
* [BUG] crash on make test
From: Marinescu Paul dan @ 2009-12-03 15:38 UTC (permalink / raw)
To: git@vger.kernel.org
In-Reply-To: <D6F784B72498304C93A8A4691967698E8EE2C44FE1@REX2.intranet.epfl.ch>
I got a crash on git's make test with and a core file in ./t/trash directory.t4200-rerere/
The problem seems to be in garbage_collect (builtin-rerere.c) where readdir can be called with a null pointer
Below is the gdb stack trace:
GNU gdb 6.8-debian
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i486-linux-gnu"...
Reading symbols from /lib/libz.so.1...done.
Loaded symbols for /lib/libz.so.1
Reading symbols from /lib/i686/cmov/libcrypto.so.0.9.8...done.
Loaded symbols for /lib/i686/cmov/libcrypto.so.0.9.8
Reading symbols from /lib/tls/i686/cmov/libpthread.so.0...Reading symbols from /usr/lib/debug/lib/tls/i686/cmov/libpthread-2.9.so...done.
done.
Loaded symbols for /lib/tls/i686/cmov/libpthread.so.0
Reading symbols from /lib/tls/i686/cmov/libc.so.6...Reading symbols from /usr/lib/debug/lib/tls/i686/cmov/libc-2.9.so...done.
done.
Loaded symbols for /lib/tls/i686/cmov/libc.so.6
Reading symbols from /usr/lib/libxml2.so.2...done.
Loaded symbols for /usr/lib/libxml2.so.2
Reading symbols from /lib/tls/i686/cmov/librt.so.1...Reading symbols from /usr/lib/debug/lib/tls/i686/cmov/librt-2.9.so...done.
done.
Loaded symbols for /lib/tls/i686/cmov/librt.so.1
Reading symbols from /lib/tls/i686/cmov/libdl.so.2...Reading symbols from /usr/lib/debug/lib/tls/i686/cmov/libdl-2.9.so...done.
done.
Loaded symbols for /lib/tls/i686/cmov/libdl.so.2
Reading symbols from /usr/lib/libelf.so.1...done.
Loaded symbols for /usr/lib/libelf.so.1
Reading symbols from /usr/lib/libstdc++.so.6...done.
Loaded symbols for /usr/lib/libstdc++.so.6
Reading symbols from /lib/tls/i686/cmov/libm.so.6...Reading symbols from /usr/lib/debug/lib/tls/i686/cmov/libm-2.9.so...done.
done.
Loaded symbols for /lib/tls/i686/cmov/libm.so.6
Reading symbols from /lib/libgcc_s.so.1...done.
Loaded symbols for /lib/libgcc_s.so.1
Reading symbols from /lib/ld-linux.so.2...Reading symbols from /usr/lib/debug/lib/ld-2.9.so...done.
done.
Loaded symbols for /lib/ld-linux.so.2
Core was generated by `git rerere gc'.
Program terminated with signal 11, Segmentation fault.
[New process 5637]
#0 0x4027fca5 in __readdir64 (dirp=0x0) at ../sysdeps/unix/readdir.c:45
in ../sysdeps/unix/readdir.c
(gdb) bt full
#0 0x4027fca5 in __readdir64 (dirp=0x0) at ../sysdeps/unix/readdir.c:45
ignore1 = 0
ignore2 = 1
dp = <value optimized out>
saved_errno = 12
#1 0x0813cfd4 in garbage_collect (rr=0xbfabe89c) at builtin-rerere.c:51
to_remove = {items = 0x0, nr = 0, alloc = 0, strdup_strings = 1}
dir = (DIR *) 0x0
e = (struct dirent *) 0x1
i = 0
cutoff = -1079252800
now = 1259852637
then = 1
#2 0x0813d970 in cmd_rerere (argc=2, argv=0xbfabeaa8, prefix=0x0) at builtin-rerere.c:121
merge_rr = {items = 0xa0d2728, nr = 1, alloc = 32, strdup_strings = 1}
i = -1
fd = 6
#3 0x0804ca57 in run_builtin (p=0x831465c, argc=2, argv=0xbfabeaa8) at git.c:249
status = 1076211824
st = {st_dev = 3418922014550254984, __pad1 = 65535, __st_ino = 1073860596, st_mode = 134517300,
st_nlink = 1073862256, st_uid = 3215714640, st_gid = 1073798779, st_rdev = 4632177755147065384, __pad2 = 1,
st_size = 1, st_blksize = 134519071, st_blocks = 180, st_atim = {tv_sec = 137446088, tv_nsec = 1}, st_mtim = {
tv_sec = 1075774256, tv_nsec = 1077161972}, st_ctim = {tv_sec = 137183648, tv_nsec = 134524528},
st_ino = 4612030924696840600}
prefix = 0x0
#4 0x0804cee8 in handle_internal_command (argc=2, argv=0xbfabeaa8) at git.c:394
p = (struct cmd_struct *) 0x831465c
cmd = 0xbfac098a "rerere"
i = 69
commands = {{cmd = 0x82d4765 "add", fn = 0x804f757 <cmd_add>, option = 5}, {cmd = 0x82d4769 "stage",
fn = 0x804f757 <cmd_add>, option = 5}, {cmd = 0x82d476f "annotate", fn = 0x8050754 <cmd_annotate>, option = 1}, {
cmd = 0x82d4778 "apply", fn = 0x80679e1 <cmd_apply>, option = 0}, {cmd = 0x82d477e "archive",
fn = 0x8069ba0 <cmd_archive>, option = 0}, {cmd = 0x82d4786 "bisect--helper",
fn = 0x806a138 <cmd_bisect__helper>, option = 5}, {cmd = 0x82d4795 "blame", fn = 0x807770d <cmd_blame>,
option = 1}, {cmd = 0x82d479b "branch", fn = 0x807d584 <cmd_branch>, option = 1}, {cmd = 0x82d47a2 "bundle",
fn = 0x807e3ec <cmd_bundle>, option = 0}, {cmd = 0x82d47a9 "cat-file", fn = 0x80803cb <cmd_cat_file>,
option = 1}, {cmd = 0x82d47b2 "checkout", fn = 0x8088f1c <cmd_checkout>, option = 5}, {
cmd = 0x82d47bb "checkout-index", fn = 0x8082fc9 <cmd_checkout_index>, option = 5}, {
cmd = 0x82d47ca "check-ref-format", fn = 0x8081920 <cmd_check_ref_format>, option = 0}, {
cmd = 0x82d47db "check-attr", fn = 0x808125a <cmd_check_attr>, option = 1}, {cmd = 0x82d47e6 "cherry",
fn = 0x80eb740 <cmd_cherry>, option = 1}, {cmd = 0x82d47ed "cherry-pick", fn = 0x814c341 <cmd_cherry_pick>,
option = 5}, {cmd = 0x82d47f9 "clone", fn = 0x808e8a1 <cmd_clone>, option = 0}, {cmd = 0x82d47ff "clean",
fn = 0x808aa34 <cmd_clean>, option = 5}, {cmd = 0x82d4805 "commit", fn = 0x809b274 <cmd_commit>, option = 5}, {
cmd = 0x82d480c "commit-tree", fn = 0x8092531 <cmd_commit_tree>, option = 1}, {cmd = 0x82d4818 "config",
fn = 0x809f881 <cmd_config>, option = 0}, {cmd = 0x82d481f "count-objects", fn = 0x80a1c75 <cmd_count_objects>,
option = 1}, {cmd = 0x82d482d "describe", fn = 0x80a4d6d <cmd_describe>, option = 1}, {cmd = 0x82d4836 "diff",
fn = 0x80a99e8 <cmd_diff>, option = 0}, {cmd = 0x82d483b "diff-files", fn = 0x80a56d0 <cmd_diff_files>,
option = 5}, {cmd = 0x82d4846 "diff-index", fn = 0x80a601c <cmd_diff_index>, option = 1}, {
cmd = 0x82d4851 "diff-tree", fn = 0x80a7307 <cmd_diff_tree>, option = 1}, {cmd = 0x82d485b "fast-export",
fn = 0x80af36f <cmd_fast_export>, option = 1}, {cmd = 0x82d4867 "fetch", fn = 0x80c1668 <cmd_fetch>,
option = 1}, {cmd = 0x82d486d "fetch-pack", fn = 0x80ba759 <cmd_fetch_pack>, option = 1}, {
cmd = 0x82d4878 "fetch--tool", fn = 0x80b4202 <cmd_fetch__tool>, option = 1}, {cmd = 0x82d4884 "fmt-merge-msg",
fn = 0x80c5038 <cmd_fmt_merge_msg>, option = 1}, {cmd = 0x82d4892 "for-each-ref",
fn = 0x80cb172 <cmd_for_each_ref>, option = 1}, {cmd = 0x82d489f "format-patch",
fn = 0x80e86a4 <cmd_format_patch>, option = 1}, {cmd = 0x82d48ac "fsck", fn = 0x80cf9d5 <cmd_fsck>, option = 1},
{cmd = 0x82d48b1 "fsck-objects", fn = 0x80cf9d5 <cmd_fsck>, option = 1}, {cmd = 0x82d48be "gc",
fn = 0x80d17fd <cmd_gc>, option = 1}, {cmd = 0x82d48c1 "get-tar-commit-id",
fn = 0x8163545 <cmd_get_tar_commit_id>, option = 0}, {cmd = 0x82d48d3 "grep", fn = 0x80d80ba <cmd_grep>,
option = 3}, {cmd = 0x82d48d8 "help", fn = 0x80dcd12 <cmd_help>, option = 0}, {cmd = 0x82d48dd "init",
fn = 0x80e0d5b <cmd_init_db>, option = 0}, {cmd = 0x82d48e2 "init-db", fn = 0x80e0d5b <cmd_init_db>,
option = 0}, {cmd = 0x82d48ea "log", fn = 0x80e4c6f <cmd_log>, option = 3}, {cmd = 0x82d48ee "ls-files",
fn = 0x80ef3e5 <cmd_ls_files>, option = 1}, {cmd = 0x82d48f7 "ls-tree", fn = 0x80f1e84 <cmd_ls_tree>,
option = 1}, {cmd = 0x82d48ff "ls-remote", fn = 0x80f0a35 <cmd_ls_remote>, option = 0}, {
cmd = 0x82d4909 "mailinfo", fn = 0x80f99ac <cmd_mailinfo>, option = 0}, {cmd = 0x82d4912 "mailsplit",
fn = 0x80fbd21 <cmd_mailsplit>, option = 0}, {cmd = 0x82d491c "merge", fn = 0x81045ff <cmd_merge>, option = 5}, {
cmd = 0x82d4922 "merge-base", fn = 0x81084c3 <cmd_merge_base>, option = 1}, {cmd = 0x82d492d "merge-file",
fn = 0x8108839 <cmd_merge_file>, option = 0}, {cmd = 0x82d4938 "merge-ours", fn = 0x8109594 <cmd_merge_ours>,
option = 1}, {cmd = 0x82d4943 "merge-recursive", fn = 0x81097ca <cmd_merge_recursive>, option = 5}, {
cmd = 0x82d4953 "merge-subtree", fn = 0x81097ca <cmd_merge_recursive>, option = 5}, {cmd = 0x82d4961 "mktree",
fn = 0x810afea <cmd_mktree>, option = 1}, {cmd = 0x82d4968 "mv", fn = 0x810ba65 <cmd_mv>, option = 5}, {
cmd = 0x82d496b "name-rev", fn = 0x810ef35 <cmd_name_rev>, option = 1}, {cmd = 0x82d4974 "pack-objects",
fn = 0x811daed <cmd_pack_objects>, option = 1}, {cmd = 0x82d4981 "peek-remote", fn = 0x80f0a35 <cmd_ls_remote>,
option = 0}, {cmd = 0x82d498d "pickaxe", fn = 0x807770d <cmd_blame>, option = 1}, {cmd = 0x82d4995 "prune",
fn = 0x812160f <cmd_prune>, option = 1}, {cmd = 0x82d499b "prune-packed", fn = 0x812029c <cmd_prune_packed>,
option = 1}, {cmd = 0x82d49a8 "push", fn = 0x8122de2 <cmd_push>, option = 1}, {cmd = 0x82d49ad "read-tree",
fn = 0x8123640 <cmd_read_tree>, option = 1}, {cmd = 0x82d49b7 "receive-pack", fn = 0x8128ec4 <cmd_receive_pack>,
option = 0}, {cmd = 0x82d49c4 "reflog", fn = 0x812ebcf <cmd_reflog>, option = 1}, {cmd = 0x82d49cb "remote",
fn = 0x813ad5e <cmd_remote>, option = 1}, {cmd = 0x82d49d2 "replace", fn = 0x813c0fc <cmd_replace>, option = 1},
{cmd = 0x82d49da "repo-config", fn = 0x809f881 <cmd_config>, option = 0}, {cmd = 0x82d49e6 "rerere",
fn = 0x813d60d <cmd_rerere>, option = 1}, {cmd = 0x82d49ed "reset", fn = 0x813f0c9 <cmd_reset>, option = 1}, {
cmd = 0x82d49f3 "rev-list", fn = 0x8142605 <cmd_rev_list>, option = 1}, {cmd = 0x82d49fc "rev-parse",
fn = 0x81461ab <cmd_rev_parse>, option = 0}, {cmd = 0x82d4a06 "revert", fn = 0x814c24b <cmd_revert>,
option = 5}, {cmd = 0x82d4a0d "rm", fn = 0x814d170 <cmd_rm>, option = 1}, {cmd = 0x82d4a10 "send-pack",
fn = 0x815167e <cmd_send_pack>, option = 1}, {cmd = 0x82d4a1a "shortlog", fn = 0x81547ad <cmd_shortlog>,
option = 2}, {cmd = 0x82d4a23 "show-branch", fn = 0x81590c0 <cmd_show_branch>, option = 1}, {
cmd = 0x82d4a2f "show", fn = 0x80e3cc2 <cmd_show>, option = 3}, {cmd = 0x82d4a34 "status",
fn = 0x809a6e5 <cmd_status>, option = 5}, {cmd = 0x82d4a3b "stripspace", fn = 0x815e3e7 <cmd_stripspace>,
option = 0}, {cmd = 0x82d4a46 "symbolic-ref", fn = 0x815e849 <cmd_symbolic_ref>, option = 1}, {
cmd = 0x82d4a53 "tag", fn = 0x816180b <cmd_tag>, option = 1}, {cmd = 0x82d4a57 "tar-tree",
fn = 0x81630ac <cmd_tar_tree>, option = 0}, {cmd = 0x82d4a60 "unpack-objects",
fn = 0x8166bdf <cmd_unpack_objects>, option = 1}, {cmd = 0x82d4a6f "update-index",
fn = 0x816b514 <cmd_update_index>, option = 1}, {cmd = 0x82d4a7c "update-ref", fn = 0x816ddd0 <cmd_update_ref>,
option = 1}, {cmd = 0x82d4a87 "update-server-info", fn = 0x816e734 <cmd_update_server_info>, option = 1}, {
cmd = 0x82d4a9a "upload-archive", fn = 0x816f579 <cmd_upload_archive>, option = 0}, {
cmd = 0x82d4aa9 "verify-tag", fn = 0x817257a <cmd_verify_tag>, option = 1}, {cmd = 0x82d4ab4 "version",
fn = 0x81f5c18 <cmd_version>, option = 0}, {cmd = 0x82d4abc "whatchanged", fn = 0x80e339b <cmd_whatchanged>,
option = 3}, {cmd = 0x82d4ac8 "write-tree", fn = 0x8172814 <cmd_write_tree>, option = 1}, {
cmd = 0x82d4ad3 "verify-pack", fn = 0x81714a2 <cmd_verify_pack>, option = 0}, {cmd = 0x82d4adf "show-ref",
fn = 0x815d8b1 <cmd_show_ref>, option = 1}, {cmd = 0x82d4ae8 "pack-refs", fn = 0x811f8a4 <cmd_pack_refs>,
option = 1}}
ext = ""
#5 0x0804d1ce in run_argv (argcp=0xbfabea20, argv=0xbfabea24) at git.c:436
done_alias = 0
#6 0x0804d6d1 in main (argc=2, argv=0xbfabeaa8) at git.c:507
cmd = 0xbfac098a "rerere"
done_help = 0
was_alias = 0
(gdb) quit
^ permalink raw reply
* Re: Git documentation consistency
From: Uri Okrent @ 2009-12-03 15:24 UTC (permalink / raw)
To: Jeff King; +Cc: The Git Mailing List
In-Reply-To: <20091203074500.GA31566@coredump.intra.peff.net>
On Wed, Dec 2, 2009 at 11:45 PM, Jeff King <peff@peff.net> wrote:
> So what systems _do_ treat "-?" specially?
>
> -Peff
Windows seems to (of course you need to use '/' instead of '-'):
Microsoft Windows [Version 6.0.6001]
c:\>dir -h
Volume in drive C has no label.
Volume Serial Number is B09A-B49F
Directory of c:\
File Not Found
c:\>dir /h
Invalid switch - "h".
c:\>dir /help
Invalid switch - "help".
c:\>dir /?
Displays a list of files and subdirectories in a directory.
DIR [drive:][path][filename] [/A[[:]attributes]] [/B] [/C] [/D] [/L] [/N]
[/O[[:]sortorder]] [/P] [/Q] [/R] [/S] [/T[[:]timefield]] [/W] [/X] [/4]
[drive:][path][filename]
Specifies drive, directory, and/or files to list.
/A Displays files with specified attributes.
attributes D Directories R Read-only files
H Hidden files A Files ready for archiving
S System files I Not content indexed files
L Reparse Points - Prefix meaning not
/B Uses bare format (no heading information or summary).
/C Display the thousand separator in file sizes. This is the
default. Use /-C to disable display of separator.
/D Same as wide but files are list sorted by column.
/L Uses lowercase.
/N New long list format where filenames are on the far right.
/O List by files in sorted order.
sortorder N By name (alphabetic) S By size (smallest first)
E By extension (alphabetic) D By date/time (oldest first)
G Group directories first - Prefix to reverse order
/P Pauses after each screenful of information.
/Q Display the owner of the file.
/R Display alternate data streams of the file.
/S Displays files in specified directory and all subdirectories.
/T Controls which time field displayed or used for sorting
timefield C Creation
A Last Access
W Last Written
/W Uses wide list format.
/X This displays the short names generated for non-8dot3 file
names. The format is that of /N with the short name inserted
before the long name. If no short name is present, blanks are
displayed in its place.
/4 Displays four-digit years
Switches may be preset in the DIRCMD environment variable. Override
preset switches by prefixing any switch with - (hyphen)--for example, /-W.
c:\>
--
Uri
Please consider the environment before printing this message.
http://www.panda.org/how_you_can_help/
^ permalink raw reply
* Re: [ANNOUNCE] Git 1.6.5.4
From: Todd Zullinger @ 2009-12-03 15:03 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Andreas Schwab, Junio C Hamano, git
In-Reply-To: <4B17D078.6080000@drmicha.warpmail.net>
[-- Attachment #1: Type: text/plain, Size: 947 bytes --]
Michael J Gruber wrote:
>>> Andreas Schwab venit, vidit, dixit 03.12.2009 13:03:
>> xmlto version 0.0.18
[...]
> Now that predates Git quite a bit (2004-01-21)...
> I think we can require at least 0.0.20, which is in Debian Lenny and
> Fedora 9, for example. I think that should have it. (I'm not sure, they
> don't use a proper vcs ;) ).
xmlto-0.0.18 is what's in RHEL/CentOS 5. It would be nice to be able
to build git docs there, which works pretty well in general (I
believe).
I built 1.6.6.rc1 on CentOS 5.4 last night with Junio's first patch
for this, which only called --stringparam if MAN_BASE_URL was set.
--
Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
A common mistake people make when trying to design something
completely foolproof is to underestimate the ingenuity of complete
fools.
-- Douglas Adams
[-- Attachment #2: Type: application/pgp-signature, Size: 542 bytes --]
^ permalink raw reply
* Re: [ANNOUNCE] Git 1.6.5.4
From: Michael J Gruber @ 2009-12-03 14:51 UTC (permalink / raw)
To: Andreas Schwab; +Cc: Junio C Hamano, git
In-Reply-To: <m2d42w5fqq.fsf@igel.home>
Andreas Schwab venit, vidit, dixit 03.12.2009 14:50:
> Michael J Gruber <git@drmicha.warpmail.net> writes:
>
>> Andreas Schwab venit, vidit, dixit 03.12.2009 13:03:
>>> Junio C Hamano <gitster@pobox.com> writes:
>>>
>>>> Unconditionally set man.base.url.for.relative.links
>>>
>>> rm -f git-add.1 && \
>>> xmlto -m manpage-normal.xsl --stringparam man.base.url.for.relative.links= man git-add.xml
>>> xmlto: unrecognized option '--stringparam'
>>> make[1]: *** [git-add.1] Error 1
>>>
>>> Andreas.
>>>
>>
>> and
>>
>> uname -a
>> xmlto --version
>>
>> says?
>
> xmlto version 0.0.18
>
> Andreas.
>
Now that predates Git quite a bit (2004-01-21)...
I think we can require at least 0.0.20, which is in Debian Lenny and
Fedora 9, for example. I think that should have it. (I'm not sure, they
don't use a proper vcs ;) ).
Michael
^ permalink raw reply
* Re: [ANNOUNCE] Git 1.6.5.4
From: Andreas Schwab @ 2009-12-03 13:50 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Junio C Hamano, git
In-Reply-To: <4B17ABE3.6060003@drmicha.warpmail.net>
Michael J Gruber <git@drmicha.warpmail.net> writes:
> Andreas Schwab venit, vidit, dixit 03.12.2009 13:03:
>> Junio C Hamano <gitster@pobox.com> writes:
>>
>>> Unconditionally set man.base.url.for.relative.links
>>
>> rm -f git-add.1 && \
>> xmlto -m manpage-normal.xsl --stringparam man.base.url.for.relative.links= man git-add.xml
>> xmlto: unrecognized option '--stringparam'
>> make[1]: *** [git-add.1] Error 1
>>
>> Andreas.
>>
>
> and
>
> uname -a
> xmlto --version
>
> says?
xmlto version 0.0.18
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: [ANNOUNCE] Git 1.6.5.4
From: Michael J Gruber @ 2009-12-03 12:15 UTC (permalink / raw)
To: Andreas Schwab; +Cc: Junio C Hamano, git
In-Reply-To: <m2hbs85koj.fsf@igel.home>
Andreas Schwab venit, vidit, dixit 03.12.2009 13:03:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> Unconditionally set man.base.url.for.relative.links
>
> rm -f git-add.1 && \
> xmlto -m manpage-normal.xsl --stringparam man.base.url.for.relative.links= man git-add.xml
> xmlto: unrecognized option '--stringparam'
> make[1]: *** [git-add.1] Error 1
>
> Andreas.
>
and
uname -a
xmlto --version
says?
Michael
^ 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