* [PATCH] execv_git_cmd(): also try PATH if everything else fails.
From: Johannes Schindelin @ 2007-10-20 22:00 UTC (permalink / raw)
To: Scott Parish; +Cc: git
In-Reply-To: <20071020205721.GA16291@srparish.net>
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, 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?
exec_cmd.c | 12 ++++++++----
1 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/exec_cmd.c b/exec_cmd.c
index 9b74ed2..c928f37 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");
--
1.5.3.4.1287.g8b31e
^ permalink raw reply related
* Re: [PATCH] On error, do not list all commands, but point to --help option.
From: Shawn O. Pearce @ 2007-10-21 2:06 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jari Aalto, git
In-Reply-To: <Pine.LNX.4.64.0710210001390.25221@racer.site>
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".
Hmm. Lets see.
"cvs foo":
Big spew of commands. Like "git foo".
"svn foo":
Unknown command: 'foo'
Type 'svn help' for usage.
Both are considered to be more newbie friendly then Git. So clearly
SVN's output of almost nothing is friendly. And so is CVS'
big spew of frequently used commands. Either way is apparently
newbie friendly.
Though I find SVN's message a little insulting, asking me to type.
I know I have to type the command, thanks.
--
Shawn.
^ permalink raw reply
* Re: Git User's Survey 2007 unfinished summary continued
From: Jakub Narebski @ 2007-10-20 23:06 UTC (permalink / raw)
To: Steffen Prohaska
Cc: Andreas Ericsson, Federico Mena Quintero, Johannes Schindelin,
git
In-Reply-To: <DE4FB702-24E8-421F-8447-04A5C7F7B5D2@zib.de>
On 10/20/07, Steffen Prohaska <prohaska@zib.de> wrote:
> Maybe we could group commands into more categories?
>
> plumbing: should be hidden from the 'normal' user. Porcelain
> should be sufficient for every standard task.
The problem is division between what is porcelain and what is plumbing.
Some commands are right on border (git-fsck, git-update-index, git-rev-parse
comes to mind).
But it should be fairly easy to:
1. put only porcelain in bash / zsh completion ('git <tab>' shows
only porcelain
2. move plumbing out of PATH, but use exec-dir instead.
[...]
> mail porcelain: the list will probably hate me for this, but
> I think all commands needed to create and send patches per
> mail are not essential. I suspect that I'll _never_ ask
> my colleagues at work to send me a patch by mail. They'll
> always push it to a shared repo.
Usually mail porcelain is in separate binary package, git-mail for
RPMS packages for example. But iMVHO git-format-patch is as often used
as other commands, and is certainly porcelain.
> import/export: Many commands are only used for importing
> from or exporting to other version control systems. Examples
> are git-cvs*, git-svn*. They are not needed once you switched
> to git.
Those are also in separate packages.
> admin: Some commands are not used in a typical workflow. For
> example git-filter-branch or git-fsck have a more admin
> flavor.
These are a few commands only. I'm not sure about how to separate
those from ordinary commands.
[...]
> So here are a few questions:
>
> Could we find a small set of core porcelain commands that
> completely cover a typical workflow? The core section of the
> manual should only refer to those commands. Absolutely no
> plumbing should be needed to tweak things. In principle, a
> typical user should be able to work if _all other_ commands
> except for core porcelain are hidden from his PATH.
The problem here I suppose might lie with the same reason why
(almost?) all Office Lite systems failed: because even if 80% of people
use only 20% of functaionality, it is not the _same_ 20%.
--
Jakub Narebski
^ permalink raw reply
* Re: Git User's Survey 2007 unfinished summary continued
From: Johannes Schindelin @ 2007-10-20 23:33 UTC (permalink / raw)
To: Jakub Narebski
Cc: Steffen Prohaska, Andreas Ericsson, Federico Mena Quintero, git
In-Reply-To: <8fe92b430710201606i47e85b24k17abd819bf0d353b@mail.gmail.com>
Hi,
On Sun, 21 Oct 2007, Jakub Narebski wrote:
> On 10/20/07, Steffen Prohaska <prohaska@zib.de> wrote:
>
> > Maybe we could group commands into more categories?
> >
> > plumbing: should be hidden from the 'normal' user. Porcelain
> > should be sufficient for every standard task.
>
> The problem is division between what is porcelain and what is plumbing.
> Some commands are right on border (git-fsck, git-update-index,
> git-rev-parse comes to mind).
Sorry, but my impression from the latest mails was that the commands are
fine. What is lacking is a nice, _small_ collection of recommended
workflows. And when we have agreed on such a set of workflows, we
optimize the hell out of them. Only this time it is not performance, but
user-friendliness.
Hmm?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] execv_git_cmd(): also try PATH if everything else fails.
From: Shawn O. Pearce @ 2007-10-21 2:36 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Scott Parish, git
In-Reply-To: <Pine.LNX.4.64.0710202258440.25221@racer.site>
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.
> exec_cmd.c | 12 ++++++++----
> 1 files changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/exec_cmd.c b/exec_cmd.c
> index 9b74ed2..c928f37 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");
> --
> 1.5.3.4.1287.g8b31e
--
Shawn.
^ permalink raw reply
* Re: [BUG] git-mv submodule failure
From: Johannes Schindelin @ 2007-10-20 21:24 UTC (permalink / raw)
To: Yin Ping; +Cc: git
In-Reply-To: <46dff0320710192301p3e1d88d5l3b662b72b051d920@mail.gmail.com>
Hi,
On Sat, 20 Oct 2007, Yin Ping wrote:
> project
> .git
> file1
> submoudle
> .git
> file2
>
> $ cd project
> $ git-mv submodule submodule1
> fatal: source directory is empty, source=submodule, destination=submodule1
>
> However, the following is ok and rename is automatically detected
> $ cd project
> $ mv submodule submodule1
> $ git-add submodule1
> $ git-commit -a
>
> which gives in vim:
> # Please enter the commit message for your changes.
> # (Comment lines starting with '#' will not be included)
> # On branch master
> # Changes to be committed:
> # (use "git reset HEAD <file>..." to unstage)
> #
> # renamed: submodule -> submodule1
> #
But of course .gitmodules is unaffected. But it should be changed, too.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Deduce exec_path also from calls to git with a relative path
From: Johannes Schindelin @ 2007-10-20 21:25 UTC (permalink / raw)
To: David Brown; +Cc: Scott R Parish, git, spearce, gitster
In-Reply-To: <20071020122516.GA23190@old.davidb.org>
Hi,
On Sat, 20 Oct 2007, David Brown wrote:
> On Sat, Oct 20, 2007 at 08:21:34AM +0100, Johannes Schindelin wrote:
>
> > For example, when you call "../../hello/world/git", it will not turn
> > "../../hello/world" into an absolute path, and use that.
>
> Did you mean "it will turn..."?
Yes, I meant that. I was in a hurry, since a car was waiting outside the
door, taking me to the highlands.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH-resent] gitk: fix in procedure drawcommits
From: Paul Mackerras @ 2007-10-21 3:01 UTC (permalink / raw)
To: Michele Ballabio; +Cc: git, Shawn O. Pearce, pdmef
In-Reply-To: <200710201802.48111.barra_cuda@katamail.com>
Michele Ballabio writes:
> This commit (and many others) has two parents, but the two parents
> have the same hash. So gitk tries to unset the same variable twice,
> hence the error. At this point, the fix for gitk should be either to
> check if the parents have the same hash when reading the commit or
> avoiding to unset two times the same variable.
Actually, there is a commit like that in the kernel tree, and with
this clue, I have managed to reproduce the problem on the kernel tree
with the command
gitk v2.6.12-rc2..13e652800d1644dfedcd0d59ac95ef0beb7f3165
I have just pushed out a fix to my gitk.git tree.
Paul.
^ permalink raw reply
* Re: Announcement of Git wikibook
From: Steven Walter @ 2007-10-21 3:09 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Ciprian Dorin Craciun, Steffen Prohaska, Evan Carroll, git
In-Reply-To: <Pine.LNX.4.64.0710202232280.25221@racer.site>
[-- Attachment #1: Type: text/plain, Size: 1577 bytes --]
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.
This makes perfect sense given that it's edited by oldtimers, who are
neither inclined nor particularly suited to explaining git to newbies;
they have simply forgotten what it was like for these concepts to be
foreign. They eat SHA1 hashes for breakfast and dream about index
files. And that's great :)
I don't think the wikibook should try to duplicate the Git User Manual.
That would be a wasted effort. But there is a niche to be filled in git
documentation, particularly in regard to specific workflows and git best
practices. With git, TMTOWTDI. It's quite difficult for a newbie to
know which of those ways will come back and bite them in the ass down the
road.
Of course, it is a wikibook, so it will go where it goes. I for one am
glad to see this project started.
--
-Steven Walter <stevenrwalter@gmail.com>
Freedom is the freedom to say that 2 + 2 = 4
B2F1 0ECC E605 7321 E818 7A65 FC81 9777 DC28 9E8F
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH] On error, do not list all commands, but point to --help option
From: Jari Aalto @ 2007-10-20 22:41 UTC (permalink / raw)
To: git
In-Reply-To: <bqaujirk.fsf@blue.sea.net>
- Remove out call to list_common_cmds_help()
- Send error message to stderr, not stdout.
Signed-off-by: Jari Aalto <jari.aalto@cante.net>
---
help.c | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/help.c b/help.c
index 1cd33ec..814a8cd 100644
--- a/help.c
+++ b/help.c
@@ -185,8 +185,7 @@ static void show_man_page(const char *git_cmd)
void help_unknown_cmd(const char *cmd)
{
- printf("git: '%s' is not a git-command\n\n", cmd);
- list_common_cmds_help();
+ fprintf(stderr, "git: '%s' is not a git-command. See --help\n\n", cmd);
exit(1);
}
--
1.5.3.2.81.g17ed
^ permalink raw reply related
* Re: [PATCH] On error, do not list all commands, but point to --help option.
From: Jeff King @ 2007-10-21 3:24 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Johannes Schindelin, Jari Aalto, git
In-Reply-To: <20071021020653.GA14735@spearce.org>
On Sat, Oct 20, 2007 at 10:06:53PM -0400, Shawn O. Pearce wrote:
> 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".
Yeah, somebody should really work on bash completion...
-Peff
^ permalink raw reply
* Re: [PATCH] gitweb: Provide title attributes for abbreviated author names.
From: Shawn O. Pearce @ 2007-10-21 3:25 UTC (permalink / raw)
To: David Symonds; +Cc: pasky, git
In-Reply-To: <1192581277533-git-send-email-dsymonds@gmail.com>
Nice, but...
David Symonds <dsymonds@gmail.com> wrote:
> +++ b/gitweb/gitweb.perl
> @@ -3461,9 +3461,15 @@ sub git_shortlog_body {
> print "<tr class=\"light\">\n";
> }
> $alternate ^= 1;
> + my $author = chop_str($co{'author_name'}, 10);
> + if ($author ne $co{'author_name'}) {
> + $author = "<span title=\"$co{'author_name'}\">" . esc_html($author) . "</span>";
Doesn't this produce invalid HTML if $co{'author_name'} has a special
HTML character in it such as & or "? Note that " is much more likely
as it is often used for nicknames. The old code properly escaped
the author name, and indeed you are doing it for the abbreviated
version but not the full version.
This bug seemed to exist in almost all (if not all) of the hunks.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] On error, do not list all commands, but point to --help option.
From: Shawn O. Pearce @ 2007-10-21 3:29 UTC (permalink / raw)
To: Jeff King; +Cc: Johannes Schindelin, Jari Aalto, git
In-Reply-To: <20071021032427.GB8545@coredump.intra.peff.net>
Jeff King <peff@peff.net> wrote:
> On Sat, Oct 20, 2007 at 10:06:53PM -0400, Shawn O. Pearce wrote:
>
> > 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".
>
> Yeah, somebody should really work on bash completion...
$ git pu<TAB><TAB>
pull push
By the time I type out "pus" and hit tab I've already typed out
the name "push ". Except I frequently find myself getting the
u before the p, which can't complete. Of course with the above
alias in place "git u<TAB>" completes out uniquely to "git push "
(between bash completion and the alias expansion).
But that alias isn't there for my bash tab completion. Its there
exactly because otherwise "git upsh" gives me 31 lines of useless
(to me) output without it.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] On error, do not list all commands, but point to --help option
From: Shawn O. Pearce @ 2007-10-21 3:33 UTC (permalink / raw)
To: Jari Aalto; +Cc: git
In-Reply-To: <ir51if2y.fsf@blue.sea.net>
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)...
> - Send error message to stderr, not stdout.
I really think this really should be done. CVS and SVN both print
to stderr in this case, as does any other program I can think of
that takes subcommands. Its just the right thing to do.
> @@ -185,8 +185,7 @@ static void show_man_page(const char *git_cmd)
>
> void help_unknown_cmd(const char *cmd)
> {
> - printf("git: '%s' is not a git-command\n\n", cmd);
> - list_common_cmds_help();
> + fprintf(stderr, "git: '%s' is not a git-command. See --help\n\n", cmd);
Why are you still printing two LFs here? We have no additional
text to display after this error message, we probably only need
the one LF.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] gitweb: Provide title attributes for abbreviated author names.
From: David Symonds @ 2007-10-21 4:29 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: pasky, git
In-Reply-To: <20071021032533.GA30717@spearce.org>
On 21/10/2007, Shawn O. Pearce <spearce@spearce.org> wrote:
> Nice, but...
>
> David Symonds <dsymonds@gmail.com> wrote:
> > +++ b/gitweb/gitweb.perl
> > @@ -3461,9 +3461,15 @@ sub git_shortlog_body {
> > print "<tr class=\"light\">\n";
> > }
> > $alternate ^= 1;
> > + my $author = chop_str($co{'author_name'}, 10);
> > + if ($author ne $co{'author_name'}) {
> > + $author = "<span title=\"$co{'author_name'}\">" . esc_html($author) . "</span>";
>
> Doesn't this produce invalid HTML if $co{'author_name'} has a special
> HTML character in it such as & or "? Note that " is much more likely
> as it is often used for nicknames. The old code properly escaped
> the author name, and indeed you are doing it for the abbreviated
> version but not the full version.
Sure, I'll fix it up and resend. I might even refactor some code at
the same time.
Dave.
^ permalink raw reply
* [PATCH 1/2] Use PRIuMAX instead of 'unsigned long long' in show-index
From: Shawn O. Pearce @ 2007-10-21 5:25 UTC (permalink / raw)
To: git
Elsewhere in Git we already use PRIuMAX and cast to uintmax_t when
we need to display a value that is 'very big' and we're not exactly
sure what the largest display size is for this platform.
This particular fix is needed so we can do the incredibly crazy
temporary hack of:
diff --git a/cache.h b/cache.h
index e0abcd6..6637fd8 100644
--- a/cache.h
+++ b/cache.h
@@ -6,6 +6,7 @@
#include SHA1_HEADER
#include <zlib.h>
+#define long long long
#if ZLIB_VERNUM < 0x1200
#define deflateBound(c,s) ((s) + (((s) + 7) >> 3) + (((s) + 63) >> 6) + 11)
allowing us to more easily look for locations where we are passing
a pointer to an 8 byte value to a function that expects a 4 byte
value. This can occur on some platforms where sizeof(long) == 8
and sizeof(size_t) == 4.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
show-index.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/show-index.c b/show-index.c
index 57ed9e8..7253991 100644
--- a/show-index.c
+++ b/show-index.c
@@ -68,7 +68,7 @@ int main(int argc, char **argv)
ntohl(off64[1]);
off64_nr++;
}
- printf("%llu %s (%08x)\n", (unsigned long long) offset,
+ printf("%" PRIuMAX " %s (%08x)\n", (uintmax_t) offset,
sha1_to_hex(entries[i].sha1),
ntohl(entries[i].crc));
}
--
1.5.3.4.1270.g2fe543
^ permalink raw reply related
* [PATCH 2/2] Correct some sizeof(size_t) != sizeof(unsigned long) typing errors
From: Shawn O. Pearce @ 2007-10-21 5:25 UTC (permalink / raw)
To: git
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(-)
diff --git a/builtin-apply.c b/builtin-apply.c
index 05c6bc3..022f916 100644
--- a/builtin-apply.c
+++ b/builtin-apply.c
@@ -1955,7 +1955,7 @@ static int apply_data(struct patch *patch, struct stat *st, struct cache_entry *
if (apply_fragments(&buf, patch) < 0)
return -1; /* note with --reject this succeeds. */
- patch->result = strbuf_detach(&buf, &patch->resultsize);
+ patch->result = strbuf_detach_ul(&buf, &patch->resultsize);
if (0 < patch->is_delete && patch->resultsize)
return error("removal patch leaves file contents");
diff --git a/builtin-archive.c b/builtin-archive.c
index 04385de..46d5de0 100644
--- a/builtin-archive.c
+++ b/builtin-archive.c
@@ -153,7 +153,7 @@ void *sha1_file_to_archive(const char *path, const unsigned char *sha1,
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_ul(&buf, sizep);
}
return buffer;
diff --git a/diff.c b/diff.c
index 6648e01..6fd0c0a 100644
--- a/diff.c
+++ b/diff.c
@@ -1519,7 +1519,7 @@ 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_ul(&buf, &s->size);
s->should_free = 1;
return 0;
}
@@ -1611,7 +1611,7 @@ int diff_populate_filespec(struct diff_filespec *s, int size_only)
if (convert_to_git(s->path, s->data, s->size, &buf)) {
munmap(s->data, s->size);
s->should_munmap = 0;
- s->data = strbuf_detach(&buf, &s->size);
+ s->data = strbuf_detach_ul(&buf, &s->size);
s->should_free = 1;
}
}
diff --git a/entry.c b/entry.c
index 98f5f6d..d36a0bb 100644
--- a/entry.c
+++ b/entry.c
@@ -120,7 +120,7 @@ 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)) {
free(new);
- new = strbuf_detach(&buf, &size);
+ new = strbuf_detach_ul(&buf, &size);
}
if (to_tempfile) {
diff --git a/strbuf.h b/strbuf.h
index 9b9e861..d6d6bd0 100644
--- a/strbuf.h
+++ b/strbuf.h
@@ -52,7 +52,13 @@ struct strbuf {
/*----- strbuf life cycle -----*/
extern void strbuf_init(struct strbuf *, size_t);
extern void strbuf_release(struct strbuf *);
-extern char *strbuf_detach(struct strbuf *, size_t *);
+extern char *strbuf_detach(struct strbuf *, unsigned long *);
+static inline char *strbuf_detach_ul(struct strbuf *a, unsigned long *n) {
+ size_t len;
+ char *res = strbuf_detach(a, &len);
+ *n = len;
+ return res;
+}
extern void strbuf_attach(struct strbuf *, void *, size_t, size_t);
static inline void strbuf_swap(struct strbuf *a, struct strbuf *b) {
struct strbuf tmp = *a;
diff --git a/test-delta.c b/test-delta.c
index 3d885ff..018e7dc 100644
--- a/test-delta.c
+++ b/test-delta.c
@@ -20,7 +20,8 @@ int main(int argc, char *argv[])
int fd;
struct stat st;
void *from_buf, *data_buf, *out_buf;
- unsigned long from_size, data_size, out_size;
+ unsigned long from_size, data_size;
+ size_t out_size;
if (argc != 5 || (strcmp(argv[1], "-d") && strcmp(argv[1], "-p"))) {
fprintf(stderr, "Usage: %s\n", usage_str);
--
1.5.3.4.1270.g2fe543
^ permalink raw reply related
* [PATCH] Define compat version of mkdtemp for systems lacking it
From: Shawn O. Pearce @ 2007-10-21 5:30 UTC (permalink / raw)
To: git
Solaris 9 doesn't have mkdtemp() so we need to emulate it for the
rsync transport implementation. Since Solaris 9 is lacking this
function we can also reasonably assume it is not available on
Solaris 8 either. The new Makfile definition NO_MKDTEMP can be
set to enable the git compat version.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
On top of 'next' so that the db/fetch-pack series will actually
build on Solaris 9.
Makefile | 8 ++++++++
compat/mkdtemp.c | 8 ++++++++
git-compat-util.h | 5 +++++
3 files changed, 21 insertions(+), 0 deletions(-)
create mode 100644 compat/mkdtemp.c
diff --git a/Makefile b/Makefile
index bb4873d..6287418 100644
--- a/Makefile
+++ b/Makefile
@@ -38,6 +38,8 @@ all::
#
# Define NO_SETENV if you don't have setenv in the C library.
#
+# Define NO_MKDTEMP if you don't have mkdtemp in the C library.
+#
# Define NO_SYMLINK_HEAD if you never want .git/HEAD to be a symbolic link.
# Enable it on Windows. By default, symrefs are still used.
#
@@ -414,12 +416,14 @@ ifeq ($(uname_S),SunOS)
NEEDS_LIBICONV = YesPlease
NO_UNSETENV = YesPlease
NO_SETENV = YesPlease
+ NO_MKDTEMP = YesPlease
NO_C99_FORMAT = YesPlease
NO_STRTOUMAX = YesPlease
endif
ifeq ($(uname_R),5.9)
NO_UNSETENV = YesPlease
NO_SETENV = YesPlease
+ NO_MKDTEMP = YesPlease
NO_C99_FORMAT = YesPlease
NO_STRTOUMAX = YesPlease
endif
@@ -610,6 +614,10 @@ ifdef NO_SETENV
COMPAT_CFLAGS += -DNO_SETENV
COMPAT_OBJS += compat/setenv.o
endif
+ifdef NO_MKDTEMP
+ COMPAT_CFLAGS += -DNO_MKDTEMP
+ COMPAT_OBJS += compat/mkdtemp.o
+endif
ifdef NO_UNSETENV
COMPAT_CFLAGS += -DNO_UNSETENV
COMPAT_OBJS += compat/unsetenv.o
diff --git a/compat/mkdtemp.c b/compat/mkdtemp.c
new file mode 100644
index 0000000..34d4b49
--- /dev/null
+++ b/compat/mkdtemp.c
@@ -0,0 +1,8 @@
+#include "../git-compat-util.h"
+
+char *gitmkdtemp(char *template)
+{
+ if (!mktemp(template) || mkdir(template, 0700))
+ return NULL;
+ return template;
+}
diff --git a/git-compat-util.h b/git-compat-util.h
index f23d934..474f1d1 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -147,6 +147,11 @@ extern ssize_t git_pread(int fd, void *buf, size_t count, off_t offset);
extern int gitsetenv(const char *, const char *, int);
#endif
+#ifdef NO_MKDTEMP
+#define mkdtemp gitmkdtemp
+extern char *gitmkdtemp(char *);
+#endif
+
#ifdef NO_UNSETENV
#define unsetenv gitunsetenv
extern void gitunsetenv(const char *);
--
1.5.3.4.1270.g2fe543
^ permalink raw reply related
* Re: [BUG] git-mv submodule failure
From: Yin Ping @ 2007-10-21 5:48 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0710202223590.25221@racer.site>
>
> 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
> Ciao,
> Dscho
>
>
--
franky
^ permalink raw reply
* Re: Git User's Survey 2007 unfinished summary continued
From: Dmitry Potapov @ 2007-10-21 6:08 UTC (permalink / raw)
To: Andreas Ericsson
Cc: Steffen Prohaska, Federico Mena Quintero, Johannes Schindelin,
Jakub Narebski, git
In-Reply-To: <4719E69B.3020906@op5.se>
On Sat, Oct 20, 2007 at 01:29:31PM +0200, Andreas Ericsson wrote:
> Steffen Prohaska wrote:
> >
> >plumbing: should be hidden from the 'normal' user. Porcelain
> > should be sufficient for every standard task.
> >
>
> Agreed. /usr/libexec/git/ seems to me to be the ideal spot for
> it.
/usr/libexec is against the Filesystem Hierarchy Standard (FHS).
It is better to use /usr/lib/git/ for that.
Dmitry
^ permalink raw reply
* Re: [PATCH] On error, do not list all commands, but point to --help option.
From: Yin Ping @ 2007-10-21 6:33 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Jeff King, Johannes Schindelin, Jari Aalto, git
In-Reply-To: <20071021032953.GC14735@spearce.org>
On 10/21/07, Shawn O. Pearce <spearce@spearce.org> wrote:
> Jeff King <peff@peff.net> wrote:
> > On Sat, Oct 20, 2007 at 10:06:53PM -0400, Shawn O. Pearce wrote:
> >
> > > 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".
> >
> > Yeah, somebody should really work on bash completion...
>
> $ git pu<TAB><TAB>
> pull push
>
> By the time I type out "pus" and hit tab I've already typed out
> the name "push ". Except I frequently find myself getting the
> u before the p, which can't complete. Of course with the above
> alias in place "git u<TAB>" completes out uniquely to "git push "
> (between bash completion and the alias expansion).
>
> But that alias isn't there for my bash tab completion. Its there
> exactly because otherwise "git upsh" gives me 31 lines of useless
> (to me) output without it.
>
My way to resolve this is to define some alias begenning with 'gt' for
frequently used commands, such as 'gtps -> git-push, gtpl ->
git-pull, gtco->git-checkout, gtci->git-commit, gtbr->git-branch'.
so that when i type 'gt<TAB>', only commands that i frequently use are
listed.
--
franky
^ permalink raw reply
* How to run git-gui always in English?
From: Steffen Prohaska @ 2007-10-21 6:47 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Git Mailing List
There are a lot of efforts going on to localize git-gui,
including technical terms like "push". Personally I don't
understand what this should be useful for. The command is called
"git push"s. So, why should it be named differently in the gui.
Anyway, I can switch it off, right? So here's my question.
How can I switch msysgit's git-gui to English, independently of
the language selected for Windows? I recognized that git-gui
adjusts to the 'language selection' of Windows. How can I
disable this? I want git-gui to always display English. Nothing
else, never! I can't help people who use a different language
in the gui, because I'll not understand what they are talking
about and they'll not understand me.
Can I set an option in git-gui's option menu? I haven't
found one.
Steffen
^ permalink raw reply
* Re: How to run git-gui always in English?
From: Shawn O. Pearce @ 2007-10-21 6:52 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Git Mailing List
In-Reply-To: <CCAD0DE0-65D4-4FEC-B02F-658010FECD04@zib.de>
Steffen Prohaska <prohaska@zib.de> wrote:
> There are a lot of efforts going on to localize git-gui,
> including technical terms like "push". Personally I don't
> understand what this should be useful for. The command is called
> "git push"s. So, why should it be named differently in the gui.
>
> Anyway, I can switch it off, right? So here's my question.
>
> How can I switch msysgit's git-gui to English, independently of
> the language selected for Windows? I recognized that git-gui
> adjusts to the 'language selection' of Windows. How can I
> disable this? I want git-gui to always display English. Nothing
> else, never! I can't help people who use a different language
> in the gui, because I'll not understand what they are talking
> about and they'll not understand me.
>
> Can I set an option in git-gui's option menu? I haven't
> found one.
Yea, we don't have a UI to let you set what language the UI should
appear in. Partly because once the UI is up we'd have to restart
the entire process to change the strings its using. And partly
because nobody has asked for this before.
I think that if you set LANG=en before you start git-gui it will
take on English, and so will all of the standard dialogs that we
"borrow" from wish.
--
Shawn.
^ permalink raw reply
* Re: How to run git-gui always in English?
From: Steffen Prohaska @ 2007-10-21 7:03 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Git Mailing List
In-Reply-To: <20071021065230.GE14735@spearce.org>
On Oct 21, 2007, at 8:52 AM, Shawn O. Pearce wrote:
> Steffen Prohaska <prohaska@zib.de> wrote:
>
>> How can I switch msysgit's git-gui to English, independently of
>> the language selected for Windows? I recognized that git-gui
>> adjusts to the 'language selection' of Windows. How can I
>> disable this? I want git-gui to always display English. Nothing
>> else, never! I can't help people who use a different language
>> in the gui, because I'll not understand what they are talking
>> about and they'll not understand me.
>>
>> Can I set an option in git-gui's option menu? I haven't
>> found one.
>>
>
> Yea, we don't have a UI to let you set what language the UI should
> appear in. Partly because once the UI is up we'd have to restart
> the entire process to change the strings its using. And partly
> because nobody has asked for this before.
>
> I think that if you set LANG=en before you start git-gui it will
> take on English, and so will all of the standard dialogs that we
> "borrow" from wish.
Hmm. I have no shell. I run git-gui from the Windows Start Menu.
It directly runs wish to execute the Windows git-gui wrapper:
--- SNIP ---
#!/bin/sh
# Tcl ignores the next line -*- tcl -*- \
exec wish "$0" -- "$@"
if { $argc >=2 && [lindex $argv 0] == "--working-dir" } {
cd [lindex $argv 1]
set argv [lrange $argv 2 end]
incr argc -2
}
set gitguidir [file dirname [info script]]
regsub -all ";" $gitguidir "\\;" gitguidir
set env(PATH) "$gitguidir;$env(PATH)"
unset gitguidir
source [file join [file dirname [info script]] git-gui.tcl]
--- SNIP ---
Do we have a chance before we source the real git-gui.tcl?
Maybe we could "set env(LANG)" based on "git config gui.lang"?
Or is it already too late because we needed to restart wish?
Steffen
^ permalink raw reply
* Re: How to run git-gui always in English?
From: Shawn O. Pearce @ 2007-10-21 7:15 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Git Mailing List
In-Reply-To: <C65193EE-A45D-49ED-8831-1A006421A915@zib.de>
Steffen Prohaska <prohaska@zib.de> wrote:
> On Oct 21, 2007, at 8:52 AM, Shawn O. Pearce wrote:
> >
> >I think that if you set LANG=en before you start git-gui it will
> >take on English, and so will all of the standard dialogs that we
> >"borrow" from wish.
>
> Do we have a chance before we source the real git-gui.tcl?
> Maybe we could "set env(LANG)" based on "git config gui.lang"?
> Or is it already too late because we needed to restart wish?
Hmm. Really quick testing here shows that we just need to make sure
env(LANG) is set before we do the msgcat::mcload call in git-gui.sh
line 104.
If we're going to use a `git config gui.lang` thing then we can
probably just make a msgcat::mclocale call on line 103 just before we
load our message file. Unfortunately this is before we have located
git so technically git-gui doesn't know how to run git-config and
thus cannot get to gui.lang. :-|
Hmm. Looking at this further we may be able to insert the mclocale
call at two locations; one at line 864 before we open the repository
wizard, and again at line 1802, just before we start to initialize
our UI. This does mean that for really serious errors (e.g. "No
git in PATH") we'll be using your native OS language.
--
Shawn.
^ 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