* Re: [PATCH 3/8] repack -A -d: use --keep-unreachable when repacking
From: Andreas Ericsson @ 2007-09-17 10:00 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0709171027400.28586@racer.site>
Johannes Schindelin wrote:
> Hi,
>
> On Mon, 17 Sep 2007, Junio C Hamano wrote:
>
>> -USAGE='[-a] [-d] [-f] [-l] [-n] [-q] [--max-pack-size=N] [--window=N] [--window-memory=N] [--depth=N]'
>> +USAGE='[-a|-A] [-d] [-f] [-l] [-n] [-q] [--max-pack-size=N] [--window=N] [--window-memory=N] [--depth=N]'
>
> Would "[-a] [-A]" not be better? In other usage lines, we have the "|"
> for alternative forms of the _same_ option, like "[-m|--merge]".
>
Well, that depends on how you look at it. -m and --merge are (sort of) mutually
exclusive, as the use of one voids the use of the other.
Likewise, using -a and -A together on the same command-line doesn't make much
sense (although -A implies -a rather than meaning the same thing).
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* commit summary, --pretty=short and other tools
From: Mike Hommey @ 2007-09-17 11:21 UTC (permalink / raw)
To: git
Hi,
I kind of shot myself in the foot with how to type proper commit
messages.
The git-commit manual page reads:
Though not required, it´s a good idea to begin the commit message with a
single short (less than 50 character) line summarizing the change,
followed by a blank line and then a more thorough description.
... and I happen to not have done the "followed by a blank line" part.
Now, git log --pretty=oneline (for instance), shows me the full commit
message on one line, which is not really what I would expect...
On the other hand, and that's how I got trapped into this, gitweb and
gitk only display the first line, be it followed by a blank line or not.
So, IMHO, there would be 2 solutions:
- either change --pretty=oneline,short and other similar things to take
only the first line and change the git-commit manpage (and whenever
else this might be written)
- or change gitweb, gitk and any other tool that would only take the
first line so that it takes the same summary as --pretty=oneline.
What do you think ?
Mike
^ permalink raw reply
* Re: commit summary, --pretty=short and other tools
From: Jeff King @ 2007-09-17 11:42 UTC (permalink / raw)
To: Mike Hommey; +Cc: git
In-Reply-To: <20070917112136.GA30201@glandium.org>
On Mon, Sep 17, 2007 at 01:21:36PM +0200, Mike Hommey wrote:
> ... and I happen to not have done the "followed by a blank line" part.
If this isn't a published repo, you can fix it with filter-branch:
git filter-branch --msg-filter 'sed "1a
"'
> Now, git log --pretty=oneline (for instance), shows me the full commit
> message on one line, which is not really what I would expect...
>
> On the other hand, and that's how I got trapped into this, gitweb and
> gitk only display the first line, be it followed by a blank line or not.
This was changed recently for git-log and company, but gitk and gitweb
have not followed suit. Traditionally, the behavior was to take the
first line. This was changed in 4234a761 to take the first paragraph.
The rationale was that people without the nice one-line summaries are
typically importing old histories, and the paragraph makes a much more
sensible summary (as opposed to cutting off the summary in
mid-sentence).
> So, IMHO, there would be 2 solutions:
> - either change --pretty=oneline,short and other similar things to take
> only the first line and change the git-commit manpage (and whenever
> else this might be written)
> - or change gitweb, gitk and any other tool that would only take the
> first line so that it takes the same summary as --pretty=oneline.
>
> What do you think ?
It depends on whether people like the new behavior. I think it is more
sensible in every case _except_ the one you have mentioned, but your
case is hopefully somewhat rare (though it just made it to the public in
1.5.3, so yours might be the first of many comments).
I do agree that it makes sense for all of the tools to be consistent.
-Peff
^ permalink raw reply
* Re: [PATCH] instaweb: support for Ruby's WEBrick server
From: Eric Wong @ 2007-09-17 11:55 UTC (permalink / raw)
To: Mike Dalessio; +Cc: git
In-Reply-To: <618c07250709161935g333f0536q31b453bd58f2d75d@mail.gmail.com>
Mike Dalessio <mike@csa.net> wrote:
> running the webrick server with git requires Ruby and Ruby's YAML and
> Webrick libraries (both of which come standard with Ruby). nice for
> single-user standalone invocations.
>
> the --httpd=webrick option generates a (short!) ruby script on the fly to
> read httpd.conf options and invoke the web server via library call. this
> script is placed in the .git/gitweb directory.
Nice. I'm in favor of adding WEBrick since it's fairly commonly
installed on developer boxes and is more consistently available
if available at all. Apache and lighttpd may not be compiled
with some modules we need.
I'm having trouble applying this patch, however. It's
whitespace-mangled and using long lines doesn't help mailers much.
> Signed-off-by: Mike Dalessio <mike.dalessio@gmail.com>
> ---
> Documentation/git-instaweb.txt | 3 ++-
> git-instaweb.sh | 29 ++++++++++++++++++++++++++++-
> 2 files changed, 30 insertions(+), 2 deletions(-)
>
> +webrick_conf () {
> + # generate a standalone server script in $fqgitdir/gitweb.
> + cat > "$fqgitdir/gitweb/$httpd" <<EOF
> +#! /usr/bin/ruby
Could we make the shebang dynamic? (capturing the output of `which ruby`
maybe, or just breaking down and using /usr/bin/env ruby). The ruby
binary seems to appear all over the place on the filesystem from my
experience, especially with its popularity amongst OSX users.
--
Eric Wong
^ permalink raw reply
* Re: [PATCH] instaweb: support for Ruby's WEBrick server
From: Thomas Adam @ 2007-09-17 12:02 UTC (permalink / raw)
To: Eric Wong; +Cc: Mike Dalessio, git
In-Reply-To: <20070917115518.GA26815@soma>
On 17/09/2007, Eric Wong <normalperson@yhbt.net> wrote:
> Could we make the shebang dynamic? (capturing the output of `which ruby`
> maybe, or just breaking down and using /usr/bin/env ruby). The ruby
> binary seems to appear all over the place on the filesystem from my
> experience, especially with its popularity amongst OSX users.
This is what /usr/bin/env is useful for, but it's not that portable.
-- Thomas Adam
^ permalink raw reply
* Re: [PATCH] instaweb: support for Ruby's WEBrick server
From: Florian Weimer @ 2007-09-17 12:25 UTC (permalink / raw)
To: Thomas Adam; +Cc: Eric Wong, Mike Dalessio, git
In-Reply-To: <18071eea0709170502s397331c5j7d77aa9531f73704@mail.gmail.com>
* Thomas Adam:
> This is what /usr/bin/env is useful for, but it's not that portable.
Yeah, it's /bin/env exclusively on some systems. 8-(
--
Florian Weimer <fweimer@bfk.de>
BFK edv-consulting GmbH http://www.bfk.de/
Kriegsstraße 100 tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99
^ permalink raw reply
* [PATCH] git-merge: add option --no-ff
From: Lars Hjemli @ 2007-09-17 12:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
This new option forces all merges to create a "true" merge commit, i.e. a
commit with multiple parents.
Although a fast-forward would normally be The Right Thing, it isn't when the
branches to be merged originated in subversion and the merge commit will
be pushed back by means of 'git svn dcommit'. In these cases, a fast-
forward merge simply will not work.
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
---
Documentation/merge-options.txt | 4 ++++
git-merge.sh | 13 +++++++++++--
t/t6028-merge-up-to-date.sh | 25 +++++++++++++++++++++++++
3 files changed, 40 insertions(+), 2 deletions(-)
diff --git a/Documentation/merge-options.txt b/Documentation/merge-options.txt
index d64c259..ed28017 100644
--- a/Documentation/merge-options.txt
+++ b/Documentation/merge-options.txt
@@ -25,3 +25,7 @@
If there is no `-s` option, a built-in list of strategies
is used instead (`git-merge-recursive` when merging a single
head, `git-merge-octopus` otherwise).
+
+--no-ff::
+ Force the creation of a merge commit even when the merge would
+ have resolved as a fast-forward operation.
diff --git a/git-merge.sh b/git-merge.sh
index 3a01db0..13b98e6 100755
--- a/git-merge.sh
+++ b/git-merge.sh
@@ -3,7 +3,7 @@
# Copyright (c) 2005 Junio C Hamano
#
-USAGE='[-n] [--summary] [--no-commit] [--squash] [-s <strategy>] [-m=<merge-message>] <commit>+'
+USAGE='[-n] [--summary] [--no-commit] [--no-ff] [--squash] [-s <strategy>] [-m=<merge-message>] <commit>+'
SUBDIRECTORY_OK=Yes
. git-sh-setup
@@ -165,6 +165,10 @@ do
merge_msg="$1"
have_message=t
;;
+ --no-ff)
+ no_ff=t
+ no_fast_forward_strategies=$all_strategies
+ ;;
-*) usage ;;
*) break ;;
esac
@@ -444,7 +448,12 @@ done
# auto resolved the merge cleanly.
if test '' != "$result_tree"
then
- parents=$(git show-branch --independent "$head" "$@" | sed -e 's/^/-p /')
+ if test $no_ff = 't'
+ then
+ parents=$(git rev-parse "$head" "$@" | sed -e 's/^/-p /')
+ else
+ parents=$(git show-branch --independent "$head" "$@" | sed -e 's/^/-p /')
+ fi
result_commit=$(printf '%s\n' "$merge_msg" | git commit-tree $result_tree $parents) || exit
finish "$result_commit" "Merge made by $wt_strategy."
dropsave
diff --git a/t/t6028-merge-up-to-date.sh b/t/t6028-merge-up-to-date.sh
index f8f3e3f..afd74e2 100755
--- a/t/t6028-merge-up-to-date.sh
+++ b/t/t6028-merge-up-to-date.sh
@@ -10,12 +10,14 @@ test_expect_success setup '
test_tick &&
git commit -m initial &&
git tag c0 &&
+ c0=$(git rev-parse c0)
echo second >file &&
git add file &&
test_tick &&
git commit -m second &&
git tag c1 &&
+ c1=$(git rev-parse c1)
git branch test
'
@@ -41,6 +43,16 @@ test_expect_success 'merge -s recursive fast-forward' '
'
+test_expect_success 'merge -s recursive --no-ff' '
+
+ git reset --hard c0 &&
+ test_tick &&
+ git merge -s recursive --no-ff c1 &&
+ test $c0 = $(git rev-parse HEAD^1) &&
+ test $c1 = $(git rev-parse HEAD^2)
+
+'
+
test_expect_success 'merge -s ours up-to-date' '
git reset --hard c1 &&
@@ -63,6 +75,19 @@ test_expect_success 'merge -s ours fast-forward' '
'
+test_expect_success 'merge -s ours --no-ff' '
+
+ git reset --hard c0 &&
+ test_tick &&
+ git merge -s ours --no-ff c1 &&
+ expect=$(git rev-parse c0^{tree}) &&
+ current=$(git rev-parse HEAD^{tree}) &&
+ test "$expect" = "$current" &&
+ test $c0 = $(git rev-parse HEAD^1) &&
+ test $c1 = $(git rev-parse HEAD^2)
+
+'
+
test_expect_success 'merge -s subtree up-to-date' '
git reset --hard c1 &&
--
1.5.3.1.92.g2f5e
^ permalink raw reply related
* Re: [PATCH] git-merge: add option --no-ff
From: Andreas Ericsson @ 2007-09-17 12:39 UTC (permalink / raw)
To: Lars Hjemli; +Cc: Junio C Hamano, git
In-Reply-To: <11900314321506-git-send-email-hjemli@gmail.com>
Lars Hjemli wrote:
> This new option forces all merges to create a "true" merge commit, i.e. a
> commit with multiple parents.
>
> Although a fast-forward would normally be The Right Thing, it isn't when the
> branches to be merged originated in subversion and the merge commit will
> be pushed back by means of 'git svn dcommit'. In these cases, a fast-
> forward merge simply will not work.
>
> If there is no `-s` option, a built-in list of strategies
> is used instead (`git-merge-recursive` when merging a single
> head, `git-merge-octopus` otherwise).
> +
> +--no-ff::
> + Force the creation of a merge commit even when the merge would
> + have resolved as a fast-forward operation.
+ Although a fast-forward would normally be The Right Thing, it isn't when the
+ branches to be merged originated in subversion and the merge commit will
+ be pushed back by means of 'git svn dcommit'. In these cases, a fast-
+ forward merge simply will not work.
Otherwise someone will sit down and try to figure out why this is necessary.
I'm having trouble understanding why this is needed, but I'll take your word
for it ;-)
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: RFC: German translation vocabulary
From: David Kastrup @ 2007-09-17 12:42 UTC (permalink / raw)
To: git
In-Reply-To: <20070917075433.GF17021@cip.informatik.uni-erlangen.de>
Alexander Wuerstlein <snalwuer@cip.informatik.uni-erlangen.de> writes:
> On 070916 23:34, David Kastrup <dak@gnu.org> wrote:
>> Alexander Wuerstlein <snalwuer@cip.informatik.uni-erlangen.de> writes:
>>
>> > On 070916 14:46, Christian Stimming <stimming@tuhh.de> wrote:
>> >> msgid "commit [noun]"
>> >> msgstr "?bertragung (Sendung?, ?bergabe?, Einspielung?, Ablagevorgang?)"
>> >
>> > "Vorgang"? (think Beamtendeutsch)
>>
>> Buchung, Einbuchung, Verbuchung, Registrierung?
>
> Transaktion?
Well, I might be biased against anything not from myself, but
"Transaktion" is anything with a permanent effect, so I find this term
too unspecific: it would equally well cover resetting, tagging,
and a number of other things.
--
David Kastrup
^ permalink raw reply
* [PATCH 0/3] the return of the strbuf
From: Pierre Habouzit @ 2007-09-17 12:52 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 1049 bytes --]
While getting rid of ->eof in strbuf (as it was somehow tasteless). It
made me aware of the fact that fast-import.c was using a custom buffer
implementation (I think that was the fourth if not the fifth). So here
is the series that eradicates it.
Trying to understand fast-import.c code, I happened to remark that it
was possible to avoid many reallocations, just by reusing old buffers
rather than dropping them (this was not possible in a readable way
before, but it is now, and uses the same mechanisms that was garbage
collecting buffers, to swap them instead).
I've not enough stuff to do real-life tests of the old fast-import and
the new one, but I wouldn't be surprised that it gives a quite nice
speed improvements for tools that use long fast-import batches. If not,
well, the code is shorter and more readable, hence it's still a gain.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH 1/3] Drop strbuf's 'eof' marker, and make read_line a first class citizen.
From: Pierre Habouzit @ 2007-09-17 9:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20070917125211.GA18176@artemis.corp>
read_line is now strbuf_getline, and is a first class citizen, it returns 0
when reading a line worked, EOF else.
The ->eof marker was used non-locally by fast-import.c, mimic the same
behaviour using a static int in "read_next_command", that now returns -1 on
EOF, and avoids to call strbuf_getline when it's in EOF state.
Also no longer automagically strbuf_release the buffer, it's counter
intuitive and breaks fast-import in a very subtle way.
Note: being at EOF implies that command_buf.len == 0.
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
---
builtin-checkout-index.c | 5 ++---
builtin-update-index.c | 8 ++++----
fast-import.c | 34 +++++++++++++++++++---------------
fetch.c | 4 ++--
mktree.c | 4 ++--
strbuf.c | 20 ++++++++------------
strbuf.h | 5 ++---
7 files changed, 39 insertions(+), 41 deletions(-)
diff --git a/builtin-checkout-index.c b/builtin-checkout-index.c
index 85e8efe..a18ecc4 100644
--- a/builtin-checkout-index.c
+++ b/builtin-checkout-index.c
@@ -277,9 +277,7 @@ int cmd_checkout_index(int argc, const char **argv, const char *prefix)
while (1) {
char *path_name;
const char *p;
-
- read_line(&buf, stdin, line_termination);
- if (buf.eof)
+ if (strbuf_getline(&buf, stdin, line_termination) == EOF)
break;
if (line_termination && buf.buf[0] == '"')
path_name = unquote_c_style(buf.buf, NULL);
@@ -292,6 +290,7 @@ int cmd_checkout_index(int argc, const char **argv, const char *prefix)
if (path_name != buf.buf)
free(path_name);
}
+ strbuf_release(&buf);
}
if (all)
diff --git a/builtin-update-index.c b/builtin-update-index.c
index 0b60513..acd5ab5 100644
--- a/builtin-update-index.c
+++ b/builtin-update-index.c
@@ -320,8 +320,7 @@ static void read_index_info(int line_termination)
* This format is to put higher order stages into the
* index file and matches git-ls-files --stage output.
*/
- read_line(&buf, stdin, line_termination);
- if (buf.eof)
+ if (strbuf_getline(&buf, stdin, line_termination) == EOF)
break;
errno = 0;
@@ -383,6 +382,7 @@ static void read_index_info(int line_termination)
bad_line:
die("malformed index info %s", buf.buf);
}
+ strbuf_release(&buf);
}
static const char update_index_usage[] =
@@ -710,8 +710,7 @@ int cmd_update_index(int argc, const char **argv, const char *prefix)
while (1) {
char *path_name;
const char *p;
- read_line(&buf, stdin, line_termination);
- if (buf.eof)
+ if (strbuf_getline(&buf, stdin, line_termination) == EOF)
break;
if (line_termination && buf.buf[0] == '"')
path_name = unquote_c_style(buf.buf, NULL);
@@ -726,6 +725,7 @@ int cmd_update_index(int argc, const char **argv, const char *prefix)
if (path_name != buf.buf)
free(path_name);
}
+ strbuf_release(&buf);
}
finish:
diff --git a/fast-import.c b/fast-import.c
index 1866d34..da04566 100644
--- a/fast-import.c
+++ b/fast-import.c
@@ -1584,20 +1584,25 @@ static void dump_marks(void)
mark_file, strerror(errno));
}
-static void read_next_command(void)
+static int read_next_command(void)
{
+ static int stdin_eof = 0;
+
+ if (stdin_eof) {
+ unread_command_buf = 0;
+ return EOF;
+ }
+
do {
if (unread_command_buf) {
unread_command_buf = 0;
- if (command_buf.eof)
- return;
} else {
struct recent_command *rc;
strbuf_detach(&command_buf);
- read_line(&command_buf, stdin, '\n');
- if (command_buf.eof)
- return;
+ stdin_eof = strbuf_getline(&command_buf, stdin, '\n');
+ if (stdin_eof)
+ return EOF;
rc = rc_free;
if (rc)
@@ -1616,6 +1621,8 @@ static void read_next_command(void)
cmd_tail = rc;
}
} while (command_buf.buf[0] == '#');
+
+ return 0;
}
static void skip_optional_lf(void)
@@ -1648,8 +1655,7 @@ static void *cmd_data (size_t *size)
size_t term_len = command_buf.len - 5 - 2;
for (;;) {
- read_line(&command_buf, stdin, '\n');
- if (command_buf.eof)
+ if (strbuf_getline(&command_buf, stdin, '\n') == EOF)
die("EOF in data (terminator '%s' not found)", term);
if (term_len == command_buf.len
&& !strcmp(term, command_buf.buf))
@@ -2095,7 +2101,7 @@ static void cmd_new_commit(void)
}
/* file_change* */
- while (!command_buf.eof && command_buf.len > 0) {
+ while (command_buf.len > 0) {
if (!prefixcmp(command_buf.buf, "M "))
file_change_m(b);
else if (!prefixcmp(command_buf.buf, "D "))
@@ -2110,7 +2116,8 @@ static void cmd_new_commit(void)
unread_command_buf = 1;
break;
}
- read_next_command();
+ if (read_next_command() == EOF)
+ break;
}
/* build the tree and the commit */
@@ -2375,11 +2382,8 @@ int main(int argc, const char **argv)
prepare_packed_git();
start_packfile();
set_die_routine(die_nicely);
- for (;;) {
- read_next_command();
- if (command_buf.eof)
- break;
- else if (!strcmp("blob", command_buf.buf))
+ while (read_next_command() != EOF) {
+ if (!strcmp("blob", command_buf.buf))
cmd_new_blob();
else if (!prefixcmp(command_buf.buf, "commit "))
cmd_new_commit();
diff --git a/fetch.c b/fetch.c
index c256e6f..b1c1f07 100644
--- a/fetch.c
+++ b/fetch.c
@@ -222,8 +222,7 @@ int pull_targets_stdin(char ***target, const char ***write_ref)
char *rf_one = NULL;
char *tg_one;
- read_line(&buf, stdin, '\n');
- if (buf.eof)
+ if (strbuf_getline(&buf, stdin, '\n') == EOF)
break;
tg_one = buf.buf;
rf_one = strchr(tg_one, '\t');
@@ -239,6 +238,7 @@ int pull_targets_stdin(char ***target, const char ***write_ref)
(*write_ref)[targets] = rf_one ? xstrdup(rf_one) : NULL;
targets++;
}
+ strbuf_release(&buf);
return targets;
}
diff --git a/mktree.c b/mktree.c
index 5dab4bd..9c137de 100644
--- a/mktree.c
+++ b/mktree.c
@@ -88,8 +88,7 @@ int main(int ac, char **av)
enum object_type type;
char *path;
- read_line(&sb, stdin, line_termination);
- if (sb.eof)
+ if (strbuf_getline(&sb, stdin, line_termination) == EOF)
break;
ptr = sb.buf;
/* Input is non-recursive ls-tree output format
@@ -121,6 +120,7 @@ int main(int ac, char **av)
if (path != ntr)
free(path);
}
+ strbuf_release(&sb);
write_tree(sha1);
puts(sha1_to_hex(sha1));
exit(0);
diff --git a/strbuf.c b/strbuf.c
index c5f9e2a..59383ac 100644
--- a/strbuf.c
+++ b/strbuf.c
@@ -17,7 +17,6 @@ void strbuf_reset(struct strbuf *sb)
{
if (sb->len)
strbuf_setlen(sb, 0);
- sb->eof = 0;
}
char *strbuf_detach(struct strbuf *sb)
@@ -145,14 +144,13 @@ ssize_t strbuf_read(struct strbuf *sb, int fd, size_t hint)
return sb->len - oldlen;
}
-void read_line(struct strbuf *sb, FILE *fp, int term)
+int strbuf_getline(struct strbuf *sb, FILE *fp, int term)
{
int ch;
- if (feof(fp)) {
- strbuf_release(sb);
- sb->eof = 1;
- return;
- }
+
+ strbuf_grow(sb, 0);
+ if (feof(fp))
+ return EOF;
strbuf_reset(sb);
while ((ch = fgetc(fp)) != EOF) {
@@ -161,11 +159,9 @@ void read_line(struct strbuf *sb, FILE *fp, int term)
strbuf_grow(sb, 1);
sb->buf[sb->len++] = ch;
}
- if (ch == EOF && sb->len == 0) {
- strbuf_release(sb);
- sb->eof = 1;
- }
+ if (ch == EOF && sb->len == 0)
+ return EOF;
- strbuf_grow(sb, 1);
sb->buf[sb->len] = '\0';
+ return 0;
}
diff --git a/strbuf.h b/strbuf.h
index f163c63..b2cbd97 100644
--- a/strbuf.h
+++ b/strbuf.h
@@ -44,11 +44,10 @@
struct strbuf {
size_t alloc;
size_t len;
- int eof;
char *buf;
};
-#define STRBUF_INIT { 0, 0, 0, NULL }
+#define STRBUF_INIT { 0, 0, NULL }
/*----- strbuf life cycle -----*/
extern void strbuf_init(struct strbuf *, size_t);
@@ -101,6 +100,6 @@ extern size_t strbuf_fread(struct strbuf *, size_t, FILE *);
/* XXX: if read fails, any partial read is undone */
extern ssize_t strbuf_read(struct strbuf *, int fd, size_t hint);
-extern void read_line(struct strbuf *, FILE *, int);
+extern int strbuf_getline(struct strbuf *, FILE *, int);
#endif /* STRBUF_H */
--
1.5.3.1
^ permalink raw reply related
* [PATCH 2/3] fast-import was using dbuf's, replace them with strbuf's.
From: Pierre Habouzit @ 2007-09-17 11:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20070917125211.GA18176@artemis.corp>
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
---
fast-import.c | 177 ++++++++++++++++++++++-----------------------------------
1 files changed, 68 insertions(+), 109 deletions(-)
diff --git a/fast-import.c b/fast-import.c
index da04566..e456eab 100644
--- a/fast-import.c
+++ b/fast-import.c
@@ -250,12 +250,6 @@ struct tag
unsigned char sha1[20];
};
-struct dbuf
-{
- void *buffer;
- size_t capacity;
-};
-
struct hash_list
{
struct hash_list *next;
@@ -323,8 +317,8 @@ static unsigned int tree_entry_alloc = 1000;
static void *avail_tree_entry;
static unsigned int avail_tree_table_sz = 100;
static struct avail_tree_content **avail_tree_table;
-static struct dbuf old_tree;
-static struct dbuf new_tree;
+static struct strbuf old_tree = STRBUF_INIT;
+static struct strbuf new_tree = STRBUF_INIT;
/* Branch data */
static unsigned long max_active_branches = 5;
@@ -346,7 +340,7 @@ static struct recent_command *cmd_tail = &cmd_hist;
static struct recent_command *rc_free;
static unsigned int cmd_save = 100;
static uintmax_t next_mark;
-static struct dbuf new_data;
+static struct strbuf new_data = STRBUF_INIT;
static void write_branch_report(FILE *rpt, struct branch *b)
{
@@ -566,17 +560,6 @@ static char *pool_strdup(const char *s)
return r;
}
-static void size_dbuf(struct dbuf *b, size_t maxlen)
-{
- if (b->buffer) {
- if (b->capacity >= maxlen)
- return;
- free(b->buffer);
- }
- b->capacity = ((maxlen / 1024) + 1) * 1024;
- b->buffer = xmalloc(b->capacity);
-}
-
static void insert_mark(uintmax_t idnum, struct object_entry *oe)
{
struct mark_set *s = marks;
@@ -1005,8 +988,7 @@ static size_t encode_header(
static int store_object(
enum object_type type,
- void *dat,
- size_t datlen,
+ struct strbuf *dat,
struct last_object *last,
unsigned char *sha1out,
uintmax_t mark)
@@ -1020,10 +1002,10 @@ static int store_object(
z_stream s;
hdrlen = sprintf((char*)hdr,"%s %lu", typename(type),
- (unsigned long)datlen) + 1;
+ (unsigned long)dat->len) + 1;
SHA1_Init(&c);
SHA1_Update(&c, hdr, hdrlen);
- SHA1_Update(&c, dat, datlen);
+ SHA1_Update(&c, dat->buf, dat->len);
SHA1_Final(sha1, &c);
if (sha1out)
hashcpy(sha1out, sha1);
@@ -1044,9 +1026,9 @@ static int store_object(
if (last && last->data && last->depth < max_depth) {
delta = diff_delta(last->data, last->len,
- dat, datlen,
+ dat->buf, dat->len,
&deltalen, 0);
- if (delta && deltalen >= datlen) {
+ if (delta && deltalen >= dat->len) {
free(delta);
delta = NULL;
}
@@ -1059,8 +1041,8 @@ static int store_object(
s.next_in = delta;
s.avail_in = deltalen;
} else {
- s.next_in = dat;
- s.avail_in = datlen;
+ s.next_in = (void *)dat->buf;
+ s.avail_in = dat->len;
}
s.avail_out = deflateBound(&s, s.avail_in);
s.next_out = out = xmalloc(s.avail_out);
@@ -1083,8 +1065,8 @@ static int store_object(
memset(&s, 0, sizeof(s));
deflateInit(&s, zlib_compression_level);
- s.next_in = dat;
- s.avail_in = datlen;
+ s.next_in = (void *)dat->buf;
+ s.avail_in = dat->len;
s.avail_out = deflateBound(&s, s.avail_in);
s.next_out = out = xrealloc(out, s.avail_out);
while (deflate(&s, Z_FINISH) == Z_OK)
@@ -1118,7 +1100,7 @@ static int store_object(
} else {
if (last)
last->depth = 0;
- hdrlen = encode_header(type, datlen, hdr);
+ hdrlen = encode_header(type, dat->len, hdr);
write_or_die(pack_data->pack_fd, hdr, hdrlen);
pack_size += hdrlen;
}
@@ -1131,9 +1113,9 @@ static int store_object(
if (last) {
if (!last->no_free)
free(last->data);
- last->data = dat;
last->offset = e->offset;
- last->len = datlen;
+ last->data = dat->buf;
+ last->len = dat->len;
}
return 0;
}
@@ -1229,14 +1211,10 @@ static int tecmp1 (const void *_a, const void *_b)
b->name->str_dat, b->name->str_len, b->versions[1].mode);
}
-static void mktree(struct tree_content *t,
- int v,
- unsigned long *szp,
- struct dbuf *b)
+static void mktree(struct tree_content *t, int v, struct strbuf *b)
{
size_t maxlen = 0;
unsigned int i;
- char *c;
if (!v)
qsort(t->entries,t->entry_count,sizeof(t->entries[0]),tecmp0);
@@ -1248,27 +1226,22 @@ static void mktree(struct tree_content *t,
maxlen += t->entries[i]->name->str_len + 34;
}
- size_dbuf(b, maxlen);
- c = b->buffer;
+ strbuf_reset(b);
+ strbuf_grow(b, maxlen);
for (i = 0; i < t->entry_count; i++) {
struct tree_entry *e = t->entries[i];
if (!e->versions[v].mode)
continue;
- c += sprintf(c, "%o", (unsigned int)e->versions[v].mode);
- *c++ = ' ';
- strcpy(c, e->name->str_dat);
- c += e->name->str_len + 1;
- hashcpy((unsigned char*)c, e->versions[v].sha1);
- c += 20;
+ strbuf_addf(b, "%o %s%c", (unsigned int)e->versions[v].mode,
+ e->name->str_dat, '\0');
+ strbuf_add(b, e->versions[v].sha1, 20);
}
- *szp = c - (char*)b->buffer;
}
static void store_tree(struct tree_entry *root)
{
struct tree_content *t = root->tree;
unsigned int i, j, del;
- unsigned long new_len;
struct last_object lo;
struct object_entry *le;
@@ -1288,16 +1261,16 @@ static void store_tree(struct tree_entry *root)
lo.depth = 0;
lo.no_free = 0;
} else {
- mktree(t, 0, &lo.len, &old_tree);
- lo.data = old_tree.buffer;
+ mktree(t, 0, &old_tree);
+ lo.len = old_tree.len;
+ lo.data = old_tree.buf;
lo.offset = le->offset;
lo.depth = t->delta_depth;
lo.no_free = 1;
}
- mktree(t, 1, &new_len, &new_tree);
- store_object(OBJ_TREE, new_tree.buffer, new_len,
- &lo, root->versions[1].sha1, 0);
+ mktree(t, 1, &new_tree);
+ store_object(OBJ_TREE, &new_tree, &lo, root->versions[1].sha1, 0);
t->delta_depth = lo.depth;
for (i = 0, j = 0, del = 0; i < t->entry_count; i++) {
@@ -1642,11 +1615,10 @@ static void cmd_mark(void)
next_mark = 0;
}
-static void *cmd_data (size_t *size)
+static void cmd_data(struct strbuf *sb)
{
- struct strbuf buffer;
+ strbuf_reset(sb);
- strbuf_init(&buffer, 0);
if (prefixcmp(command_buf.buf, "data "))
die("Expected 'data n' command, found: %s", command_buf.buf);
@@ -1660,8 +1632,8 @@ static void *cmd_data (size_t *size)
if (term_len == command_buf.len
&& !strcmp(term, command_buf.buf))
break;
- strbuf_addbuf(&buffer, &command_buf);
- strbuf_addch(&buffer, '\n');
+ strbuf_addbuf(sb, &command_buf);
+ strbuf_addch(sb, '\n');
}
free(term);
}
@@ -1671,7 +1643,7 @@ static void *cmd_data (size_t *size)
length = strtoul(command_buf.buf + 5, NULL, 10);
while (n < length) {
- size_t s = strbuf_fread(&buffer, length - n, stdin);
+ size_t s = strbuf_fread(sb, length - n, stdin);
if (!s && feof(stdin))
die("EOF in data (%lu bytes remaining)",
(unsigned long)(length - n));
@@ -1680,8 +1652,6 @@ static void *cmd_data (size_t *size)
}
skip_optional_lf();
- *size = buffer.len;
- return strbuf_detach(&buffer);
}
static int validate_raw_date(const char *src, char *result, int maxlen)
@@ -1744,15 +1714,14 @@ static char *parse_ident(const char *buf)
static void cmd_new_blob(void)
{
- size_t l;
- void *d;
+ struct strbuf buf;
read_next_command();
cmd_mark();
- d = cmd_data(&l);
-
- if (store_object(OBJ_BLOB, d, l, &last_blob, NULL, next_mark))
- free(d);
+ strbuf_init(&buf, 0);
+ cmd_data(&buf);
+ if (store_object(OBJ_BLOB, &buf, &last_blob, NULL, next_mark))
+ strbuf_release(&buf);
}
static void unload_one_branch(void)
@@ -1848,14 +1817,15 @@ static void file_change_m(struct branch *b)
}
if (inline_data) {
- size_t l;
- void *d;
+ struct strbuf buf;
+
if (!p_uq)
p = p_uq = xstrdup(p);
read_next_command();
- d = cmd_data(&l);
- if (store_object(OBJ_BLOB, d, l, &last_blob, sha1, 0))
- free(d);
+ strbuf_init(&buf, 0);
+ cmd_data(&buf);
+ if (store_object(OBJ_BLOB, &buf, &last_blob, sha1, 0))
+ strbuf_release(&buf);
} else if (oe) {
if (oe->type != OBJ_BLOB)
die("Not a blob (actually a %s): %s",
@@ -2062,9 +2032,8 @@ static struct hash_list *cmd_merge(unsigned int *count)
static void cmd_new_commit(void)
{
+ static struct strbuf msg = STRBUF_INIT;
struct branch *b;
- void *msg;
- size_t msglen;
char *sp;
char *author = NULL;
char *committer = NULL;
@@ -2089,7 +2058,7 @@ static void cmd_new_commit(void)
}
if (!committer)
die("Expected committer but didn't get one");
- msg = cmd_data(&msglen);
+ cmd_data(&msg);
read_next_command();
cmd_from(b);
merge_list = cmd_merge(&merge_count);
@@ -2124,46 +2093,39 @@ static void cmd_new_commit(void)
store_tree(&b->branch_tree);
hashcpy(b->branch_tree.versions[0].sha1,
b->branch_tree.versions[1].sha1);
- size_dbuf(&new_data, 114 + msglen
- + merge_count * 49
- + (author
- ? strlen(author) + strlen(committer)
- : 2 * strlen(committer)));
- sp = new_data.buffer;
- sp += sprintf(sp, "tree %s\n",
+
+ strbuf_reset(&new_data);
+ strbuf_addf(&new_data, "tree %s\n",
sha1_to_hex(b->branch_tree.versions[1].sha1));
if (!is_null_sha1(b->sha1))
- sp += sprintf(sp, "parent %s\n", sha1_to_hex(b->sha1));
+ strbuf_addf(&new_data, "parent %s\n", sha1_to_hex(b->sha1));
while (merge_list) {
struct hash_list *next = merge_list->next;
- sp += sprintf(sp, "parent %s\n", sha1_to_hex(merge_list->sha1));
+ strbuf_addf(&new_data, "parent %s\n", sha1_to_hex(merge_list->sha1));
free(merge_list);
merge_list = next;
}
- sp += sprintf(sp, "author %s\n", author ? author : committer);
- sp += sprintf(sp, "committer %s\n", committer);
- *sp++ = '\n';
- memcpy(sp, msg, msglen);
- sp += msglen;
+ strbuf_addf(&new_data,
+ "author %s\n"
+ "committer %s\n"
+ "\n",
+ author ? author : committer, committer);
+ strbuf_addbuf(&new_data, &msg);
free(author);
free(committer);
- free(msg);
- if (!store_object(OBJ_COMMIT,
- new_data.buffer, sp - (char*)new_data.buffer,
- NULL, b->sha1, next_mark))
+ if (!store_object(OBJ_COMMIT, &new_data, NULL, b->sha1, next_mark))
b->pack_id = pack_id;
b->last_commit = object_count_by_type[OBJ_COMMIT];
}
static void cmd_new_tag(void)
{
+ static struct strbuf msg = STRBUF_INIT;
char *sp;
const char *from;
char *tagger;
struct branch *s;
- void *msg;
- size_t msglen;
struct tag *t;
uintmax_t from_mark = 0;
unsigned char sha1[20];
@@ -2214,24 +2176,21 @@ static void cmd_new_tag(void)
/* tag payload/message */
read_next_command();
- msg = cmd_data(&msglen);
+ cmd_data(&msg);
/* build the tag object */
- size_dbuf(&new_data, 67+strlen(t->name)+strlen(tagger)+msglen);
- sp = new_data.buffer;
- sp += sprintf(sp, "object %s\n", sha1_to_hex(sha1));
- sp += sprintf(sp, "type %s\n", commit_type);
- sp += sprintf(sp, "tag %s\n", t->name);
- sp += sprintf(sp, "tagger %s\n", tagger);
- *sp++ = '\n';
- memcpy(sp, msg, msglen);
- sp += msglen;
+ strbuf_reset(&new_data);
+ strbuf_addf(&new_data,
+ "object %s\n"
+ "type %s\n"
+ "tag %s\n"
+ "tagger %s\n"
+ "\n",
+ sha1_to_hex(sha1), commit_type, t->name, tagger);
+ strbuf_addbuf(&new_data, &msg);
free(tagger);
- free(msg);
- if (store_object(OBJ_TAG, new_data.buffer,
- sp - (char*)new_data.buffer,
- NULL, t->sha1, 0))
+ if (store_object(OBJ_TAG, &new_data, NULL, t->sha1, 0))
t->pack_id = MAX_PACK_ID;
else
t->pack_id = pack_id;
--
1.5.3.1
^ permalink raw reply related
* [PATCH 3/3] fast-import optimization:
From: Pierre Habouzit @ 2007-09-17 12:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20070917125211.GA18176@artemis.corp>
Now that cmd_data acts on a strbuf, make last_object stashed buffer be a
strbuf as well. On new stash, don't free the last stashed buffer, rather
swap it with the one you will stash, this way, callers of store_object can
act on static strbufs, and at some point, fast-import won't allocate new
memory for objects buffers.
---
fast-import.c | 52 ++++++++++++++++++++--------------------------------
1 files changed, 20 insertions(+), 32 deletions(-)
diff --git a/fast-import.c b/fast-import.c
index e456eab..e2a4834 100644
--- a/fast-import.c
+++ b/fast-import.c
@@ -182,11 +182,10 @@ struct mark_set
struct last_object
{
- void *data;
- unsigned long len;
+ struct strbuf data;
uint32_t offset;
unsigned int depth;
- unsigned no_free:1;
+ unsigned no_swap : 1;
};
struct mem_pool
@@ -310,7 +309,7 @@ static struct mark_set *marks;
static const char* mark_file;
/* Our last blob */
-static struct last_object last_blob;
+static struct last_object last_blob = { STRBUF_INIT, 0, 0, 0 };
/* Tree management */
static unsigned int tree_entry_alloc = 1000;
@@ -950,9 +949,7 @@ static void end_packfile(void)
free(old_p);
/* We can't carry a delta across packfiles. */
- free(last_blob.data);
- last_blob.data = NULL;
- last_blob.len = 0;
+ strbuf_release(&last_blob.data);
last_blob.offset = 0;
last_blob.depth = 0;
}
@@ -1024,8 +1021,8 @@ static int store_object(
return 1;
}
- if (last && last->data && last->depth < max_depth) {
- delta = diff_delta(last->data, last->len,
+ if (last && last->data.buf && last->depth < max_depth) {
+ delta = diff_delta(last->data.buf, last->data.len,
dat->buf, dat->len,
&deltalen, 0);
if (delta && deltalen >= dat->len) {
@@ -1111,11 +1108,14 @@ static int store_object(
free(out);
free(delta);
if (last) {
- if (!last->no_free)
- free(last->data);
+ if (last->no_swap) {
+ last->data = *dat;
+ } else {
+ struct strbuf tmp = *dat;
+ *dat = last->data;
+ last->data = tmp;
+ }
last->offset = e->offset;
- last->data = dat->buf;
- last->len = dat->len;
}
return 0;
}
@@ -1242,7 +1242,7 @@ static void store_tree(struct tree_entry *root)
{
struct tree_content *t = root->tree;
unsigned int i, j, del;
- struct last_object lo;
+ struct last_object lo = { STRBUF_INIT, 0, 0, /* no_swap */ 1 };
struct object_entry *le;
if (!is_null_sha1(root->versions[1].sha1))
@@ -1254,19 +1254,11 @@ static void store_tree(struct tree_entry *root)
}
le = find_object(root->versions[0].sha1);
- if (!S_ISDIR(root->versions[0].mode)
- || !le
- || le->pack_id != pack_id) {
- lo.data = NULL;
- lo.depth = 0;
- lo.no_free = 0;
- } else {
+ if (S_ISDIR(root->versions[0].mode) && le && le->pack_id == pack_id) {
mktree(t, 0, &old_tree);
- lo.len = old_tree.len;
- lo.data = old_tree.buf;
+ lo.data = old_tree;
lo.offset = le->offset;
lo.depth = t->delta_depth;
- lo.no_free = 1;
}
mktree(t, 1, &new_tree);
@@ -1714,14 +1706,12 @@ static char *parse_ident(const char *buf)
static void cmd_new_blob(void)
{
- struct strbuf buf;
+ static struct strbuf buf = STRBUF_INIT;
read_next_command();
cmd_mark();
- strbuf_init(&buf, 0);
cmd_data(&buf);
- if (store_object(OBJ_BLOB, &buf, &last_blob, NULL, next_mark))
- strbuf_release(&buf);
+ store_object(OBJ_BLOB, &buf, &last_blob, NULL, next_mark);
}
static void unload_one_branch(void)
@@ -1817,15 +1807,13 @@ static void file_change_m(struct branch *b)
}
if (inline_data) {
- struct strbuf buf;
+ static struct strbuf buf = STRBUF_INIT;
if (!p_uq)
p = p_uq = xstrdup(p);
read_next_command();
- strbuf_init(&buf, 0);
cmd_data(&buf);
- if (store_object(OBJ_BLOB, &buf, &last_blob, sha1, 0))
- strbuf_release(&buf);
+ store_object(OBJ_BLOB, &buf, &last_blob, sha1, 0);
} else if (oe) {
if (oe->type != OBJ_BLOB)
die("Not a blob (actually a %s): %s",
--
1.5.3.1
^ permalink raw reply related
* Re: metastore
From: Francis Moreau @ 2007-09-17 13:04 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: Grzegorz Kulewski, martin f krafft, git
In-Reply-To: <86veaby050.fsf@blue.stonehenge.com>
Hello,
On 9/16/07, Randal L. Schwartz <merlyn@stonehenge.com> wrote:
> >>>>> "Grzegorz" == Grzegorz Kulewski <kangur@polcom.net> writes:
>
> Grzegorz> Not only for tracking /etc or /home but also for example for "web
> Grzegorz> applications" (for example in PHP). In that case file and directory
> Grzegorz> permissions can be as important as the source code tracked and it is pain to
> Grzegorz> chmod (and sometimes chown) all files to different values after each
> Grzegorz> checkout. Not speaking about potential race.
>
> Uh, works just fine for me to manage my web site content. The point is
> that I treat git for what it is... a source code management system.
> And then I have a Makefile that "installs" my source code into the live
> directory, with the right modes during installation.
>
> Why does everyone keep wanting "work dir == live dir". Ugh! The work dir is
> the *source*... it gets *copied* into your live dir *somehow*. And *that* is
> where the meta information needs to be. In that "somehow".
>
Interesting. Could you show us what this makefile actually looks ?
How would you create a repo to track /etc ? I'm thinking of importing
this directory by using tar, do you think it's correct ?
thanks.
--
Francis
^ permalink raw reply
* Re: [PATCH] git-merge: add option --no-ff
From: Lars Hjemli @ 2007-09-17 13:16 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Junio C Hamano, git
In-Reply-To: <46EE7584.8010202@op5.se>
On 9/17/07, Andreas Ericsson <ae@op5.se> wrote:
> Lars Hjemli wrote:
> > This new option forces all merges to create a "true" merge commit, i.e. a
> > commit with multiple parents.
> >
> > Although a fast-forward would normally be The Right Thing, it isn't when the
> > branches to be merged originated in subversion and the merge commit will
> > be pushed back by means of 'git svn dcommit'. In these cases, a fast-
> > forward merge simply will not work.
> >
> > If there is no `-s` option, a built-in list of strategies
> > is used instead (`git-merge-recursive` when merging a single
> > head, `git-merge-octopus` otherwise).
> > +
> > +--no-ff::
> > + Force the creation of a merge commit even when the merge would
> > + have resolved as a fast-forward operation.
>
> + Although a fast-forward would normally be The Right Thing, it isn't when the
> + branches to be merged originated in subversion and the merge commit will
> + be pushed back by means of 'git svn dcommit'. In these cases, a fast-
> + forward merge simply will not work.
>
> Otherwise someone will sit down and try to figure out why this is necessary.
True.
> I'm having trouble understanding why this is needed, but I'll take your word
> for it ;-)
I'll try to explain:
When 'git-svn dcommit' decides which commits it should push back
subversion, it scans the output from 'git-log --first-parent HEAD'
looking for embedded 'git-svn-id' lines. These lines contain the url
of the upstream subversion repository + the subversion revision
number. So the problem with fast-forward merges of subversion branches
is that the output from 'git-log --first-parent HEAD' will show
commits from the wrong subversion branch (the fast-forwarded commits).
This could maybe be fixed in git-svn if it learned a different way of
discovering the upstream subversion branch, but then it would make
git-svn commit n revisions to subversion (again, the fast-forwarded
commits) instead of a single merge-commit. This would look (in
subversion) like a series of n cherry-picks from the merged branch.
Btw: maybe the --no-ff section in merge-options.txt could just link to
git-svn.txt, which in turn could have some lengthy explanation about
merge --no-ff/dcommit behaviour?
--
larsh
^ permalink raw reply
* Re: [PATCH] git-merge: add option --no-ff
From: Johannes Schindelin @ 2007-09-17 13:23 UTC (permalink / raw)
To: Lars Hjemli; +Cc: Andreas Ericsson, Junio C Hamano, git
In-Reply-To: <8c5c35580709170616i49a8836hb60423c5eebf601d@mail.gmail.com>
Hi,
On Mon, 17 Sep 2007, Lars Hjemli wrote:
> When 'git-svn dcommit' decides which commits it should push back
> subversion, it scans the output from 'git-log --first-parent HEAD'
> looking for embedded 'git-svn-id' lines. These lines contain the url
> of the upstream subversion repository + the subversion revision
> number.
> So the problem with fast-forward merges of subversion branches is that
> the output from 'git-log --first-parent HEAD' will show commits from the
> wrong subversion branch (the fast-forwarded commits).
Ah, I think I know what you're trying to get at. But "git svn fetch &&
git rebase git-svn" might be a better approach than "git svn fetch && git
merge --no-ff git-svn", no?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 0/3] the return of the strbuf
From: Pierre Habouzit @ 2007-09-17 13:35 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20070917125211.GA18176@artemis.corp>
[-- Attachment #1: Type: text/plain, Size: 1577 bytes --]
On lun, sep 17, 2007 at 12:52:11 +0000, Pierre Habouzit wrote:
> While getting rid of ->eof in strbuf (as it was somehow tasteless). It
> made me aware of the fact that fast-import.c was using a custom buffer
> implementation (I think that was the fourth if not the fifth). So here
> is the series that eradicates it.
>
> Trying to understand fast-import.c code, I happened to remark that it
> was possible to avoid many reallocations, just by reusing old buffers
> rather than dropping them (this was not possible in a readable way
> before, but it is now, and uses the same mechanisms that was garbage
> collecting buffers, to swap them instead).
>
> I've not enough stuff to do real-life tests of the old fast-import and
> the new one, but I wouldn't be surprised that it gives a quite nice
> speed improvements for tools that use long fast-import batches. If not,
> well, the code is shorter and more readable, hence it's still a gain.
Shawn: Johannes makes me remark that you are git-fast-import author,
hence may want to be Cc-ed of that series, so here is a mail so that you
don't miss the thread.
The list: it's often hard to know who you should Cc on a given change,
I use format.headers to force Junio and git@, but sometimes you want a
different set of persons. I wonder if this could not be wired in the
repository, as a .gitattribute extension ?
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] git-merge: add option --no-ff
From: Chris Shoemaker @ 2007-09-17 13:37 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Lars Hjemli, Andreas Ericsson, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0709171422340.28586@racer.site>
On Mon, Sep 17, 2007 at 02:23:38PM +0100, Johannes Schindelin wrote:
> Hi,
>
> On Mon, 17 Sep 2007, Lars Hjemli wrote:
>
> > When 'git-svn dcommit' decides which commits it should push back
> > subversion, it scans the output from 'git-log --first-parent HEAD'
> > looking for embedded 'git-svn-id' lines. These lines contain the url
> > of the upstream subversion repository + the subversion revision
> > number.
>
> > So the problem with fast-forward merges of subversion branches is that
> > the output from 'git-log --first-parent HEAD' will show commits from the
> > wrong subversion branch (the fast-forwarded commits).
>
> Ah, I think I know what you're trying to get at. But "git svn fetch &&
> git rebase git-svn" might be a better approach [...]
BTW, this is spelled "git svn rebase" these days.
-chris
^ permalink raw reply
* Re: [PATCH] git-merge: add option --no-ff
From: Lars Hjemli @ 2007-09-17 13:38 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Andreas Ericsson, Junio C Hamano, git, Eric Wong
In-Reply-To: <Pine.LNX.4.64.0709171422340.28586@racer.site>
[Cc'd Eric since he's the expert on git-svn]
On 9/17/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Mon, 17 Sep 2007, Lars Hjemli wrote:
>
> > When 'git-svn dcommit' decides which commits it should push back
> > subversion, it scans the output from 'git-log --first-parent HEAD'
> > looking for embedded 'git-svn-id' lines. These lines contain the url
> > of the upstream subversion repository + the subversion revision
> > number.
>
> > So the problem with fast-forward merges of subversion branches is that
> > the output from 'git-log --first-parent HEAD' will show commits from the
> > wrong subversion branch (the fast-forwarded commits).
>
> Ah, I think I know what you're trying to get at. But "git svn fetch &&
> git rebase git-svn" might be a better approach than "git svn fetch && git
> merge --no-ff git-svn", no?
If I'm understanding you right: no. After a rebase, the commits would
be ignored by git-svn when looking for the subversion upstream branch
(since the commit SHA1's would no longer match the ones stored in
git-svn's rev_db), but the subversion history would look like
'cherry-picked n commits from merged branch' after dcommit.
--
larsh
^ permalink raw reply
* Re: [PATCH] git-merge: add option --no-ff
From: Lars Hjemli @ 2007-09-17 13:40 UTC (permalink / raw)
To: Chris Shoemaker
Cc: Johannes Schindelin, Andreas Ericsson, Junio C Hamano, git
In-Reply-To: <20070917133742.GA10923@pe.Belkin>
On 9/17/07, Chris Shoemaker <c.shoemaker@cox.net> wrote:
> On Mon, Sep 17, 2007 at 02:23:38PM +0100, Johannes Schindelin wrote:
> > Ah, I think I know what you're trying to get at. But "git svn fetch &&
> > git rebase git-svn" might be a better approach [...]
>
> BTW, this is spelled "git svn rebase" these days.
Not in this case, since 'git-svn rebase' would fall in the same trap
as 'git-svn dcommit'.
--
larsh
^ permalink raw reply
* Re: [PATCH] git-merge: add option --no-ff
From: Johannes Schindelin @ 2007-09-17 13:52 UTC (permalink / raw)
To: Chris Shoemaker; +Cc: Lars Hjemli, Andreas Ericsson, Junio C Hamano, git
In-Reply-To: <20070917133742.GA10923@pe.Belkin>
Hi,
On Mon, 17 Sep 2007, Chris Shoemaker wrote:
> On Mon, Sep 17, 2007 at 02:23:38PM +0100, Johannes Schindelin wrote:
>
> > "git svn fetch && git rebase git-svn" might be a better approach [...]
>
> BTW, this is spelled "git svn rebase" these days.
Heh. Missed that.
Thanks,
Dscho
^ permalink raw reply
* Re: [PATCH] instaweb: support for Ruby's WEBrick server
From: Mike Dalessio @ 2007-09-17 13:55 UTC (permalink / raw)
To: Florian Weimer; +Cc: Thomas Adam, Eric Wong, git
In-Reply-To: <823axd32dz.fsf@mid.bfk.de>
I could generate a second /bin/sh script to run
"ruby .../webrick.rb"
This would assume that 'ruby' was in the user's $PATH, but that seems
like a reasonable expectation.
The drawback is that we'd be generating TWO scripts, one ruby script
to invoke the server, and one shell script to run the ruby
script. This seems a little ... circuitous.
Another idea is to hack the $httpd variable to contain a command
string like "ruby .../webrick.rb", with the drawback then being a lack
of obviousness, since the convention is that the variable contains the
same command as the --httpd argument, and is named the same as
the <webserver>_conf() functions.
On 9/17/07, Florian Weimer <fweimer@bfk.de> wrote:
> * Thomas Adam:
>
> > This is what /usr/bin/env is useful for, but it's not that portable.
>
> Yeah, it's /bin/env exclusively on some systems. 8-(
>
> --
> Florian Weimer <fweimer@bfk.de>
> BFK edv-consulting GmbH http://www.bfk.de/
> Kriegsstraße 100 tel: +49-721-96201-1
> D-76133 Karlsruhe fax: +49-721-96201-99
>
--
mike dalessio
mike@csa.net
^ permalink raw reply
* Re: [PATCH] git-merge: add option --no-ff
From: Johannes Schindelin @ 2007-09-17 13:57 UTC (permalink / raw)
To: Lars Hjemli; +Cc: Andreas Ericsson, Junio C Hamano, git, Eric Wong
In-Reply-To: <8c5c35580709170638mc0c8279pa86d71bd79fd3084@mail.gmail.com>
Hi,
On Mon, 17 Sep 2007, Lars Hjemli wrote:
> [Cc'd Eric since he's the expert on git-svn]
>
> On 9/17/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>
> > Ah, I think I know what you're trying to get at. But "git svn fetch
> > && git rebase git-svn" might be a better approach than "git svn fetch
> > && git merge --no-ff git-svn", no?
>
> If I'm understanding you right: no. After a rebase, the commits would be
> ignored by git-svn when looking for the subversion upstream branch
> (since the commit SHA1's would no longer match the ones stored in
> git-svn's rev_db), but the subversion history would look like
> 'cherry-picked n commits from merged branch' after dcommit.
I feel that I am not really qualified here, since I am a strict git-svn
_user_, but AFAICT it worked here all the time, _especially_ with fast
forwards. The trick is that all commits that were added after the branch
point do _not_ contain any svn lines.
But then, I do not use svn branches here, and that might be the problem?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] git-merge: add option --no-ff
From: Lars Hjemli @ 2007-09-17 14:12 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Andreas Ericsson, Junio C Hamano, git, Eric Wong
In-Reply-To: <Pine.LNX.4.64.0709171454031.28586@racer.site>
On 9/17/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> But then, I do not use svn branches here, and that might be the problem?
Probably. The case I'm trying to solve is:
-git-svn branch A is merged into git-svn branch B
-A is a fast-forward of B
This might look unrealistic, but it happened to me today when I wanted
to merge a feature-branch into a relase-branch. The release-branch had
previously been merged into the feature-branch (to get a few
bugfixes), but the release-branch had not changed since this merge. So
when merging the feature-branch into the release-branch it just
fast-forwarded, leaving me with an 'un-dcomittable' release-branch. I
obviously could have done the merge in subversion (haha!), but doing
it in git preserves the correct history.
Btw: I have redone the merge with --no-ff, and dcommit then worked
like a charm ;-)
--
larsh
^ permalink raw reply
* Re: [PATCH 3/3] git-apply: add tests for stripping of leading and trailing whitespace
From: Krzysztof Halasa @ 2007-09-17 14:16 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: Junio C Hamano, git
In-Reply-To: <11899829421064-git-send-email-bfields@citi.umich.edu>
"J. Bruce Fields" <bfields@citi.umich.edu> writes:
> +test_expect_success \
> + '8 or more consecutive initial spaces' \
> + 'checkstrip 4'
It may be valid, some projects use tabs for indentation and spaces
for alignment, e.g.:
if (cond && (cond1 ||
cond2))
...
The second line is actually:
cond2))
<TAB--->SSSSSSSSSSSSScond2))
where 'S' means space.
This is the only way to write code which display correctly with
different tab sizes.
With tab = 4 spaces it would be expanded to:
if (cond && (cond1 ||
cond2))
...
I.e., it would be still fine.
Most of the formating tools probably can't do it automatically.
--
Krzysztof Halasa
^ 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