* Re: [PATCH] Define compat version of mkdtemp for systems lacking it
From: Johannes Schindelin @ 2007-10-21 22:03 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20071021053015.GA31995@spearce.org>
Hi,
On Sun, 21 Oct 2007, Shawn O. Pearce wrote:
> Solaris 9 doesn't have mkdtemp() so we need to emulate it for the
> rsync transport implementation.
Thanks. I've been meaning to do it for msysGit, but I never came around
to do it...
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] execv_git_cmd(): also try PATH if everything else fails.
From: Johannes Schindelin @ 2007-10-21 22:02 UTC (permalink / raw)
To: Scott Parish; +Cc: git
In-Reply-To: <20071021182150.GG16291@srparish.net>
Hi,
On Sun, 21 Oct 2007, Scott Parish wrote:
> diff --git a/exec_cmd.c b/exec_cmd.c
> index 9b74ed2..374ffc9 100644
> --- a/exec_cmd.c
> +++ b/exec_cmd.c
> @@ -99,8 +103,8 @@ int execv_git_cmd(const char **argv)
>
> trace_argv_printf(argv, -1, "trace: exec:");
>
> - /* execve() can only ever return if it fails */
> - execve(git_command, (char **)argv, environ);
> + /* execvp() can only ever return if it fails */
> + execvp(git_command, (char **)argv);
I'd rather have it conditional upon *exec_dir (see the brown paper bag
patch I just sent).
Ciao,
Dscho
^ permalink raw reply
* [PATCH] execv_git_cmd(): also try PATH if everything else fails.
From: Johannes Schindelin @ 2007-10-21 21:59 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Scott Parish, git
In-Reply-To: <20071021023614.GB14735@spearce.org>
Earlier, we tried to find the git commands in several possible exec
dirs. Now, if all of these failed, try to find the git command in
PATH.
This allows you to install the git programs somewhere else than
originally specified when building git, as long as you add that location
to the PATH.
Initial implementation by Scott R Parish.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
On Sat, 20 Oct 2007, Shawn O. Pearce wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > On Sat, 20 Oct 2007, Scott Parish wrote:
> >
> > > Actually, i didn't test it right, execve() were using the
> > > files in my cwd. In addition to you patch, you'd need to use
> > > execvp() instead of execve().
> >
> > Ah, right. I missed that one ;-)
> >
> > How about this instead?
>
> Uhhh. Its the same, isn't it? Still using execve() which means
> we will not look at PATH in the final attempt.
Sorry. I forgot to --amend.
exec_cmd.c | 17 ++++++++++++-----
1 files changed, 12 insertions(+), 5 deletions(-)
diff --git a/exec_cmd.c b/exec_cmd.c
index 9b74ed2..70b84b0 100644
--- a/exec_cmd.c
+++ b/exec_cmd.c
@@ -36,7 +36,8 @@ int execv_git_cmd(const char **argv)
int i;
const char *paths[] = { current_exec_path,
getenv(EXEC_PATH_ENVIRONMENT),
- builtin_exec_path };
+ builtin_exec_path,
+ "" };
for (i = 0; i < ARRAY_SIZE(paths); ++i) {
size_t len;
@@ -44,9 +45,12 @@ int execv_git_cmd(const char **argv)
const char *exec_dir = paths[i];
const char *tmp;
- if (!exec_dir || !*exec_dir) continue;
+ if (!exec_dir) continue;
- if (*exec_dir != '/') {
+ if (!*exec_dir)
+ /* try PATH */
+ *git_command = '\0';
+ else if (*exec_dir != '/') {
if (!getcwd(git_command, sizeof(git_command))) {
fprintf(stderr, "git: cannot determine "
"current directory: %s\n",
@@ -81,7 +85,7 @@ int execv_git_cmd(const char **argv)
len = strlen(git_command);
rc = snprintf(git_command + len, sizeof(git_command) - len,
- "/git-%s", argv[0]);
+ "%sgit-%s", *exec_dir ? "/" : "", argv[0]);
if (rc < 0 || rc >= sizeof(git_command) - len) {
fprintf(stderr,
"git: command name given is too long.\n");
@@ -100,7 +104,10 @@ int execv_git_cmd(const char **argv)
trace_argv_printf(argv, -1, "trace: exec:");
/* execve() can only ever return if it fails */
- execve(git_command, (char **)argv, environ);
+ if (*exec_dir)
+ execve(git_command, (char **)argv, environ);
+ else
+ execvp(git_command, (char **)argv);
trace_printf("trace: exec failed: %s\n", strerror(errno));
--
1.5.3.4.1289.ga1432
^ permalink raw reply related
* Re: [PATCH] Be nice with compilers that do not support runtime paths at all.
From: Benoit SIGOURE @ 2007-10-21 21:56 UTC (permalink / raw)
To: git list
In-Reply-To: <34DAC3CA-E226-4488-8B03-FC45A6A95F78@lrde.epita.fr>
[-- Attachment #1: Type: text/plain, Size: 3364 bytes --]
On Oct 4, 2007, at 5:59 PM, Benoit SIGOURE wrote:
> On Oct 4, 2007, at 1:18 AM, Junio C Hamano wrote:
>
>> Benoit Sigoure <tsuna@lrde.epita.fr> writes:
>>
>>> diff --git a/Makefile b/Makefile
>>> index a1fe443..7c6c453 100644
>>> --- a/Makefile
>>> +++ b/Makefile
>>> @@ -100,6 +100,9 @@ all::
>>> # that tells runtime paths to dynamic libraries;
>>> # "-Wl,-rpath=/path/lib" is used instead.
>>> #
>>> +# Define NO_RPATH if your dynamic loader doesn't support runtime
>>> paths at
>>> +# all.
>>> +#
>>> # Define USE_NSEC below if you want git to care about sub-second
>>> file mtimes
>>> # and ctimes. Note that you need recent glibc (at least 2.2.4)
>>> for this, and
>>> # it will BREAK YOUR LOCAL DIFFS! show-diff and anything using
>>> it will likely
>>
>> Thanks for this part;
>>
>>> @@ -507,6 +510,7 @@ ifeq ($(uname_S),Darwin)
>>> BASIC_LDFLAGS += -L/opt/local/lib
>>> endif
>>> endif
>>> + NO_RPATH = YesPlease
>>> endif
>>
>> I'll let Darwin users to fight the defaults for this part out.
>
> No more replies on this thread, and the Apple documentation
> confirms that there is no rpath support in the dynamic loader of
> OSX 10.4 and before. I don't know about the soon-to-be-released
> 10.5 aka Leopard.
>
>>> @@ -521,7 +525,10 @@ ifndef NO_CURL
>>> ifdef CURLDIR
>>> # Try "-Wl,-rpath=$(CURLDIR)/$(lib)" in such a case.
>>> BASIC_CFLAGS += -I$(CURLDIR)/include
>>> - CURL_LIBCURL = -L$(CURLDIR)/$(lib) $(CC_LD_DYNPATH)$(CURLDIR)/$
>>> (lib) -lcurl
>>> + CURL_LIBCURL = -L$(CURLDIR)/$(lib) -lcurl
>>> +ifndef NO_RPATH
>>> + CURL_LIBCURL += $(CC_LD_DYNPATH)$(CURLDIR)/$(lib)
>>> +endif
>>> else
>>> CURL_LIBCURL = -lcurl
>>> endif
>>
>>> @@ -539,7 +546,10 @@ endif
>>>
>>> ifdef ZLIB_PATH
>>> BASIC_CFLAGS += -I$(ZLIB_PATH)/include
>>> - EXTLIBS += -L$(ZLIB_PATH)/$(lib) $(CC_LD_DYNPATH)$(ZLIB_PATH)/$
>>> (lib)
>>> + EXTLIBS += -L$(ZLIB_PATH)/$(lib)
>>> +ifndef NO_RPATH
>>> + EXTLIBS += $(CC_LD_DYNPATH)$(ZLIB_PATH)/$(lib)
>>> +endif
>>> endif
>>> EXTLIBS += -lz
>>>
>>
>> While these parts are ugly but correct, I think...
>>
>>> @@ -547,7 +557,10 @@ ifndef NO_OPENSSL
>>> OPENSSL_LIBSSL = -lssl
>>> ifdef OPENSSLDIR
>>> BASIC_CFLAGS += -I$(OPENSSLDIR)/include
>>> - OPENSSL_LINK = -L$(OPENSSLDIR)/$(lib) $(CC_LD_DYNPATH)$
>>> (OPENSSLDIR)/$(lib)
>>> + OPENSSL_LINK = -L$(OPENSSLDIR)/$(lib)
>>> +ifndef NO_RPATH
>>> + OPENSSL_LINK = $(CC_LD_DYNPATH)$(OPENSSLDIR)/$(lib)
>>> +endif
>>> else
>>> OPENSSL_LINK =
>>> endif
>>
>> this and the ICONV one are missing s/=/+=/.
>
> You're right, sorry.
>
>>
>> If we do not care about supporting too old GNU make, we can do
>> this by first adding this near the top:
>>
>> ifndef NO_RPATH
>> LINKER_PATH = -L$(1) $(CC_LD_DYNPATH)$(1)
>> else
>> LINKER_PATH = -L$(1)
>> endif
>>
>> and then doing something like:
>>
>> CURL_LIBCURL = $(call LINKER_PATH,$(CURLDIR)/$(lib))
>> OPENSSL_LINK = $(call LINKER_PATH,$(OPENSSLDIR)/$(lib))
>>
>> to make it easier to read and less error prone.
>>
>
> Yes. I can rework the patch, but the question is: do you care
> about old GNU make? Can I rewrite the patch with this feature?
I know Junio is still offline but maybe someone else has an objection
against this?
--
Benoit Sigoure aka Tsuna
EPITA Research and Development Laboratory
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 186 bytes --]
^ permalink raw reply
* [PATCH] "git help -a" should search all exec_paths and PATH
From: Scott R Parish @ 2007-10-21 21:48 UTC (permalink / raw)
To: git
Currently "git help -a" only searches in the highest priority exec_path,
meaning at worst, nothing is listed if the git commands are only available
from the PATH. It also makes git slightly less extensible.
To fix this, help.c is modified to search in all the exec_paths and PATH
for potential git commands. So that it has access to all the exec_paths,
exec_cmd.c now exposes the various paths. "current_exec_path" is renamed
as its name is misleading.
Signed-off-by: Scott R Parish <srp@srparish.net>
---
exec_cmd.c | 26 +++++++++++---
exec_cmd.h | 3 ++
git.c | 2 +-
help.c | 103 +++++++++++++++++++++++++++++++++++++++++++-----------------
4 files changed, 98 insertions(+), 36 deletions(-)
diff --git a/exec_cmd.c b/exec_cmd.c
index 374ffc9..2c787a4 100644
--- a/exec_cmd.c
+++ b/exec_cmd.c
@@ -5,21 +5,35 @@
extern char **environ;
static const char *builtin_exec_path = GIT_EXEC_PATH;
-static const char *current_exec_path;
+static const char *argv_exec_path;
-void git_set_exec_path(const char *exec_path)
+void git_set_argv_exec_path(const char *exec_path)
{
- current_exec_path = exec_path;
+ argv_exec_path = exec_path;
}
+const char *git_argv_exec_path(void)
+{
+ return argv_exec_path;
+}
+
+const char *git_builtin_exec_path(void)
+{
+ return builtin_exec_path;
+}
+
+const char *git_env_exec_path(void)
+{
+ return getenv(EXEC_PATH_ENVIRONMENT);
+}
/* Returns the highest-priority, location to look for git programs. */
const char *git_exec_path(void)
{
const char *env;
- if (current_exec_path)
- return current_exec_path;
+ if (argv_exec_path)
+ return argv_exec_path;
env = getenv(EXEC_PATH_ENVIRONMENT);
if (env && *env) {
@@ -34,7 +48,7 @@ int execv_git_cmd(const char **argv)
{
char git_command[PATH_MAX + 1];
int i;
- const char *paths[] = { current_exec_path,
+ const char *paths[] = { argv_exec_path,
getenv(EXEC_PATH_ENVIRONMENT),
builtin_exec_path,
"" };
diff --git a/exec_cmd.h b/exec_cmd.h
index 849a839..315fe83 100644
--- a/exec_cmd.h
+++ b/exec_cmd.h
@@ -3,6 +3,9 @@
extern void git_set_exec_path(const char *exec_path);
extern const char* git_exec_path(void);
+extern const char* git_argv_exec_path(void);
+extern const char* git_builtin_exec_path(void);
+extern const char* git_env_exec_path(void);
extern int execv_git_cmd(const char **argv); /* NULL terminated */
extern int execl_git_cmd(const char *cmd, ...);
diff --git a/git.c b/git.c
index 853e66c..b67fb17 100644
--- a/git.c
+++ b/git.c
@@ -51,7 +51,7 @@ static int handle_options(const char*** argv, int* argc, int* envchanged)
if (!prefixcmp(cmd, "--exec-path")) {
cmd += 11;
if (*cmd == '=')
- git_set_exec_path(cmd + 1);
+ git_set_argv_exec_path(cmd + 1);
else {
puts(git_exec_path());
exit(0);
diff --git a/help.c b/help.c
index b0d2dd4..85b2853 100644
--- a/help.c
+++ b/help.c
@@ -93,37 +93,27 @@ static void pretty_print_string_list(struct cmdname **cmdname, int longest)
}
}
-static void list_commands(const char *exec_path, const char *pattern)
+static unsigned int list_commands_in_dir(const char *dir, const char *prefix)
{
unsigned int longest = 0;
- char path[PATH_MAX];
- int dirlen;
- DIR *dir = opendir(exec_path);
+ int start_dir = open(".", O_RDONLY, 0);
+ DIR *dirp = opendir(dir);
struct dirent *de;
- if (!dir) {
- fprintf(stderr, "git: '%s': %s\n", exec_path, strerror(errno));
- exit(1);
+ if (!dirp || chdir(dir)) {
+ fchdir(start_dir);
+ close(start_dir);
+ return 0;
}
- dirlen = strlen(exec_path);
- if (PATH_MAX - 20 < dirlen) {
- fprintf(stderr, "git: insanely long exec-path '%s'\n",
- exec_path);
- exit(1);
- }
-
- memcpy(path, exec_path, dirlen);
- path[dirlen++] = '/';
-
- while ((de = readdir(dir)) != NULL) {
+ while ((de = readdir(dirp)) != NULL) {
struct stat st;
int entlen;
-
- if (prefixcmp(de->d_name, "git-"))
+
+ if (prefixcmp(de->d_name, prefix))
continue;
- strcpy(path+dirlen, de->d_name);
- if (stat(path, &st) || /* stat, not lstat */
+
+ if (stat(de->d_name, &st) || /* stat, not lstat */
!S_ISREG(st.st_mode) ||
!(st.st_mode & S_IXUSR))
continue;
@@ -137,12 +127,67 @@ static void list_commands(const char *exec_path, const char *pattern)
add_cmdname(de->d_name + 4, entlen-4);
}
- closedir(dir);
- printf("git commands available in '%s'\n", exec_path);
- printf("----------------------------");
- mput_char('-', strlen(exec_path));
- putchar('\n');
+ closedir(dirp);
+ fchdir(start_dir);
+ close(start_dir);
+
+ return longest;
+}
+
+static unsigned int list_commands_in_PATH(const char *prefix)
+{
+ unsigned int longest = 0;
+ unsigned int len;
+ const char *env_path = getenv("PATH");
+ char *paths, *path, *colon;
+
+ if (!env_path)
+ return longest;
+
+ path = paths = xstrdup(env_path);
+
+ while ((char *)1 != path) {
+ if ((colon = strchr(path, ':')))
+ *colon = 0;
+
+ len = list_commands_in_dir(path, prefix);
+ longest = MAX(longest, len);
+
+ path = colon + 1;
+ }
+
+ free(paths);
+ return longest;
+}
+
+static void list_commands(const char *prefix)
+{
+ unsigned int longest = 0;
+ unsigned int len;
+ const char *paths[] = { git_argv_exec_path(),
+ git_env_exec_path(),
+ git_builtin_exec_path(),
+ "" };
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(paths); i++) {
+ if (!paths[i])
+ continue;
+
+ if (!*paths[i]) {
+ /* try PATH */
+ len = list_commands_in_PATH(prefix);
+ longest = MAX(longest, len);
+ }
+ else {
+ len = list_commands_in_dir(paths[i], prefix);
+ longest = MAX(longest, len);
+ }
+ }
+
+ printf("available git commands\n");
+ printf("----------------------\n");
pretty_print_string_list(cmdname, longest - 4);
putchar('\n');
}
@@ -158,7 +203,7 @@ static void list_common_cmds_help(void)
puts("The most commonly used git commands are:");
for (i = 0; i < ARRAY_SIZE(common_cmds); i++) {
- printf(" %s ", common_cmds[i].name);
+ printf(" %s ", common_cmds[i].name);
mput_char(' ', longest - strlen(common_cmds[i].name));
puts(common_cmds[i].help);
}
@@ -210,7 +255,7 @@ int cmd_help(int argc, const char **argv, const char *prefix)
else if (!strcmp(help_cmd, "--all") || !strcmp(help_cmd, "-a")) {
printf("usage: %s\n\n", git_usage_string);
if(exec_path)
- list_commands(exec_path, "git-*");
+ list_commands("git-");
exit(0);
}
--
1.5.3.4.209.g5d1ce-dirty
^ permalink raw reply related
* [PATCH] "git help" and "git help -a" shouldn't exit(1) unless they error
From: Scott R Parish @ 2007-10-21 21:47 UTC (permalink / raw)
To: git
Signed-off-by: Scott R Parish <srp@srparish.net>
---
help.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/help.c b/help.c
index 1cd33ec..b0d2dd4 100644
--- a/help.c
+++ b/help.c
@@ -204,14 +204,14 @@ int cmd_help(int argc, const char **argv, const char *prefix)
if (!help_cmd) {
printf("usage: %s\n\n", git_usage_string);
list_common_cmds_help();
- exit(1);
+ exit(0);
}
else if (!strcmp(help_cmd, "--all") || !strcmp(help_cmd, "-a")) {
printf("usage: %s\n\n", git_usage_string);
if(exec_path)
list_commands(exec_path, "git-*");
- exit(1);
+ exit(0);
}
else
--
1.5.3.4.209.g5d1ce-dirty
^ permalink raw reply related
* Re: .gittattributes handling has deficiencies
From: Steffen Prohaska @ 2007-10-21 20:21 UTC (permalink / raw)
To: david; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0710211056580.4818@asgard>
On Oct 21, 2007, at 7:57 PM, david@lang.hm wrote:
> On Sun, 21 Oct 2007, Steffen Prohaska wrote:
>
>> On Oct 21, 2007, at 7:09 PM, david@lang.hm wrote:
>>
>>> On Sun, 21 Oct 2007, Steffen Prohaska wrote:
>>>> On Oct 21, 2007, at 11:19 AM, david@lang.hm wrote:
>>>>>> But this is really hard to solve. We would need to compare
>>>>>> attributes before and after for _all_ files that have attributes
>>>>>> in one of the two commits and check if they changed. If so, we
>>>>>> need to do a fresh checkout according to the new attributes.
>>>>> if you know that you will get the new .gitattributes if it
>>>>> changes, setup a post-checkout hook to checkout everything if
>>>>> it has changed. it's far from ideal, but it should be a good,
>>>>> safe, first approximation.
>>>> That's not good enough. I'll stop using .gitattributes. I
>>>> need to teach >40 devs how to use git on Windows. I only use
>>>> features that work flawlessly. .gitattributes doesn't. It bit
>>>> me twice now.
>>> why would checking everything out if .gitattributes has changed
>>> not work? I can see why _not_ doing so would cause problems, and
>>> I freely acknowledge that this approach imposes a performance hit
>>> by checking everything out twice, but I don't see how it would
>>> not be reliable.
>>
>> What do you mean by "checking out everything"?
>> Which command do you propose?
>
> something like git checkout -f
I suspected this. I see two problems:
1) it's too dangerous: I throws away _all_ changes, not only
changes that are related to gitattributes.
2) it doesn't work reliably. git checkout -f will only update
files that git detects as changed. But you could have files that
should have crlf in the working copy but actually have only lf.
Those would not be updated.
I'll not recommend this. Not using .gitattributes is the only
sane solution.
Steffen
^ permalink raw reply
* [PATCH] Split out "exact content match" phase of rename detection
From: Linus Torvalds @ 2007-10-21 18:40 UTC (permalink / raw)
To: Git Mailing List, Junio C Hamano, Shawn O. Pearce
In-Reply-To: <alpine.LFD.0.999.0710201158580.10525@woody.linux-foundation.org>
Split out "exact content match" phase of rename detection
This makes the exact content match a separate function of its own.
Partly to cut down a bit on the size of the diffcore_rename() function
(which is too complex as it is), and partly because there are smarter
ways to do this than an O(m*n) loop over it all, and that function
should be rewritten to take that into account.
Whether I'll get to the rewrite or not is not clear, but this is a
worthy cleanup regardless.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
---
So, I'm looking a bit at rename handling, since it's got the scalability
problems. Andy Chu of google pointed to an algorithm that doesn't use a
m*n array, but instead a hash table to match things up, and that should be
much better. No promises as to whether I'll ever actually implement it,
but just looking at that diffcore_rename function makes your head ache,
and while this doesn't improve any code, at least it splits one
independent thing out of it..
---
diffcore-rename.c | 90 +++++++++++++++++++++++++++++++++--------------------
1 files changed, 56 insertions(+), 34 deletions(-)
diff --git a/diffcore-rename.c b/diffcore-rename.c
index 142e537..2077a9b 100644
--- a/diffcore-rename.c
+++ b/diffcore-rename.c
@@ -262,6 +262,58 @@ static int compute_stays(struct diff_queue_struct *q,
return 1;
}
+/*
+ * Find exact renames first.
+ *
+ * The first round matches up the up-to-date entries,
+ * and then during the second round we try to match
+ * cache-dirty entries as well.
+ *
+ * Note: the rest of the rename logic depends on this
+ * phase also populating all the filespecs for any
+ * entry that isn't matched up with an exact rename,
+ * see "is_exact_match()".
+ */
+static int find_exact_renames(void)
+{
+ int rename_count = 0;
+ int contents_too;
+
+ for (contents_too = 0; contents_too < 2; contents_too++) {
+ int i;
+
+ for (i = 0; i < rename_dst_nr; i++) {
+ struct diff_filespec *two = rename_dst[i].two;
+ int j;
+
+ if (rename_dst[i].pair)
+ continue; /* dealt with an earlier round */
+ for (j = 0; j < rename_src_nr; j++) {
+ int k;
+ struct diff_filespec *one = rename_src[j].one;
+ if (!is_exact_match(one, two, contents_too))
+ continue;
+
+ /* see if there is a basename match, too */
+ for (k = j; k < rename_src_nr; k++) {
+ one = rename_src[k].one;
+ if (basename_same(one, two) &&
+ is_exact_match(one, two,
+ contents_too)) {
+ j = k;
+ break;
+ }
+ }
+
+ record_rename_pair(i, j, (int)MAX_SCORE);
+ rename_count++;
+ break; /* we are done with this entry */
+ }
+ }
+ }
+ return rename_count;
+}
+
void diffcore_rename(struct diff_options *options)
{
int detect_rename = options->detect_rename;
@@ -270,12 +322,11 @@ void diffcore_rename(struct diff_options *options)
struct diff_queue_struct *q = &diff_queued_diff;
struct diff_queue_struct outq;
struct diff_score *mx;
- int i, j, rename_count, contents_too;
+ int i, j, rename_count;
int num_create, num_src, dst_cnt;
if (!minimum_score)
minimum_score = DEFAULT_RENAME_SCORE;
- rename_count = 0;
for (i = 0; i < q->nr; i++) {
struct diff_filepair *p = q->queue[i];
@@ -318,40 +369,11 @@ void diffcore_rename(struct diff_options *options)
if (rename_dst_nr * rename_src_nr > rename_limit * rename_limit)
goto cleanup;
- /* We really want to cull the candidates list early
+ /*
+ * We really want to cull the candidates list early
* with cheap tests in order to avoid doing deltas.
- * The first round matches up the up-to-date entries,
- * and then during the second round we try to match
- * cache-dirty entries as well.
*/
- for (contents_too = 0; contents_too < 2; contents_too++) {
- for (i = 0; i < rename_dst_nr; i++) {
- struct diff_filespec *two = rename_dst[i].two;
- if (rename_dst[i].pair)
- continue; /* dealt with an earlier round */
- for (j = 0; j < rename_src_nr; j++) {
- int k;
- struct diff_filespec *one = rename_src[j].one;
- if (!is_exact_match(one, two, contents_too))
- continue;
-
- /* see if there is a basename match, too */
- for (k = j; k < rename_src_nr; k++) {
- one = rename_src[k].one;
- if (basename_same(one, two) &&
- is_exact_match(one, two,
- contents_too)) {
- j = k;
- break;
- }
- }
-
- record_rename_pair(i, j, (int)MAX_SCORE);
- rename_count++;
- break; /* we are done with this entry */
- }
- }
- }
+ rename_count = find_exact_renames();
/* Have we run out the created file pool? If so we can avoid
* doing the delta matrix altogether.
^ permalink raw reply related
* Re: [PATCH] execv_git_cmd(): also try PATH if everything else fails.
From: Scott Parish @ 2007-10-21 18:21 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0710202258440.25221@racer.site>
Earlier, we tried to find the git commands in several possible exec
dirs. Now, if all of these failed, try to find the git command in
PATH.
This allows you to install the git programs somewhere else than
originally specified when building git, as long as you add that location
to the PATH.
Implementation by Johannes Schindelin
Signed-off-by: Scott R Parish <srp@srparish.net>
---
exec_cmd.c | 16 ++++++++++------
1 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/exec_cmd.c b/exec_cmd.c
index 9b74ed2..374ffc9 100644
--- a/exec_cmd.c
+++ b/exec_cmd.c
@@ -36,7 +36,8 @@ int execv_git_cmd(const char **argv)
int i;
const char *paths[] = { current_exec_path,
getenv(EXEC_PATH_ENVIRONMENT),
- builtin_exec_path };
+ builtin_exec_path,
+ "" };
for (i = 0; i < ARRAY_SIZE(paths); ++i) {
size_t len;
@@ -44,9 +45,12 @@ int execv_git_cmd(const char **argv)
const char *exec_dir = paths[i];
const char *tmp;
- if (!exec_dir || !*exec_dir) continue;
+ if (!exec_dir) continue;
- if (*exec_dir != '/') {
+ if (!*exec_dir)
+ /* try PATH */
+ *git_command = '\0';
+ else if (*exec_dir != '/') {
if (!getcwd(git_command, sizeof(git_command))) {
fprintf(stderr, "git: cannot determine "
"current directory: %s\n",
@@ -81,7 +85,7 @@ int execv_git_cmd(const char **argv)
len = strlen(git_command);
rc = snprintf(git_command + len, sizeof(git_command) - len,
- "/git-%s", argv[0]);
+ "%sgit-%s", *exec_dir ? "/" : "", argv[0]);
if (rc < 0 || rc >= sizeof(git_command) - len) {
fprintf(stderr,
"git: command name given is too long.\n");
@@ -99,8 +103,8 @@ int execv_git_cmd(const char **argv)
trace_argv_printf(argv, -1, "trace: exec:");
- /* execve() can only ever return if it fails */
- execve(git_command, (char **)argv, environ);
+ /* execvp() can only ever return if it fails */
+ execvp(git_command, (char **)argv);
trace_printf("trace: exec failed: %s\n", strerror(errno));
--
1.5.3.4.206.g58ba4-dirty
^ permalink raw reply related
* Re: .gittattributes handling has deficiencies
From: david @ 2007-10-21 17:57 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: git
In-Reply-To: <1A07FEE6-88D8-4ED7-BEFD-F7F3B71310A5@zib.de>
On Sun, 21 Oct 2007, Steffen Prohaska wrote:
> On Oct 21, 2007, at 7:09 PM, david@lang.hm wrote:
>
>> On Sun, 21 Oct 2007, Steffen Prohaska wrote:
>>
>>> On Oct 21, 2007, at 11:19 AM, david@lang.hm wrote:
>>>
>>>>> But this is really hard to solve. We would need to compare
>>>>> attributes before and after for _all_ files that have attributes
>>>>> in one of the two commits and check if they changed. If so, we
>>>>> need to do a fresh checkout according to the new attributes.
>>>> if you know that you will get the new .gitattributes if it changes, setup
>>>> a post-checkout hook to checkout everything if it has changed. it's far
>>>> from ideal, but it should be a good, safe, first approximation.
>>>
>>>
>>> That's not good enough. I'll stop using .gitattributes. I
>>> need to teach >40 devs how to use git on Windows. I only use
>>> features that work flawlessly. .gitattributes doesn't. It bit
>>> me twice now.
>>
>> why would checking everything out if .gitattributes has changed not work? I
>> can see why _not_ doing so would cause problems, and I freely acknowledge
>> that this approach imposes a performance hit by checking everything out
>> twice, but I don't see how it would not be reliable.
>
> What do you mean by "checking out everything"?
> Which command do you propose?
something like git checkout -f
David Lang
^ permalink raw reply
* Re: .gittattributes handling has deficiencies
From: Steffen Prohaska @ 2007-10-21 17:25 UTC (permalink / raw)
To: david; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0710211007430.4818@asgard>
On Oct 21, 2007, at 7:09 PM, david@lang.hm wrote:
> On Sun, 21 Oct 2007, Steffen Prohaska wrote:
>
>> On Oct 21, 2007, at 11:19 AM, david@lang.hm wrote:
>>
>>>> But this is really hard to solve. We would need to compare
>>>> attributes before and after for _all_ files that have attributes
>>>> in one of the two commits and check if they changed. If so, we
>>>> need to do a fresh checkout according to the new attributes.
>>> if you know that you will get the new .gitattributes if it
>>> changes, setup a post-checkout hook to checkout everything if it
>>> has changed. it's far from ideal, but it should be a good, safe,
>>> first approximation.
>>
>>
>> That's not good enough. I'll stop using .gitattributes. I
>> need to teach >40 devs how to use git on Windows. I only use
>> features that work flawlessly. .gitattributes doesn't. It bit
>> me twice now.
>
> why would checking everything out if .gitattributes has changed not
> work? I can see why _not_ doing so would cause problems, and I
> freely acknowledge that this approach imposes a performance hit by
> checking everything out twice, but I don't see how it would not be
> reliable.
What do you mean by "checking out everything"?
Which command do you propose?
Steffen
^ permalink raw reply
* Re: .gittattributes handling has deficiencies
From: david @ 2007-10-21 17:09 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: git
In-Reply-To: <B61AE1A9-E983-4ACE-BF71-8FDC113A4F34@zib.de>
On Sun, 21 Oct 2007, Steffen Prohaska wrote:
> On Oct 21, 2007, at 11:19 AM, david@lang.hm wrote:
>
>>> But this is really hard to solve. We would need to compare
>>> attributes before and after for _all_ files that have attributes
>>> in one of the two commits and check if they changed. If so, we
>>> need to do a fresh checkout according to the new attributes.
>>
>> if you know that you will get the new .gitattributes if it changes, setup a
>> post-checkout hook to checkout everything if it has changed. it's far from
>> ideal, but it should be a good, safe, first approximation.
>
>
> That's not good enough. I'll stop using .gitattributes. I
> need to teach >40 devs how to use git on Windows. I only use
> features that work flawlessly. .gitattributes doesn't. It bit
> me twice now.
why would checking everything out if .gitattributes has changed not work?
I can see why _not_ doing so would cause problems, and I freely
acknowledge that this approach imposes a performance hit by checking
everything out twice, but I don't see how it would not be reliable.
David Lang
> Luckily, core.autocrlf works if you set it before the first
> checkout and never change it. This seems sufficient for me if
> all files that have mixed line endings are fixed right away.
>
> Steffen
^ permalink raw reply
* Re: [PATCH] On error, do not list all commands, but point to --help option.
From: Andreas Ericsson @ 2007-10-21 14:17 UTC (permalink / raw)
To: Jan Hudec
Cc: Wincent Colaiuta, Shawn O. Pearce, Johannes Schindelin,
Jari Aalto, git
In-Reply-To: <20071021131351.GE8887@efreet.light.src>
Jan Hudec wrote:
> On Sun, Oct 21, 2007 at 14:42:25 +0200, Andreas Ericsson wrote:
>> Wincent Colaiuta wrote:
>>> El 21/10/2007, a las 4:06, Shawn O. Pearce escribió:
>>>> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>>>>>>> On Sat, 20 Oct 2007, Jari Aalto wrote:
>>>>>>>
>>>>>>>> - commented out call to list_common_cmds_help()
>>>>> Well, I'm almost sure of the opposite. One of the big results of the
>>>>> Git
>>>>> Survey was that git is still not user-friendly enough. Your patch would
>>>>> only make this issue worse.
>>>> Actually I think Jari's patch helps for the reason originally
>>>> stated in the message (less output when you make a small typo).
>>>> Though I agree that the commented out code should just be removed.
>>>>
>>>> I actually had to do `git config alias.upsh push` just to keep
>>>> myself from screaming every time I made a small typo and Git gave
>>>> me a screenful of "helpful reminders".
>>> If you want to go really user friendly, how about a check against the list
>>> of known commands using a shortest-edit distance algorithm?
>> http://en.wikipedia.org/wiki/Levenshtein_distance
>>
>> Implementing the algorithm doesn't seem terribly difficult.
>
> That's not the correct algorithm (you need to consider transpozitions, so you
> need at least http://en.wikipedia.org/wiki/Damerau-Levenshtein_distance, but
> I would not think that's the easier, or faster, way to do it. Though this
> would have to be benchmarked -- calculating the edit distance is quadratic,
> while generating the list of possibilities (and seeing whether they exist) is
> linear, but with large constant. So the question is, whether we have few
> enough commands that the quadratic calculation might be faster.
>
It's intended to be used for strings of length 3-14, run through once when the
user has given bogus input. We're not gonna index databases here. Simplicity
in the implementation almost certainly outweighs the performance penalty of
doing it the stupid way.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] On error, do not list all commands, but point to --help option.
From: Jan Hudec @ 2007-10-21 13:13 UTC (permalink / raw)
To: Andreas Ericsson
Cc: Wincent Colaiuta, Shawn O. Pearce, Johannes Schindelin,
Jari Aalto, git
In-Reply-To: <471B4931.5040102@op5.se>
[-- Attachment #1: Type: text/plain, Size: 1771 bytes --]
On Sun, Oct 21, 2007 at 14:42:25 +0200, Andreas Ericsson wrote:
> Wincent Colaiuta wrote:
>> El 21/10/2007, a las 4:06, Shawn O. Pearce escribió:
>>> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>>>>>> On Sat, 20 Oct 2007, Jari Aalto wrote:
>>>>>>
>>>>>>> - commented out call to list_common_cmds_help()
>>>>
>>>> Well, I'm almost sure of the opposite. One of the big results of the
>>>> Git
>>>> Survey was that git is still not user-friendly enough. Your patch would
>>>> only make this issue worse.
>>>
>>> Actually I think Jari's patch helps for the reason originally
>>> stated in the message (less output when you make a small typo).
>>> Though I agree that the commented out code should just be removed.
>>>
>>> I actually had to do `git config alias.upsh push` just to keep
>>> myself from screaming every time I made a small typo and Git gave
>>> me a screenful of "helpful reminders".
>> If you want to go really user friendly, how about a check against the list
>> of known commands using a shortest-edit distance algorithm?
>
> http://en.wikipedia.org/wiki/Levenshtein_distance
>
> Implementing the algorithm doesn't seem terribly difficult.
That's not the correct algorithm (you need to consider transpozitions, so you
need at least http://en.wikipedia.org/wiki/Damerau-Levenshtein_distance, but
I would not think that's the easier, or faster, way to do it. Though this
would have to be benchmarked -- calculating the edit distance is quadratic,
while generating the list of possibilities (and seeing whether they exist) is
linear, but with large constant. So the question is, whether we have few
enough commands that the quadratic calculation might be faster.
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* gitk still interested in translations?
From: Christian Stimming @ 2007-10-21 12:54 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git, Junio C Hamano
In-Reply-To: <18090.44123.905869.974967@cargo.ozlabs.ibm.com>
Hi Paul,
in July I submitted patches to add the necessary framework for UI
translations/i18n to the gitk tool [1] [2], and I'd also volunteer to provide
a full German translation. As you pointed out [3], this would require some
decisions on integration and installation places, which according to Junios
reply [4] didn't seem too difficult.
What is the progress on your i18n plans in gitk? None of the patches had been
applied to gitk, have they? If you say you *are* interested, I'd be happy to
provide an up-to-date patch against gitk.git @ kernel.org for #1 Makefile
rules, #2 msgcat integration, and most importantly #3 message markup.
Christian
[1] http://marc.info/?l=git&m=118554802809395&w=2
[2] http://marc.info/?l=git&m=118554865029767&w=2
[3] http://marc.info/?l=git&m=118559040716553&w=2
[4] http://marc.info/?l=git&m=118559853016496&w=2
Am Samstag, 28. Juli 2007 04:39 schrieb Paul Mackerras:
> Christian Stimming writes:
> > Similar to the discussion in git-gui, all user-visible strings are
> > passed through the [mc ...] procedure to have them translated by msgcat.
> >
> > Signed-off-by: Christian Stimming <stimming@tuhh.de>
> > ---
> > @Paul: Are you interested in applying this? If yes, I'd happily
>
> Yes, it doesn't look too bad. The patch seemed to be line-wrapped and
> whitespace-damaged, though.
>
> > provide the Makefile rules for string extraction and translation
> > catalog updates, but I'd like to hear a proposal or decision on where
> > to place them. Should the po files for translation go into the po/
> > subdirectory? And then a proposal/decision of where to install the
> > compiled .msg catalogs will be necessary.
>
> Yes indeed. Junio?
>
> Is it possible to include the translations, or at least the more
> common translations, in the Tcl code itself? So far I have managed to
> have gitk be self-contained, in that it doesn't need any external data
> files, which simplifies installation and is a useful attribute in some
> situations.
>
> Also I would want to be sure that gitk wouldn't crash or fail to
> function if it can't find its message catalogs.
>
> Paul.
^ permalink raw reply
* Re: [PATCH] On error, do not list all commands, but point to --help option.
From: Andreas Ericsson @ 2007-10-21 12:42 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: Shawn O. Pearce, Johannes Schindelin, Jari Aalto, git
In-Reply-To: <ED3FFB7A-861F-47E4-97EA-D7A05552FC2C@wincent.com>
Wincent Colaiuta wrote:
> El 21/10/2007, a las 4:06, Shawn O. Pearce escribió:
>
>> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>>>>> On Sat, 20 Oct 2007, Jari Aalto wrote:
>>>>>
>>>>>> - commented out call to list_common_cmds_help()
>>>
>>> Well, I'm almost sure of the opposite. One of the big results of the
>>> Git
>>> Survey was that git is still not user-friendly enough. Your patch would
>>> only make this issue worse.
>>
>> Actually I think Jari's patch helps for the reason originally
>> stated in the message (less output when you make a small typo).
>> Though I agree that the commented out code should just be removed.
>>
>> I actually had to do `git config alias.upsh push` just to keep
>> myself from screaming every time I made a small typo and Git gave
>> me a screenful of "helpful reminders".
>
> If you want to go really user friendly, how about a check against the
> list of known commands using a shortest-edit distance algorithm?
>
http://en.wikipedia.org/wiki/Levenshtein_distance
Implementing the algorithm doesn't seem terribly difficult.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH-resent] gitk: fix in procedure drawcommits
From: Rocco Rutte @ 2007-10-21 12:12 UTC (permalink / raw)
To: Michele Ballabio; +Cc: Paul Mackerras, git, Shawn O. Pearce
In-Reply-To: <200710201802.48111.barra_cuda@katamail.com>
[ No need to Cc: me as I'm on the git list, too ]
Hi,
* Michele Ballabio [07-10-20 18:02:47 +0200] wrote:
>Uh-oh. I think I just found the issue. That's probably a bug
>somewhere in the import (either fast-export or fast-import or
>the original repo, I don't know), so I'm not sure if gitk
>should be patched, but since the resulting repo seems correct
>as far as git is concerned (i.e. git fsck --full --strict
>doesn't complain), I guess something should be done.
>Here is the culprit (or so I think). One of the guilty commits is:
> commit a3b4383d69e0754346578c85ba8ff7c05bd88705
> tree 1bf99cd22abe97c59f8c0b7ad6b8244f0854b8af
> parent 6d919fccf603aba995035fa0fb507aa2bd3bf0ae
> parent 6d919fccf603aba995035fa0fb507aa2bd3bf0ae
> author Brendan Cully <brendan@kublai.com> 1179646159 -0700
> committer Brendan Cully <brendan@kublai.com> 1179646159 -0700
> Forget SMTP password if authentication fails.
> Thanks to Gregory Shapiro for the initial patch (I've moved the reset
> from smtp_auth_sasl up to smtp_auth, and used the account API
> instead of twiddling account bits by hand). Closes #2872.
Oh. Yes, this is a bug in the python scripts that get merges quite
wrong. I didn't notice that earlier as git doesn't complain and the
contents of the repo turns out as identical.
I'll push fixes (e.g. packed refs support) to the fast-export repo in
Monday. With these changes, the mutt repo as well hg-crew (which has far
more merges than the mutt repo) seem to work correctly (no identical
parents and identical contents).
Thanks for tracking it down.
Still I think fast-import could warn or error out if its gets such
content which doesn't really make sense...
Rocco
^ permalink raw reply
* Re: [PATCH 2/2] Correct some sizeof(size_t) != sizeof(unsigned long) typing errors
From: Pierre Habouzit @ 2007-10-21 10:31 UTC (permalink / raw)
To: René Scharfe; +Cc: Shawn O. Pearce, git
In-Reply-To: <471B1AA5.8070009@lsrfire.ath.cx>
[-- Attachment #1: Type: text/plain, Size: 958 bytes --]
On Sun, Oct 21, 2007 at 09:23:49AM +0000, René Scharfe wrote:
> > Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
> > ---
> > builtin-apply.c | 2 +-
> > builtin-archive.c | 2 +-
> > diff.c | 4 ++--
> > entry.c | 2 +-
> > strbuf.h | 8 +++++++-
> > test-delta.c | 3 ++-
> > 6 files changed, 14 insertions(+), 7 deletions(-)
>
> I have a feeling this is going in then wrong direction. Shouldn't
> we rather use size_t everywhere? malloc() takes a size_t, and it's
> the basis of strbuf and also of the file content functions.
I agree, Junio was working on a patch that generalized use of size_t's
when unsigned long where used and size_t meant, I suppose he didn't had
the time to push it.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: .gittattributes handling has deficiencies
From: Steffen Prohaska @ 2007-10-21 10:27 UTC (permalink / raw)
To: david; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0710210204580.4818@asgard>
On Oct 21, 2007, at 11:19 AM, david@lang.hm wrote:
>> But this is really hard to solve. We would need to compare
>> attributes before and after for _all_ files that have attributes
>> in one of the two commits and check if they changed. If so, we
>> need to do a fresh checkout according to the new attributes.
>
> if you know that you will get the new .gitattributes if it changes,
> setup a post-checkout hook to checkout everything if it has
> changed. it's far from ideal, but it should be a good, safe, first
> approximation.
That's not good enough. I'll stop using .gitattributes. I
need to teach >40 devs how to use git on Windows. I only use
features that work flawlessly. .gitattributes doesn't. It bit
me twice now.
Luckily, core.autocrlf works if you set it before the first
checkout and never change it. This seems sufficient for me if
all files that have mixed line endings are fixed right away.
Steffen
^ permalink raw reply
* Re: [PATCH] On error, do not list all commands, but point to --help option
From: Jan Hudec @ 2007-10-21 10:09 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Jari Aalto, git
In-Reply-To: <20071021033318.GD14735@spearce.org>
[-- Attachment #1: Type: text/plain, Size: 564 bytes --]
On Sat, Oct 20, 2007 at 23:33:18 -0400, Shawn O. Pearce wrote:
> Jari Aalto <jari.aalto@cante.net> wrote:
> > - Remove out call to list_common_cmds_help()
>
> Even if the list is against this change (which I'm in favor of)...
I didn't get the impression that the _whole_ list is against. I think that
the rather longish list should only be shown for 'git help' and when no
command was specified (but that is handled by implying help, so this change
does not apply to that case), so I am in favor of this.
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Announcement of Git wikibook
From: Steffen Prohaska @ 2007-10-21 10:06 UTC (permalink / raw)
To: Wincent Colaiuta
Cc: Steven Walter, Johannes Schindelin, Ciprian Dorin Craciun,
Evan Carroll, git
In-Reply-To: <F430333B-B29B-4992-9474-0E87006CBA77@wincent.com>
On Oct 21, 2007, at 11:10 AM, Wincent Colaiuta wrote:
> El 21/10/2007, a las 5:09, Steven Walter escribió:
>
>> On Sat, Oct 20, 2007 at 10:34:34PM +0100, Johannes Schindelin wrote:
>>> I am torn. On one side I like the Wiki approach. On the other
>>> hand, the
>>> Wiki will get less review by git oldtimers, whereas the patches to
>>> user-manual are usually reviewed as thoroughly as the code patches.
>>
>> No offense, but review by old timers can be both a blessing and a
>> curse.
>> Well, it's not the "review" that is so much a problem as the
>> "editorial
>> control." In my opinion (and I believe this is what the original
>> poster
>> was saying), the official Git User Manual focuses more on technical
>> issues and less on introducing git to a new user.
>
> But it's not an "intro", it's a user manual. That means it's
> supposed to be a comprehensive, in-depth treatment of just about
> everything. The technical content is a good thing; it's supposed to
> be the document you turn to when you want to move beyond
> superficial use to genuine, in-depth understanding.
But it could also have introductory parts and parts decribing
specific workflows.
Something similar to svnbook or cvsbook would be perfect. I
believe a reasonable goal is that you'll get all need if you
search gitbook with google.
Steffen
^ permalink raw reply
* Re: [BUG] git-mv submodule failure
From: Johannes Schindelin @ 2007-10-21 10:02 UTC (permalink / raw)
To: Yin Ping; +Cc: git
In-Reply-To: <46dff0320710202248v56af5cb0gcf7dacb32848eca3@mail.gmail.com>
Hi,
On Sun, 21 Oct 2007, Yin Ping wrote:
> > But of course .gitmodules is unaffected. But it should be changed, too.
>
> IMHO, changing .gitmodules is what the 'git-submodule mv' should do, and
> 'git-mv' should only rename the module directory
No. If you "git mv" a submodule, it makes absolutely no sense to leave
.gitmodules as is.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] git-cherry-pick: improve description of -x.
From: Ralf Wildenhues @ 2007-10-21 9:36 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Frank Lichtenheld, git
In-Reply-To: <20071020031917.GR14735@spearce.org>
Reword the first sentence of the description of -x, in order to
make it easier to read and understand.
Signed-off-by: Ralf Wildenhues <Ralf.Wildenhues@gmx.de>
---
* Shawn O. Pearce wrote on Sat, Oct 20, 2007 at 05:19:17AM CEST:
> Frank Lichtenheld <frank@lichtenheld.de> wrote:
> > On Fri, Oct 19, 2007 at 07:41:34PM +0200, Ralf Wildenhues wrote:
> > >
> > > Is that by design (because there were conflicts) or an omission?
> > > In case of the former, maybe the description of -x should mention this.
> >
> > git commit currently doesn't know that you commit a cherry-pick. The -c
> > only says to use the commit message of the original commit. So this is
> > currently by design.
>
> Ralf, can you submit an updated version of this patch that describes
> the current behavior better, given the "by design" remark above
> from Frank?
Here it goes. Still makes me wonder whether that is the ideal mode of
operation or not.
FWIW, I think the previous passive voice wording was correct English,
but here's a rewrite using mostly active voice (sound nicer anyway).
Cheers,
Ralf
Documentation/git-cherry-pick.txt | 11 ++++++-----
1 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/Documentation/git-cherry-pick.txt b/Documentation/git-cherry-pick.txt
index 47b1e8c..76a2edf 100644
--- a/Documentation/git-cherry-pick.txt
+++ b/Documentation/git-cherry-pick.txt
@@ -27,11 +27,12 @@ OPTIONS
message prior committing.
-x::
- Cause the command to append which commit was
- cherry-picked after the original commit message when
- making a commit. Do not use this option if you are
- cherry-picking from your private branch because the
- information is useless to the recipient. If on the
+ When recording the commit, append to the original commit
+ message a note that indicates which commit this change
+ was cherry-picked from. Append the note only for cherry
+ picks without conflicts. Do not use this option if
+ you are cherry-picking from your private branch because
+ the information is useless to the recipient. If on the
other hand you are cherry-picking between two publicly
visible branches (e.g. backporting a fix to a
maintenance branch for an older release from a
--
1.5.3.1.153.g89df5
^ permalink raw reply related
* Re: [PATCH 2/2] Correct some sizeof(size_t) != sizeof(unsigned long) typing errors
From: René Scharfe @ 2007-10-21 9:23 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20071021052537.GB31927@spearce.org>
Fix size_t vs. unsigned long pointer mismatch warnings introduced
with the addition of strbuf_detach().
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
---
Shawn O. Pearce schrieb:
> On at least one system I've used recently sizeof(size_t) == 4
> and sizeof(unsigned long) == 8. Trying to pass a pointer to an 8
> byte value into strbuf_detach() causes problems as the function is
> expecting an address for a 4 byte result location. Writing only 4
> bytes here will leave the other 4 bytes unitialized and may cause
> problems when the caller evalutes the result.
>
> I am introducing strbuf_detach_ul() as a variant that takes its
> size as an unsigned long rather than as a size_t. This approach is
> shorter than fixing all of the callers to use their own temporary
> size_t value for the call.
>
> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
> ---
> builtin-apply.c | 2 +-
> builtin-archive.c | 2 +-
> diff.c | 4 ++--
> entry.c | 2 +-
> strbuf.h | 8 +++++++-
> test-delta.c | 3 ++-
> 6 files changed, 14 insertions(+), 7 deletions(-)
I have a feeling this is going in then wrong direction. Shouldn't
we rather use size_t everywhere? malloc() takes a size_t, and it's
the basis of strbuf and also of the file content functions.
The following patch is shorter, though it adds one more line than
your's. The result is slightly uglier, but it's a good reminder to
use size_t in more places.
That said, I realize that converting read_sha1_file() et al. would
be quite painful. Maybe too painful?
builtin-apply.c | 2 +-
builtin-archive.c | 4 +++-
diff.c | 8 ++++++--
entry.c | 4 +++-
4 files changed, 13 insertions(+), 5 deletions(-)
diff --git a/builtin-apply.c b/builtin-apply.c
index 047a60d..541a6f4 100644
--- a/builtin-apply.c
+++ b/builtin-apply.c
@@ -152,7 +152,7 @@ struct patch {
unsigned int is_rename:1;
struct fragment *fragments;
char *result;
- unsigned long resultsize;
+ size_t resultsize;
char old_sha1_prefix[41];
char new_sha1_prefix[41];
struct patch *next;
diff --git a/builtin-archive.c b/builtin-archive.c
index 04385de..6f29c2f 100644
--- a/builtin-archive.c
+++ b/builtin-archive.c
@@ -148,12 +148,14 @@ void *sha1_file_to_archive(const char *path, const unsigned char *sha1,
buffer = read_sha1_file(sha1, type, sizep);
if (buffer && S_ISREG(mode)) {
struct strbuf buf;
+ size_t size = 0;
strbuf_init(&buf, 0);
strbuf_attach(&buf, buffer, *sizep, *sizep + 1);
convert_to_working_tree(path, buf.buf, buf.len, &buf);
convert_to_archive(path, buf.buf, buf.len, &buf, commit);
- buffer = strbuf_detach(&buf, sizep);
+ buffer = strbuf_detach(&buf, &size);
+ *sizep = size;
}
return buffer;
diff --git a/diff.c b/diff.c
index 0bd7e24..df82ed6 100644
--- a/diff.c
+++ b/diff.c
@@ -1512,6 +1512,7 @@ static int reuse_worktree_file(const char *name, const unsigned char *sha1, int
static int populate_from_stdin(struct diff_filespec *s)
{
struct strbuf buf;
+ size_t size = 0;
strbuf_init(&buf, 0);
if (strbuf_read(&buf, 0, 0) < 0)
@@ -1519,7 +1520,8 @@ static int populate_from_stdin(struct diff_filespec *s)
strerror(errno));
s->should_munmap = 0;
- s->data = strbuf_detach(&buf, &s->size);
+ s->data = strbuf_detach(&buf, &size);
+ s->size = size;
s->should_free = 1;
return 0;
}
@@ -1609,9 +1611,11 @@ int diff_populate_filespec(struct diff_filespec *s, int size_only)
*/
strbuf_init(&buf, 0);
if (convert_to_git(s->path, s->data, s->size, &buf)) {
+ size_t size = 0;
munmap(s->data, s->size);
s->should_munmap = 0;
- s->data = strbuf_detach(&buf, &s->size);
+ s->data = strbuf_detach(&buf, &size);
+ s->size = size;
s->should_free = 1;
}
}
diff --git a/entry.c b/entry.c
index 98f5f6d..cfadc6a 100644
--- a/entry.c
+++ b/entry.c
@@ -119,8 +119,10 @@ static int write_entry(struct cache_entry *ce, char *path, const struct checkout
*/
strbuf_init(&buf, 0);
if (convert_to_working_tree(ce->name, new, size, &buf)) {
+ size_t newsize = 0;
free(new);
- new = strbuf_detach(&buf, &size);
+ new = strbuf_detach(&buf, &newsize);
+ size = newsize;
}
if (to_tempfile) {
^ permalink raw reply related
* Re: .gittattributes handling has deficiencies
From: david @ 2007-10-21 9:19 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: git
In-Reply-To: <1192956535617-git-send-email-prohaska@zib.de>
On Sun, 21 Oct 2007, Steffen Prohaska wrote:
> If a .gitattributes is in the work tree and we checkout a
> different head, the .gitattributes of the head we are switching
> to must have precedence. Files are expected to be converted as
> configured in the .gitattributes that is available in the head
> we're switching to.
>
> This adds a test case revealing deficiencies of the current
> handling of .gitattributes.
>
> At a first glance, I saw two possible resolutions:
> 1) .gitattributes from the index has precedence. It's unclear
> how merging can be handled appropriately.
> 2) .gitattributes are handled as a special file. Checkout is a
> two pass process. In the first pass only the special file
> .gitattributes is checked out. In th second pass the remaining
> files are added. Maybe this gives a perspective how to handle
> merges.
>
> But actually the issue is much harder to solve.
>
> Here is what needs to be done: Whenever the attributes of a file
> change the file must be freshly checked out according to the
> attributes of the head we switch to.
this is the same problem that we would have with the extended file
attributes, in the discussion for those it was suggested that I refrence
the file from the index rather then from the file system to avoid needing
to do two passes.
> The file itself does not
> necessarily change between the two commits. A fresh checkout is
> already needed if only .gitattributes change.
>
> But this is really hard to solve. We would need to compare
> attributes before and after for _all_ files that have attributes
> in one of the two commits and check if they changed. If so, we
> need to do a fresh checkout according to the new attributes.
if you know that you will get the new .gitattributes if it changes, setup
a post-checkout hook to checkout everything if it has changed. it's far
from ideal, but it should be a good, safe, first approximation.
you shouldn't need to check all files of all attributes, only on any that
match the lines that get changed. the hook for this is exactly the type of
thing that I was talking about in the metastore thread.
> Maybe the gitattributes of a file should be part of the per-file
> flags in the index. Thus we could verify if the flags changed and
> if so, adjust the work tree accordig to the new flags. I'm
> lacking a deeper insight into the git internals. Therefore, I
> can't really say if the index is the right place. But it looks
> to me as if changing an attribute should be treated similar to a
> changing sha1, as far as the work tree is concerned.
the problem with this is that each attribute ends up needing it's own
flag, which severely limits extending things (see the discussions on file
permissions for examples). it's also much harder to manipulate them then
in a file.
David Lang
> So, I need some help.
> Steffen
>
> ---
> t/t0020-crlf.sh | 23 +++++++++++++++++++++++
> 1 files changed, 23 insertions(+), 0 deletions(-)
>
> diff --git a/t/t0020-crlf.sh b/t/t0020-crlf.sh
> index 62bc4bb..5d7e033 100755
> --- a/t/t0020-crlf.sh
> +++ b/t/t0020-crlf.sh
> @@ -371,6 +371,29 @@ test_expect_success 'in-tree .gitattributes (4)' '
> }
> '
>
> +test_expect_success 'in-tree .gitattributes (5)' '
> +
> + git reset --hard master &&
> + echo >.gitattributes &&
> + git add .gitattributes &&
> + git commit -m "empty .gitattributes" &&
> + rm -rf tmp one dir .gitattributes patch.file three &&
> + git reset --hard master &&
> + git checkout master^ &&
> +
> + if remove_cr one >/dev/null
> + then
> + echo "Eh? one should not have CRLF"
> + false
> + else
> + : happy
> + fi &&
> + remove_cr three >/dev/null || {
> + echo "Eh? three should still have CRLF"
> + false
> + }
> +'
> +
> test_expect_success 'invalid .gitattributes (must not crash)' '
>
> echo "three +crlf" >>.gitattributes &&
>
^ 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