* [PATCH 1/3] builtin-branch: remove duplicated code
From: Lars Hjemli @ 2008-07-26 10:27 UTC (permalink / raw)
To: git
In-Reply-To: <1217068045-3575-1-git-send-email-hjemli@gmail.com>
The previous optimization to --[no-]merged ended up with some duplicated
code which this patch removes.
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
---
builtin-branch.c | 9 ++-------
1 files changed, 2 insertions(+), 7 deletions(-)
diff --git a/builtin-branch.c b/builtin-branch.c
index 5db8ad8..675a9b1 100644
--- a/builtin-branch.c
+++ b/builtin-branch.c
@@ -214,7 +214,6 @@ static int append_ref(const char *refname, const unsigned char *sha1, int flags,
struct commit *commit;
int kind;
int len;
- static struct commit_list branch;
/* Detect kind */
if (!prefixcmp(refname, "refs/heads/")) {
@@ -238,13 +237,9 @@ static int append_ref(const char *refname, const unsigned char *sha1, int flags,
if ((kind & ref_list->kinds) == 0)
return 0;
- if (merge_filter != NO_FILTER) {
- branch.item = lookup_commit_reference_gently(sha1, 1);
- if (!branch.item)
- die("Unable to lookup tip of branch %s", refname);
+ if (merge_filter != NO_FILTER)
add_pending_object(&ref_list->revs,
- (struct object *)branch.item, refname);
- }
+ (struct object *)commit, refname);
/* Resize buffer */
if (ref_list->index >= ref_list->alloc) {
--
1.6.0.rc0.79.gb0320
^ permalink raw reply related
* [PATCH] t7601: extend the 'merge picks up the best result' test
From: Miklos Vajna @ 2008-07-26 11:54 UTC (permalink / raw)
To: git
In-Reply-To: <7v7ibenx75.fsf@gitster.siamese.dyndns.org>
The test only checked if the best result picking code works if there are
multiple strategies set in the config. Add a similar one that tests if
the same true if the -s option of git merge was used multiple times.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
On Tue, Jul 22, 2008 at 01:24:14AM -0700, Junio C Hamano <gitster@pobox.com> wrote:
> Don't. pull.* has always been defined as "list of strategies", and -s
> has
> always been defined to take "a" strategy.
OK. Here is a testcase for the later. As far as I see the behaviour of
multiple -s was not checked till now.
t/t7601-merge-pull-config.sh | 15 +++++++++++++++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/t/t7601-merge-pull-config.sh b/t/t7601-merge-pull-config.sh
index 6b9f638..55aa6b5 100755
--- a/t/t7601-merge-pull-config.sh
+++ b/t/t7601-merge-pull-config.sh
@@ -112,6 +112,21 @@ test_expect_success 'setup conflicted merge' '
# recusive is choosen.
test_expect_success 'merge picks up the best result' '
+ git config --unset-all pull.twohead &&
+ git reset --hard c5 &&
+ git merge -s resolve c6
+ resolve_count=$(conflict_count) &&
+ git reset --hard c5 &&
+ git merge -s recursive c6
+ recursive_count=$(conflict_count) &&
+ git reset --hard c5 &&
+ git merge -s recursive -s resolve c6
+ auto_count=$(conflict_count) &&
+ test $auto_count = $recursive_count &&
+ test $auto_count != $resolve_count
+'
+
+test_expect_success 'merge picks up the best result (from config)' '
git config pull.twohead "recursive resolve" &&
git reset --hard c5 &&
git merge -s resolve c6
--
1.5.6.4.433.g09651.dirty
^ permalink raw reply related
* [PATCH 2/7] builtin-help: change the current directory back in list_commands_in_dir()
From: Miklos Vajna @ 2008-07-26 11:54 UTC (permalink / raw)
To: git
In-Reply-To: <cover.1217037178.git.vmiklos@frugalware.org>
That function used to do a chdir() without switching back to the
original directory. That was not a problem till this function was used
only inside builtin-help, but once other builtins use it as well, this
is a problem, for example when the object database path is relative.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
help.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/help.c b/help.c
index fb93df0..d71937e 100644
--- a/help.c
+++ b/help.c
@@ -425,7 +425,9 @@ static unsigned int list_commands_in_dir(struct cmdnames *cmds,
int prefix_len;
DIR *dir = opendir(path);
struct dirent *de;
+ static char old_path[PATH_MAX+1];
+ getcwd(old_path, sizeof(old_path));
if (!dir || chdir(path))
return 0;
@@ -452,6 +454,7 @@ static unsigned int list_commands_in_dir(struct cmdnames *cmds,
}
closedir(dir);
+ chdir(old_path);
return longest;
}
--
1.6.0.rc0.14.g95f8.dirty
^ permalink raw reply related
* [PATCH 3/7] builtin-help: make list_commands() a bit more generic
From: Miklos Vajna @ 2008-07-26 11:54 UTC (permalink / raw)
To: git
In-Reply-To: <cover.1217037178.git.vmiklos@frugalware.org>
That function now takes two paramters to control the prefix of the
listed commands, and a second parameter to specify the title of the
table. This can be useful for listing not only all git commands, but
specific ones, like merge strategies.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
help.c | 10 +++++-----
help.h | 1 +
2 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/help.c b/help.c
index d71937e..f71fff4 100644
--- a/help.c
+++ b/help.c
@@ -501,13 +501,13 @@ static unsigned int load_command_list(const char *prefix)
return longest;
}
-static void list_commands(void)
+void list_commands(const char *prefix, const char *title)
{
- unsigned int longest = load_command_list(NULL);
+ unsigned int longest = load_command_list(prefix);
const char *exec_path = git_exec_path();
if (main_cmds.cnt) {
- printf("available git commands in '%s'\n", exec_path);
+ printf("available %s in '%s'\n", title, exec_path);
printf("----------------------------");
mput_char('-', strlen(exec_path));
putchar('\n');
@@ -516,7 +516,7 @@ static void list_commands(void)
}
if (other_cmds.cnt) {
- printf("git commands available from elsewhere on your $PATH\n");
+ printf("%s available from elsewhere on your $PATH\n", title);
printf("---------------------------------------------------\n");
pretty_print_string_list(&other_cmds, longest);
putchar('\n');
@@ -697,7 +697,7 @@ int cmd_help(int argc, const char **argv, const char *prefix)
if (show_all) {
printf("usage: %s\n\n", git_usage_string);
- list_commands();
+ list_commands("git-", "git commands");
printf("%s\n", git_more_info_string);
return 0;
}
diff --git a/help.h b/help.h
index 73da8d6..0741662 100644
--- a/help.h
+++ b/help.h
@@ -2,5 +2,6 @@
#define HELP_H
int is_git_command(const char *s, const char *prefix);
+void list_commands(const char *prefix, const char *title);
#endif /* HELP_H */
--
1.6.0.rc0.14.g95f8.dirty
^ permalink raw reply related
* [PATCH 0/7] Allow custom merge strategies
From: Miklos Vajna @ 2008-07-26 11:54 UTC (permalink / raw)
To: git
Hi,
This series adds support for custom merge strategies.
The first 3 patches modify builtin-help to allow using it from other
builtins. This is necessary because in the error message of 'git merge
-s foobar' we show something like 'git help -a', but we list only merge
strategies. A command is considered a merge strategy if it has a
git-merge- prefix and is listed in the all_strategy array or it is
somewhere in PATH, but outside `git --exec-path`, so that git-merge-ours
and other strategies are shown, git-merge-index and other
git-merge-named (but not strategy) commands are hidden.
The last two is about removing those problematic 'git-merge-index',
'git-merge-tree' and other bogus commands from the output of 'git merge
-s foobar'. I think the benefit of doing it that way is that we don't
have to maintain a list of commands which are named git-merge-foo but
not strategies _and_ the custom strategies can have a form of
git-merge-foo, without adding extra complexity (like forcing users to
name them git-merge-custom-foo).
NOTE: At the moment the custom strategies are named as git-merge-foo as
well, mainly because I think it's not that problematic to exclude the
already existing git-merge-fo non-strategy commands, but this can be
changed to git-merge-strategy-foo if we really want so.
Also, I'm aware that this is a feature and we are in rc freeze, I just
did not want to keep back this series till 1.6.0 is out.
Miklos Vajna (7):
Make is_git_command() usable outside builtin-help
builtin-help: change the current directory back in
list_commands_in_dir()
builtin-help: make list_commands() a bit more generic
builtin-merge: allow using a custom strategy
Add a new test for using a custom merge strategy
builtin-help: make it possible to exclude some commands in
list_commands()
builtin-merge: avoid non-strategy git-merge commands in error message
Makefile | 1 +
builtin-merge.c | 30 +++++++++++++++++++++------
help.c | 50 ++++++++++++++++++++++++----------------------
help.h | 19 +++++++++++++++++
t/t7606-merge-custom.sh | 45 ++++++++++++++++++++++++++++++++++++++++++
5 files changed, 114 insertions(+), 31 deletions(-)
create mode 100644 help.h
create mode 100755 t/t7606-merge-custom.sh
^ permalink raw reply
* [PATCH 1/7] Make is_git_command() usable outside builtin-help
From: Miklos Vajna @ 2008-07-26 11:54 UTC (permalink / raw)
To: git
In-Reply-To: <cover.1217037178.git.vmiklos@frugalware.org>
Other builtins may want to check if a given command is a valid git
command or not as well. Additionally add a new parameter that specifies
a custom prefix, so that the "git-" prefix is no longer hardwired.
Useful for example to limit the search for "git-merge-*".
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
Makefile | 1 +
help.c | 25 ++++++++++++++-----------
help.h | 6 ++++++
3 files changed, 21 insertions(+), 11 deletions(-)
create mode 100644 help.h
diff --git a/Makefile b/Makefile
index b01cf1c..85e79f6 100644
--- a/Makefile
+++ b/Makefile
@@ -346,6 +346,7 @@ LIB_H += git-compat-util.h
LIB_H += graph.h
LIB_H += grep.h
LIB_H += hash.h
+LIB_H += help.h
LIB_H += list-objects.h
LIB_H += ll-merge.h
LIB_H += log-tree.h
diff --git a/help.c b/help.c
index bfc84ae..fb93df0 100644
--- a/help.c
+++ b/help.c
@@ -418,17 +418,20 @@ static int is_executable(const char *name)
}
static unsigned int list_commands_in_dir(struct cmdnames *cmds,
- const char *path)
+ const char *path,
+ const char *prefix)
{
unsigned int longest = 0;
- const char *prefix = "git-";
- int prefix_len = strlen(prefix);
+ int prefix_len;
DIR *dir = opendir(path);
struct dirent *de;
if (!dir || chdir(path))
return 0;
+ if (!prefix)
+ prefix = "git-";
+ prefix_len = strlen(prefix);
while ((de = readdir(dir)) != NULL) {
int entlen;
@@ -452,7 +455,7 @@ static unsigned int list_commands_in_dir(struct cmdnames *cmds,
return longest;
}
-static unsigned int load_command_list(void)
+static unsigned int load_command_list(const char *prefix)
{
unsigned int longest = 0;
unsigned int len;
@@ -461,7 +464,7 @@ static unsigned int load_command_list(void)
const char *exec_path = git_exec_path();
if (exec_path)
- longest = list_commands_in_dir(&main_cmds, exec_path);
+ longest = list_commands_in_dir(&main_cmds, exec_path, prefix);
if (!env_path) {
fprintf(stderr, "PATH not set\n");
@@ -473,7 +476,7 @@ static unsigned int load_command_list(void)
if ((colon = strchr(path, PATH_SEP)))
*colon = 0;
- len = list_commands_in_dir(&other_cmds, path);
+ len = list_commands_in_dir(&other_cmds, path, prefix);
if (len > longest)
longest = len;
@@ -497,7 +500,7 @@ static unsigned int load_command_list(void)
static void list_commands(void)
{
- unsigned int longest = load_command_list();
+ unsigned int longest = load_command_list(NULL);
const char *exec_path = git_exec_path();
if (main_cmds.cnt) {
@@ -543,9 +546,9 @@ static int is_in_cmdlist(struct cmdnames *c, const char *s)
return 0;
}
-static int is_git_command(const char *s)
+int is_git_command(const char *s, const char *prefix)
{
- load_command_list();
+ load_command_list(prefix);
return is_in_cmdlist(&main_cmds, s) ||
is_in_cmdlist(&other_cmds, s);
}
@@ -566,7 +569,7 @@ static const char *cmd_to_page(const char *git_cmd)
return "git";
else if (!prefixcmp(git_cmd, "git"))
return git_cmd;
- else if (is_git_command(git_cmd))
+ else if (is_git_command(git_cmd, NULL))
return prepend("git-", git_cmd);
else
return prepend("git", git_cmd);
@@ -704,7 +707,7 @@ int cmd_help(int argc, const char **argv, const char *prefix)
}
alias = alias_lookup(argv[0]);
- if (alias && !is_git_command(argv[0])) {
+ if (alias && !is_git_command(argv[0], NULL)) {
printf("`git %s' is aliased to `%s'\n", argv[0], alias);
return 0;
}
diff --git a/help.h b/help.h
new file mode 100644
index 0000000..73da8d6
--- /dev/null
+++ b/help.h
@@ -0,0 +1,6 @@
+#ifndef HELP_H
+#define HELP_H
+
+int is_git_command(const char *s, const char *prefix);
+
+#endif /* HELP_H */
--
1.6.0.rc0.14.g95f8.dirty
^ permalink raw reply related
* [PATCH 6/7] builtin-help: make it possible to exclude some commands in list_commands()
From: Miklos Vajna @ 2008-07-26 11:54 UTC (permalink / raw)
To: git
In-Reply-To: <cover.1217037178.git.vmiklos@frugalware.org>
The supposed method is to build a list of commands to be excluded using
add_cmdname(), then pass the list as the new exclude parameter. If no
exclude is needed, NULL should be used.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
help.c | 24 ++++++++++--------------
help.h | 14 +++++++++++++-
2 files changed, 23 insertions(+), 15 deletions(-)
diff --git a/help.c b/help.c
index f71fff4..de1be6d 100644
--- a/help.c
+++ b/help.c
@@ -9,6 +9,7 @@
#include "common-cmds.h"
#include "parse-options.h"
#include "run-command.h"
+#include "help.h"
static struct man_viewer_list {
struct man_viewer_list *next;
@@ -300,16 +301,9 @@ static inline void mput_char(char c, unsigned int num)
putchar(c);
}
-static struct cmdnames {
- int alloc;
- int cnt;
- struct cmdname {
- size_t len;
- char name[1];
- } **names;
-} main_cmds, other_cmds;
+struct cmdnames main_cmds, other_cmds;
-static void add_cmdname(struct cmdnames *cmds, const char *name, int len)
+void add_cmdname(struct cmdnames *cmds, const char *name, int len)
{
struct cmdname *ent = xmalloc(sizeof(*ent) + len);
@@ -458,7 +452,7 @@ static unsigned int list_commands_in_dir(struct cmdnames *cmds,
return longest;
}
-static unsigned int load_command_list(const char *prefix)
+static unsigned int load_command_list(const char *prefix, struct cmdnames *exclude)
{
unsigned int longest = 0;
unsigned int len;
@@ -497,13 +491,15 @@ static unsigned int load_command_list(const char *prefix)
sizeof(*other_cmds.names), cmdname_compare);
uniq(&other_cmds);
exclude_cmds(&other_cmds, &main_cmds);
+ if (exclude)
+ exclude_cmds(&main_cmds, exclude);
return longest;
}
-void list_commands(const char *prefix, const char *title)
+void list_commands(const char *prefix, const char *title, struct cmdnames *exclude)
{
- unsigned int longest = load_command_list(prefix);
+ unsigned int longest = load_command_list(prefix, exclude);
const char *exec_path = git_exec_path();
if (main_cmds.cnt) {
@@ -551,7 +547,7 @@ static int is_in_cmdlist(struct cmdnames *c, const char *s)
int is_git_command(const char *s, const char *prefix)
{
- load_command_list(prefix);
+ load_command_list(prefix, NULL);
return is_in_cmdlist(&main_cmds, s) ||
is_in_cmdlist(&other_cmds, s);
}
@@ -697,7 +693,7 @@ int cmd_help(int argc, const char **argv, const char *prefix)
if (show_all) {
printf("usage: %s\n\n", git_usage_string);
- list_commands("git-", "git commands");
+ list_commands("git-", "git commands", NULL);
printf("%s\n", git_more_info_string);
return 0;
}
diff --git a/help.h b/help.h
index 0741662..85d3b74 100644
--- a/help.h
+++ b/help.h
@@ -1,7 +1,19 @@
#ifndef HELP_H
#define HELP_H
+struct cmdnames {
+ int alloc;
+ int cnt;
+ struct cmdname {
+ size_t len;
+ char name[1];
+ } **names;
+};
+
int is_git_command(const char *s, const char *prefix);
-void list_commands(const char *prefix, const char *title);
+void list_commands(const char *prefix, const char *title, struct cmdnames *exclude);
+void add_cmdname(struct cmdnames *cmds, const char *name, int len);
+
+extern struct cmdnames main_cmds, other_cmds;
#endif /* HELP_H */
--
1.6.0.rc0.14.g95f8.dirty
^ permalink raw reply related
* [PATCH 7/7] builtin-merge: avoid non-strategy git-merge commands in error message
From: Miklos Vajna @ 2008-07-26 11:54 UTC (permalink / raw)
To: git
In-Reply-To: <cover.1217037178.git.vmiklos@frugalware.org>
If an invalid strategy is supplied, like -s foobar, then git-merge
listed all git-merge-* commands. This is not perfect, since for example
git-merge-index is not a valid strategy.
These are now removed from the output by scanning the list of main
commands; if the git-merge-foo command is listed in the all_strategy
list, then it's shown, otherwise excluded. This does not exclude
commands somewhere else in the PATH, where custom strategies are
expected.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
builtin-merge.c | 13 ++++++++++++-
1 files changed, 12 insertions(+), 1 deletions(-)
diff --git a/builtin-merge.c b/builtin-merge.c
index cdbc692..4084e07 100644
--- a/builtin-merge.c
+++ b/builtin-merge.c
@@ -88,8 +88,19 @@ static struct strategy *get_strategy(const char *name)
return &all_strategy[i];
if (!is_git_command(name, "git-merge-")) {
+ struct cmdnames not_strategies;
+
+ memset(¬_strategies, 0, sizeof(struct cmdnames));
+ for (i = 0; i < main_cmds.cnt; i++) {
+ int j, found = 0;
+ for (j = 0; j < ARRAY_SIZE(all_strategy); j++)
+ if (!strcmp(main_cmds.names[i]->name, all_strategy[j].name))
+ found = 1;
+ if (!found)
+ add_cmdname(¬_strategies, main_cmds.names[i]->name, strlen(main_cmds.names[i]->name));
+ }
fprintf(stderr, "Could not find merge strategy '%s'.\n\n", name);
- list_commands("git-merge-", "strategies");
+ list_commands("git-merge-", "strategies", ¬_strategies);
exit(1);
}
--
1.6.0.rc0.14.g95f8.dirty
^ permalink raw reply related
* [PATCH 5/7] Add a new test for using a custom merge strategy
From: Miklos Vajna @ 2008-07-26 11:54 UTC (permalink / raw)
To: git
In-Reply-To: <cover.1217037178.git.vmiklos@frugalware.org>
Testing is done by creating a simple git-merge-theirs strategy which is
the opposite of ours. Using this in real merges is not recommended but
it's perfect for our testing needs.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
t/t7606-merge-custom.sh | 45 +++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 45 insertions(+), 0 deletions(-)
create mode 100755 t/t7606-merge-custom.sh
diff --git a/t/t7606-merge-custom.sh b/t/t7606-merge-custom.sh
new file mode 100755
index 0000000..f295e56
--- /dev/null
+++ b/t/t7606-merge-custom.sh
@@ -0,0 +1,45 @@
+#!/bin/sh
+
+test_description='git-merge
+
+Testing a custom strategy.'
+
+. ./test-lib.sh
+
+cat > git-merge-theirs << EOF
+#!/bin/sh
+eval git read-tree --reset -u \\\$\$#
+EOF
+chmod +x git-merge-theirs
+PATH=.:$PATH
+export PATH
+
+test_expect_success 'setup' '
+ echo c0 > c0.c &&
+ git add c0.c &&
+ git commit -m c0 &&
+ git tag c0 &&
+ echo c1 > c1.c &&
+ git add c1.c &&
+ git commit -m c1 &&
+ git tag c1 &&
+ git reset --hard c0 &&
+ echo c2 > c2.c &&
+ git add c2.c &&
+ git commit -m c2 &&
+ git tag c2
+'
+
+test_expect_success 'merge c2 with a custom strategy' '
+ git reset --hard c1 &&
+ git merge -s theirs c2 &&
+ test "$(git rev-parse c1)" != "$(git rev-parse HEAD)" &&
+ test "$(git rev-parse c1)" = "$(git rev-parse HEAD^1)" &&
+ test "$(git rev-parse c2)" = "$(git rev-parse HEAD^2)" &&
+ git diff --exit-code &&
+ test -f c0.c &&
+ test ! -f c1.c &&
+ test -f c2.c
+'
+
+test_done
--
1.6.0.rc0.14.g95f8.dirty
^ permalink raw reply related
* [PATCH 4/7] builtin-merge: allow using a custom strategy
From: Miklos Vajna @ 2008-07-26 11:54 UTC (permalink / raw)
To: git
In-Reply-To: <cover.1217037178.git.vmiklos@frugalware.org>
Allow using a custom strategy, as long as it's named git-merge-foo. The
error handling is now done using is_git_command(). The list of available
strategies is now shown by list_commands().
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
builtin-merge.c | 19 ++++++++++++-------
1 files changed, 12 insertions(+), 7 deletions(-)
diff --git a/builtin-merge.c b/builtin-merge.c
index e78fa18..cdbc692 100644
--- a/builtin-merge.c
+++ b/builtin-merge.c
@@ -22,6 +22,7 @@
#include "log-tree.h"
#include "color.h"
#include "rerere.h"
+#include "help.h"
#define DEFAULT_TWOHEAD (1<<0)
#define DEFAULT_OCTOPUS (1<<1)
@@ -77,7 +78,7 @@ static int option_parse_message(const struct option *opt,
static struct strategy *get_strategy(const char *name)
{
int i;
- struct strbuf err;
+ struct strategy *ret;
if (!name)
return NULL;
@@ -86,12 +87,16 @@ static struct strategy *get_strategy(const char *name)
if (!strcmp(name, all_strategy[i].name))
return &all_strategy[i];
- strbuf_init(&err, 0);
- for (i = 0; i < ARRAY_SIZE(all_strategy); i++)
- strbuf_addf(&err, " %s", all_strategy[i].name);
- fprintf(stderr, "Could not find merge strategy '%s'.\n", name);
- fprintf(stderr, "Available strategies are:%s.\n", err.buf);
- exit(1);
+ if (!is_git_command(name, "git-merge-")) {
+ fprintf(stderr, "Could not find merge strategy '%s'.\n\n", name);
+ list_commands("git-merge-", "strategies");
+ exit(1);
+ }
+
+ ret = xmalloc(sizeof(struct strategy));
+ memset(ret, 0, sizeof(struct strategy));
+ ret->name = xstrdup(name);
+ return ret;
}
static void append_strategy(struct strategy *s)
--
1.6.0.rc0.14.g95f8.dirty
^ permalink raw reply related
* Re: Mailing lists, was Re: [RFC] Git User's Survey 2008
From: Marek Zawirski @ 2008-07-26 12:19 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Shawn O. Pearce, Junio C Hamano, Johannes Schindelin, git
In-Reply-To: <200807261254.53939.jnareb@gmail.com>
Jakub Narebski wrote:
> On Sat, 26 July 2008, Shawn O. Pearce wrote:
(...)
>> Actually I'd like the editor integration to be broken out (if
>> it isn't already) so we can see which editors (and thus which
>> integrations) are popular among users. I think it would help all
>> of the integration authors, as well as make it clear to end-users
>> where we have integration available/under development, in case they
>> were not aware of it previously.
>
> So you would like to see something like the following question in the
> upcoming Git User's Survey?
>
> xx. Which editors/IDEs/RADs do you use?
> (zero or more; multiple choice with 'other')
> - Emacs, Vim, Eclipse, KDevelop, Anjuta, TextMate, Notepad++,
> Visual Studio, other
> + what choices should be in the list of editors and IDE;
> or should perhaps this question be free-form?
If we stay with hard coded list of IDEs, I'd add NetBeans to this list.
I have an impression that quite many folks are asking about NetBeans
support for Git. Particularly, comparison between number of Eclipse and
NetBeans users using Git is interesting matter for potential jgit usage.
--
Marek Zawirski [zawir]
marek.zawirski@gmail.com
^ permalink raw reply
* Re: [PATCH] t7601: extend the 'merge picks up the best result' test
From: Miklos Vajna @ 2008-07-26 12:33 UTC (permalink / raw)
To: git
In-Reply-To: <1217073292-27945-1-git-send-email-vmiklos@frugalware.org>
[-- Attachment #1: Type: text/plain, Size: 454 bytes --]
On Sat, Jul 26, 2008 at 01:54:45PM +0200, Miklos Vajna <vmiklos@frugalware.org> wrote:
> The test only checked if the best result picking code works if there are
> multiple strategies set in the config. Add a similar one that tests if
> the same true if the -s option of git merge was used multiple times.
Ignore this one. I run git send-email *.patch when sending out the other
series and forgot to do an rm *.patch before format-patch.
Sorry,
Miklos
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: git-scm.com
From: Petr Baudis @ 2008-07-26 13:07 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Scott Chacon, git
In-Reply-To: <m3hcadul6j.fsf@localhost.localdomain>
On Sat, Jul 26, 2008 at 01:03:26AM -0700, Jakub Narebski wrote:
> "Scott Chacon" <schacon@gmail.com> writes:
>
> > A followup on the post I did a few days ago about Git documentation.
> > I forked Petr's git.or.cz site and put up a version that I think is a
> > bit more accessible and newbie-friendly at git-scm.com. I had meant
> > to discuss this with Petr before posting it to you all, but I
> > published a blog post that got a bit more attention than I expected,
> > and I didn't want you all to think I didn't care about your opinion,
> > as some have already accused me of.
>
> On thing I am curious about: how do you plan to have current version
> of Git in the download / last version section? Petr Baudis uses
> custom script, which search git mailing list for "[ANNOUNCE]" posts,
> and automatically updates download / last version links.
Actually, I scan the last tag on maint branch using git descirbe; the
ANNOUNCE posts are scanned by the RSS feed. Originally, git-scm scanned
kernel.org download directory for the latest tarball, but it seemed that
would break on something like the 1.4.4.5, so it also moved to the git
describe method:
http://repo.or.cz/w/git-homepage.git?a=blob;f=update.sh
http://github.com/schacon/learn-github/tree/master/script/get_version.rb
One Scott's concern that didn't occur to me was that a the time of
release, we could have broken links between the time tag is created and
tarballs are wrapped up. I *think* that in practice, this happens at the
same time, I wonder if Junio could confirm that.
--
Petr "Pasky" Baudis
As in certain cults it is possible to kill a process if you know
its true name. -- Ken Thompson and Dennis M. Ritchie
^ permalink raw reply
* Re: [PATCH] init: handle empty "template" parameter, was Re: fetch refspec foo/* matches foo*
From: Johannes Schindelin @ 2008-07-26 13:13 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20080726083356.GB10104@sigill.intra.peff.net>
Hi,
On Sat, 26 Jul 2008, Jeff King wrote:
> Also, while I have your attention, Junio, here is another bug fix
> that should go into 1.6.0. I posted the patch as a "how about this" deep
> in a thread and got no response (which means no complaints, right?).
Again it is in a thread...
> This patch just checks for that condition in copy_templates
> and aborts. As a side effect, this means that --template=
> now has the meaning "don't copy any templates."
I deem this patch obviously correct, and your reasoning as to what an
empty parameter should mean makes sense.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Modify mingw_main() workaround to avoid link errors
From: Johannes Schindelin @ 2008-07-26 13:17 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Johannes Sixt, git, Junio C Hamano
In-Reply-To: <1217065304-27815-1-git-send-email-prohaska@zib.de>
Hi,
On Sat, 26 Jul 2008, Steffen Prohaska wrote:
> -#define main(c,v) main(int argc, const char **argv) \
> +#define main(c,v) dummy_decl_mingw_main(); \
What is this dummy_*() statement supposed to do?
Note that I still think it would be a better fix to refactor the
lookup_prog() function from mingw.c.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] git-svn: teach dcommit about svn auto-props
From: Brad King @ 2008-07-26 14:08 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <20080726054547.GA20494@untitled>
Eric Wong wrote:
> Brad King <brad.king@kitware.com> wrote:
>> Signed-off-by: Brad King <brad.king@kitware.com>
>
> Acked-by: Eric Wong <normalperson@yhbt.net>
Great, thanks!
>> ---
>> Eric Wong wrote:
>>> I haven't had the chance to look at this. Can anybody else shed more
>>> light on that bug? It's really strange that the tests won't run because
>>> of it. Are you unable to run some git-svn tests or all of them?
>> Just that one fails. All others (including the one in the patch below) pass.
>
> Exactly which test fails for you? Perhaps it's some setting in your
> ~/.subversion/config that's causing it to fail. Maybe we should set
> $HOME and use a clean ~/.subversion/config for git-svn tests regardless
> if that turns out to be the case...
$ cd $gitsrc/t
$ export SVNSERVE_PORT=5432
$ ./t9113-git-svn-dcommit-new-file.sh
* ok 1: start tracking an empty repo
* FAIL 2: create files in new directory with dcommit
mkdir git-new-dir &&
echo hello > git-new-dir/world &&
git update-index --add git-new-dir/world &&
git commit -m hello &&
start_svnserve &&
git svn dcommit
* failed 1 among 2 test(s)
I hacked the test script to log the dcommit output to a file, and I see
this:
Committing to svn://127.0.0.1:5432 ...
Use of uninitialized value in concatenation (.) or string at
/usr/lib/perl5/SVN/Core.pm line 584.
Authorization failed: at $gitsrc/t/../git-svn line 3329
(I replaced my git source dir full path with $gitsrc).
The version of libsvn-perl is: 1.5.0dfsg1-4
Please let me know if you need more info.
I tried moving my ~/.subversion/config out of the way but it makes no
difference. However, I agree we should block the user's home svn config
when running other dcommit tests now that we have auto-props. Perhaps
just using the --config-dir option with an empty directory would be enough.
-Brad
^ permalink raw reply
* [PATCH] Set up argv0_path correctly, even when argv[0] is just the basename
From: Johannes Schindelin @ 2008-07-26 14:14 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Johannes Sixt, git, Junio C Hamano
In-Reply-To: <1217065304-27815-1-git-send-email-prohaska@zib.de>
When the program 'git' is in the PATH, the argv[0] is set to the basename.
However, argv0_path needs the full path, so add a function to discover the
program by traversing the PATH manually.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
So it is not easily possible to reuse this function in
compat/mingw.c, as Junio said that compat/ should not depend
(at least too much) on libgit.a.
Of course, we could try to follow a symlinked git, too, but I
think this is overkill until someone proves me wrong.
exec_cmd.c | 22 ++++++++++++++++++++++
exec_cmd.h | 1 +
git.c | 6 ++++++
3 files changed, 29 insertions(+), 0 deletions(-)
diff --git a/exec_cmd.c b/exec_cmd.c
index 0ed768d..048f3ca 100644
--- a/exec_cmd.c
+++ b/exec_cmd.c
@@ -125,3 +125,25 @@ int execl_git_cmd(const char *cmd,...)
argv[argc] = NULL;
return execv_git_cmd(argv);
}
+
+char *lookup_program_in_path(const char *program)
+{
+ struct strbuf buf = STRBUF_INIT;
+ const char *path = getenv("PATH");
+
+ if (!path || !*path)
+ return NULL;
+
+ for (;;) {
+ const char *colon = strchrnul(path, PATH_SEP);
+
+ strbuf_setlen(&buf, 0);
+ strbuf_addf(&buf, "%.*s/%s",
+ (int)(colon - path), path, program);
+ if (!access(buf.buf, X_OK))
+ return strbuf_detach(&buf, NULL);
+ if (!*colon)
+ return NULL;
+ path = colon + 1;
+ }
+}
diff --git a/exec_cmd.h b/exec_cmd.h
index 0c46cd5..4548390 100644
--- a/exec_cmd.h
+++ b/exec_cmd.h
@@ -8,5 +8,6 @@ extern void setup_path(void);
extern int execv_git_cmd(const char **argv); /* NULL terminated */
extern int execl_git_cmd(const char *cmd, ...);
extern const char *system_path(const char *path);
+extern char *lookup_program_in_path(const char *program);
#endif /* GIT_EXEC_CMD_H */
diff --git a/git.c b/git.c
index 54c5bfa..0ec8ee1 100644
--- a/git.c
+++ b/git.c
@@ -428,6 +428,12 @@ int main(int argc, const char **argv)
do
--slash;
while (cmd <= slash && !is_dir_sep(*slash));
+ if (slash < cmd) {
+ cmd = lookup_program_in_path(cmd);
+ for (slash = (char *)cmd + strlen(cmd) - 1;
+ cmd <= slash && !is_dir_sep(*slash); slash--)
+ ; /* do nothing */
+ }
if (cmd <= slash) {
*slash++ = 0;
git_set_argv0_path(cmd);
--
1.5.6.2.516.g22071
^ permalink raw reply related
* Re: Official Git Homepage change? Re: git-scm.com
From: Petr Baudis @ 2008-07-26 14:17 UTC (permalink / raw)
To: Scott Chacon; +Cc: git
In-Reply-To: <d411cc4a0807260007i26791084lce6b6a8d74b831cc@mail.gmail.com>
Hi,
On Sat, Jul 26, 2008 at 12:07:03AM -0700, Scott Chacon wrote:
> On Fri, Jul 25, 2008 at 6:53 PM, Petr Baudis <pasky@suse.cz> wrote:
> > Plenty of minor fixes are available for pull at
> >
> > git://github.com/pasky/learn-github.git
> > (http://github.com/pasky/learn-github/tree/master)
>
> I've pulled in all this stuff and it should be live now.
thanks.
> >
> > Other non-trivial nits:
> >
> > * I'm feeling a bit uneasy about listing so many projects using Git;
> > I haven't heard about quite a few of these and I'm not sure on what
> > merit should we list projects. "Prototype" or "Liftweb" and probably
> > even "Rubinius", is that going to ring a bell for major part of visitors
> > so that they say "oh, even _those_ guys are using Git"?
>
> Based on a conversation in the other thread, I think we should have a
> list that is suggested by the community and just have the 3 or 4 that
> are really famous (Git, Linux, RoR...) and have the rest randomly
> pulled from that list - changed every day or so.
Maybe it is because of my general background, but I think X.org, WINE
and Fedora (probably in this order) really belong to the list as well.
If you say Prototype and MooTools are huge projects that are very
well-known in the web programmer community too, it makes sense to
include them as well; and that would be it. I might add
<p align="right"><em>...and many more</em><p>
below the list.
Having some of the list randomly generated is an interesting idea, but
it should be clearly visually separated from the static part, and it
would probably take a bit of work to tune this to show only interesting
projects ($size * sqrt(activity)$ or something).
> > * Reusing captions from command manpages in the Documentation page
> > shows nicely how awful they sometimes are. :-) This is probably something
> > to fix upstream, though.
>
> I saw you changed some of these, I can take another pass. I'm not
> entirely sure how useful it is to have the commands on that page, to
> tell the truth. This may go away as the documentation page evolves.
I agree. I changed none though, I just reordered some of the commands.
> > * Is "Git for the lazy" really unique in some regard to deserve to be
> > listed among the other resources? I think we should minimalize
> > redundancy at the documentation page, the amount of material is already
> > overwhelming and it should be obvious for the visitor which document to
> > choose based on his needs. I have similar doubts about the 37signals
> > resources.
> >
> > In other words, "let's keep the resources orthogonal!"
>
> I agree - I would like to pull a lot of the information in those links
> into one open-source book that is kept up by the community and hosted
> at this page. The documentation page will change significantly as we
> try to simplify and maximize the usefulness of the page.
But that's a long-term project, I'm talking about the usefulness of
some of the links right now.
> > * There is no reference to the Wiki in the documentation, only to the
> > [GitDocumentation] page; I think there should be a reference to the
> > [GitFaq] page too - a lot of important points that are not obvious
> > to newcomers are covered there. I'm just not sure where exactly to put
> > the link.
> >
> > * I would go as far as put the link to the Wiki itself to the
> > navigation bar, simply since it is such a crucial resource.
>
>
> Perhaps I should just do this - would that cover the previous one as well?
It seems you did, which is great! I think there should be a direct FAQ
link as well, though.
> > How does that compare with the Git user manual? Have you considered
> > collaborating on that one, or what are your reasons not to? Or are you
> > trying to do something different?
>
> I would like to - I have personally found that invaluable in learning
> Git, but I would like it to be more digestible and I would like to add
> a lot of supporting media to it - screencasts and diagrams, to help
> people that are more visual learners. Loading up a document where the
> TOC is several pages long is intimidating and difficult to start and
> stop with.
Making it more digestible is certainly a worthy goal. :-) I think both
screencasts and diagrams could be valuable for the user manual, but
the question is how to best integrate them into the manual and if it
makes sense to do this within the Git tree, or how to cross-merge.
However, at the documentation side I focus pretty much exclusively on
improving the reference documentation, so that's not for me to discuss.
--
Petr "Pasky" Baudis
As in certain cults it is possible to kill a process if you know
its true name. -- Ken Thompson and Dennis M. Ritchie
^ permalink raw reply
* Re: git sequencer prototype
From: Johannes Schindelin @ 2008-07-26 14:19 UTC (permalink / raw)
To: Stephan Beyer; +Cc: git, Christian Couder, Daniel Barkalow
In-Reply-To: <1217049644-8874-1-git-send-email-s-beyer@gmx.net>
Hi,
On Sat, 26 Jul 2008, Stephan Beyer wrote:
> In the last patchset I mentioned the issue, that the prototype is slow
> as hell. I know some bottlenecks, but I have not even tried to change
> that, because this is no issue for the builtin.
Why is it no issue for the builtin? Is it so much different from the
prototype?
Personally, I think if the prototype is so much slower, there is no sense
applying it into git.git, but I'd rather see you work on the builtin and
finalize it.
Ciao,
Dscho
^ permalink raw reply
* Re: Official Git Homepage change? Re: git-scm.com
From: Petr Baudis @ 2008-07-26 14:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Scott Chacon, git
In-Reply-To: <7vtzedmeqh.fsf@gitster.siamese.dyndns.org>
On Fri, Jul 25, 2008 at 09:49:42PM -0700, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > On Fri, 25 Jul 2008, Junio C Hamano wrote:
> >
> >> It's also somewhat interesting to observe that several people I have
> >> never heard of in the git circle are simultaneously doing new git books,
> >> apparently never asking for much technical advice from core git people,
> >> by the way.
I would say we actually worked hard to make itpossible to understand
Git without being a Git contributor and knowing the code inside-out,
didn't we? So in a sense, having books about Git written by people
outside of the developer community could be considered a certain
milestone for Git usability. At least provided the books are good, and
reading the excerpts from
http://www.pragprog.com/titles/tsgit/pragmatic-version-control-using-git
has been a little disturbing experience at times. Then again, it is an
early alpha probably far before technical editing, so it is too early
to draw conclusions. (And after doing technical editing for a very thick
Czech book on low-level Linux programming, my standards for this phase
of book development had to be... somewhat lowered. ;-)
> Oh, mine was not a criticism but was just an observation.
>
> Maybe the folks we consider as "git community members" are either too
> narrow, or too detached from the "real user community", and it could be
> that git books are better written without us.
The numbers in another part of the thread show something important -
GitHub is more than SIX TIMES BIGGER than repo.or.cz! How many of you
have GitHub accounts, and how many of you are actively using repo.or.cz?
:-) And GitHub is not "just" Ruby on Rails *at all*:
http://github.com/blog/99-popular-languages
Overally, it seems that Git is getting huge traction in the web
developers community while this is something I would presume the core
Git community of kernel hackers and such is mostly unaware of (and it is
somewhat amusing contrast). Now, these are people who we will probably
never see on the mailing list, not just because they frequently don't
even know C, and don't care to, but they might have actually never used
a mailing list before! These are the people who frequently could not
care about their VCS' internals less and finding out that Git works well
enough for them is something rather satisfying for me personally.
I don't know if this should have any immediate effect on how we
develop Git etc., but I think it is good to be aware of the fact that
silently, huge amount of "dark mass" Git projects is accumulating and
that Git is making headways in areas many of us were little aware of.
--
Petr "Pasky" Baudis
As in certain cults it is possible to kill a process if you know
its true name. -- Ken Thompson and Dennis M. Ritchie
^ permalink raw reply
* Re: Official Git Homepage change? Re: git-scm.com
From: Rene Herman @ 2008-07-26 14:48 UTC (permalink / raw)
To: Scott Chacon; +Cc: Junio C Hamano, Petr Baudis, git
In-Reply-To: <d411cc4a0807260027t4b9c3b08x1f865ec75d976ef6@mail.gmail.com>
On 26-07-08 09:27, Scott Chacon wrote:
> Perhaps it would be useful to split the mailing list into
> core/contrib and support lists? I would be happy to help out
> answering questions - a lot of them come directly to me anyhow
> because of the gitcasts site and such.
A git-user list would be welcomed at least by me. It remains to be seen
how useful it would be (and stay) as often the user lists for a project
dwinddle a bit but I've subcribed and unsubscribed to this list a number
of times now since unless I've a specific question to ask, the list is
too busy too just sit around on; I end up deleting all list mail unread
every night anyway, so I just unsubcribe again.
Maybe a less busy and less implementation focussed list could help "me
and mine" gradually pick up new tips and tricks. Depends ofcourse on
willingness of some of the more proficient to be involved in that list
as well...
Rene.
^ permalink raw reply
* Re: [PATCH 2/5] Add git-sequencer documentation
From: Johannes Schindelin @ 2008-07-26 14:47 UTC (permalink / raw)
To: Stephan Beyer; +Cc: git, Christian Couder, Daniel Barkalow
In-Reply-To: <1217049644-8874-3-git-send-email-s-beyer@gmx.net>
Hi,
On Sat, 26 Jul 2008, Stephan Beyer wrote:
> +-B::
> +--batch::
> + Run in batch mode. If unexpected user intervention is needed
> + (e.g. a conflict or the need to run an editor), 'git-sequencer' fails.
Does it abort, or leave a dirty tree?
> +--onto=<base>::
> + Checkout given commit or branch before sequencing.
> + If you provide a branch, sequencer will make the provided
> + changes on the branch, i.e. the branch will be changed.
Whoa, does that mean that
$ git checkout my-private-branch
$ git sequencer --onto=master
will change _master_?
> +--continue::
> + Restart the sequencing process after having resolved a merge conflict.
What about 'edit'? Does it restart the sequencing process after editing a
file or commit message, too?
> +--skip::
> + Restart the sequencing process by skipping the current instruction.
s/ by/,/
> +--status::
> + Show the current status of 'git-sequencer' and what
> + operations can be done to change that status.
Nice.
> +--edit::
> + Invoke editor to edit the unprocessed part of the TODO file.
Nice!
> +If you nonetheless noticed that you made a mistake, you can
> +overwrite `.git/sequencer/todo` with `.git/sequencer/todo.old` and
> +rerun `git sequencer --edit`.
Speaking of "todo": there was an explicit request to change that to
"git-rebase-todo" for rebase -i, so that syntax highlighting could be
switched on.
> +-q::
> +--quiet::
> + Suppress output. Implies `--no-advice`.
> + (Not yet implemented.)
So this is not meant for application yet. Okay.
> +-v::
> +--verbose::
> + Be more verbose.
More?
> +NOTES
> +-----
> +
> +When sequencing, it is possible, that you are changing the history of
s/possible,/possible/ I know that mistake, being a German myself.
> +a branch in a way that can cause problems for anyone who already has
> +a copy of the branch in their repository and tries to pull updates from
> +you. You should understand the implications of using 'git-sequencer' on
> +a repository that you share.
How about this instead?
Note that sequencing will rewrite the history of the branch.
This will cause problems if you published the branch prior to
rewriting the history, as the former tip is no longer an
ancestor of the new tip.
In other words, if you rewrite an already published branch, users
that pull from you _will_ get a bogus merge.
> +'git-sequencer' will usually be called by another git porcelain, like
s/another git procelain/other git programs/
> +TODO FILE FORMAT
> +----------------
> +
> +The TODO file contains basically one instruction per line.
s/basically //
> +edit <commit>::
> + Pick a commit and pause the sequencer process to let you
> + make changes.
> ++
> +This is a short form for `pick <commit> and `pause` on separate lines.
It might make sense to explain 'pick' before 'edit', then.
> +mark <mark>::
> + Set a symbolic mark for the last commit.
> + `<mark>` is an unsigned integer starting at 1 and
> + prefixed with a colon, e.g. `:1`.
> ++
> +The marks can help if you want to refer to commits that you
> +created during the sequencer process, e.g. if you want to
> +merge such a commit.
It might make sense to explain 'merge' before that, then.
> + --mainline=<n>;;
> + Allow you to pick merge commits by specifying the
> + parent number (beginning from 1) to let sequencer
> + replay the changes relative to the specified parent.
Why is this called "mainline", and not "parent"?
> [... talking about 'patch']
>
> + --exclude=<path-pattern>;;
> + Do not apply changes to files matching the given path pattern.
> + This can be useful when importing patchsets, where you want to
> + exclude certain files or directories.
You might just as well support the new "--directory" option of git-apply,
too, and/or --recount.
> [talking about 'squash']
>
> + --collect-signoffs;;
> + Collect the Signed-off-by: lines of each commit and
> + add them to the squashed commit message.
> + (Not yet implemented.)
I really have to wonder how useful that is. Or how correct, for that
matter.
> +
> + --include-merges;;
> + Sanity check does not fail if you have merges
> + between HEAD and <mark>.
It may be a commit, too, right? And why does it make sense to check that
there are no merges? I mean, it is just as if I did two cherry-picks, the
second with -n, and then commit --amend it. Can make tons of sense...
> +Here are some examples that shall ease the start with the TODO
> +file format.
> +Make sure you have understood the `pick` and perhaps the `patch` command.
> +Those will not be explained further.
This sentence is insulting. Strike it.
> +------------
> +$ git rev-list --no-merges --reverse A^..E | sed -e 's/^/pick /'`
> +------------
Don't.
$ git log --pretty=format:'pick %h' --no-merges --reverse A^..E
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 5/5] Migrate rebase-i to sequencer
From: Johannes Schindelin @ 2008-07-26 14:52 UTC (permalink / raw)
To: Stephan Beyer; +Cc: git, Christian Couder, Daniel Barkalow
In-Reply-To: <1217049644-8874-6-git-send-email-s-beyer@gmx.net>
Hi,
On Sat, 26 Jul 2008, Stephan Beyer wrote:
> For git-rebase-i -p (preserving merges) merges should be
> rewritten. For this, the sequencer instructions "mark", "merge"
> and "reset" are used.
Ah, the ugliness returns.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Set up argv0_path correctly, even when argv[0] is just the basename
From: Rene Herman @ 2008-07-26 14:54 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Steffen Prohaska, Johannes Sixt, git, Junio C Hamano
In-Reply-To: <alpine.DEB.1.00.0807261613120.26810@eeepc-johanness>
On 26-07-08 16:14, Johannes Schindelin wrote:
> When the program 'git' is in the PATH, the argv[0] is set to the
> basename. However, argv0_path needs the full path, so add a function
> to discover the program by traversing the PATH manually.
While not having read the context for this, this ofcourse sounds like a
huge gaping race-condition. If applicable here (as said, did not read
context) you generally want to make sure that there's no window that a
path could be replaced -- while perhaps not here, that's often the kind
of thing that security attacks end up abusing.
Rene.
^ permalink raw reply
* Re: [PATCH 2/7] builtin-help: change the current directory back in list_commands_in_dir()
From: Johannes Schindelin @ 2008-07-26 14:58 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git
In-Reply-To: <4f2b03391e3f85cf2224f97a2a7765d08707bd73.1217037178.git.vmiklos@frugalware.org>
Hi,
On Sat, 26 Jul 2008, Miklos Vajna wrote:
> That function used to do a chdir() without switching back to the
> original directory. That was not a problem till this function was used
> only inside builtin-help, but once other builtins use it as well, this
> is a problem, for example when the object database path is relative.
I had to work around that in my patch "git wrapper: DWIM mistyped
commands", too :-)
Ciao,
Dscho
^ 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