* 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
* [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
* 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
* 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: 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
* [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
* 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
* 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
* 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
* [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: [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
* 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
* [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
* [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 2/4] Add I18N-wrappers for low-level IO-routines
From: Timur Sufiev @ 2009-10-27 13:54 UTC (permalink / raw)
To: git; +Cc: Timur Sufiev
In-Reply-To: <1256651643-18382-1-git-send-email-timur@iris-comp.ru>
Signed-off-by: Timur Sufiev <timur@iris-comp.ru>
---
Makefile | 2 +
io-i18n.c | 129 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
io-i18n.h | 23 +++++++++++
3 files changed, 154 insertions(+), 0 deletions(-)
create mode 100644 io-i18n.h
diff --git a/Makefile b/Makefile
index 42b7d60..ac8e807 100644
--- a/Makefile
+++ b/Makefile
@@ -459,6 +459,7 @@ LIB_H += tree-walk.h
LIB_H += unpack-trees.h
LIB_H += userdiff.h
LIB_H += utf8.h
+LIB_H += io-i18n.h
LIB_H += wt-status.h
LIB_OBJS += abspath.o
@@ -562,6 +563,7 @@ LIB_OBJS += unpack-trees.o
LIB_OBJS += usage.o
LIB_OBJS += userdiff.o
LIB_OBJS += utf8.o
+LIB_OBJS += io-i18n.o
LIB_OBJS += walker.o
LIB_OBJS += wrapper.o
LIB_OBJS += write_or_die.o
diff --git a/io-i18n.c b/io-i18n.c
index 4dcc2db..9d89ac3 100644
--- a/io-i18n.c
+++ b/io-i18n.c
@@ -1,3 +1,4 @@
+#include "io-i18n.h"
#include "utf8.h"
#include "cache.h"
@@ -80,3 +81,131 @@ char *filename_to_local(const char *filename)
return NULL;
#endif
}
+
+int stat_i18n(const char *filename, struct stat *buf)
+{
+ int ret;
+ char *out = filename_to_local(filename);
+
+ if (out != NULL) {
+ ret = stat(out, buf);
+ free(out);
+ } else
+ ret = stat(filename, buf);
+ return ret;
+}
+
+int lstat_i18n(const char *filename, struct stat *buf)
+{
+
+ int ret;
+ char *out = filename_to_local(filename);
+
+ if (out != NULL) {
+ ret = lstat(out, buf);
+ free(out);
+ } else
+ ret = lstat(filename, buf);
+ return ret;
+}
+
+DIR *opendir_i18n(const char *dirname)
+{
+ DIR *dir;
+ char *out = filename_to_local(dirname);
+
+ if (out != NULL) {
+ dir = opendir(out);
+ free(out);
+ } else
+ dir = opendir(dirname);
+ return dir;
+}
+
+struct dirent *readdir_i18n(DIR * dirstream)
+{
+ struct dirent *de = readdir(dirstream);
+
+ if (de) {
+ char *out = filename_to_utf8(de->d_name);
+
+ if (out) {
+ int len = strlen(out);
+ if (len >= NAME_MAX) {
+ warning("readdir_i18n: converted dir entry name length exceeds NAME_MAX and will be truncated\n");
+ len = NAME_MAX - 1;
+ }
+ memcpy(de->d_name, out, len);
+ de->d_name[len] = '\0';
+ free(out);
+ }
+ return de;
+ } else
+ return NULL;
+}
+
+int open_i18n(const char *filename, int flags, mode_t mode)
+{
+ int ret;
+ char *out = filename_to_local(filename);
+
+ if (out != NULL) {
+ ret = open(out, flags, mode);
+ free(out);
+ } else
+ ret = open(filename, flags, mode);
+ return ret;
+}
+
+FILE *fopen_i18n(const char *filename, const char *opentype)
+{
+ FILE *file;
+ char *out = filename_to_local(filename);
+
+ if (out != NULL) {
+ file = fopen(out, opentype);
+ free(out);
+ } else
+ file = fopen(filename, opentype);
+ return file;
+}
+
+int chmod_i18n(const char *filename, mode_t mode)
+{
+ int ret;
+ char *out = filename_to_local(filename);
+
+ if (out != NULL) {
+ ret = chmod(out, mode);
+ free(out);
+ } else
+ ret = chmod(filename, mode);
+ return ret;
+}
+
+int link_i18n(const char *oldname, const char *newname)
+{
+ char *old_out = filename_to_local(oldname);
+ char *new_out = filename_to_local(newname);
+ int ret = link(old_out ? old_out : oldname,
+ new_out ? new_out : newname);
+
+ if (old_out)
+ free(old_out);
+ if (new_out)
+ free(new_out);
+ return ret;
+}
+
+int unlink_i18n(const char *filename)
+{
+ char *out = filename_to_local(filename);
+ int ret;
+
+ if (out) {
+ ret = unlink(out);
+ free(out);
+ } else
+ ret = unlink(filename);
+ return ret;
+}
diff --git a/io-i18n.h b/io-i18n.h
new file mode 100644
index 0000000..c386e20
--- /dev/null
+++ b/io-i18n.h
@@ -0,0 +1,23 @@
+#ifndef GIT_IO_I18N_H
+#define GIT_IO_I18N_H
+
+#define _FILE_OFFSET_BITS 64
+
+#include <sys/stat.h>
+#include <dirent.h>
+#include <stdio.h>
+
+#define DEFAULT_OPEN_MODE 0
+
+char *filename_to_local (const char* filename);
+int stat_i18n(const char *filename, struct stat *buf);
+int lstat_i18n(const char *filename, struct stat *buf);
+DIR* opendir_i18n(const char *dirname);
+struct dirent *readdir_i18n(DIR *dirstream);
+int open_i18n(const char *filename, int flags, mode_t mode);
+FILE *fopen_i18n(const char *filename, const char *opentype);
+int chmod_i18n(const char *filename, mode_t mode);
+int link_i18n(const char *oldname, const char *newname);
+int unlink_i18n(const char *filename);
+
+#endif /* GIT_IO_I18N_H */
--
1.6.5.1
^ permalink raw reply related
* Re: [PATCH] Fix memory leak in transport-helper
From: Johannes Schindelin @ 2009-10-27 14:11 UTC (permalink / raw)
To: Daniel Barkalow
Cc: Shawn O. Pearce, Junio C Hamano, Johan Herland, Nanako Shiraishi,
Sverre Rabbelier, git
In-Reply-To: <alpine.LNX.2.00.0910270032170.14365@iabervon.org>
Hi,
On Tue, 27 Oct 2009, Daniel Barkalow wrote:
> diff --git a/transport-helper.c b/transport-helper.c
> index f57e84c..479539d 100644
> --- a/transport-helper.c
> +++ b/transport-helper.c
> @@ -67,6 +67,13 @@ static int disconnect_helper(struct transport *transport)
> return 0;
> }
>
> +static int close_helper(struct transport *transport)
> +{
> + disconnect_helper(transport);
> + free(transport->data);
> + return 0;
> +}
Why did you not leech the transport->data = NULL; part from Peff/Sverre's
patch?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 1/4] Add routines for filenames encoding <local encoding> <-> UTF-8
From: Peter Krefting @ 2009-10-27 14:16 UTC (permalink / raw)
To: Timur Sufiev; +Cc: git
In-Reply-To: <1256651643-18382-1-git-send-email-timur@iris-comp.ru>
Timur Sufiev:
> The point is to make Git aware of filenames local encoding and make it
> keep all filenames in UTF-8 internally.
Good.
> If `i18n.filenameslocalencoding' option was set via git-config to a
> correct <codepage> encoding, 2 things should be done:
Windows supports UTF-16 file names, but need to use wchar_t APIs for fopen()
and friends. Have you looked at any of that?
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* Re: [PATCH] rebase -i: more graceful handling of invalid commands
From: Johannes Schindelin @ 2009-10-27 14:17 UTC (permalink / raw)
To: Jan Krüger; +Cc: kusmabite, Git Mailing List
In-Reply-To: <20091027133932.60b996c3@perceptron>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 872 bytes --]
Hi,
On Tue, 27 Oct 2009, Jan Krüger wrote:
> 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>
ACK,
Dscho
^ permalink raw reply
* Re: [PATCH] rebase -i: more graceful handling of invalid commands
From: Thomas Rast @ 2009-10-27 14:21 UTC (permalink / raw)
To: Jan Krüger; +Cc: kusmabite, Git Mailing List
In-Reply-To: <20091027133932.60b996c3@perceptron>
Jan Krüger wrote:
> 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
I think you need s/sha/sha1/ here?
> + then
> + die_with_patch $sha1 "Please fix this in the file $TODO."
> + else
> + die "Please fix this in the file $TODO."
> + fi
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: Getting Ensimag students to work on Git for a few weeks
From: Clemens Buchacher @ 2009-10-27 14:44 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <vpqocntxhzv.fsf@bauges.imag.fr>
On Tue, Oct 27, 2009 at 11:12:52AM +0100, Matthieu Moy wrote:
> 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.
That's not much time to get familiar with a complex project like git. So you
will have to do something extremely simple, which probably means that it
won't be anything exciting. If it were, someone else would have done it
already.
Clemens
^ permalink raw reply
* [PATCH v2] rebase -i: more graceful handling of invalid commands
From: Jan Krüger @ 2009-10-27 14:58 UTC (permalink / raw)
To: Thomas Rast
Cc: kusmabite, Git Mailing List, Junio C Hamano, Johannes Schindelin
In-Reply-To: <200910271521.09164.trast@student.ethz.ch>
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>
Acked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
Thomas Rast wrote:
> I think you need s/sha/sha1/ here?
Of course. For some reason I forgot testing the code path where the
SHA1 is actually valid. Sorry about that.
Dscho's ACK lifted off
<http://article.gmane.org/gmane.comp.version-control.git/131341>.
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 "$sha1" >/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
* [PATCH] gitk: Use the --submodule option for diffs
From: Jens Lehmann @ 2009-10-27 14:59 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Junio C Hamano, Git Mailing List
Instead of just showing not-quite-helpful SHA-1 pairs display the first
lines of the corresponding commit messages in the submodule (similar to
the output of 'git submodule summary').
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
---
This patch applies to 'next' and uses the new --submodule option of git
diff to achieve a more meaningful output of submodule differences in
gitk.
Any objections against making this the default?
(for those interested: a version of git gui with similar functionality
is available in 'master' of Shawn's repo but not yet merged).
gitk-git/gitk | 23 +++++++++++++++++++----
1 files changed, 19 insertions(+), 4 deletions(-)
diff --git a/gitk-git/gitk b/gitk-git/gitk
index a0214b7..5e2572d 100644
--- a/gitk-git/gitk
+++ b/gitk-git/gitk
@@ -7207,7 +7207,7 @@ proc diffcmd {ids flags} {
if {$i >= 0} {
if {[llength $ids] > 1 && $j < 0} {
# comparing working directory with some specific revision
- set cmd [concat | git diff-index $flags]
+ set cmd [concat | git diff-index --submodule $flags]
if {$i == 0} {
lappend cmd -R [lindex $ids 1]
} else {
@@ -7215,13 +7215,13 @@ proc diffcmd {ids flags} {
}
} else {
# comparing working directory with index
- set cmd [concat | git diff-files $flags]
+ set cmd [concat | git diff-files --submodule $flags]
if {$j == 1} {
lappend cmd -R
}
}
} elseif {$j >= 0} {
- set cmd [concat | git diff-index --cached $flags]
+ set cmd [concat | git diff-index --cached --submodule $flags]
if {[llength $ids] > 1} {
# comparing index with specific revision
if {$i == 0} {
@@ -7234,7 +7234,7 @@ proc diffcmd {ids flags} {
lappend cmd HEAD
}
} else {
- set cmd [concat | git diff-tree -r $flags $ids]
+ set cmd [concat | git diff-tree -r --submodule $flags $ids]
}
return $cmd
}
@@ -7481,6 +7481,21 @@ proc getblobdiffline {bdf ids} {
set diffnparents [expr {[string length $ats] - 1}]
set diffinhdr 0
+ } elseif {![string compare -length 10 "Submodule " $line]} {
+ # start of a new submodule
+ if {[string compare [$ctext get "end - 4c" end] "\n \n\n"]} {
+ $ctext insert end "\n"; # Add newline after commit message
+ }
+ set curdiffstart [$ctext index "end - 1c"]
+ lappend ctext_file_names ""
+ set fname [string range $line 10 [expr [string last " " $line] - 1]]
+ lappend ctext_file_lines $fname
+ makediffhdr $fname $ids
+ $ctext insert end "\n$line\n" filesep
+ } elseif {![string compare -length 3 " >" $line]} {
+ $ctext insert end "$line\n" dresult
+ } elseif {![string compare -length 3 " <" $line]} {
+ $ctext insert end "$line\n" d0
} elseif {$diffinhdr} {
if {![string compare -length 12 "rename from " $line]} {
set fname [string range $line [expr 6 + [string first " from " $line] ] end]
--
1.6.5.2.182.g338ab.dirty
^ permalink raw reply related
* [msysGit Herald] The 11th revision of the msysGit Herald
From: Johannes Schindelin @ 2009-10-27 15:06 UTC (permalink / raw)
To: msysgit, git
Good morning Git land!
A busy and frantic Tuesday afternoon is as good an occasion as any to
offer to you the 11th revision of the msysGit Herald, the quite
irregular news letter to keep you informed about msysGit, the effort
to bring one of the most powerful Source Code Management systems to
the Operating System known as Windows.
These are the covered topics:
Some trivia
Git Cheetah goes platform independent!
Interview with Sebastian Schuberth
This issue is more to distract myself from my ever-growing day-job
obligations than to inform about breakthrough developments in Git for
Windows; Actually, it is a good sign that there are no major new
things, as this means that Git on Windows is finally where we wanted
it to be: stable.
Some trivia
===========
Whenever I am too overworked to do something sensible, but too bored
to go to sleep, too, I do utterly senseless stuff like factoring 1453
(have fun!), reading xkcd, or looking at Google Analytics.
This time, it was the latter, and I looked at the top ten countries
accessing our website:
* USA 2904
* Germany 987
* China 809
* UK 580
* Japan 489
* Russia 438
* France 379
* Canada 341
* Brazil 248
* Poland 229
(Total: 11.115)
Compare this with the first week of msysGit:
* USA 90
* UK 57
* Norway 35
* Germany 24
* Sweden 23
* Italy 8
* Hungary 8
* Japan 6
* Netherlands 5
* France 5
(Total: 298)
So we have come a long way. It is striking how the top ten are divided
between the rich countries, with the exception of China. So, Windows
is a rich man's Operating System. Big news. You got to be rich to go
for a coffee whenever you load a text document.
The trend that the website is accessed mostly during the working week
is even more prominent now than it was in the beginning. Just compare
the last week:
* Monday 1453 (the same prime number as in xkcd 247... coincidence?)
* Tuesday 1676
* Wednesday 1667
* Thursday 1628
* Friday 1591
* Saturday 933
* Sunday 918
to the 3rd week after msysGit was born (the first two and a half weeks
of msysGit were a little chaotic, so they are not representative):
* Monday 98
* Tuesday 54
* Wednesday 46
* Thursday 39
* Friday 39 (wait, the same as Thursday? Again... coincidence?)
* Saturday 13
* Sunday 33
So the trend is definitely that the weekdays are almost equal, with
drop offs on Monday (drinking coffee to get out of the weekend?) and
Friday (leaving maybe an hour early, or at least not doing anything
during that hour?), but the weekends are barely over the half of the
weekday baseline, which makes me wonder what the Windows users do on
weekends. Use Linux, maybe?
A little under a half accessed more than 1 page, which I found quite
encouraging, but then, to get at the downloads, you have to click a
second time. Assuming that some people do not find the direct download
button, and taking into account that 86% access 3 pages or less, that
means that only 14% are interested enough in more information to
actually access other information.
It is fascinating that only 90.76% actually surf to our website using
Windows, and a full 5.08% is Linux (MacOSX: 3.72%). Of course, in
theory you could pretend, but then, I do not expect the average
Windows user to know that this is even possible.
Another interesting tidbit is that while Google helped most of the
visitors find our webpage in the beginning, now it is only 35.81%, and
a full 21.36% come via git-scm.com instead.
It struck me as odd that the search terms "tortoisegit" and "tortoise
git" were responsible for 7.71% of our traffic, when I thought that I
made quite clear what I think of the TortoiseGit effort.
Git Cheetah goes platform independent!
======================================
Recently, Heiko Voigt got interested in improving Git Cheetah, and to
catch my attention worked on making the architecture
platform-independent.
He caught my attention, indeed, and Git Cheetah now works not only in
the Microsoft Explorer, but also in MacOSX' Finder (for the moment,
only up to Leopard; help for getting it to work on Snow Leopard is
very much appreciated) and in GNOME's Nautilus (which should cover at
least the American half of Linux users).
Great stuff.
Interview with Sebastian Schuberth
==================================
Recently I attended the GitTogether in Berlin, and for the first time
had a chance to see the faces behind some email addresses, including
Sebastian's. He is most known in the msysGit project for his huge
effort to make a commercial-grade installer for Git for Windows.
Somehow I managed during those years (msysGit is already 2.5 years old
-- time flies like an arrow) to miss the fact that I did not honor
Sebastian by interviewing him for the Herald yet. Let's undo that
mistake.
> 1) How did you get involved with Git?
It all started when the management of the company I used to work for
finally saw reason to move away from CVS. I was annoyed by CVS long
before that, but my tries to get people to use SVN instead failed
miserably, although I already had all the conversion done, mostly due
to the management failing to see CVS' issues and being unwilling to
spend resources on the migration, and some stubborn CVS command line
junkies that did not want to learn new commands ;-) That was in
October 2006.
But as our SCM requirements got more demanding due to an increasing
number of offices and cooperation partners at different sites, it
became clear a DVCS would be beneficial. Steffen, who's involved in
the msysGit project, too, was the contact person at one of our
cooperation partners at that time. In the second half of 2007, IIRC,
he evaluated Mercurial and Git, Git coming out as the winner. Not
questioning his preference too much (as we were happy some one took
the time to do a thorough test of both systems) and trusting Steffen's
expertise, we agreed on giving Git a try.
> 2) What were the reasons that you started working on Git?
Being mainly a Windows developer, it quickly turned out that there was
no nice Windows support in Git back then. There was Cygwin's Git, but
it had several issues, and conflicted with our company policy to
install Cygwin with text mode mounts. Digging a little further, I came
across msysGit which was more what I wanted. At that time, msysGit was
packaged a 7-Zip SFX, lacking the usual settings like creating
shortcuts and uninstall capabilities which a Windows user would
probably expect. This is when I started to work on an Inno Setup based
installer that also creates hard-links on NTFS drives instead of
making copies for the various Git commands etc. I just wanted to
polish things a little bit in order to avoid colleagues who were not
so fond of switching away from CVS from finding a reason to complain
already when launching the Git installer ;-) Meanwhile, the installer
has gained a lot of features and I think it does a good job at
configuring the most basic Git settings in a nice and easy way, and it
has paid off to replace the 7-Zip SFX installer.
> 3) What do you like most in Git?
As Git also was my first DVCS, I like several things about Git that
are common across many DVCS. I find stashing changes, squashing
commits and rebasing branches to be particularly useful features.
Moreover, I like the simple fact that there's only one .git directory
at the top of your working tree, and not in every sub-directory. Also,
the reflog can be very handy if you messed something up :-) Using
hashes instead of version / revision numbers also is a very practical
thing. And I really adore Git for its speed on Linux (not on Windows,
though, but I believe that's not Git's fault; it rather rather seems
to be a general issue of how NTFS performs for a large number of small
files).
> 4) What do you hate most in Git?
Hmm, hard to say. Instead of a single big issue that I would hate,
there are some smaller issues that annoy me. For example, I still
think the documentation is too technical and uses too much
Git-specific vocabulary instead of using more common expressions. When
working on Windows, I dislike that msysGit, as the name suggests,
depends on MSYS and on tools from the Unix world. I believe all
programs in the Git distribution should become binaries compiled for a
specific platform, and not rely on shell interpreters or third-party
languages like Tcl/Tk.
> 5) What was the most surprising moment when working with Git?
That big merges basically just work! It's so much less work doing
merges with Git than with CVS, as Git just does the right thing,
usually :-)
> 6) What was the most frustrating moment when working with Git?
Well, this is not so much about working *with* Git, but rather working
*on* Git: I really cannot understand how submitting patches for
upstream Git is still done via e-mail. We all know the benefits of
Git, so we should make use of them! For example in the form of a mob
branch like msysGit does. I've heard arguments before, like that it's
easier to comment on patches inline if they're contained in an e-mail,
but all that does not outweigh the advantages like getting rid of the
various formatting / white-space issues that occur regularly and the
time overhead for applying the patch to the correct branch.
> 7) In what environment do you work?
I work in a dual-boot environment with Windows Vista and Ubuntu 9.04.
I recently upgraded my PC to an Intel Core i7 920 with 6 GB of RAM and
a decent NVIDIA graphics board, as I do a lot of (GP)GPU stuff, mostly
using OpenGL and CUDA / OpenCL.
> 8) What other hobbies do you have?
Besides involvement in other OSS projects and working on my own
private programming projects, I also did and do several martial arts
and ride the motorcycle.
> 9) What is your favourite movie?
That depends on the genre, but currently one of my all-time favorites
is "Kung Fu Hustle" :-)
> 10) What are your visions for Git? (I.e. where do you want it to
go?)
I'd really like to see Git becoming a first-choice for pure Windows
developers, too, not only e.g. for people that need to make a project
that already uses Git and works on Unix compile on Windows. And as
much as I like the diversity of e.g. Git GUI tools, which is in the
nature of every OSS project, I think for the sake of clarity for the
users and to combine features and developing efforts, several projects
should merge. For example, I doubt that we need something in the order
of five different Git Windows Explorer shell extensions.
^ permalink raw reply
* Re: git update --prune issue
From: Jeffrey Middleton @ 2009-10-27 15:07 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git
In-Reply-To: <4AE6B28F.9010407@drmicha.warpmail.net>
On Tue, Oct 27, 2009 at 3:42 AM, Michael J Gruber
<git@drmicha.warpmail.net> wrote:
> 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
I don't *think* I'll see it this way - I was doing essentially this
prior to introduction of the --prune option, and never saw it then.
> Does it depend on the order, i.e.:
>
> git remote update steph
> git remote update kevin
> git remote prune steph
I've tried once and saw no problems. I just realized I should be
saving off all remote refs before doing a remote update --prune again
- next time I see the problem I should be able to rule out everything
for sure. Sorry I didn't do that sooner. However, I'm still fairly
sure it's specific to the all-at-once operation of remote update
--prune since I never saw it before that feature, and because once
that command finishes, everything is okay.
> Does "git fsck --full" say anything special?
Just 47 dangling blobs, 23 dangling trees, and 13 dangling commits.
> Michael
>
^ permalink raw reply
* Re: possible usability issue in rebase -i?
From: Baz @ 2009-10-27 15:17 UTC (permalink / raw)
To: kusmabite; +Cc: Git Mailing List
In-Reply-To: <40aa078e0910270313j5dc68576v86a3947f0dc7f9f@mail.gmail.com>
2009/10/27 Erik Faye-Lund <kusmabite@googlemail.com>:
> 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.
I've got a somewhat related minor usability issue with rebase -i. I
accidentally typed something like 'git rebase -i -z' and got this
message:
error: unknown switch `z'
usage: git-rebase [-i] [options] [--] <upstream> [<branch>]
or: git-rebase [-i] (--continue | --abort | --skip)
Available options are
-v, --verbose display a diffstat of what changed upstream
--onto ... rebase onto given branch instead of upstream
-p, --preserve-merges
try to recreate merges instead of ignoring them
-s, --strategy ... use the given merge strategy
-m, --merge always used (no-op)
-i, --interactive always used (no-op)
The last two lines were the surprise. It suggested to me that '-i' and
'-m' were now the defaults for git-rebase - which of course they're
not. A user would not know that this is actually reporting the flags
that work for git-rebase--interactive, especially since that's not
what the command calls itself. I wasn't sure about the best approach
to fixing this - the only comparable commands that pass arbitrary
flags down to an exec'd program make it clear what program is going to
be called (usually git merge) and so interpreting errors is easier.
It seems the intent here was to signal that the flags are different
once a rebase is in progress, but this usage message is shown when
rebase -i -z is called in any state.
Cheers,
Brian
>
> --
> Erik "kusma" Faye-Lund
> --
> 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
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