* [PATCH 4/4] Make mingw-compatibility layer to be aware of I18N-wrappers
From: Timur Sufiev @ 2009-10-27 13:54 UTC (permalink / raw)
To: git; +Cc: Timur Sufiev
In-Reply-To: <1256651643-18382-3-git-send-email-timur@iris-comp.ru>
Signed-off-by: Timur Sufiev <timur@iris-comp.ru>
---
compat/fopen.c | 5 +++--
compat/mingw.c | 24 ++++++++++++++++++------
compat/mingw.h | 12 ++++++++++++
compat/mkstemps.c | 3 ++-
compat/regex/regex.c | 9 ++++++++-
compat/regex/regex.h | 3 +++
compat/win32.h | 13 +++++++++++--
io-i18n.h | 8 ++++++++
8 files changed, 65 insertions(+), 12 deletions(-)
diff --git a/compat/fopen.c b/compat/fopen.c
index b5ca142..9136a14 100644
--- a/compat/fopen.c
+++ b/compat/fopen.c
@@ -10,6 +10,7 @@
*/
#undef FREAD_READS_DIRECTORIES
#include "../git-compat-util.h"
+#include "io-i18n.h"
FILE *git_fopen(const char *path, const char *mode)
{
@@ -17,9 +18,9 @@ FILE *git_fopen(const char *path, const char *mode)
struct stat st;
if (mode[0] == 'w' || mode[0] == 'a')
- return fopen(path, mode);
+ return fopen_i18n(path, mode);
- if (!(fp = fopen(path, mode)))
+ if (!(fp = fopen_i18n(path, mode)))
return NULL;
if (fstat(fileno(fp), &st)) {
diff --git a/compat/mingw.c b/compat/mingw.c
index 6b5b5b2..9cb135a 100644
--- a/compat/mingw.c
+++ b/compat/mingw.c
@@ -253,7 +253,7 @@ int mingw_utime (const char *file_name, const struct utimbuf *times)
int fh, rc;
/* must have write permission */
- if ((fh = open(file_name, O_RDWR | O_BINARY)) < 0)
+ if ((fh = open_i18n(file_name, O_RDWR | O_BINARY, DEFAULT_OPEN_MODE)) < 0)
return -1;
time_t_to_filetime(times->modtime, &mft);
@@ -278,7 +278,7 @@ int mkstemp(char *template)
char *filename = mktemp(template);
if (filename == NULL)
return -1;
- return open(filename, O_RDWR | O_CREAT, 0600);
+ return open_i18n(filename, O_RDWR | O_CREAT, 0600);
}
int gettimeofday(struct timeval *tv, void *tz)
@@ -519,7 +519,7 @@ static const char *parse_interpreter(const char *cmd)
if (n >= 4 && !strcasecmp(cmd+n-4, ".exe"))
return NULL;
- fd = open(cmd, O_RDONLY);
+ fd = open_i18n(cmd, O_RDONLY, DEFAULT_OPEN_MODE);
if (fd < 0)
return NULL;
n = read(fd, buf, sizeof(buf)-1);
@@ -1135,10 +1135,14 @@ sig_handler_t mingw_signal(int sig, sig_handler_t handler)
static const char *make_backslash_path(const char *path)
{
static char buf[PATH_MAX + 1];
+ char *out = filename_to_local(path);
char *c;
- if (strlcpy(buf, path, PATH_MAX) >= PATH_MAX)
- die("Too long path: %.*s", 60, path);
+ if ( strlcpy(buf, out ? out : path, PATH_MAX) >= PATH_MAX) {
+ die("Too long path: %.*s", 60, out ? out : path);
+ free(out);
+ }
+ free(out);
for (c = buf; *c; c++) {
if (*c == '/')
@@ -1158,6 +1162,9 @@ int link(const char *oldpath, const char *newpath)
{
typedef BOOL (WINAPI *T)(const char*, const char*, LPSECURITY_ATTRIBUTES);
static T create_hard_link = NULL;
+ char *old_out = filename_to_local(oldpath);
+ char *new_out = filename_to_local(newpath);
+
if (!create_hard_link) {
create_hard_link = (T) GetProcAddress(
GetModuleHandle("kernel32.dll"), "CreateHardLinkA");
@@ -1168,10 +1175,15 @@ int link(const char *oldpath, const char *newpath)
errno = ENOSYS;
return -1;
}
- if (!create_hard_link(newpath, oldpath, NULL)) {
+ if (!create_hard_link(new_out ? new_out : newpath,
+ old_out ? old_out : oldpath, NULL)) {
+ free(new_out);
+ free(old_out);
errno = err_win_to_posix(GetLastError());
return -1;
}
+ free(new_out);
+ free(old_out);
return 0;
}
diff --git a/compat/mingw.h b/compat/mingw.h
index 5b5258b..0d1dc83 100644
--- a/compat/mingw.h
+++ b/compat/mingw.h
@@ -1,5 +1,16 @@
+#ifndef GIT_MINGW_H
+#define GIT_MINGW_H
#include <winsock2.h>
+/* 3 following lines are taken from io-i18n.h because we cannot
+ include it here: if we do so, readdir_i18n prototype will
+ be inconsistent with with other code which properly uses all
+ mingw defines
+*/
+char *filename_to_local (const char* filename);
+int open_i18n(const char *filename, int flags, mode_t mode);
+#define DEFAULT_OPEN_MODE 0
+
/*
* things that are not available in header files
*/
@@ -273,3 +284,4 @@ struct mingw_dirent
#define readdir(x) mingw_readdir(x)
struct dirent *mingw_readdir(DIR *dir);
#endif // !NO_MINGW_REPLACE_READDIR
+#endif // GIT_MINGW_H
diff --git a/compat/mkstemps.c b/compat/mkstemps.c
index 14179c8..0cdd42d 100644
--- a/compat/mkstemps.c
+++ b/compat/mkstemps.c
@@ -1,4 +1,5 @@
#include "../git-compat-util.h"
+#include "../io-i18n.h"
/* Adapted from libiberty's mkstemp.c. */
@@ -47,7 +48,7 @@ int gitmkstemps(char *pattern, int suffix_len)
template[4] = letters[v % num_letters]; v /= num_letters;
template[5] = letters[v % num_letters]; v /= num_letters;
- fd = open(pattern, O_CREAT | O_EXCL | O_RDWR, 0600);
+ fd = open_i18n(pattern, O_CREAT | O_EXCL | O_RDWR, 0600);
if (fd > 0)
return fd;
/*
diff --git a/compat/regex/regex.c b/compat/regex/regex.c
index 67d5c37..2deec55 100644
--- a/compat/regex/regex.c
+++ b/compat/regex/regex.c
@@ -450,8 +450,15 @@ static int debug = 0;
#define DEBUG_PRINT_DOUBLE_STRING(w, s1, sz1, s2, sz2) \
if (debug) print_double_string (w, s1, sz1, s2, sz2)
-
+#ifdef __USE_MINGW_ACCESS
+void
+ printchar(char c)
+{
+ putc(c, stderr);
+}
+#else
extern void printchar ();
+#endif // __USE_MINGW_ACCESS
/* Print the fastmap in human-readable form. */
diff --git a/compat/regex/regex.h b/compat/regex/regex.h
index 6eb64f1..a5f2809 100644
--- a/compat/regex/regex.h
+++ b/compat/regex/regex.h
@@ -29,6 +29,9 @@
#include <stddef.h>
#endif
+#ifdef __USE_MINGW_ACCESS
+#include <conio.h>
+#endif
/* The following bits are used to determine the regexp syntax we
recognize. The set/not-set meanings are chosen so that Emacs syntax
diff --git a/compat/win32.h b/compat/win32.h
index 8ce9104..f71e36d 100644
--- a/compat/win32.h
+++ b/compat/win32.h
@@ -20,8 +20,17 @@ static inline int file_attr_to_st_mode (DWORD attr)
static inline int get_file_attr(const char *fname, WIN32_FILE_ATTRIBUTE_DATA *fdata)
{
- if (GetFileAttributesExA(fname, GetFileExInfoStandard, fdata))
- return 0;
+ char *out = filename_to_local(fname);
+ int ret;
+
+ if ( out != NULL ) {
+ ret = GetFileAttributesExA(out, GetFileExInfoStandard, fdata);
+ free(out);
+ } else
+ ret = GetFileAttributesExA(fname, GetFileExInfoStandard, fdata);
+
+ if ( ret )
+ return 0;
switch (GetLastError()) {
case ERROR_ACCESS_DENIED:
diff --git a/io-i18n.h b/io-i18n.h
index c386e20..7329105 100644
--- a/io-i18n.h
+++ b/io-i18n.h
@@ -6,6 +6,14 @@
#include <sys/stat.h>
#include <dirent.h>
#include <stdio.h>
+#include <limits.h>
+
+#ifdef __USE_MINGW_ACCESS
+#include <windows.h>
+#define NAME_MAX MAX_PATH
+#define stat _stati64
+#define dirent mingw_dirent
+#endif
#define DEFAULT_OPEN_MODE 0
--
1.6.5.1
^ permalink raw reply related
* [PATCH 1/4] Add routines for filenames encoding <local encoding> <-> UTF-8
From: Timur Sufiev @ 2009-10-27 13:54 UTC (permalink / raw)
To: git; +Cc: Timur Sufiev
The point is to make Git aware of filenames local encoding and make it
keep all filenames in UTF-8 internally. If
`i18n.filenameslocalencoding' option was set via git-config to a
correct <codepage> encoding, 2 things should be done:
1. Translate all filenames read by READDIR from <codepage> into UTF-8.
2. Translate all filenames passed to IO-routines from UTF-8 into
<codepage>.
Signed-off-by: Timur Sufiev <timur@iris-comp.ru>
---
cache.h | 1 +
config.c | 3 ++
environment.c | 1 +
io-i18n.c | 82 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++
4 files changed, 87 insertions(+), 0 deletions(-)
create mode 100644 io-i18n.c
diff --git a/cache.h b/cache.h
index 96840c7..7f19f7a 100644
--- a/cache.h
+++ b/cache.h
@@ -919,6 +919,7 @@ extern int user_ident_explicitly_given;
extern const char *git_commit_encoding;
extern const char *git_log_output_encoding;
+extern const char *git_filenames_local_encoding;
extern const char *git_mailmap_file;
/* IO helper functions */
diff --git a/config.c b/config.c
index c644061..2be6531 100644
--- a/config.c
+++ b/config.c
@@ -539,6 +539,9 @@ static int git_default_i18n_config(const char *var, const char *value)
if (!strcmp(var, "i18n.logoutputencoding"))
return git_config_string(&git_log_output_encoding, var, value);
+ if (!strcmp(var, "i18n.filenameslocalencoding"))
+ return git_config_string(&git_filenames_local_encoding, var, value);
+
/* Add other config variables here and to Documentation/config.txt. */
return 0;
}
diff --git a/environment.c b/environment.c
index 5de6837..b101f7b 100644
--- a/environment.c
+++ b/environment.c
@@ -24,6 +24,7 @@ int warn_ambiguous_refs = 1;
int repository_format_version;
const char *git_commit_encoding;
const char *git_log_output_encoding;
+const char *git_filenames_local_encoding;
int shared_repository = PERM_UMASK;
const char *apply_default_whitespace;
const char *apply_default_ignorewhitespace;
diff --git a/io-i18n.c b/io-i18n.c
new file mode 100644
index 0000000..4dcc2db
--- /dev/null
+++ b/io-i18n.c
@@ -0,0 +1,82 @@
+#include "utf8.h"
+#include "cache.h"
+
+inline static int is_string_ascii(const char *str)
+{
+ int is_ascii = 1;
+
+ for (; *str && is_ascii; str++)
+ is_ascii &= isascii(*str);
+
+ return is_ascii;
+}
+
+static char *filename_to_utf8(const char *filename)
+{
+ char *out;
+
+ if (is_string_ascii(filename))
+ return NULL;
+
+#ifndef NO_ICONV
+ if (git_filenames_local_encoding && !is_utf8(filename)) {
+ out = reencode_string(filename,
+ "utf-8", git_filenames_local_encoding);
+#ifdef DEBUG_I18N
+ fprintf(stderr, "Local -> UTF8 encoding: <%s> -> <%s>\n",
+ filename, out);
+#endif
+ return out;
+ } else if (git_filenames_local_encoding && is_utf8(filename)) {
+#ifdef DEBUG_I18N
+ fprintf(stderr,
+ "Filename <%s> is already utf8-encoded, doing nothing...\n",
+ filename);
+#endif
+ return NULL;
+ } else {
+#ifdef DEBUG_I18N
+ fprintf(stderr, "No local encoding set, doing nothing...\n");
+#endif
+ return NULL;
+ }
+#else /* #ifdef NO_ICONV */
+ warning("No iconv support, doing nothing...\n");
+ return NULL;
+#endif
+}
+
+char *filename_to_local(const char *filename)
+{
+ char *out;
+
+ if (is_string_ascii(filename))
+ return NULL;
+
+#ifndef NO_ICONV
+ if (git_filenames_local_encoding && is_utf8(filename)) {
+ out = reencode_string(filename,
+ git_filenames_local_encoding, "utf-8");
+#ifdef DEBUG_I18N
+ fprintf(stderr, "UTF8 -> local encoding: <%s> -> <%s>\n",
+ filename, out);
+#endif
+ return out;
+ } else if (git_filenames_local_encoding && !is_utf8(filename)) {
+#ifdef DEBUG_I18N
+ fprintf(stderr,
+ "Filename <%s> is already local-encoded, doing nothing...\n",
+ filename);
+#endif
+ return NULL;
+ } else {
+#ifdef DEBUG_I18N
+ fprintf(stderr, "No local encoding set, doing nothing...\n");
+#endif
+ return NULL;
+ }
+#else /* #ifdef NO_ICONV */
+ warning("No iconv support, doing nothing...\n");
+ return NULL;
+#endif
+}
--
1.6.5.1
^ permalink raw reply related
* Re: Getting Ensimag students to work on Git for a few weeks
From: Johannes Schindelin @ 2009-10-27 13:59 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <vpqocntxhzv.fsf@bauges.imag.fr>
Hi,
On Tue, 27 Oct 2009, Matthieu Moy wrote:
> I'd like to propose a kind of mini-google summer of code to the students
> of the the school where I teach, i.e. Ensimag, France (
> http://ensimag.grenoble-inp.fr/ ). In short, this means having a few
> students working for Git for a month at no cost ;-).
Do not underestimate the cost of time and nerves, both on the student's
and the mentor's part.
I spent an insane amount of time on the Google Summer of Code this year,
a relatively small (but not less frustrating) part of which was with Git.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 2/2] git-completion.bash: prevent 'git help' from searching for git repository
From: Gerrit Pape @ 2009-10-27 13:30 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <20090904110936.6663.qmail@046e1bfbf7e41d.315fe32.mid.smarden.org>
Hi Junio, I suggest to apply this patch from Johannes to master.
Thanks, Gerrit.
On Fri, Sep 04, 2009 at 11:09:36AM +0000, Gerrit Pape wrote:
> On Fri, Sep 04, 2009 at 12:22:36PM +0200, Johannes Schindelin wrote:
> > -- snipsnap --
> > [PATCH] git help -a: do not look for a repository
>
> Perfect, thanks.
>
> Acked-by: Gerrit Pape <pape@smarden.org>
>
> > Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
> >
> > ---
> >
> > builtin-help.c | 6 +++---
> > 1 files changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/builtin-help.c b/builtin-help.c
> > index e1eba77..719aa23 100644
> > --- a/builtin-help.c
> > +++ b/builtin-help.c
> > @@ -416,9 +416,6 @@ int cmd_help(int argc, const char **argv, const char *prefix)
> > const char *alias;
> > load_command_list("git-", &main_cmds, &other_cmds);
> >
> > - setup_git_directory_gently(&nongit);
> > - git_config(git_help_config, NULL);
> > -
> > argc = parse_options(argc, argv, prefix, builtin_help_options,
> > builtin_help_usage, 0);
> >
> > @@ -429,6 +426,9 @@ int cmd_help(int argc, const char **argv, const char *prefix)
> > return 0;
> > }
> >
> > + setup_git_directory_gently(&nongit);
> > + git_config(git_help_config, NULL);
> > +
> > if (!argv[0]) {
> > printf("usage: %s\n\n", git_usage_string);
> > list_common_cmds_help();
> > --
> > To unsubscribe from this list: send the line "unsubscribe git" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] help -i: properly error out if no info viewer can be found
From: Gerrit Pape @ 2009-10-27 13:31 UTC (permalink / raw)
To: Junio C Hamano, git
With this commit, git help -i <cmd> prints an error message and exits
non-zero instead of being silent and exit code 0.
Reported by Trent W. Buck through
http://bugs.debian.org/537664
Signed-off-by: Gerrit Pape <pape@smarden.org>
---
builtin-help.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/builtin-help.c b/builtin-help.c
index e1eba77..e1ade8e 100644
--- a/builtin-help.c
+++ b/builtin-help.c
@@ -372,6 +372,7 @@ static void show_info_page(const char *git_cmd)
const char *page = cmd_to_page(git_cmd);
setenv("INFOPATH", system_path(GIT_INFO_PATH), 1);
execlp("info", "info", "gitman", page, NULL);
+ die("no info viewer handled the request");
}
static void get_html_page_path(struct strbuf *page_path, const char *page)
--
1.6.5.2
^ permalink raw reply related
* Re: Autodiscovery of git repositories from HTML
From: Jan Krüger @ 2009-10-27 13:32 UTC (permalink / raw)
To: Thomas Thurman; +Cc: git
In-Reply-To: <20091027130000.GX30085@Dorothy.plexq.com>
> I have a web page which lives in a git repository so that it can be
> easily mirrored. I would like to use a "rel" link to the URL of the
> git repository so that it can be automatically discovered, like an
> RSS feed:
>
> <link rel="alternate" type="???" href="http://example.com/.git"/>
>
> Is there any existing convention as to what the type should be?
I don't think there is any such convention, since I don't think anyone
has done this before (but it would have interesting use cases).
Actually, I don't think rel="alternate" describes the relation well; a
repository isn't exactly an alternate version of the document.
If we don't care about the standard, we might want to use something like
the widely used rel="shortcut icon", e.g. rel="git repository".
Jan
^ permalink raw reply
* Re: Autodiscovery of git repositories from HTML
From: Jakub Narebski @ 2009-10-27 13:28 UTC (permalink / raw)
To: Thomas Thurman; +Cc: git
In-Reply-To: <20091027130000.GX30085@Dorothy.plexq.com>
Thomas Thurman <tthurman@gnome.org> writes:
> I have a web page which lives in a git repository so that it can be
> easily mirrored. I would like to use a "rel" link to the URL of the git
> repository so that it can be automatically discovered, like an RSS feed:
>
> <link rel="alternate" type="???" href="http://example.com/.git"/>
>
> Is there any existing convention as to what the type should be?
> Note that this isn't necessarily the same question as what a git
> repository should be served as over HTTP: the Universal Edit Button uses
> a dummy MIME type of "application/x-wiki".
See proposal at http://joey.kitenet.net/rfc/rel-vcs/
(which use 'rel' microformat, rather than 'type' microformat).
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Autodiscovery of git repositories from HTML
From: Thomas Thurman @ 2009-10-27 13:00 UTC (permalink / raw)
To: git
I have a web page which lives in a git repository so that it can be
easily mirrored. I would like to use a "rel" link to the URL of the git
repository so that it can be automatically discovered, like an RSS feed:
<link rel="alternate" type="???" href="http://example.com/.git"/>
Is there any existing convention as to what the type should be?
Note that this isn't necessarily the same question as what a git
repository should be served as over HTTP: the Universal Edit Button uses
a dummy MIME type of "application/x-wiki".
Thomas
--
Thomas Thurman - thomas at thurman.org.uk - http://marnanel.org
What if a dragon stole your library books? http://borrowable.net
^ permalink raw reply
* [PATCH] rebase -i: more graceful handling of invalid commands
From: Jan Krüger @ 2009-10-27 12:39 UTC (permalink / raw)
To: kusmabite; +Cc: Git Mailing List
In-Reply-To: <40aa078e0910270313j5dc68576v86a3947f0dc7f9f@mail.gmail.com>
Currently, when there is an invalid command, the rest of the line is
still treated as if the command had been valid, i.e. rebase -i attempts
to produce a patch, using the next argument as a SHA1 name. If there is
no next argument or an invalid one, very confusing error messages
appear (the line was '.'; path to git-rebase-todo substituted):
Unknown command: .
fatal: ambiguous argument 'Please fix this in the file $somefile.':
unknown revision or path not in the working tree.
Use '--' to separate paths from revisions
fatal: Not a valid object name Please fix this in the file $somefile.
fatal: bad revision 'Please fix this in the file $somefile.'
Instead, verify the validity of the remaining line and error out earlier
if necessary.
Signed-off-by: Jan Krüger <jk@jk.gs>
---
> I recently came over a not-overly-helpful error in git rebase -i, when
> a line got wrapped by the editor so that a part of the commit-message
> was interpreted as a command:
Here is a suggested fix.
git-rebase--interactive.sh | 7 ++++++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index a1879e3..fdd8eb6 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -416,7 +416,12 @@ do_next () {
;;
*)
warn "Unknown command: $command $sha1 $rest"
- die_with_patch $sha1 "Please fix this in the file $TODO."
+ if git rev-parse --verify -q "$sha" >/dev/null
+ then
+ die_with_patch $sha1 "Please fix this in the file $TODO."
+ else
+ die "Please fix this in the file $TODO."
+ fi
;;
esac
test -s "$TODO" && return
--
1.6.5.rc1
^ permalink raw reply related
* Re: date change of commit?
From: Miklos Vajna @ 2009-10-27 12:21 UTC (permalink / raw)
To: Alex K; +Cc: Matthieu Moy, git
In-Reply-To: <e4a904790910270241g4a165023o30438c5d000b5de4@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 428 bytes --]
On Tue, Oct 27, 2009 at 10:41:47AM +0100, Alex K <spaceoutlet@gmail.com> wrote:
> Thank you. And how would you use git-filter-branch to create another
> branch with a different time stamp? Is it possible to commit under a
> different time stamp than the one provided by your default local time?
You can set GIT_AUTHOR_DATE and GIT_COMMITTER_DATE. Both expect a format
like: "1112911993 -0700" (unix timestamp + timezone info).
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] Fix resource leaks in wrapper.c
From: Michael J Gruber @ 2009-10-27 11:44 UTC (permalink / raw)
To: Laszlo Papp; +Cc: Johannes Sixt, Laszlo Papp, git
In-Reply-To: <a362e8010910270335g106024e6if3f016c271ab55d6@mail.gmail.com>
Laszlo Papp venit, vidit, dixit 27.10.2009 11:35:
>
>
> On Tue, Oct 27, 2009 at 9:26 AM, Michael J Gruber
> <git@drmicha.warpmail.net <mailto:git@drmicha.warpmail.net>> wrote:
>
> Johannes Sixt venit, vidit, dixit 27.10.2009 08:13:
> > Laszlo Papp schrieb:
> >> @@ -266,7 +266,7 @@ int odb_mkstemp(char *template, size_t limit,
> const char *pattern)
> >> fd = mkstemp(template);
> >> if (0 <= fd)
> >> return fd;
> >> -
> >> + close(fd);
> >
> > Sorry, where is here a resource leak? You are "closing" something
> that was
> > never opened because fd is less than zero.
> >
> > Ditto for the other case.
>
> I guess it's about silencing some challenged code analysis tool. I
> recall that last time we had something like this we decided that coders
> are smarter than tools... and also that clean up like this (for real
> leaks) would be something for libgit.
>
> Michael
>
>
> Yeah you're rights guys, sorry for my fault, this cppcheck program is
> not the best at this momment, really sorry.
No need to feel overly sorry, but in general it helps if, in a commit
message or thereabout, you say something like "cppcheck found the
following (potential) errors".
Cheers,
Michael
^ permalink raw reply
* Re: [PATCHv3 0/3] git-gui: more robust handling of fancy repos
From: Bert Wesarg @ 2009-10-27 11:35 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git, Markus Heidelberg, Shawn O. Pearce
In-Reply-To: <1250467128-29839-1-git-send-email-giuseppe.bilotta@gmail.com>
On Mon, Aug 17, 2009 at 00:58, Giuseppe Bilotta
<giuseppe.bilotta@gmail.com> wrote:
> As promised a long time ago (March 30), version 3 of the small patchset
> to improve handling of repositories in git gui. The most significant
> change is the addition of the third patch.
>
> The first patch allows git gui to work with respotiories for which
> the worktree is not the parent of the gitdir.
>
> The second patch refactors bare repository detection, improves the error
> message if the bare support feature is disabled, and disabled
> inapplicable menu entries.
>
> The third patch allows git-gui to work properly when launched from the
> .git directory itself, solving the issue Markus Heidelberg was having in
> http://thread.gmane.org/gmane.comp.version-control.git/115044
>
> Giuseppe Bilotta (3):
> git-gui: handle non-standard worktree locations
> git-gui: handle bare repos correctly
> git-gui: work from the .git dir
What is the state of this patch, I can't find it applied.
I would also suggest to always export GIT_DIR into the environment, so
that guitools can relay on this.
Regards,
Bert
^ permalink raw reply
* [PATCH] Do not try to remove directories when removing old links
From: Sebastian Schuberth @ 2009-10-27 11:23 UTC (permalink / raw)
To: git
When building Git with MSVC on Windows, directories named after the Git alias
are created for the output files, e.g. there is a "git-merge-index" directory
next to the "git-merge-index.exe" executable in the build root. Previously,
"make all" just checked if "git-merge-index" and "git-merge-index.exe" are the
same file, and if not, tried to remove "git-merge-index". This fails in the
case of "git-merge-index" being a directory, which is why this is checked now.
Signed-off-by: Sebastian Schuberth <sschuberth@gmail.com>
---
Makefile | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
index 42b7d60..268aede 100644
--- a/Makefile
+++ b/Makefile
@@ -1375,7 +1375,7 @@ SHELL = $(SHELL_PATH)
all:: shell_compatibility_test $(ALL_PROGRAMS) $(BUILT_INS) $(OTHER_PROGRAMS) GIT-BUILD-OPTIONS
ifneq (,$X)
- $(QUIET_BUILT_IN)$(foreach p,$(patsubst %$X,%,$(filter %$X,$(ALL_PROGRAMS) $(BUILT_INS) git$X)), test '$p' -ef '$p$X' || $(RM) '$p';)
+ $(QUIET_BUILT_IN)$(foreach p,$(patsubst %$X,%,$(filter %$X,$(ALL_PROGRAMS) $(BUILT_INS) git$X)), test -d '$p' -o '$p' -ef '$p$X' || $(RM) '$p';)
endif
all::
--
1.6.5.rc2.13.g1be2
^ permalink raw reply related
* Making Git easy to use -- without RTFM, was Re: [PATCH] Proof-of-concept patch to remember what the detached HEAD was
From: Johannes Schindelin @ 2009-10-27 10:33 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: git
In-Reply-To: <20091027124156.6117@nanako3.lavabit.com>
Hi,
[culling the Cc: list, as this subthread is probably irrelevant most of
the previous members]
On Tue, 27 Oct 2009, Nanako Shiraishi wrote:
> Quoting Johannes Schindelin <Johannes.Schindelin@gmx.de>
>
> [actually not, Nanako quoted Junio here, I guess]
>
> > I suspect the above is another example of your needing to do a better
> > job explaining yourself here, but from "just commit all the changes
> > without saying message", my knee-jerk reaction is "git commit -a -m
> > 'no message'".
>
> > You would need to justify why -m 'no message' does not fit the bill
> > better than just saying "is very sensible to ask for these things", as
> > I highly suspect that I misunderstood what "these things" are in your
> > five lines to come up with that "solution" that you are now going to
> > explain why that is not what the end user wanted. And in this case, I
> > do not think it is that me being disconnected from the real world, but
> > that your explanation is insufficient.
>
> I'm also curious about the situation when a commit with no message is
> useful, but unfortunately I don't think I saw you explained clearly
> enough what this user request wanted to achieve or what "these things"
> in your message were for us to understand why it is a sensible and valid
> thing to ask.
I am sure that your creative mind does not need my concrete example to
come up with a situation where an empty commit message is useful.
Anyhow, here it is: one of my users refused to touch SCMs _at all_, for
decades. There was only one choice: have a Git branch with a purely
linear history that contains the copy of the working tree at the end of
the day, with whatever changes accumulated over the day, or no history at
all.
Sure, some people will now argue that it should be easy to educate that
user to use Git properly. But that is as naive as it would be to try to
educate those people so they know how unrealistic educating users is.
Not because users are not intelligent -- they are -- but because they want
to spend their time in a more efficient manner than to learn how to
operate a version control system.
You know, when there is a hurdle half of the people you see cannot get
over, there are some who make the hurdle half as high, and there are
others who put more hurdles there and call it a sport.
In this case, I would have preferred to make the hurdle half as high, but
I think I just have to wait a couple of years; reality will take care of
things.
Ciao,
Dscho
^ permalink raw reply
* From 200 to 404 to 407.
From: Peter Odéus @ 2009-10-27 10:18 UTC (permalink / raw)
To: git
Hi,
Doing a "git clone..." using authenticated proxy (set in $http_proxy):
Upon initial success (HTTP 200) and receiving a single HTTP 404 (not
found), every GET after that renders a HTTP 407 (Proxy authentication
required).
curl -I "url_giving_http_407" comes out just fine as a HTTP 200.
Bug or just me?
^ permalink raw reply
* possible usability issue in rebase -i?
From: Erik Faye-Lund @ 2009-10-27 10:13 UTC (permalink / raw)
To: Git Mailing List
I recently came over a not-overly-helpful error in git rebase -i, when
a line got wrapped by the editor so that a part of the commit-message
was interpreted as a command:
---
$ git rebase -i HEAD~20
<edit file>
Unknown command: .
fatal: ambiguous argument 'Please fix this in the file C:/msysgit/git/.git/rebas
e-merge/git-rebase-todo.': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions
fatal: Not a valid object name Please fix this in the file C:/msysgit/git/.git/r
ebase-merge/git-rebase-todo.
fatal: bad revision 'Please fix this in the file C:/msysgit/git/.git/rebase-merg
e/git-rebase-todo.'
$ git --version
git version 1.6.5.1386.g43a7a.dirty
---
In this particular case, the first character on the new line was '.',
so the first line of the error message makes perfect sense, but the
lines that followed the real error got me pretty confused. Perhaps
this is something that could be cleaned away? I'd think that an
unknown command always should be fatal, and not need to propagate
further. But I might be wrong, as I'm not familiar with the inner
workings of rebase -i.
--
Erik "kusma" Faye-Lund
^ permalink raw reply
* Getting Ensimag students to work on Git for a few weeks
From: Matthieu Moy @ 2009-10-27 10:12 UTC (permalink / raw)
To: git
Hi,
I'd like to propose a kind of mini-google summer of code to the
students of the the school where I teach, i.e. Ensimag, France
( http://ensimag.grenoble-inp.fr/ ). In short, this means having a few
students working for Git for a month at no cost ;-).
Currently, the students have an end-of-year project (in equivalent of
master 1) with the choice between many subjects, some of them being
somehow "real-life" (i.e. actually usefull things), and other being
artificial (i.e. enjoy doing it, and throw it away afterwards).
This year, I'd like to propose a subject "contribution to an existing
free software", and since the one I know best currently is Git, this
would take the form of "contribution to the Git project". I'd see the
practical organization a bit like the google summer of code: chose a
feature (the GSoC proposals on the wiki can be a good source of
inspiration), and implement it with the goal of being eventually
merged upstream. There would be no money involved, but the students
get a grade at the end. I would anyway follow the work of the
students, but a co-mentoring from a Git expert would be great.
The students work full-time for about 3 weeks (May 20th to June 16th),
and are grouped by teams of 2 to 4 students. Given my bandwidth, I
plan to propose only one group of 4 students this year, but we may
scale up later, who knows.
We have plenty of time before this starts, but I'm just sending this
email to get your feeling on it.
Any opinion? Do you like the idea?
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: more fancy ignoring of files ('if' in .gitignore?)
From: Paolo Bonzini @ 2009-10-27 10:00 UTC (permalink / raw)
To: Sebastian Schubert; +Cc: git
In-Reply-To: <200910271030.54571.schubert.seb@googlemail.com>
On 10/27/2009 10:30 AM, Sebastian Schubert wrote:
> Hi,
>
> I would like to ignore files if certain other files are present. In my
> special case, I want to ignore foo.pdf and foo.eps if foo.fig is
> present (both pdf and eps are generated on the fly but don't belong
> into repository). In general, I do NOT want to ignore pdf or eps. There
> are a lot of foos so I would like to have a general solution.
>
> Is this possible?
I suggesting adding to your makefile a rule like
.gitignore: $(wildcard *.fig)
(grep -ve \.pdf$ \.eps$ .gitignore;
for i in $^; do echo $i; done | \
sed -n 's/fig$/eps/p; s/eps$/pdf/p') > .gitignore.tmp
mv .gitignore.tmp .gitignore
Paolo
^ permalink raw reply
* Re: more fancy ignoring of files ('if' in .gitignore?)
From: Michael J Gruber @ 2009-10-27 9:56 UTC (permalink / raw)
To: Sebastian Schubert; +Cc: git
In-Reply-To: <200910271030.54571.schubert.seb@googlemail.com>
Sebastian Schubert venit, vidit, dixit 27.10.2009 10:30:
> Hi,
>
> I would like to ignore files if certain other files are present. In my
> special case, I want to ignore foo.pdf and foo.eps if foo.fig is
> present (both pdf and eps are generated on the fly but don't belong
> into repository). In general, I do NOT want to ignore pdf or eps. There
> are a lot of foos so I would like to have a general solution.
>
> Is this possible?
No.
You can script around it by making e.g. your build process (which
generated pdf/eps from fig) add a specific foo.pdf etc to .gitignore.
In fact, at the the time you add a fig to your repo you should add (&
commit) corresponding lines to .gitignore. This is the common approach.
Alternatively, you can update your ignore with
rm -f .gitignore;find . -name \*.fig | while read i;do echo -e
${i%fig}pdf "\n" ${i%fig}eps >>.gitignore;done
if you have no other ignore patterns in there. (This is q&d, adjust if
you have spaces in file names or such.)
Michael
^ permalink raw reply
* Re: date change of commit?
From: Alex K @ 2009-10-27 9:41 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <vpq1vkrqttt.fsf@bauges.imag.fr>
Thank you. And how would you use git-filter-branch to create another
branch with a different time stamp? Is it possible to commit under a
different time stamp than the one provided by your default local time?
2009/10/25 Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>:
> Alex K <spaceoutlet@gmail.com> writes:
>
>> Hello,
>>
>> Is it possible to change the date of a commit?
>
> See git-filter-branch. This won't change the date of the existing
> commit (which is impossible in Git), but will create another commit
> where only the date has been changed.
>
> --
> Matthieu Moy
> http://www-verimag.imag.fr/~moy/
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* more fancy ignoring of files ('if' in .gitignore?)
From: Sebastian Schubert @ 2009-10-27 9:30 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 440 bytes --]
Hi,
I would like to ignore files if certain other files are present. In my
special case, I want to ignore foo.pdf and foo.eps if foo.fig is
present (both pdf and eps are generated on the fly but don't belong
into repository). In general, I do NOT want to ignore pdf or eps. There
are a lot of foos so I would like to have a general solution.
Is this possible?
Cheers
Sebastian
PS: Please CC my personal email address.
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: git update --prune issue
From: Michael J Gruber @ 2009-10-27 8:42 UTC (permalink / raw)
To: Jeffrey Middleton; +Cc: git
In-Reply-To: <4389ce950910261508p7eca354el77bad07305a80952@mail.gmail.com>
Jeffrey Middleton venit, vidit, dixit 26.10.2009 23:08:
> I have an unreliable problem when using "git remote update --prune".
> git claims that many refs from a particular remote do not point to a
> valid object, but only after finishing another update. I've included
> a shortened version of the output from one particular instance of the
> issue. Note that the errors are printed for every subsequent remote
> as well. However, after the update is completed, everything is fine.
>
> It seems to only happen when there are non-fast-forward changes (new
> branch, forced update, pruned branch). The issue only happens with
> this particular remote, which I've tried removing and recreating, and
> is the same type of remote as all my others (another user's
> NFS-mounted home directory). However, my remotes are all individual
> developers, and this developer is the only one who ever rebases her
> working branches. (recloning the repo from origin and setting up my
> config and remotes all over again has also had no effect)
>
> Unfortunately, I have been unable to reproduce the problem in any test
> repos - for example, though a forced update and a pruned branch in the
> problematic remote along with an update in another remote seems to
> fairly reliably produce the problem in this repo, recreating that
> situation in another repo doesn't cause any problems. Sorry for the
> incomplete bug report, but perhaps this will be enough to go on!
>
> Thanks,
> Jeffrey
>
>
> I've seen the issue in previous versions built from git.git master, as
> well as v1.6.3.3, but for this particular one:
>
> $ git --version
> git version 1.6.5.1.61.ge79999
>
> $ git remote update --prune
> Updating origin
> remote: Counting objects: 42, done.
> remote: Compressing objects: 100% (9/9), done.
> remote: Total 15 (delta 9), reused 12 (delta 6)
> Unpacking objects: 100% (15/15), done.
> From /users/cxtfcm/CxTF_DB
> 88b8613..d40f26d 2009.Q4 -> origin/2009.Q4
> d40f26d..56305b8 dev -> origin/dev
> Updating steph
> remote: Counting objects: 299, done.
> remote: Compressing objects: 100% (241/241), done.
> remote: Total 276 (delta 186), reused 19 (delta 6)
> Receiving objects: 100% (276/276), 41.09 KiB | 10 KiB/s, done.
> Resolving deltas: 100% (186/186), completed with 17 local objects.
> From /users/sdewet/CxTF_DEV/CxTF_DB
> + c2439dd...69cb5c3 beta_gc_dev -> steph/beta_gc_dev (forced update)
> + fb25173...f0e4963 beta_veh_dev -> steph/beta_veh_dev (forced update)
> * [new branch] beta_veh_dev_old -> steph/beta_veh_dev_old
> Pruning steph
> URL: /users/sdewet/CxTF_DEV/CxTF_DB/
> * [pruned] steph/beta_gc_dev_old
> Updating kevin
> error: refs/remotes/steph/beta_gc_dev does not point to a valid object!
> error: refs/remotes/steph/beta_veh_dev does not point to a valid object!
> Updating jose
> error: refs/remotes/steph/beta_gc_dev does not point to a valid object!
> error: refs/remotes/steph/beta_veh_dev does not point to a valid object!
> ### many more remotes with the same errors ###
Do you get the same problem if you do the steps individually, i.e.:
git remote update steph
git remote prune steph
git remote update kevin
Does it depend on the order, i.e.:
git remote update steph
git remote update kevin
git remote prune steph
Does "git fsck --full" say anything special?
Michael
^ permalink raw reply
* Re: [PATCH] Fix resource leaks in wrapper.c
From: Michael J Gruber @ 2009-10-27 8:26 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Laszlo Papp, git, Laszlo Papp
In-Reply-To: <4AE69DA7.6030704@viscovery.net>
Johannes Sixt venit, vidit, dixit 27.10.2009 08:13:
> Laszlo Papp schrieb:
>> @@ -266,7 +266,7 @@ int odb_mkstemp(char *template, size_t limit, const char *pattern)
>> fd = mkstemp(template);
>> if (0 <= fd)
>> return fd;
>> -
>> + close(fd);
>
> Sorry, where is here a resource leak? You are "closing" something that was
> never opened because fd is less than zero.
>
> Ditto for the other case.
I guess it's about silencing some challenged code analysis tool. I
recall that last time we had something like this we decided that coders
are smarter than tools... and also that clean up like this (for real
leaks) would be something for libgit.
Michael
^ permalink raw reply
* Re: git-svn: add support for merges during 'git svn fetch'
From: Eric Wong @ 2009-10-27 7:14 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Junio C Hamano, Sam Vilain, git
In-Reply-To: <20091027124056.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> wrote:
> Quoting Eric Wong <normalperson@yhbt.net>
> > Sam Vilain <sam.vilain@catalyst.net.nz> wrote:
> >> This series adds support for converting SVN merges - in the two
> >> popular formats, SVK and SVN 1.5+, into git parents.
> >
> > Thanks Sam,
> >
> > There's a couple of whitespace issues with lines being too long (using 8
> > character wide tabs). Otherwise I'm happy to Ack and get them out for
> > more testing/exposure; especially since I'm unlikely to exercise the
> > functionality myself[1] and doesn't appear to break anything.
> >
> > Thanks again.
>
> What is the status of this series and what should happen now?
>
> Will Eric add his Ack and send you a pull request, or will you fix
> them up, forge Eric's Ack and start cooking in your 'next' branch?
Thanks for the ping, I got sidetracked and forgot about this. I've
fixed up minor formatting details, acked and pushed out Sam's changes to
git://git.bogomips.org/git-svn along with one I small fix I originally
sent out a bad patch for.
Eric Wong (1):
git svn: fix fetch where glob is on the top-level URL
Sam Vilain (5):
git-svn: add test data for SVK merge, with script.
git-svn: allow test setup script to support PERL env. var
git-svn: convert SVK merge tickets to extra parents
git-svn: add test data for SVN 1.5+ merge, with script.
git-svn: convert SVN 1.5+ / svnmerge.py svn:mergeinfo props to parents
(tests pass on the same box where I have my latest code this time :)
--
Eric Wong
^ permalink raw reply
* Re: [PATCH] Fix resource leaks in wrapper.c
From: Johannes Sixt @ 2009-10-27 7:13 UTC (permalink / raw)
To: Laszlo Papp; +Cc: git, Laszlo Papp
In-Reply-To: <1256615635-4940-1-git-send-email-djszapi@archlinux.us>
Laszlo Papp schrieb:
> @@ -266,7 +266,7 @@ int odb_mkstemp(char *template, size_t limit, const char *pattern)
> fd = mkstemp(template);
> if (0 <= fd)
> return fd;
> -
> + close(fd);
Sorry, where is here a resource leak? You are "closing" something that was
never opened because fd is less than zero.
Ditto for the other case.
-- Hannes
^ 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