* Re: [PATCH] git.el: Support for incremental status updates.
From: Karl Hasselström @ 2007-07-31 19:58 UTC (permalink / raw)
To: Alexandre Julliard; +Cc: David Kågedal, git
In-Reply-To: <874pjktnoe.fsf@wine.dyndns.org>
On 2007-07-31 20:48:01 +0200, Alexandre Julliard wrote:
> Yes, it's a new function. Something like this should work:
>
> From: Alexandre Julliard <julliard@winehq.org>
> Date: Tue, 31 Jul 2007 20:45:53 +0200
> Subject: [PATCH] git.el: Avoid using ewoc-set-data for compatibility with Emacs 21.
>
> Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Acked-by: Karl Hasselström <kha@treskal.com>
I've only tested it on emacs 21, though.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [RFH PATCH] Teach the emacs git mode about core.excludesfile
From: Karl Hasselström @ 2007-07-31 19:57 UTC (permalink / raw)
To: Alexandre Julliard; +Cc: git
In-Reply-To: <87abtcvozz.fsf@wine.dyndns.org>
On 2007-07-31 12:36:32 +0200, Alexandre Julliard wrote:
> I would do it this way:
>
> From: Alexandre Julliard <julliard@winehq.org>
> Date: Tue, 31 Jul 2007 12:19:05 +0200
> Subject: [PATCH] git.el: Take into account the core.excludesfile config option.
>
> Also don't require .git/info/exclude to exist in order to list unknown
> files.
>
> Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Acked-by: Karl Hasselström <kha@treskal.com>
Works beautifully, thanks.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [PATCH 1/4] Fix allocation of "int*" instead of "int".
From: Jeff King @ 2007-07-31 19:56 UTC (permalink / raw)
To: Christian Couder; +Cc: Junio Hamano, git
In-Reply-To: <20070731144829.ea83d43d.chriscool@tuxfamily.org>
On Tue, Jul 31, 2007 at 02:48:29PM +0200, Christian Couder wrote:
> - weights = xcalloc(on_list, sizeof(int*));
> + weights = xcalloc(on_list, sizeof(int));
How about the correct-by-definition sizeof(*weights)?
-Peff
^ permalink raw reply
* [PATCH] Add test case for basic commit functionality.
From: Kristian Høgsberg @ 2007-07-31 19:37 UTC (permalink / raw)
To: git; +Cc: gitster, Kristian Høgsberg
In-Reply-To: <7vodhtgq99.fsf@assigned-by-dhcp.cox.net>
Signed-off-by: Kristian Høgsberg <krh@redhat.com>
---
Update: using test_tick now, create test files as part of tests, split
amend failure and bad options failure into separate test cases.
t/t7501-commit.sh | 133 +++++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 133 insertions(+), 0 deletions(-)
create mode 100644 t/t7501-commit.sh
diff --git a/t/t7501-commit.sh b/t/t7501-commit.sh
new file mode 100644
index 0000000..ef0aab5
--- /dev/null
+++ b/t/t7501-commit.sh
@@ -0,0 +1,133 @@
+#!/bin/sh
+#
+# Copyright (c) 2007 Kristian Høgsberg <krh@redhat.com>
+#
+
+# FIXME: Test the various index usages, -i and -o, test reflog,
+# signoff, hooks
+
+test_description='git-commit'
+. ./test-lib.sh
+
+test_tick
+
+test_expect_success \
+ "initial status" \
+ "echo 'bongo bongo' >file &&
+ git-add file && \
+ git-status | grep 'Initial commit'"
+
+test_expect_failure \
+ "fail initial amend" \
+ "git-commit --amend"
+
+test_expect_success \
+ "initial commit" \
+ "git-commit -m initial"
+
+test_expect_failure \
+ "invalid options 1" \
+ "git-commit --amend -F file"
+
+test_expect_failure \
+ "invalid options 2" \
+ "git-commit -C HEAD -m illegal"
+
+test_expect_failure \
+ "using invalid commit with -C" \
+ "git-commit -C bogus"
+
+test_expect_failure \
+ "testing nothing to commit" \
+ "git-commit -m initial"
+
+test_expect_success \
+ "next commit" \
+ "echo 'bongo bongo bongo' >file \
+ git-commit -m next -a"
+
+test_expect_failure \
+ "commit message from non-existing file" \
+ "echo 'more bongo: bongo bongo bongo bongo' >file && \
+ git-commit -F gah -a"
+
+cat >msg <<EOF
+
+
+
+Signed-off-by: hula
+EOF
+test_expect_failure \
+ "empty commit message" \
+ "git-commit -F msg -a"
+
+test_expect_success \
+ "commit message from file" \
+ "echo 'this is the commit message, coming from a file' >msg && \
+ git-commit -F msg -a"
+
+cat >editor <<\EOF
+#!/bin/sh
+sed -i -e "s/a file/an amend commit/g" $1
+EOF
+chmod 755 editor
+
+test_expect_success \
+ "amend commit" \
+ "VISUAL=./editor git-commit --amend"
+
+test_expect_failure \
+ "passing --amend and -F" \
+ "echo 'enough with the bongos' >file && \
+ git-commit -F msg --amend ."
+
+test_expect_success \
+ "using message from other commit" \
+ "git-commit -C HEAD^ ."
+
+cat >editor <<\EOF
+#!/bin/sh
+sed -i -e "s/amend/older/g" $1
+EOF
+chmod 755 editor
+
+test_expect_success \
+ "editing message from other commit" \
+ "echo 'hula hula' >file && \
+ VISUAL=./editor git-commit -c HEAD^ -a"
+
+test_expect_success \
+ "message from stdin" \
+ "echo 'silly new contents' >file && \
+ echo commit message from stdin | git-commit -F - -a"
+
+test_expect_success \
+ "overriding author from command line" \
+ "echo 'gak' >file && \
+ git-commit -m 'author' --author 'Rubber Duck <rduck@convoy.org>' -a"
+
+test_expect_success \
+ "interactive add" \
+ "echo 7 | git-commit --interactive | grep 'What now'"
+
+test_expect_success \
+ "showing committed revisions" \
+ "git-rev-list HEAD >current"
+
+# We could just check the head sha1, but checking each commit makes it
+# easier to isolate bugs.
+
+cat >expected <<\EOF
+72c0dc9855b0c9dadcbfd5a31cab072e0cb774ca
+9b88fc14ce6b32e3d9ee021531a54f18a5cf38a2
+3536bbb352c3a1ef9a420f5b4242d48578b92aa7
+d381ac431806e53f3dd7ac2f1ae0534f36d738b9
+4fd44095ad6334f3ef72e4c5ec8ddf108174b54a
+402702b49136e7587daa9280e91e4bb7cb2179f7
+EOF
+
+test_expect_success \
+ 'validate git-rev-list output.' \
+ 'diff current expected'
+
+test_done
--
1.5.2.GIT
^ permalink raw reply related
* Re: Git User's Survey 2007 - web survey site
From: Paolo Ciarrocchi @ 2007-07-31 19:07 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Martin Langhoff
In-Reply-To: <200707311835.03197.jnareb@gmail.com>
On 7/31/07, Jakub Narebski <jnareb@gmail.com> wrote:
> Jakub Narebski wrote:
> > On 7/31/07, Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com> wrote:
> >> On 7/31/07, Jakub Narebski <jnareb@gmail.com> wrote:
>
> >>> I might have no access ti Internet for a while, so the survey start
> >>> might get delayed. Unless of course somebody want's to do the honors...
>
> False alarm. Of course, if you want to help... for example some of those
> magazines, journals, blogs, news sites use form submission, and not via
> email.
Jakub Narebski
> Sure, I'll help as much as I can.
> >> I might help.
> >> Did you already choose the web survey service?
> >
> > No. I was thinking about using the same as in previous survey.
>
> http://www.survey.net.nz
When I wrote the first survey Martin Langhoff help me in getting the
data into the site.
Maybe he can help us this time too (Martin CC'ed ;-)
> Requirements for survey site: single answer and multiple answer
> questions, single line and textarea answers. It would be nice
> to have select form for the state, and for the language but it
> is not required. I'd rather it not be heavyweight.
>
> I'd like for it to have place for comment to question (which will
> not be present in the summary), like example answers or explanation
> of question. It would be nice to have questions divided into sections.
>
> Any other proposals?
I'll google a bit but I think we should proceed as you suggested.
--
Paolo
http://paolo.ciarrocchi.googlepages.com/
Philip Stanhope IV conte di Chesterfield
^ permalink raw reply
* Re: [PATCH] git.el: Support for incremental status updates.
From: Alexandre Julliard @ 2007-07-31 18:48 UTC (permalink / raw)
To: Karl Hasselström; +Cc: David Kågedal, git
In-Reply-To: <20070731111438.GA17903@diana.vm.bytemark.co.uk>
Karl Hasselström <kha@treskal.com> writes:
> git.el already requires ewoc. And it uses a number of ewoc functions
> (and has done so since its creation); this newly introduced call is
> the only one that fails.
>
> Also, I've just discovered that with Emacs 22.1, I don't see this
> problem. So my guess is that ewoc-set-data is newer than Emacs 21.4.
Yes, it's a new function. Something like this should work:
From 8da6b3257fe785484c5683fc97edccf75ac5588d Mon Sep 17 00:00:00 2001
From: Alexandre Julliard <julliard@winehq.org>
Date: Tue, 31 Jul 2007 20:45:53 +0200
Subject: [PATCH] git.el: Avoid using ewoc-set-data for compatibility with Emacs 21.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
---
contrib/emacs/git.el | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/contrib/emacs/git.el b/contrib/emacs/git.el
index 9bcd7c4..f6102fc 100644
--- a/contrib/emacs/git.el
+++ b/contrib/emacs/git.el
@@ -530,7 +530,7 @@ and returns the process output as a string."
(setf (git-fileinfo->needs-refresh info) t)
(when node ;preserve the marked flag
(setf (git-fileinfo->marked info) (git-fileinfo->marked (ewoc-data node))))
- (if node (ewoc-set-data node info) (ewoc-enter-last status info))))
+ (if node (setf (ewoc-data node) info) (ewoc-enter-last status info))))
(defun git-run-diff-index (status files)
"Run git-diff-index on FILES and parse the results into STATUS.
--
1.5.3.rc3.97.gcb90c
--
Alexandre Julliard
julliard@winehq.org
^ permalink raw reply related
* Re: merge time
From: Steffen Prohaska @ 2007-07-31 18:06 UTC (permalink / raw)
To: Linus Torvalds
Cc: Jeff King, david, Shawn O. Pearce, Junio C Hamano,
Matthew L Foster, git
In-Reply-To: <alpine.LFD.0.999.0707301038380.4161@woody.linux-foundation.org>
On Jul 30, 2007, at 7:42 PM, Linus Torvalds wrote:
> On Mon, 30 Jul 2007, Jeff King wrote:
>>
>> If you followed a strict policy of always merging topics to a "base"
>> branch as your first parent, then never allowing fast forwards should
>> allow a very easy-to-read history in gitk.
>
> Only if only *one* person ever does any merges.
>
> Immediately when you have other people merging code, you're now
> back in
> the same boat.
>
> This is why I personally think the whole policy of "no fast
> forward" is
> totally broken. It's only usable in a non-distributed environment,
> where
> there is one central person who does everything (a so-called "star
> topology").
I think no fast forward merges can always provide useful information.
Public releases are often created from a public, linear branch that
is not arbitrarily jumping around. Even if more than one person creates
such releases there must be some agreement upon the responsibility for
the release and thus for the branch the releases are created from.
If all agreed to merge topics following the "no fast forward" policy and
to use the release branch as a first parent, the commits along the first
parents would document how commits came into the release branch. Non
fast
forward merges would always document that a series of commits was added
to the release branch at once at the (local time) of the merge commit.
If fast forwards are allowed it depends on whether the release branch
can
be fast-forwarded over a series of commits on a topic branch or not.
In case of fast-forward, the history makes you believe each of the
commits
of the topic branch entered the release branch separately. It hides that
they were all merged at once.
I think, avoiding fast forwards may also be used to document a different
level of quality required from commits to a topic branch and from
commits
to the release branch. A the time of the merge the tip of a topic branch
must fulfill all quality requirements, for example compile on all
platforms
and pass all tests. But this need not be the case for every single
commit
on the topic branch. If you avoid fast forwards you still get a chain of
commits along the first parent that would fulfill your quality
requirements.
If you allowed a fast forward over a low quality topic branch your chain
might be broken and you can't be sure, which commits will have high
quality
and which one have a lower quality.
You may argue that this is all crap because every single commit
should be
of highest quality, but I think this is unrealistic. Especially if
more than
one person is jointly working on a topic branch and less experienced and
more experienced developers work together. It may also be rational to
first
get the basic functionality right and later polish work for several
platforms
and usage scenarios.
Obviously other techniques, like rewriting a topic branch to a
perfect commit
series may be used as well. But from my understanding this may be
hard if more
than a single person is involved. You could also squash the complete
topic
branch into a single commit but then valuable history might get lost.
I don't see why what I have in mind would break if other people are
merging
code, too. They may or may not follow my local rules. But at the time of
merging their changes, I can enforce my local quality policy and
document
this by create a merge commit.
This could even be applied recursively. You could start to do a
couple of
merges but only thoroughly test the final result of the last merge.
You could
then enforce a link between the last very stable commit before you
did all the
merges and the very well tested result after the final merge by
enforcing a
"no fast forward" merge.
I'm not quite sure if such a history would be useful in the long term or
may just become to complex. I'm also not sure if the artificial links
would
cause any trouble. I'm wondering, for example, if there are any cases
in which
the additional links would make branching and merging harder.
Steffen
^ permalink raw reply
* [PATCH] Allow fmt_ident to get an arbitrary buffer for the output
From: Alex Riesen @ 2007-07-31 17:16 UTC (permalink / raw)
To: Kristian Høgsberg; +Cc: Junio C Hamano, git
[-- Attachment #1: Type: text/plain, Size: 565 bytes --]
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
builtin-blame.c | 5 +++--
cache.h | 8 +++++++-
ident.c | 47 +++++++++++++++++++++--------------------------
3 files changed, 31 insertions(+), 29 deletions(-)
On 7/31/07, Alex Riesen <raa.lkml@gmail.com> wrote:
> Ach, that's why... Junio, how about this then? I'd even suggest adding
> the buffer argument to fmt_ident and use it everywhere (ATM there is
> only one user outside of ident.c: builtin-blame.c).
Something like this (on top of the previous re git_author|committer_info)
[-- Attachment #2: 0002-Allow-fmt_ident-to-get-an-arbitrary-buffer-for-the-out.txt --]
[-- Type: text/plain, Size: 4461 bytes --]
From fd728acc96ec35e36b0a8233c9f9c2f0eb78fd1d Mon Sep 17 00:00:00 2001
From: Alex Riesen <raa.lkml@gmail.com>
Date: Tue, 31 Jul 2007 19:13:06 +0200
Subject: [PATCH] Allow fmt_ident to get an arbitrary buffer for the output
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
builtin-blame.c | 5 +++--
cache.h | 8 +++++++-
ident.c | 47 +++++++++++++++++++++--------------------------
3 files changed, 31 insertions(+), 29 deletions(-)
diff --git a/builtin-blame.c b/builtin-blame.c
index 0519339..2d5e35d 100644
--- a/builtin-blame.c
+++ b/builtin-blame.c
@@ -1995,7 +1995,7 @@ static struct commit *fake_working_tree_commit(const char *path, const char *con
struct origin *origin;
unsigned char head_sha1[20];
char *buf;
- const char *ident;
+ char ident[FMT_IDENT_BUFSIZE];
int fd;
time_t now;
unsigned long fin_size;
@@ -2108,7 +2108,8 @@ static struct commit *fake_working_tree_commit(const char *path, const char *con
cache_tree_invalidate_path(active_cache_tree, path);
commit->buffer = xmalloc(400);
- ident = fmt_ident("Not Committed Yet", "not.committed.yet", NULL, 0);
+ fmt_ident(ident, sizeof(ident),
+ "Not Committed Yet", "not.committed.yet", NULL, 0);
snprintf(commit->buffer, 400,
"tree 0000000000000000000000000000000000000000\n"
"parent %s\n"
diff --git a/cache.h b/cache.h
index 53801b8..d7b2ef6 100644
--- a/cache.h
+++ b/cache.h
@@ -425,7 +425,13 @@ unsigned long approxidate(const char *);
extern const char *git_author_info(int);
extern const char *git_committer_info(int);
-extern const char *fmt_ident(const char *name, const char *email, const char *date_str, int);
+#define FMT_IDENT_BUFSIZE 1000
+extern char *fmt_ident(char *buffer,
+ int bufsize,
+ const char *name,
+ const char *email,
+ const char *date_str,
+ int error_on_no_name);
struct checkout {
const char *base_dir;
diff --git a/ident.c b/ident.c
index 0d59090..a29d217 100644
--- a/ident.c
+++ b/ident.c
@@ -192,9 +192,9 @@ static const char *env_hint =
"Add --global to set your account\'s default\n"
"\n";
-#define FMT_IDENT_BUFSIZE 1000
-static char *fmt_ident_buf(char *buffer, const char *name, const char *email,
- const char *date_str, int error_on_no_name)
+char *fmt_ident(char *buffer, int size,
+ const char *name, const char *email,
+ const char *date_str, int error_on_no_name)
{
char date[50];
int i;
@@ -227,34 +227,28 @@ static char *fmt_ident_buf(char *buffer, const char *name, const char *email,
if (date_str)
parse_date(date_str, date, sizeof(date));
- i = copy(buffer, FMT_IDENT_BUFSIZE, 0, name);
- i = add_raw(buffer, FMT_IDENT_BUFSIZE, i, " <");
- i = copy(buffer, FMT_IDENT_BUFSIZE, i, email);
- i = add_raw(buffer, FMT_IDENT_BUFSIZE, i, "> ");
- i = copy(buffer, FMT_IDENT_BUFSIZE, i, date);
- if (i >= FMT_IDENT_BUFSIZE)
+ i = copy(buffer, size, 0, name);
+ i = add_raw(buffer, size, i, " <");
+ i = copy(buffer, size, i, email);
+ i = add_raw(buffer, size, i, "> ");
+ i = copy(buffer, size, i, date);
+ if (i >= size)
die("Impossibly long personal identifier");
buffer[i] = 0;
return buffer;
}
-const char *fmt_ident(const char *name, const char *email,
- const char *date_str, int error_on_no_name)
-{
- static char buffer[FMT_IDENT_BUFSIZE];
- return fmt_ident_buf(buffer, name, email, date_str, error_on_no_name);
-}
-
const char *git_author_info(int error_on_no_name)
{
static char *buffer;
if (!buffer)
buffer = xmalloc(FMT_IDENT_BUFSIZE);
- return fmt_ident_buf(buffer,
- getenv("GIT_AUTHOR_NAME"),
- getenv("GIT_AUTHOR_EMAIL"),
- getenv("GIT_AUTHOR_DATE"),
- error_on_no_name);
+ return fmt_ident(buffer,
+ FMT_IDENT_BUFSIZE,
+ getenv("GIT_AUTHOR_NAME"),
+ getenv("GIT_AUTHOR_EMAIL"),
+ getenv("GIT_AUTHOR_DATE"),
+ error_on_no_name);
}
const char *git_committer_info(int error_on_no_name)
@@ -262,9 +256,10 @@ const char *git_committer_info(int error_on_no_name)
static char *buffer;
if (!buffer)
buffer = xmalloc(FMT_IDENT_BUFSIZE);
- return fmt_ident_buf(buffer,
- getenv("GIT_COMMITTER_NAME"),
- getenv("GIT_COMMITTER_EMAIL"),
- getenv("GIT_COMMITTER_DATE"),
- error_on_no_name);
+ return fmt_ident(buffer,
+ FMT_IDENT_BUFSIZE,
+ getenv("GIT_COMMITTER_NAME"),
+ getenv("GIT_COMMITTER_EMAIL"),
+ getenv("GIT_COMMITTER_DATE"),
+ error_on_no_name);
}
--
1.5.3.rc3.132.g39179
^ permalink raw reply related
* [PATCH] Allow git_author|committer_info be called in the same expression
From: Alex Riesen @ 2007-07-31 16:57 UTC (permalink / raw)
To: Kristian Høgsberg; +Cc: Junio C Hamano, git
[-- Attachment #1: Type: text/plain, Size: 1180 bytes --]
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
ident.c | 49 ++++++++++++++++++++++++++++++++-----------------
1 files changed, 32 insertions(+), 17 deletions(-)
On 7/31/07, Kristian Høgsberg <krh@redhat.com> wrote:
> There's number of buffers that don't get freed: the strbuf, the commit
> message buffer, and the strdup'ed author and committer info. All the
> leaks are not critical since the process exits immediately. As for the
> strbuf leak, I was thinking about renaming strbuf_begin to strbuf_reset
> and making it public[1], which will then be used for freeing up strbuf
> memory. The message buffer leak should be fixed by adding a
> strbuf_read_fd() that just reads it straight into the strbuf. The
> xstrdup's are necessary because fmt_ident uses a static buffer (thanks,
> test case :). We could add rotating static buffers for fmt_ident like
> git_path and avoid the strdups, but again, the leaks are not critical.
Ach, that's why... Junio, how about this then? I'd even suggest adding
the buffer argument to fmt_ident and use it everywhere (ATM there is
only one user outside of ident.c: builtin-blame.c).
This one is applicable immediately, though
[-- Attachment #2: 0001-Allow-git_author-committer_info-be-called-in-the-same.txt --]
[-- Type: text/plain, Size: 2862 bytes --]
From 0c86739aa9f5db19ebcd2bc041622c317611c87f Mon Sep 17 00:00:00 2001
From: Alex Riesen <raa.lkml@gmail.com>
Date: Tue, 31 Jul 2007 18:48:23 +0200
Subject: [PATCH] Allow git_author|committer_info be called in the same expression
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
ident.c | 49 ++++++++++++++++++++++++++++++++-----------------
1 files changed, 32 insertions(+), 17 deletions(-)
diff --git a/ident.c b/ident.c
index 6612d17..0d59090 100644
--- a/ident.c
+++ b/ident.c
@@ -192,10 +192,10 @@ static const char *env_hint =
"Add --global to set your account\'s default\n"
"\n";
-const char *fmt_ident(const char *name, const char *email,
- const char *date_str, int error_on_no_name)
+#define FMT_IDENT_BUFSIZE 1000
+static char *fmt_ident_buf(char *buffer, const char *name, const char *email,
+ const char *date_str, int error_on_no_name)
{
- static char buffer[1000];
char date[50];
int i;
@@ -227,29 +227,44 @@ const char *fmt_ident(const char *name, const char *email,
if (date_str)
parse_date(date_str, date, sizeof(date));
- i = copy(buffer, sizeof(buffer), 0, name);
- i = add_raw(buffer, sizeof(buffer), i, " <");
- i = copy(buffer, sizeof(buffer), i, email);
- i = add_raw(buffer, sizeof(buffer), i, "> ");
- i = copy(buffer, sizeof(buffer), i, date);
- if (i >= sizeof(buffer))
+ i = copy(buffer, FMT_IDENT_BUFSIZE, 0, name);
+ i = add_raw(buffer, FMT_IDENT_BUFSIZE, i, " <");
+ i = copy(buffer, FMT_IDENT_BUFSIZE, i, email);
+ i = add_raw(buffer, FMT_IDENT_BUFSIZE, i, "> ");
+ i = copy(buffer, FMT_IDENT_BUFSIZE, i, date);
+ if (i >= FMT_IDENT_BUFSIZE)
die("Impossibly long personal identifier");
buffer[i] = 0;
return buffer;
}
+const char *fmt_ident(const char *name, const char *email,
+ const char *date_str, int error_on_no_name)
+{
+ static char buffer[FMT_IDENT_BUFSIZE];
+ return fmt_ident_buf(buffer, name, email, date_str, error_on_no_name);
+}
+
const char *git_author_info(int error_on_no_name)
{
- return fmt_ident(getenv("GIT_AUTHOR_NAME"),
- getenv("GIT_AUTHOR_EMAIL"),
- getenv("GIT_AUTHOR_DATE"),
- error_on_no_name);
+ static char *buffer;
+ if (!buffer)
+ buffer = xmalloc(FMT_IDENT_BUFSIZE);
+ return fmt_ident_buf(buffer,
+ getenv("GIT_AUTHOR_NAME"),
+ getenv("GIT_AUTHOR_EMAIL"),
+ getenv("GIT_AUTHOR_DATE"),
+ error_on_no_name);
}
const char *git_committer_info(int error_on_no_name)
{
- return fmt_ident(getenv("GIT_COMMITTER_NAME"),
- getenv("GIT_COMMITTER_EMAIL"),
- getenv("GIT_COMMITTER_DATE"),
- error_on_no_name);
+ static char *buffer;
+ if (!buffer)
+ buffer = xmalloc(FMT_IDENT_BUFSIZE);
+ return fmt_ident_buf(buffer,
+ getenv("GIT_COMMITTER_NAME"),
+ getenv("GIT_COMMITTER_EMAIL"),
+ getenv("GIT_COMMITTER_DATE"),
+ error_on_no_name);
}
--
1.5.3.rc3.132.g39179
^ permalink raw reply related
* Git User's Survey 2007 - web survey site
From: Jakub Narebski @ 2007-07-31 16:35 UTC (permalink / raw)
To: git; +Cc: Paolo Ciarrocchi
In-Reply-To: <8fe92b430707310530y555bae6dw11e4a4ea5d6934b0@mail.gmail.com>
Jakub Narebski wrote:
> On 7/31/07, Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com> wrote:
>> On 7/31/07, Jakub Narebski <jnareb@gmail.com> wrote:
>>> I might have no access ti Internet for a while, so the survey start
>>> might get delayed. Unless of course somebody want's to do the honors...
False alarm. Of course, if you want to help... for example some of those
magazines, journals, blogs, news sites use form submission, and not via
email.
>> I might help.
>> Did you already choose the web survey service?
>
> No. I was thinking about using the same as in previous survey.
http://www.survey.net.nz
Requirements for survey site: single answer and multiple answer
questions, single line and textarea answers. It would be nice
to have select form for the state, and for the language but it
is not required. I'd rather it not be heavyweight.
I'd like for it to have place for comment to question (which will
not be present in the summary), like example answers or explanation
of question. It would be nice to have questions divided into sections.
Any other proposals?
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: Efficient way to import snapshots?
From: Theodore Tso @ 2007-07-31 16:15 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Craig Boston, Junio C Hamano, Git Mailing List
In-Reply-To: <alpine.LFD.0.999.0707310845490.4161@woody.linux-foundation.org>
On Tue, Jul 31, 2007 at 08:50:19AM -0700, Linus Torvalds wrote:
> Very interesting. And thanks. The whole "ZFS is great" internet meme seems
> to be partly due to not a lot of people having used or compared it in real
> life. I'm sure it's wonderful for some things, but it clearly does have a
> lot of downsides too.
I'm pretty sure Sun's marketing machine is also very much part of it;
I'm not convinced all of the blogs pitching ZFS as the most wonderful
thing since sliced bread were all, shall we say, unbiased or
uninfluenced by Sun. Add to that the fact that the Solaris 10 License
Agreement prohibits you from publishing benchmark numbers without
Sun's permisison, and it's not at all surprising that most of what
people have heard of ZFS has all been the positive stuff. But with
more people playing with ZFS in the FreeBSD and OpenSolaris camps, I'm
sure a more balanced view that shows its advantages *and*
disadvantages will start showing up.
- Ted
^ permalink raw reply
* Re: Efficient way to import snapshots?
From: Linus Torvalds @ 2007-07-31 15:50 UTC (permalink / raw)
To: Craig Boston; +Cc: Theodore Tso, Junio C Hamano, Git Mailing List
In-Reply-To: <20070731135332.GA58867@nowhere>
On Tue, 31 Jul 2007, Craig Boston wrote:
>
> I just so happen to be rebuilding the zfs pool on that server this
> morning in order to add more swap, so your wish(1tcl) is my rcmd(3).
You, sir, are a total geek.
I'm not sure if that's a compliment or a curse.
> Same machine, on a UFS filesystem (single disk, since zfs was doing the
> RAID), with the cache tuning parameters reset back to defaults:
>
> First 'git status' after a reboot:
> git status 2.23s user 2.23s system 17% cpu 24.987 total
>
> Second:
> git status 1.81s user 1.34s system 98% cpu 3.188 total
>
> Third:
> git status 1.76s user 1.45s system 98% cpu 3.252 total
>
> So I definitely think the problem is just that with its increased
> overhead, ZFS simply can't keep all the metadata in the cache with the
> available memory.
Very interesting. And thanks. The whole "ZFS is great" internet meme seems
to be partly due to not a lot of people having used or compared it in real
life. I'm sure it's wonderful for some things, but it clearly does have a
lot of downsides too.
Linus
^ permalink raw reply
* Re: [PATCH 3/5] Add strbuf_printf() to do formatted printing to a strbuf.
From: Kristian Høgsberg @ 2007-07-31 15:33 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0707311554220.14781@racer.site>
On Tue, 2007-07-31 at 15:55 +0100, Johannes Schindelin wrote:
> Hi,
>
> On Tue, 31 Jul 2007, Kristian H?gsberg wrote:
>
> > On Mon, 2007-07-30 at 21:36 -0700, Junio C Hamano wrote:
> > > Kristian Høgsberg <krh@redhat.com> writes:
> > >
> > > > +static void inline strbuf_grow(struct strbuf *sb, size_t extra)
> > > > +{
> > > > + while (sb->alloc < sb->len + extra)
> > > > sb->alloc = sb->alloc * 3 / 2 + 16;
> > > > + sb->buf = xrealloc(sb->buf, sb->alloc);
> > > > +}
> > >
> > > Somehow this while () loop to compute the growth factor bothers
> > > me but that is probably a minor detail.
> >
> > Think of it as a more efficient way of adding one character at a time :)
> > And it's logarithmic in the number of extra bytes. By the way, I
> > normally just double the size in these cases, which gives you amortized
> > linear performance for adding to the buffer. What's behind the * 3 / 2
> > idea?
>
> But why not
>
> sb->alloc = alloc_nr(sb->len + extra);
That should work, or even ALLOC_GROW, I guess. Didn't know about those
macros. But still, why not just double the size?
Kristian
^ permalink raw reply
* Re: [PATCH 3/5] Add strbuf_printf() to do formatted printing to a strbuf.
From: Kristian Høgsberg @ 2007-07-31 15:28 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0707311556150.14781@racer.site>
On Tue, 2007-07-31 at 15:57 +0100, Johannes Schindelin wrote:
> Hi,
>
> On Tue, 31 Jul 2007, Kristian H?gsberg wrote:
>
> > On Mon, 2007-07-30 at 21:36 -0700, Junio C Hamano wrote:
> > > Kristian Høgsberg <krh@redhat.com> writes:
> > >
> > > > +void strbuf_printf(struct strbuf *sb, const char *fmt, ...)
> > > > +{
> > > > + char one_line[2048];
> > > > + va_list args;
> > > > + int len;
> > >
> > > Such a nice abstraction so far, and then at the highest level of
> > > callchain we have this hardcoded limit?
> >
> > Yeah, I know, it sucks. I'd like to just run vsnprintf with a 0-sized
> > buffer to get the length, and then grow the buffer by that much, but
> > that's not very portable as far as I know.
>
> We do have nfvasprintf()...
Ah, ok... it looks like it's using the second approach I described:
printing into a temp buffer, and realloc'ing and printing again if it
didn't fit. But it dies with 'out of memory' if vsnprintf returns < 0,
is that reasonable? I'm not familiar with what will make vsnprintf
return a negative value... Also, that implementation potentially uses
the va_list twice, which isn't universally supported. C99 introduces
va_copy for this case, but that's also not available everywhere.
However, if the nfvasprintf implementation in trace.c is fine, I'll just
use that approach in strbuf_printf too. I'd just like to know that the
above issues aren't a problem on win32, since part of my motivation for
doing this is to make git available on windows so it will be easier for
people to choose git.
Kristian
^ permalink raw reply
* [PATCH] Mention libiconv as a requirement for git-am
From: Nguyen Thai Ngoc Duy @ 2007-07-31 15:09 UTC (permalink / raw)
To: git, Johannes Sixt, Han-Wen Nienhuys
---
Han-Wen, any chance to include libiconv to the installer? You may need
to set NEEDS_ICONV, ICONVDIR and NO_ICONV properly to make git-am work.
README.MinGW | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/README.MinGW b/README.MinGW
index 89b7065..c0b8f66 100644
--- a/README.MinGW
+++ b/README.MinGW
@@ -28,6 +28,7 @@ In order to compile this code you need:
zlib-1.2.3-mingwPORT-1.tar
w32api-3.6.tar.gz
tcltk-8.4.1-1.exe (for gitk, git-gui)
+ libiconv-1.9.2-1-{lib,bin}.zip (for git-am, from http://gnuwin32.sourceforge.net/packages/libiconv.htm)
STATUS
--
1.5.0.7
^ permalink raw reply related
* Re: [PATCH 3/5] Add strbuf_printf() to do formatted printing to a strbuf.
From: Johannes Schindelin @ 2007-07-31 14:57 UTC (permalink / raw)
To: Kristian Høgsberg; +Cc: Junio C Hamano, git
In-Reply-To: <1185891786.11086.40.camel@hinata.boston.redhat.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 660 bytes --]
Hi,
On Tue, 31 Jul 2007, Kristian H?gsberg wrote:
> On Mon, 2007-07-30 at 21:36 -0700, Junio C Hamano wrote:
> > Kristian Høgsberg <krh@redhat.com> writes:
> >
> > > +void strbuf_printf(struct strbuf *sb, const char *fmt, ...)
> > > +{
> > > + char one_line[2048];
> > > + va_list args;
> > > + int len;
> >
> > Such a nice abstraction so far, and then at the highest level of
> > callchain we have this hardcoded limit?
>
> Yeah, I know, it sucks. I'd like to just run vsnprintf with a 0-sized
> buffer to get the length, and then grow the buffer by that much, but
> that's not very portable as far as I know.
We do have nfvasprintf()...
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 3/5] Add strbuf_printf() to do formatted printing to a strbuf.
From: Johannes Schindelin @ 2007-07-31 14:55 UTC (permalink / raw)
To: Kristian Høgsberg; +Cc: Junio C Hamano, git
In-Reply-To: <1185891786.11086.40.camel@hinata.boston.redhat.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 882 bytes --]
Hi,
On Tue, 31 Jul 2007, Kristian H?gsberg wrote:
> On Mon, 2007-07-30 at 21:36 -0700, Junio C Hamano wrote:
> > Kristian Høgsberg <krh@redhat.com> writes:
> >
> > > +static void inline strbuf_grow(struct strbuf *sb, size_t extra)
> > > +{
> > > + while (sb->alloc < sb->len + extra)
> > > sb->alloc = sb->alloc * 3 / 2 + 16;
> > > + sb->buf = xrealloc(sb->buf, sb->alloc);
> > > +}
> >
> > Somehow this while () loop to compute the growth factor bothers
> > me but that is probably a minor detail.
>
> Think of it as a more efficient way of adding one character at a time :)
> And it's logarithmic in the number of extra bytes. By the way, I
> normally just double the size in these cases, which gives you amortized
> linear performance for adding to the buffer. What's behind the * 3 / 2
> idea?
But why not
sb->alloc = alloc_nr(sb->len + extra);
Hmm?
Ciao,
Dscho
^ permalink raw reply
* Re: git-gui i18n / 0.9.x plans
From: Shawn O. Pearce @ 2007-07-31 14:32 UTC (permalink / raw)
To: Jean-François Veillette; +Cc: git
In-Reply-To: <1E593130-7BBC-488D-88A5-2E16D68614A6@yahoo.ca>
Jean-Fran??ois Veillette <jean_francois_veillette@yahoo.ca> wrote:
> Le 07-07-30 à 21:28, Shawn O. Pearce a écrit :
> > - UI for cherry-pick/revert
> > - Hunk splitting/selection
>
> It would be nice to use the configured external merge tool (git
> mergetool) to help here (in my case os-x:opendiff/FileMerge).
> Having a visual diff between
> - the repository and the index
> - the index and the workarea
> - the repository and the workarea
Hmm. According to the manual[1]:
opendiff file1 file2 [-ancestor ancestorFile] [-merge mergeFile]
what should be the file1/file2/ancesorFile here?
Another problem is this paragraph:
opendiff exits immediately after the comparison request has been
sent to FileMerge.
Uhhhh... how does git-gui know the user is done and the mergeFile
should be staged?
I'm also on OS X (its my primary development system for git-gui)
so I might consider working on this, but after looking at the
manpage I'm not so sure...
[1] http://developer.apple.com/documentation/Darwin/Reference/ManPages/man1/opendiff.1.html
--
Shawn.
^ permalink raw reply
* Re: [PATCH 3/5] Add strbuf_printf() to do formatted printing to a strbuf.
From: Kristian Høgsberg @ 2007-07-31 14:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vhcnlgpeo.fsf@assigned-by-dhcp.cox.net>
On Mon, 2007-07-30 at 21:36 -0700, Junio C Hamano wrote:
> Kristian Høgsberg <krh@redhat.com> writes:
>
> > +static void inline strbuf_grow(struct strbuf *sb, size_t extra)
> > +{
> > + while (sb->alloc < sb->len + extra)
> > sb->alloc = sb->alloc * 3 / 2 + 16;
> > + sb->buf = xrealloc(sb->buf, sb->alloc);
> > +}
>
> Somehow this while () loop to compute the growth factor bothers
> me but that is probably a minor detail.
Think of it as a more efficient way of adding one character at a time :)
And it's logarithmic in the number of extra bytes. By the way, I
normally just double the size in these cases, which gives you amortized
linear performance for adding to the buffer. What's behind the * 3 / 2
idea?
> > +void strbuf_printf(struct strbuf *sb, const char *fmt, ...)
> > +{
> > + char one_line[2048];
> > + va_list args;
> > + int len;
>
> Such a nice abstraction so far, and then at the highest level of
> callchain we have this hardcoded limit?
Yeah, I know, it sucks. I'd like to just run vsnprintf with a 0-sized
buffer to get the length, and then grow the buffer by that much, but
that's not very portable as far as I know. Another approach is to just
vsnprintf into the one_line buffer and copy it into the strbuf if it
doesn't overflow. If it does overflow, grow the buffer with that amount
and vsnprintf into the buffer. I don't think that's portable either,
since vsnprintf can't be relied upon to return the number of characters
it would have printed. One thing that would work, but is much more
involved is to lift the vsnprintf implementation from something like
glib.
So, I dunno... given the options, I opted for a simple solution with
some limitations. Given how many other functions in git work on a fixed
sized static buffer (for example, the fmt_ident case mentioned in
another email), I wouldn't think this is a problem
Kristian
^ permalink raw reply
* Re: [PATCH 1/5] Add test case for basic commit functionality.
From: Kristian Høgsberg @ 2007-07-31 14:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vodhtgq99.fsf@assigned-by-dhcp.cox.net>
On Mon, 2007-07-30 at 21:18 -0700, Junio C Hamano wrote:
> Kristian Høgsberg <krh@redhat.com> writes:
>
> > +# Pick a date so we get consistent commits. 7/7/07 means good luck!
> > +export GIT_AUTHOR_DATE="July 7, 2007"
> > +export GIT_COMMITTER_DATE="July 7, 2007"
>
> Other scripts use test_tick for consistent commits; just to let
> you know, the above is as good if you intend to use only one
> timestamp.
Ok, cool, I'll send out an updated test case.
Kristian
^ permalink raw reply
* Re: [PATCH 5/5] Split out the actual commit creation from the option parsing etc.
From: Kristian Høgsberg @ 2007-07-31 14:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v8x8xgp3s.fsf@assigned-by-dhcp.cox.net>
On Mon, 2007-07-30 at 21:43 -0700, Junio C Hamano wrote:
> Kristian Høgsberg <krh@redhat.com> writes:
>
> > @@ -85,40 +129,20 @@ int cmd_commit_tree(int argc, const char **argv, const char *prefix)
> > parents++;
> > }
> >
> > - /* Not having i18n.commitencoding is the same as having utf-8 */
> > - encoding_is_utf8 = is_encoding_utf8(git_commit_encoding);
> > + buffer = NULL;
> > + if (read_fd(0, &buffer, &len))
> > + die("Could not read commit message from standard input");
> >
> > - strbuf_init(&sb);
> > - strbuf_printf(&sb, "tree %s\n", sha1_to_hex(tree_sha1));
> > + commit_sha1 = create_commit(tree_sha1,
> > + parent_sha1, parents,
> > + xstrdup(git_author_info(1)),
> > + xstrdup(git_committer_info(1)),
> > + buffer, len);
>
> Hmph, the series was so nice so far, but here we have a few new
> leak, presumably so small per process invocation that we do not
> care about?
There's number of buffers that don't get freed: the strbuf, the commit
message buffer, and the strdup'ed author and committer info. All the
leaks are not critical since the process exits immediately. As for the
strbuf leak, I was thinking about renaming strbuf_begin to strbuf_reset
and making it public[1], which will then be used for freeing up strbuf
memory. The message buffer leak should be fixed by adding a
strbuf_read_fd() that just reads it straight into the strbuf. The
xstrdup's are necessary because fmt_ident uses a static buffer (thanks,
test case :). We could add rotating static buffers for fmt_ident like
git_path and avoid the strdups, but again, the leaks are not critical.
Kristian
[1] strbuf_begin() is a good name the way it's used in strbuf.c where
it's balanced by strbuf_end(), but as a general purpose reset function
it's better name strbuf_reset(), I think
^ permalink raw reply
* Re: Efficient way to import snapshots?
From: Craig Boston @ 2007-07-31 13:53 UTC (permalink / raw)
To: Theodore Tso; +Cc: Linus Torvalds, Junio C Hamano, Git Mailing List
In-Reply-To: <20070731042347.GG25876@thunk.org>
On Tue, Jul 31, 2007 at 12:23:47AM -0400, Theodore Tso wrote:
> On Mon, Jul 30, 2007 at 06:44:13PM -0700, Linus Torvalds wrote:
> >
> > Oh, ok. Solaris.
For reference, as I mentioned to Linus & Junio in an excessively
verbose, and probably uninteresting to most of the git-list members,
message about the performance characteristics of ZFS, I'm actually
running FreeBSD-current with the experimental port of ZFS.
So, even less tested & tuned than it is on Solaris. Part of what I'm
doing is stress testing the filesystem on machines with less than the
recommended memory. Even if performance is suboptimal, it should at
least not break anything.
> Craig, it might be interesting to see what sort of results you get if
> you use UFS instead of ZFS in your low-memory constrained
> environment...
I just so happen to be rebuilding the zfs pool on that server this
morning in order to add more swap, so your wish(1tcl) is my rcmd(3).
Same machine, on a UFS filesystem (single disk, since zfs was doing the
RAID), with the cache tuning parameters reset back to defaults:
First 'git status' after a reboot:
git status 2.23s user 2.23s system 17% cpu 24.987 total
Second:
git status 1.81s user 1.34s system 98% cpu 3.188 total
Third:
git status 1.76s user 1.45s system 98% cpu 3.252 total
So I definitely think the problem is just that with its increased
overhead, ZFS simply can't keep all the metadata in the cache with the
available memory.
Craig
^ permalink raw reply
* Re: "git stash" is not known to git
From: Jeff King @ 2007-07-31 13:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, David Kastrup, Linus Torvalds
In-Reply-To: <7vps29f0gp.fsf@assigned-by-dhcp.cox.net>
On Tue, Jul 31, 2007 at 01:20:54AM -0700, Junio C Hamano wrote:
> + * 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.
> */
Yes, that matches my reading of the code.
-Jeff
^ permalink raw reply
* Re: git-gui i18n / 0.9.x plans
From: Jean-François Veillette @ 2007-07-31 13:38 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20070731012804.GZ20052@spearce.org>
Le 07-07-30 à 21:28, Shawn O. Pearce a écrit :
> - UI for cherry-pick/revert
> - Hunk splitting/selection
It would be nice to use the configured external merge tool (git
mergetool) to help here (in my case os-x:opendiff/FileMerge).
Having a visual diff between
- the repository and the index
- the index and the workarea
- the repository and the workarea
Sorry, I can't contribute (never touched tcl/tk), I can only
suggest ... and hope for the best.
- jfv
^ permalink raw reply
* Re: git-svn and distributed git
From: Väinö Järvelä @ 2007-07-31 12:31 UTC (permalink / raw)
To: git
In-Reply-To: <65B05BC3-2BC2-4451-87C2-940113C55287@pp.inet.fi>
On Jul 31, 2007, at 12:42, Väinö Järvelä wrote:
> I have thought about using two branches on the server, master,
> which will only include commits already processed through git-svn,
> and dev, which is used to pull the "local" changes to be committed
> to Subversion. But my inexperience with git got me here, and I
> can't seem to be able to get any updates from the other branch. And
> I'm not even sure if this is the right approach to this problem.
I got the branched situation to work. I was just pushing and pulling
wrong when it didn't work. I guess I didn't understand the
documentation well enough to fiddle around with remotes.
I got the branching to work with simple commands:
server$ git push origin dev
laptop$ git pull server dev
laptop$ git-svn dcommit && git push server && git branch -r -d dev
server$ git checkout master && git pull origin && git branch -D dev
But that's a lot of commands, am I still missing something with the
branching?
Regards,
Väinö
^ 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