* Re: [PATCH 6/7] walk PATH to generate list of commands for "help -a"
From: Junio C Hamano @ 2007-10-25 5:33 UTC (permalink / raw)
To: Scott Parish; +Cc: git
In-Reply-To: <20071025050736.GG759@srparish.net>
Scott Parish <sRp@srparish.net> writes:
> On Wed, Oct 24, 2007 at 09:42:42PM -0700, Junio C Hamano wrote:
>
>> Scott R Parish <srp@srparish.net> writes:
>>
>> > Signed-off-by: Scott R Parish <srp@srparish.net>
>>
>> Rationale?
>
> Well, the ultimate reason that i've been working on all of this is
> i'd like to push git as a viable development tool where i work. To
> give an effective idea, lets say that shared tools get placed on
> nfs servers, which can be mounted to different paths depending on
> which nfs server is up or down or which system is the nfs client.
It sounds to me that your nfs client systems might find what
people usually expect in /usr/local/bin not there but on
/mnt/random47/bin depending on the system, without a reasonable
system administration effort that places stable symlinks to give
end users a consistent view of the world regardless from which
client, which sounds insane. I personally do not think we
should support lazy system administrators by making git unsafe.
But using PATH as a fallback is what we already do for scripts,
and that is good enough to deal with such an installation.
> Should i be putting all that in my commit messages?
Even in a well behaved installation, where everything is found
where they should be (iow, GIT_EXEC_PATH), this is needed
because 4/7 lets you run a custom "git that" command from PATH
and this 6/7 is to teach "help -a" about it. I think at least
that much needs to be said in the commit message.
>> There are two cases execv_git_cmd() runs "git-that" from a non
>> standard place, if we take your [PATCH 4/7].
>>
>> - If there is a directory that contains a location that used to
>> hold an old installation of git-* commands (some of which may
>> have been removed in the latest git) and if the user has that
>> directory on PATH, we would run obsolete git subcommand from
>> there.
>
> I could see that as being problematic. I suppose there are ways
> around that (have "git" pass to "git-cmd" an argument of what version
> it is) but none that i really like.
As I said, this is making git a bit less safe from unintended
leftover executables, but the scripts already work that way and
your 4/7 merely makes the C level in line with that behaviour.
I do not think it is too much of a problem anyway.
>> It may be nicer if the user can somehow tell from the output if
>> each of the command is from the standard set (i.e. on
>> GIT_EXEC_PATH or built-in), or from a non standard place (either
>> custom command as intended, or an unintended obsolete leftover).
>
> What if git marked commands that weren't found in the location where
> it thinks that it is running from?
Currently "git help -a" says "available in $where" at the top.
Perhaps make a separate list that is listed as "available from
elsewhere" and show the ones that are on PATH but not masked by
the ones on GIT_EXEC_PATH?
git commands available in '/home/junio/git-next/bin'
----------------------------------------------------
add gui rebase--interactive
add--interactive hash-object receive-pack
...
git commands available from elsewhere on your $PATH
----------------------------------------------------
frotz nitfol
^ permalink raw reply
* Re: [PATCH 6/7] walk PATH to generate list of commands for "help -a"
From: Scott Parish @ 2007-10-25 5:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vve8v24al.fsf@gitster.siamese.dyndns.org>
On Wed, Oct 24, 2007 at 09:42:42PM -0700, Junio C Hamano wrote:
> Scott R Parish <srp@srparish.net> writes:
>
> > Signed-off-by: Scott R Parish <srp@srparish.net>
>
> Rationale?
Well, the ultimate reason that i've been working on all of this is
i'd like to push git as a viable development tool where i work. To
give an effective idea, lets say that shared tools get placed on
nfs servers, which can be mounted to different paths depending on
which nfs server is up or down or which system is the nfs client.
I have no control over each users PATH nor things like MANPATH or
GIT_EXEC_PATH and have no way of compiling in a path ahead of time,
but i would like to provide the easiest user experiance possible,
meaning that whether they have git in their PATH, or whether they
are using an absolute or relative path to it, it just works, hopefully
including "git help" and "git help -a".
Should i be putting all that in my commit messages?
> There are two cases execv_git_cmd() runs "git-that" from a non
> standard place, if we take your [PATCH 4/7].
>
> - If there is a directory that contains a location that used to
> hold an old installation of git-* commands (some of which may
> have been removed in the latest git) and if the user has that
> directory on PATH, we would run obsolete git subcommand from
> there.
I could see that as being problematic. I suppose there are ways
around that (have "git" pass to "git-cmd" an argument of what version
it is) but none that i really like.
> - If the user has a custom command "git-that" in $HOME/bin/
> that is outside GIT_EXEC_PATH, the new subcommand "that" can
> be used as if it is part of the official git. This is an
> improvement [PATCH 4/7] would bring in. We allow this
> already for scripts anyway, and the patch is merely making
> the behaviour of the execv_git_cmd() consistent with it.
>
> It may be nicer if the user can somehow tell from the output if
> each of the command is from the standard set (i.e. on
> GIT_EXEC_PATH or built-in), or from a non standard place (either
> custom command as intended, or an unintended obsolete leftover).
What if git marked commands that weren't found in the location where
it thinks that it is running from?
sRp
--
Scott Parish
http://srparish.net/
^ permalink raw reply
* Re: [PATCH 2/7] s/pattern/prefix/ in help's list_commands
From: Scott Parish @ 2007-10-25 4:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v640v3ix1.fsf@gitster.siamese.dyndns.org>
On Wed, Oct 24, 2007 at 09:41:30PM -0700, Junio C Hamano wrote:
> Scott R Parish <srp@srparish.net> writes:
>
> > list_commands() currently accepts and ignores a "pattern" argument,
> > and then hard codes a prefix as well as some magic numbers.
>
> Correct observation.
>
> Personally, I find this static function should not pretend to be
> as flexible --- it is to list git subcommands anyway (and it
> even knows about ".exe"), so rather than renaming the pattern
> and using it, it might be simpler and cleaner to just drop the
> parameter and be done with it.
Nice, i like that even better
sRp
--
Scott Parish
http://srparish.net/
^ permalink raw reply
* Re: [PATCH 1/7] "git" calls help_unknown_cmd(""); "git help" and "git help -a" return 0
From: Scott Parish @ 2007-10-25 4:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vd4v33iy0.fsf@gitster.siamese.dyndns.org>
On Wed, Oct 24, 2007 at 09:40:55PM -0700, Junio C Hamano wrote:
> Sorry, but I fail to see why this is an improvement.
>
> However, with the current implementation, these changes to
> help.c also make "git<Enter>" to exit with 0 after it gives
> help, which is not so nice (both "cvs" and "svn" without
> parameter seem to exit with 1 and it sort of makes sense,
> although I do not think it matters much). As a few datapoints,
> "cvs -H" exits with 1 and "svn help" exits with 0.
That's strange because when i run that patch on my system:
% ./git; echo $?
git: '' is not a git-command
<list of common commands>
1
% ./git help; echo $?
<list of common commands>
0
% ./git help -a; echo $?
<list of all commands>
0
> So in short,
>
> - "git" should retain the current behaviour (both output and
> exit code).
>
> - "git help" should retain the current output but probably
> should exit with 0.
>
> - Ditto for "git help -a".
That's what i was hoping this patch did. I'm not entirely sure how
its wrong as it seems to work for me.
Regarding "git: '' is not a git-command" the way i was seeing that
is that git is usually only called with commands, and '' isn't a
valid command, hence the reason to exit 1, the help is just a nice
user experience.
sRp
--
Scott Parish
http://srparish.net/
^ permalink raw reply
* Re: [PATCH 6/7] walk PATH to generate list of commands for "help -a"
From: Junio C Hamano @ 2007-10-25 4:42 UTC (permalink / raw)
To: Scott R Parish; +Cc: git
In-Reply-To: <1193283437-1706-6-git-send-email-srp@srparish.net>
Scott R Parish <srp@srparish.net> writes:
> Signed-off-by: Scott R Parish <srp@srparish.net>
Rationale?
There are two cases execv_git_cmd() runs "git-that" from a non
standard place, if we take your [PATCH 4/7].
- If there is a directory that contains a location that used to
hold an old installation of git-* commands (some of which may
have been removed in the latest git) and if the user has that
directory on PATH, we would run obsolete git subcommand from
there.
- If the user has a custom command "git-that" in $HOME/bin/
that is outside GIT_EXEC_PATH, the new subcommand "that" can
be used as if it is part of the official git. This is an
improvement [PATCH 4/7] would bring in. We allow this
already for scripts anyway, and the patch is merely making
the behaviour of the execv_git_cmd() consistent with it.
It may be nicer if the user can somehow tell from the output if
each of the command is from the standard set (i.e. on
GIT_EXEC_PATH or built-in), or from a non standard place (either
custom command as intended, or an unintended obsolete leftover).
^ permalink raw reply
* Re: [PATCH 2/7] s/pattern/prefix/ in help's list_commands
From: Junio C Hamano @ 2007-10-25 4:41 UTC (permalink / raw)
To: Scott R Parish; +Cc: git
In-Reply-To: <1193283437-1706-2-git-send-email-srp@srparish.net>
Scott R Parish <srp@srparish.net> writes:
> list_commands() currently accepts and ignores a "pattern" argument,
> and then hard codes a prefix as well as some magic numbers.
Correct observation.
Personally, I find this static function should not pretend to be
as flexible --- it is to list git subcommands anyway (and it
even knows about ".exe"), so rather than renaming the pattern
and using it, it might be simpler and cleaner to just drop the
parameter and be done with it.
^ permalink raw reply
* Re: [PATCH 1/7] "git" calls help_unknown_cmd(""); "git help" and "git help -a" return 0
From: Junio C Hamano @ 2007-10-25 4:40 UTC (permalink / raw)
To: Scott R Parish; +Cc: git
In-Reply-To: <1193283437-1706-1-git-send-email-srp@srparish.net>
Scott R Parish <srp@srparish.net> writes:
> Signed-off-by: Scott R Parish <srp@srparish.net>
> ---
> git.c | 5 ++---
> help.c | 4 ++--
> 2 files changed, 4 insertions(+), 5 deletions(-)
>
> diff --git a/git.c b/git.c
> index 853e66c..e1c99e3 100644
> --- a/git.c
> +++ b/git.c
> @@ -445,9 +445,8 @@ int main(int argc, const char **argv)
> if (!prefixcmp(argv[0], "--"))
> argv[0] += 2;
> } else {
> - /* Default command: "help" */
> - argv[0] = "help";
> - argc = 1;
> + /* The user didn't specify a command; give them help */
> + help_unknown_cmd("");
Sorry, but I fail to see why this is an improvement.
If you type "git<Enter>", before this patch we call cmd_help()
without help_cmd, which gives the usage string and lists common
commands, and exits with 1.
With this patch, you get "git: '' is not a git-command",
followed by list of common commands, and then the invocation
exits with 1.
I think "git help" should exit with 0. The user asked for help,
we give help, everything is going as expected and there is no
reason to exit with non-zero.
However, with the current implementation, these changes to
help.c also make "git<Enter>" to exit with 0 after it gives
help, which is not so nice (both "cvs" and "svn" without
parameter seem to exit with 1 and it sort of makes sense,
although I do not think it matters much). As a few datapoints,
"cvs -H" exits with 1 and "svn help" exits with 0.
So in short,
- "git" should retain the current behaviour (both output and
exit code).
- "git help" should retain the current output but probably
should exit with 0.
- Ditto for "git help -a".
^ permalink raw reply
* Re: [PATCH] git-cvsimport: Add -N option to force a new import
From: Matt McCutchen @ 2007-10-25 4:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfxzz51d7.fsf@gitster.siamese.dyndns.org>
On Wed, 2007-10-24 at 20:17 -0700, Junio C Hamano wrote:
> Matt McCutchen <matt@mattmccutchen.net> writes:
>
> > I had a git repository for development of rsync and wanted to start
> > importing the upstream CVS with git-cvsimport, but git-cvsimport saw
> > that the git repository existed and insisted on updating a previous
> > import. This patch adds an -N option to git-cvsimport to force a new
> > import and updates the documentation appropriately.
>
> Sounds like a useful addition. Tests?
Are there existing tests for git-cvsimport somewhere whose example I
could follow? (I didn't see any in t/ .) If not, I suppose I will just
write a simple script that runs git-cvsimport with and without -N and
with and without an existing, empty git repository and checks that the
right things happen.
Matt
^ permalink raw reply
* [PATCH 7/7] shell should call setup_path() instead of manually setting up its path
From: Scott R Parish @ 2007-10-25 3:37 UTC (permalink / raw)
To: git; +Cc: Scott R Parish
In-Reply-To: <1193283437-1706-6-git-send-email-srp@srparish.net>
Signed-off-by: Scott R Parish <srp@srparish.net>
---
shell.c | 8 +-------
1 files changed, 1 insertions(+), 7 deletions(-)
diff --git a/shell.c b/shell.c
index cfe372b..9826109 100644
--- a/shell.c
+++ b/shell.c
@@ -24,17 +24,11 @@ static int do_cvs_cmd(const char *me, char *arg)
const char *cvsserver_argv[3] = {
"cvsserver", "server", NULL
};
- const char *oldpath = getenv("PATH");
- struct strbuf newpath = STRBUF_INIT;
if (!arg || strcmp(arg, "server"))
die("git-cvsserver only handles server: %s", arg);
- strbuf_addstr(&newpath, git_exec_path());
- strbuf_addch(&newpath, ':');
- strbuf_addstr(&newpath, oldpath);
-
- setenv("PATH", strbuf_detach(&newpath, NULL), 1);
+ setup_path(NULL);
return execv_git_cmd(cvsserver_argv);
}
--
gitgui.0.8.4.11176.gd9205-dirty
^ permalink raw reply related
* [PATCH 7/7] shell should call setup_path() instead of manually setting up its path
From: Scott R Parish @ 2007-10-25 3:44 UTC (permalink / raw)
To: git; +Cc: Scott R Parish
Signed-off-by: Scott R Parish <srp@srparish.net>
---
shell.c | 8 +-------
1 files changed, 1 insertions(+), 7 deletions(-)
diff --git a/shell.c b/shell.c
index cfe372b..9826109 100644
--- a/shell.c
+++ b/shell.c
@@ -24,17 +24,11 @@ static int do_cvs_cmd(const char *me, char *arg)
const char *cvsserver_argv[3] = {
"cvsserver", "server", NULL
};
- const char *oldpath = getenv("PATH");
- struct strbuf newpath = STRBUF_INIT;
if (!arg || strcmp(arg, "server"))
die("git-cvsserver only handles server: %s", arg);
- strbuf_addstr(&newpath, git_exec_path());
- strbuf_addch(&newpath, ':');
- strbuf_addstr(&newpath, oldpath);
-
- setenv("PATH", strbuf_detach(&newpath, NULL), 1);
+ setup_path(NULL);
return execv_git_cmd(cvsserver_argv);
}
--
gitgui.0.8.4.11176.gd9205-dirty
^ permalink raw reply related
* [PATCH 5/7] chdir() into list_commands() dir instead of building paths for stat()
From: Scott R Parish @ 2007-10-25 3:37 UTC (permalink / raw)
To: git; +Cc: Scott R Parish
In-Reply-To: <1193283437-1706-4-git-send-email-srp@srparish.net>
Signed-off-by: Scott R Parish <srp@srparish.net>
---
help.c | 18 +++---------------
1 files changed, 3 insertions(+), 15 deletions(-)
diff --git a/help.c b/help.c
index 950f62d..906f8f6 100644
--- a/help.c
+++ b/help.c
@@ -96,35 +96,23 @@ static void pretty_print_string_list(struct cmdname **cmdname, int longest)
static void list_commands(const char *exec_path, const char *prefix)
{
unsigned int longest = 0;
- char path[PATH_MAX];
- int dirlen;
int prefix_len = strlen(prefix);
DIR *dir = opendir(exec_path);
struct dirent *de;
- if (!dir) {
+ if (!dir || chdir(exec_path)) {
fprintf(stderr, "git: '%s': %s\n", exec_path, strerror(errno));
exit(1);
}
- 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) {
struct stat st;
int entlen;
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;
--
gitgui.0.8.4.11176.gd9205-dirty
^ permalink raw reply related
* [PATCH 4/7] use only the PATH for exec'ing git commands
From: Scott R Parish @ 2007-10-25 3:37 UTC (permalink / raw)
To: git; +Cc: Scott R Parish
In-Reply-To: <1193283437-1706-3-git-send-email-srp@srparish.net>
We need to correctly set up PATH for non-c based git commands. Since we
already do this, we can just use that PATH and execvp, instead of looping
over the paths with execve.
This patch adds a setup_path() function to exec_cmd.c, which sets
the PATH order correctly for our search order. execv_git_cmd() is
stripped down to setting up argv and calling execvp(). git.c's main()
only only needs to call setup_path().
Signed-off-by: Scott R Parish <srp@srparish.net>
---
exec_cmd.c | 121 ++++++++++++++++++++++++++----------------------------------
exec_cmd.h | 1 +
git.c | 43 +++------------------
3 files changed, 60 insertions(+), 105 deletions(-)
diff --git a/exec_cmd.c b/exec_cmd.c
index 8b681d0..c228dbf 100644
--- a/exec_cmd.c
+++ b/exec_cmd.c
@@ -29,85 +29,68 @@ const char *git_exec_path(void)
return builtin_exec_path;
}
+static void add_path(struct strbuf *out, const char *path)
+{
+ if (path && strlen(path)) {
+ if (is_absolute_path(path))
+ strbuf_addstr(out, path);
+ else
+ strbuf_addstr(out, make_absolute_path(path));
+
+ strbuf_addch(out, ':');
+ }
+}
+
+void setup_path(const char *cmd_path)
+{
+ const char *old_path = getenv("PATH");
+ struct strbuf new_path;
+
+ strbuf_init(&new_path, 0);
+
+ add_path(&new_path, argv_exec_path);
+ add_path(&new_path, getenv(EXEC_PATH_ENVIRONMENT));
+ add_path(&new_path, builtin_exec_path);
+ add_path(&new_path, cmd_path);
+
+ if (old_path)
+ strbuf_addstr(&new_path, old_path);
+ else
+ strbuf_addstr(&new_path, "/usr/local/bin:/usr/bin:/bin");
+
+ setenv("PATH", new_path.buf, 1);
+
+ strbuf_release(&new_path);
+}
int execv_git_cmd(const char **argv)
{
- char git_command[PATH_MAX + 1];
- int i;
- const char *paths[] = { argv_exec_path,
- getenv(EXEC_PATH_ENVIRONMENT),
- builtin_exec_path };
-
- for (i = 0; i < ARRAY_SIZE(paths); ++i) {
- size_t len;
- int rc;
- const char *exec_dir = paths[i];
- const char *tmp;
-
- if (!exec_dir || !*exec_dir) continue;
-
- if (*exec_dir != '/') {
- if (!getcwd(git_command, sizeof(git_command))) {
- fprintf(stderr, "git: cannot determine "
- "current directory: %s\n",
- strerror(errno));
- break;
- }
- len = strlen(git_command);
-
- /* Trivial cleanup */
- while (!prefixcmp(exec_dir, "./")) {
- exec_dir += 2;
- while (*exec_dir == '/')
- exec_dir++;
- }
-
- rc = snprintf(git_command + len,
- sizeof(git_command) - len, "/%s",
- exec_dir);
- if (rc < 0 || rc >= sizeof(git_command) - len) {
- fprintf(stderr, "git: command name given "
- "is too long.\n");
- break;
- }
- } else {
- if (strlen(exec_dir) + 1 > sizeof(git_command)) {
- fprintf(stderr, "git: command name given "
- "is too long.\n");
- break;
- }
- strcpy(git_command, exec_dir);
- }
-
- len = strlen(git_command);
- rc = snprintf(git_command + len, sizeof(git_command) - len,
- "/git-%s", argv[0]);
- if (rc < 0 || rc >= sizeof(git_command) - len) {
- fprintf(stderr,
- "git: command name given is too long.\n");
- break;
- }
+ struct strbuf cmd;
+ const char *tmp;
- /* argv[0] must be the git command, but the argv array
- * belongs to the caller, and my be reused in
- * subsequent loop iterations. Save argv[0] and
- * restore it on error.
- */
+ strbuf_init(&cmd, 0);
+ strbuf_addf(&cmd, "git-%s", argv[0]);
- tmp = argv[0];
- argv[0] = git_command;
+ /* argv[0] must be the git command, but the argv array
+ * belongs to the caller, and my be reused in
+ * subsequent loop iterations. Save argv[0] and
+ * restore it on error.
+ */
+ tmp = argv[0];
+ argv[0] = cmd.buf;
- trace_argv_printf(argv, -1, "trace: exec:");
+ 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(cmd.buf, (char **)argv);
- trace_printf("trace: exec failed: %s\n", strerror(errno));
+ trace_printf("trace: exec failed: %s\n", strerror(errno));
- argv[0] = tmp;
- }
- return -1;
+ argv[0] = tmp;
+ strbuf_release(&cmd);
+
+ return -1;
}
diff --git a/exec_cmd.h b/exec_cmd.h
index da99287..a892355 100644
--- a/exec_cmd.h
+++ b/exec_cmd.h
@@ -3,6 +3,7 @@
extern void git_set_argv_exec_path(const char *exec_path);
extern const char* git_exec_path(void);
+extern void setup_path(const char *);
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 f659338..a639e42 100644
--- a/git.c
+++ b/git.c
@@ -6,28 +6,6 @@
const char git_usage_string[] =
"git [--version] [--exec-path[=GIT_EXEC_PATH]] [-p|--paginate|--no-pager] [--bare] [--git-dir=GIT_DIR] [--work-tree=GIT_WORK_TREE] [--help] COMMAND [ARGS]";
-static void prepend_to_path(const char *dir, int len)
-{
- const char *old_path = getenv("PATH");
- char *path;
- int path_len = len;
-
- if (!old_path)
- old_path = "/usr/local/bin:/usr/bin:/bin";
-
- path_len = len + strlen(old_path) + 1;
-
- path = xmalloc(path_len + 1);
-
- memcpy(path, dir, len);
- path[len] = ':';
- memcpy(path + len + 1, old_path, path_len - len);
-
- setenv("PATH", path, 1);
-
- free(path);
-}
-
static int handle_options(const char*** argv, int* argc, int* envchanged)
{
int handled = 0;
@@ -403,7 +381,7 @@ int main(int argc, const char **argv)
{
const char *cmd = argv[0] ? argv[0] : "git-help";
char *slash = strrchr(cmd, '/');
- const char *exec_path = NULL;
+ const char *cmd_path = NULL;
int done_alias = 0;
/*
@@ -413,10 +391,7 @@ int main(int argc, const char **argv)
*/
if (slash) {
*slash++ = 0;
- if (*cmd == '/')
- exec_path = cmd;
- else
- exec_path = xstrdup(make_absolute_path(cmd));
+ cmd_path = cmd;
cmd = slash;
}
@@ -451,16 +426,12 @@ int main(int argc, const char **argv)
cmd = argv[0];
/*
- * We execute external git command via execv_git_cmd(),
- * which looks at "--exec-path" option, GIT_EXEC_PATH
- * environment, and $(gitexecdir) in Makefile while built,
- * in this order. For scripted commands, we prepend
- * the value of the exec_path variable to the PATH.
+ * We use PATH to find git commands, but we prepend some higher
+ * precidence paths: the "--exec-path" option, the GIT_EXEC_PATH
+ * environment, and the $(gitexecdir) from the Makefile at build
+ * time.
*/
- if (exec_path)
- prepend_to_path(exec_path, strlen(exec_path));
- exec_path = git_exec_path();
- prepend_to_path(exec_path, strlen(exec_path));
+ setup_path(cmd_path);
while (1) {
/* See if it's an internal command */
--
gitgui.0.8.4.11176.gd9205-dirty
^ permalink raw reply related
* [PATCH 3/7] "current_exec_path" is a misleading name, use "argv_exec_path" Signed-off-by: Scott R Parish <srp@srparish.net>
From: Scott R Parish @ 2007-10-25 3:37 UTC (permalink / raw)
To: git; +Cc: Scott R Parish
In-Reply-To: <1193283437-1706-2-git-send-email-srp@srparish.net>
---
exec_cmd.c | 12 ++++++------
exec_cmd.h | 2 +-
git.c | 2 +-
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/exec_cmd.c b/exec_cmd.c
index 9b74ed2..8b681d0 100644
--- a/exec_cmd.c
+++ b/exec_cmd.c
@@ -5,11 +5,11 @@
extern char **environ;
static const char *builtin_exec_path = GIT_EXEC_PATH;
-static const char *current_exec_path;
+static const char *argv_exec_path = 0;
-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;
}
@@ -18,8 +18,8 @@ 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 +34,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..da99287 100644
--- a/exec_cmd.h
+++ b/exec_cmd.h
@@ -1,7 +1,7 @@
#ifndef GIT_EXEC_CMD_H
#define GIT_EXEC_CMD_H
-extern void git_set_exec_path(const char *exec_path);
+extern void git_set_argv_exec_path(const char *exec_path);
extern const char* git_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 e1c99e3..f659338 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);
--
gitgui.0.8.4.11176.gd9205-dirty
^ permalink raw reply related
* [PATCH 2/7] s/pattern/prefix/ in help's list_commands
From: Scott R Parish @ 2007-10-25 3:37 UTC (permalink / raw)
To: git; +Cc: Scott R Parish
In-Reply-To: <1193283437-1706-1-git-send-email-srp@srparish.net>
list_commands() currently accepts and ignores a "pattern" argument,
and then hard codes a prefix as well as some magic numbers. This
renames the arg from pattern to prefix and uses that instead of the
hardcoded stuff.
Signed-off-by: Scott R Parish <srp@srparish.net>
---
help.c | 13 +++++++------
1 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/help.c b/help.c
index b0d2dd4..950f62d 100644
--- a/help.c
+++ b/help.c
@@ -93,11 +93,12 @@ static void pretty_print_string_list(struct cmdname **cmdname, int longest)
}
}
-static void list_commands(const char *exec_path, const char *pattern)
+static void list_commands(const char *exec_path, const char *prefix)
{
unsigned int longest = 0;
char path[PATH_MAX];
int dirlen;
+ int prefix_len = strlen(prefix);
DIR *dir = opendir(exec_path);
struct dirent *de;
@@ -120,7 +121,7 @@ static void list_commands(const char *exec_path, const char *pattern)
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 */
@@ -128,14 +129,14 @@ static void list_commands(const char *exec_path, const char *pattern)
!(st.st_mode & S_IXUSR))
continue;
- entlen = strlen(de->d_name);
+ entlen = strlen(de->d_name) - prefix_len;
if (has_extension(de->d_name, ".exe"))
entlen -= 4;
if (longest < entlen)
longest = entlen;
- add_cmdname(de->d_name + 4, entlen-4);
+ add_cmdname(de->d_name + prefix_len, entlen);
}
closedir(dir);
@@ -143,7 +144,7 @@ static void list_commands(const char *exec_path, const char *pattern)
printf("----------------------------");
mput_char('-', strlen(exec_path));
putchar('\n');
- pretty_print_string_list(cmdname, longest - 4);
+ pretty_print_string_list(cmdname, longest);
putchar('\n');
}
@@ -210,7 +211,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(exec_path, "git-");
exit(0);
}
--
gitgui.0.8.4.11176.gd9205-dirty
^ permalink raw reply related
* [PATCH 6/7] walk PATH to generate list of commands for "help -a"
From: Scott R Parish @ 2007-10-25 3:37 UTC (permalink / raw)
To: git; +Cc: Scott R Parish
In-Reply-To: <1193283437-1706-5-git-send-email-srp@srparish.net>
Signed-off-by: Scott R Parish <srp@srparish.net>
---
help.c | 69 ++++++++++++++++++++++++++++++++++++++++++++++++---------------
1 files changed, 52 insertions(+), 17 deletions(-)
diff --git a/help.c b/help.c
index 906f8f6..3f8b4aa 100644
--- a/help.c
+++ b/help.c
@@ -64,6 +64,19 @@ static int cmdname_compare(const void *a_, const void *b_)
return strcmp(a->name, b->name);
}
+static void uniq(struct cmdname **cmdname)
+{
+ int i, j;
+
+ for (i = j = 1; i < cmdname_cnt; i++) {
+ if (strcmp(cmdname[i]->name, cmdname[i-1]->name)) {
+ cmdname[j++] = cmdname[i];
+ }
+ }
+
+ cmdname_cnt = j;
+}
+
static void pretty_print_string_list(struct cmdname **cmdname, int longest)
{
int cols = 1, rows;
@@ -71,12 +84,13 @@ static void pretty_print_string_list(struct cmdname **cmdname, int longest)
int max_cols = term_columns() - 1; /* don't print *on* the edge */
int i, j;
+ qsort(cmdname, cmdname_cnt, sizeof(*cmdname), cmdname_compare);
+ uniq(cmdname);
+
if (space < max_cols)
cols = max_cols / space;
rows = (cmdname_cnt + cols - 1) / cols;
- qsort(cmdname, cmdname_cnt, sizeof(*cmdname), cmdname_compare);
-
for (i = 0; i < rows; i++) {
printf(" ");
@@ -93,19 +107,17 @@ static void pretty_print_string_list(struct cmdname **cmdname, int longest)
}
}
-static void list_commands(const char *exec_path, const char *prefix)
+static unsigned int list_commands_in_dir(const char *dir, const char *prefix)
{
unsigned int longest = 0;
int prefix_len = strlen(prefix);
- DIR *dir = opendir(exec_path);
+ DIR *dirp = opendir(dir);
struct dirent *de;
- if (!dir || chdir(exec_path)) {
- fprintf(stderr, "git: '%s': %s\n", exec_path, strerror(errno));
- exit(1);
- }
+ if (!dirp || chdir(dir))
+ return 0;
- while ((de = readdir(dir)) != NULL) {
+ while ((de = readdir(dirp)) != NULL) {
struct stat st;
int entlen;
@@ -126,12 +138,37 @@ static void list_commands(const char *exec_path, const char *prefix)
add_cmdname(de->d_name + prefix_len, entlen);
}
- closedir(dir);
+ closedir(dirp);
- printf("git commands available in '%s'\n", exec_path);
- printf("----------------------------");
- mput_char('-', strlen(exec_path));
- putchar('\n');
+ return longest;
+}
+
+static void list_commands(const char *prefix)
+{
+ unsigned int longest = 0;
+ unsigned int len;
+ const char *env_path = getenv("PATH");
+ char *paths, *path, *colon;
+
+ if (!env_path) {
+ fprintf(stderr, "PATH not set\n");
+ exit(1);
+ }
+
+ 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);
+
+ printf("available git commands\n");
+ printf("----------------------\n");
pretty_print_string_list(cmdname, longest);
putchar('\n');
}
@@ -188,7 +225,6 @@ int cmd_version(int argc, const char **argv, const char *prefix)
int cmd_help(int argc, const char **argv, const char *prefix)
{
const char *help_cmd = argc > 1 ? argv[1] : NULL;
- const char *exec_path = git_exec_path();
if (!help_cmd) {
printf("usage: %s\n\n", git_usage_string);
@@ -198,8 +234,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);
}
--
gitgui.0.8.4.11176.gd9205-dirty
^ permalink raw reply related
* [PATCH 1/7] "git" calls help_unknown_cmd(""); "git help" and "git help -a" return 0
From: Scott R Parish @ 2007-10-25 3:37 UTC (permalink / raw)
To: git; +Cc: Scott R Parish
Signed-off-by: Scott R Parish <srp@srparish.net>
---
git.c | 5 ++---
help.c | 4 ++--
2 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/git.c b/git.c
index 853e66c..e1c99e3 100644
--- a/git.c
+++ b/git.c
@@ -445,9 +445,8 @@ int main(int argc, const char **argv)
if (!prefixcmp(argv[0], "--"))
argv[0] += 2;
} else {
- /* Default command: "help" */
- argv[0] = "help";
- argc = 1;
+ /* The user didn't specify a command; give them help */
+ help_unknown_cmd("");
}
cmd = argv[0];
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
--
gitgui.0.8.4.11176.gd9205-dirty
^ permalink raw reply related
* Re: [PATCH] git-cvsimport: Add -N option to force a new import
From: Junio C Hamano @ 2007-10-25 3:17 UTC (permalink / raw)
To: Matt McCutchen; +Cc: git
In-Reply-To: <1193268519.8008.11.camel@mattlaptop2>
Matt McCutchen <matt@mattmccutchen.net> writes:
> I had a git repository for development of rsync and wanted to start
> importing the upstream CVS with git-cvsimport, but git-cvsimport saw
> that the git repository existed and insisted on updating a previous
> import. This patch adds an -N option to git-cvsimport to force a new
> import and updates the documentation appropriately.
Sounds like a useful addition. Tests?
^ permalink raw reply
* Re: Feature request: Limit git-status reports to a directory
From: Yin Ping @ 2007-10-25 2:14 UTC (permalink / raw)
To: Michel Marti; +Cc: git
In-Reply-To: <ffofbm$lmc$1@ger.gmane.org>
On 10/25/07, Michel Marti <mma@objectxp.com> wrote:
> I am sometimes interested in only seeing the status for a specific
> directory (and its sub-directories), but git-status is no help in this
> case - passing a directory does some sort of "git-commit --dry-run". I
> first thought that this is a bug until I saw in the man-page that this
> is actually a feature...
It's also painful for me. IMHO, the behaviour of "git-status" should
keep consistent with "git-diff" and "git-log" which allow for the
path.
Another point, It will be helpful to add a config item to change the
default behaviour for 'git-diff" and "git-log". For example,
'diff.defaultcurrentpath=true' to let git only show difference in
current directory instead of difference in top directory when typing
'git-diff'
>
> - Michel
>
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
franky
^ permalink raw reply
* Re: git-remote: Use of uninitialized value in string ne, line 248
From: Junio C Hamano @ 2007-10-25 1:48 UTC (permalink / raw)
To: Alex Riesen; +Cc: git discussion list, Martin F Krafft
In-Reply-To: <20071024193954.GA5280@steel.home>
Alex Riesen <raa.lkml@gmail.com> writes:
> Junio C Hamano, Wed, Oct 24, 2007 13:49:51 +0200:
>> Perhaps....
>>
>> git-remote.perl | 3 ++-
>> 1 files changed, 2 insertions(+), 1 deletions(-)
>>
>> diff --git a/git-remote.perl b/git-remote.perl
>> index 9ca3e7e..4cee044 100755
>> --- a/git-remote.perl
>> +++ b/git-remote.perl
>> @@ -244,7 +244,8 @@ sub show_remote {
>> print "* remote $name\n";
>> print " URL: $info->{'URL'}\n";
>> for my $branchname (sort keys %$branch) {
>> - next if ($branch->{$branchname}{'REMOTE'} ne $name);
>> + next if (!$branch->{$branchname}{'REMOTE'} ||
>
> just you never call yor branches "0".
Ok, that is about remote name '0' but whatever...
-- >8 --
[PATCH] git-remote: fix "Use of uninitialized value in string ne"
martin f krafft <madduck@madduck.net> writes:
> piper:~> git remote show origin
> * remote origin
> URL: ssh://git.madduck.net/~/git/etc/mailplate.git
> Use of uninitialized value in string ne at /usr/local/stow/git/bin/git-remote line 248.
This is because there might not be branch.<name>.remote defined but
the code unconditionally dereferences $branch->{$name}{'REMOTE'} and
compares with another string.
Tested-by: Martin F Krafft <madduck@madduck.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
git-remote.perl | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/git-remote.perl b/git-remote.perl
index 8e2dc4d..11630b1 100755
--- a/git-remote.perl
+++ b/git-remote.perl
@@ -244,7 +244,8 @@ sub show_remote {
print "* remote $name\n";
print " URL: $info->{'URL'}\n";
for my $branchname (sort keys %$branch) {
- next if ($branch->{$branchname}{'REMOTE'} ne $name);
+ next unless (defined $branch->{$branchname}{'REMOTE'} &&
+ $branch->{$branchname}{'REMOTE'} eq $name);
my @merged = map {
s|^refs/heads/||;
$_;
--
1.5.3.4.1324.ga7925
^ permalink raw reply related
* Re: What's cooking in git.git (topics)
From: Scott Parish @ 2007-10-25 0:35 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Junio C Hamano, git
In-Reply-To: <471F8EA0.9030902@op5.se>
On Wed, Oct 24, 2007 at 08:27:44PM +0200, Andreas Ericsson wrote:
> > Should i resend my string of patches? I've seen people numbering
> > their patches, should i do that as well?
>
> 'git format-patch -n' will do it for you. I take it you've found
> out about git-send-email already?
I actually hadn't seen either of those. Thanks!
sRp
--
Scott Parish
http://srparish.net/
^ permalink raw reply
* Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued
From: Jakub Narebski @ 2007-10-24 23:48 UTC (permalink / raw)
To: Andreas Ericsson
Cc: J. Bruce Fields, Steffen Prohaska, Johannes Schindelin,
Federico Mena Quintero, git
In-Reply-To: <471F9FD1.6080002@op5.se>
On 10/24/07, Andreas Ericsson <ae@op5.se> wrote:
> git pull. Not git push. git pull operates on one working branch
> at a time (by default), whereas git push uploads and fast-forwards
> all the common branches (by default). I want git pull to work like
> git push.
git push is opposite (almost) to git fetch, not to git pull.
--
Jakub Narebski
^ permalink raw reply
* [PATCH] git-cvsimport: Add -N option to force a new import
From: Matt McCutchen @ 2007-10-24 23:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
I had a git repository for development of rsync and wanted to start
importing the upstream CVS with git-cvsimport, but git-cvsimport saw
that the git repository existed and insisted on updating a previous
import. This patch adds an -N option to git-cvsimport to force a new
import and updates the documentation appropriately.
Signed-off-by: Matt McCutchen <matt@mattmccutchen.net>
---
I implemented this because I needed it; adopt it in the main git if you
like it.
Documentation/git-cvsimport.txt | 5 ++++-
git-cvsimport.perl | 9 ++++++---
2 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/Documentation/git-cvsimport.txt b/Documentation/git-cvsimport.txt
index fdd7ec7..f595957 100644
--- a/Documentation/git-cvsimport.txt
+++ b/Documentation/git-cvsimport.txt
@@ -13,7 +13,7 @@ SYNOPSIS
[-A <author-conv-file>] [-p <options-for-cvsps>] [-P <file>]
[-C <git_repository>] [-z <fuzz>] [-i] [-k] [-u] [-s <subst>]
[-a] [-m] [-M <regex>] [-S <regex>] [-L <commitlimit>]
- [-r <remote>] [<CVS_module>]
+ [-r <remote>] [-N] [<CVS_module>]
DESCRIPTION
@@ -144,6 +144,9 @@ It is not recommended to use this feature if you intend to
export changes back to CVS again later with
gitlink:git-cvsexportcommit[1].
+-N::
+ Do a new import even if the git repository already exists.
+
-h::
Print a short usage message and exit.
diff --git a/git-cvsimport.perl b/git-cvsimport.perl
index 2954fb8..6f03be9 100755
--- a/git-cvsimport.perl
+++ b/git-cvsimport.perl
@@ -29,7 +29,7 @@ use IPC::Open2;
$SIG{'PIPE'}="IGNORE";
$ENV{'TZ'}="UTC";
-our ($opt_h,$opt_o,$opt_v,$opt_k,$opt_u,$opt_d,$opt_p,$opt_C,$opt_z,$opt_i,$opt_P, $opt_s,$opt_m,$opt_M,$opt_A,$opt_S,$opt_L, $opt_a, $opt_r);
+our ($opt_h,$opt_o,$opt_v,$opt_k,$opt_u,$opt_d,$opt_p,$opt_C,$opt_z,$opt_i,$opt_P, $opt_s,$opt_m,$opt_M,$opt_A,$opt_S,$opt_L, $opt_a, $opt_r, $opt_N);
my (%conv_author_name, %conv_author_email);
sub usage(;$) {
@@ -40,7 +40,7 @@ Usage: ${\basename $0} # fetch/update GIT from CVS
[-o branch-for-HEAD] [-h] [-v] [-d CVSROOT] [-A author-conv-file]
[-p opts-for-cvsps] [-P file] [-C GIT_repository] [-z fuzz] [-i] [-k]
[-u] [-s subst] [-a] [-m] [-M regex] [-S regex] [-L commitlimit]
- [-r remote] [CVS_module]
+ [-r remote] [-N] [CVS_module]
END
exit(1);
}
@@ -114,7 +114,7 @@ sub read_repo_config {
}
}
-my $opts = "haivmkuo:d:p:r:C:z:s:M:P:A:S:L:";
+my $opts = "haivmkuNo:d:p:r:C:z:s:M:P:A:S:L:";
read_repo_config($opts);
getopts($opts) or usage();
usage if $opt_h;
@@ -563,7 +563,10 @@ unless (-d $git_dir) {
die "Cannot init the GIT db at $git_tree: $?\n" if $?;
system("git-read-tree");
die "Cannot init an empty tree: $?\n" if $?;
+ $opt_N = 1;
+}
+if ($opt_N) {
$last_branch = $opt_o;
$orig_branch = "";
} else {
--
1.5.3.3.128.g56927
^ permalink raw reply related
* Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued
From: Johannes Schindelin @ 2007-10-24 23:28 UTC (permalink / raw)
To: Steffen Prohaska
Cc: Peter Baumann, Andreas Ericsson, J. Bruce Fields, Jakub Narebski,
Federico Mena Quintero, git
In-Reply-To: <008A7EF9-6F58-47AE-9AA0-B466797F6B1D@zib.de>
Hi,
On Thu, 25 Oct 2007, Steffen Prohaska wrote:
> On Oct 25, 2007, at 12:14 AM, Johannes Schindelin wrote:
>
> > But I think I have to drive my message home again: if what you desire
> > becomes reality, you take away the clear distinction between local and
> > remote branches. In fact, those branches are neither local (because
> > the next pull will automatically update them with remote changes, but
> > _only_ if they fast-forward) nor remote (because you plan to work on
> > them locally).
>
> Exactly, because I do not work on those branches alone. These are
> _shared_ branches. I can work on such a branch with a group of
> developers. I'm willing to accept this bit of chaos.
It is not just a chaos. I see a serious problem here. On _your_
computer, you do _not_ have a shared branch. Which is visible _even_ in
your modified work flow when you have unpushed changes.
So your desired illusion that your local branches are anything but local
branches will never be perfect enough.
> Your rebase workflow is not possible if more than one dev wants to work
> on the topic branch together.
Why not? I do it all the time. CVS users do it all the time, for that
matter.
> Eventually you can linearize such a topic branch using rebase. But you
> need to agree first that everyone else needs to delete the branch.
No, you can linearize your branch already while cleaning up your local
branch before continuing to work on the topic.
> > But here is a proposal which should make you and your developers
> > happy, _and_ should be even easier to explain:
> >
> > Work with topic branches. And when you're done, delete them.
>
> Again, if you want to share the topic branch the situation gets
> more complex.
Hardly so. In my proposed solution to your problem, there is nothing
which prevents you from working off of another branch than "master".
> > So the beginning of the day could look like this:
> >
> > git fetch
> > git checkout -b todays-topic origin/master
> >
> > [hack hack hack]
> > [test test test]
> > [debug debug debug]
> > [occasionally commit]
> > [occasionally git rebase -i origin/master]
> >
> > and the end of the topic
> >
> > git branch -M master
> > git push origin master
> >
> > If you should not be ready to push by the end of the day, no need to
> > worry. Just stay on that topic branch, and before pushing, do
> >
> > git fetch
> > git rebase origin/master
> >
> > In _every_ case where I explained git, I found that people appreciated the
> > two-step procedures (like you will find in the examples I showed you
> > above): one git command to work locally, and one to push/fetch to/from
> > origin.
>
> Maybe. I know git quite well now and in a shared workflow "git pull"
> with auto-fast-forward would help me. I often need to run "for each
> local branch: git checkout ; git merge" to get rid of the errors
> reported by "git push".
The problem I see here: you know git quite well. Others don't, and will
be mightily confused why pull updates local branches sometimes, and
sometimes not.
Ciao,
Dscho
^ permalink raw reply
* Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued
From: Jakub Narebski @ 2007-10-24 23:27 UTC (permalink / raw)
To: Karl Hasselström; +Cc: git, Catalin Marinas
In-Reply-To: <20071024113123.GB6459@diana.vm.bytemark.co.uk>
On 10/24/07, Karl Hasselström <kha@treskal.com> wrote:
> On 2007-10-24 13:04:01 +0200, Jakub Narebski wrote:
>
>> By the way, there is SRPM for StGIT in
>> http://homepage.ntlworld.com/cmarinas/stgit/ (I need it because I
>> have Python 2.4), but it is not listed on downloads page...
>
> I'll leave the webpage question to Catalin, but I'm curious about the
> Python version remark. What exactly is the problem?
If I remember correctly the StGIT RPM requires python 2.5
(and is build using python 2.5, so install with --force doesn't work).
BTW. SRPM is better than tar.gz because I can simply do "rpmbuild
--rebuild" to get binary RPM to install.
--
Jakub Narebski
^ permalink raw reply
* Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued
From: Steffen Prohaska @ 2007-10-24 22:51 UTC (permalink / raw)
To: J. Bruce Fields
Cc: Johannes Schindelin, Peter Baumann, Andreas Ericsson,
Jakub Narebski, Federico Mena Quintero, git
In-Reply-To: <20071024223815.GN29830@fieldses.org>
On Oct 25, 2007, at 12:38 AM, J. Bruce Fields wrote:
> On Thu, Oct 25, 2007 at 12:33:37AM +0200, Steffen Prohaska wrote:
>> Maybe. I know git quite well now and in a shared workflow "git pull"
>> with auto-fast-forward would help me. I often need to run "for each
>> local branch: git checkout ; git merge" to get rid of the errors
>> reported by "git push".
>
> Hm. There's gotta be more efficient ways to do that. Maybe "git
> push .
> origin/branch:branch" for each local "branch"?
>
> But I'm still a little confused why you don't just want to "git push
> name-of-branch" and avoid the whole problem.
There are two points:
- The current implementation of "git push" creates a remote branch
if it does not yet exist. I want a safety net: "git push" only pushes
if the remote branch already exists. In a sense "git push" is safer
than "git push branch-with-typo". I use "git push branchname"
exclusively for _creating_ new branches on the remote.
- Sometimes I updated two local branches and want to push. "git push"
just works.
I started to believe that "git push" should always do the right
thing. Maybe it is not possible, but actually "git push" always
does the right thing for me if I ignore the error messages
about local branches that need merging. I tend to merge all
such branches right away, although it is a bit of a hassel.
Otherwise, there will be a day I'll miss an important error.
What concerns me more is how to explain the behaviour to others.
Right now, I can't tell them that "git push" just works but need
to go into a lot of details.
Steffen
^ 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