* [PATCH 5/9] builtin-rev-list.c: use parse_options()
From: Michele Ballabio @ 2008-07-23 21:42 UTC (permalink / raw)
To: git; +Cc: gitster
In-Reply-To: <1216849332-26813-1-git-send-email-barra_cuda@katamail.com>
Signed-off-by: Michele Ballabio <barra_cuda@katamail.com>
---
builtin-rev-list.c | 132 +++++++++++++++++++++++++--------------------------
1 files changed, 65 insertions(+), 67 deletions(-)
diff --git a/builtin-rev-list.c b/builtin-rev-list.c
index 893762c..9200b20 100644
--- a/builtin-rev-list.c
+++ b/builtin-rev-list.c
@@ -11,44 +11,16 @@
#include "builtin.h"
#include "log-tree.h"
#include "graph.h"
+#include "parse-options.h"
/* bits #0-15 in revision.h */
#define COUNTED (1u<<16)
-static const char rev_list_usage[] =
-"git rev-list [OPTION] <commit-id>... [ -- paths... ]\n"
-" limiting output:\n"
-" --max-count=nr\n"
-" --max-age=epoch\n"
-" --min-age=epoch\n"
-" --sparse\n"
-" --no-merges\n"
-" --remove-empty\n"
-" --all\n"
-" --branches\n"
-" --tags\n"
-" --remotes\n"
-" --stdin\n"
-" --quiet\n"
-" ordering output:\n"
-" --topo-order\n"
-" --date-order\n"
-" --reverse\n"
-" formatting output:\n"
-" --parents\n"
-" --children\n"
-" --objects | --objects-edge\n"
-" --unpacked\n"
-" --header | --pretty\n"
-" --abbrev=nr | --no-abbrev\n"
-" --abbrev-commit\n"
-" --left-right\n"
-" special purpose:\n"
-" --bisect\n"
-" --bisect-vars\n"
-" --bisect-all"
-;
+static const char * const rev_list_usage[] = {
+ "git rev-list [OPTION] <commit-id>... [ -- paths... ]",
+ NULL
+};
static struct rev_info revs;
@@ -575,15 +547,65 @@ static struct commit_list *find_bisection(struct commit_list *list,
return best;
}
+static int parse_header_cb(const struct option *opt, const char *arg, int unset)
+{
+ struct rev_info *t_revs = opt->value;
+ t_revs->verbose_header = unset ? 0 : 1;
+ return 0;
+}
+
int cmd_rev_list(int argc, const char **argv, const char *prefix)
{
struct commit_list *list;
- int i;
int read_from_stdin = 0;
int bisect_show_vars = 0;
int bisect_find_all = 0;
int quiet = 0;
+ const struct option options[] = {
+ OPT_GROUP("limiting output:"),
+ OPT_ARGUMENT("max-count=nr", "limit number of commits output"),
+ OPT_ARGUMENT("max-age=epoch", "limit commits output by time"),
+ OPT_ARGUMENT("min-age=epoch", "limit commits output by time"),
+ OPT_ARGUMENT("sparse", ""),
+ OPT_ARGUMENT("no-merges", "do not print merges"),
+ OPT_ARGUMENT("remove-empty", "stop when a given path disappears from the tree"),
+ OPT_ARGUMENT("all", "all refs"),
+ OPT_ARGUMENT("branches", "show local branches"),
+ OPT_ARGUMENT("tags", "show tags"),
+ OPT_ARGUMENT("remotes", "show remote-tracking branches"),
+ OPT_BOOLEAN(0, "stdin", &read_from_stdin,
+ "read commits also from command line"),
+ OPT__QUIET(&quiet),
+ OPT_GROUP("ordering output:"),
+ OPT_ARGUMENT("topo-order", "show commits in topological order"),
+ OPT_ARGUMENT("date-order", "use date order, preserving topology"),
+ OPT_ARGUMENT("reverse", "output commits in reverse order"),
+ OPT_GROUP("formatting output:"),
+ OPT_ARGUMENT("parents", "print the parents of the commit"),
+ OPT_ARGUMENT("children", "print the children of the commit"),
+ OPT_ARGUMENT("objects", "print all objects"),
+ OPT_ARGUMENT("objects-edge", "similar to --objects, used by git-pack-objects"),
+ OPT_ARGUMENT("unpacked", "print objects not in packs"),
+ { OPTION_CALLBACK, 0, "header", &revs, NULL,
+ "use raw-format", PARSE_OPT_NOARG, parse_header_cb, 0 },
+ OPT_ARGUMENT("pretty", "print contents in a given format"),
+ OPT_BOOLEAN(0, "timestamp", &show_timestamp,
+ "print the raw commit timestamp"),
+ OPT_ARGUMENT("abbrev-commit", "show short sha1"),
+ OPT_ARGUMENT("abbrev=nr", "number of digits used for short sha1"),
+ OPT_ARGUMENT("no-abbrev", "do not use short sha1"),
+ OPT_ARGUMENT("left-right", "mark side of symmetric diff"),
+ OPT_ARGUMENT("graph", "show an ASCII graph"),
+ OPT_GROUP("special purpose:"),
+ OPT_BOOLEAN(0, "bisect", &bisect_list, "useful for binary searches"),
+ OPT_BOOLEAN(0, "bisect-all", &bisect_find_all,
+ "order commits by their distance from given commits"),
+ OPT_BOOLEAN(0, "bisect-vars", &bisect_show_vars,
+ "like --bisect, but ready to be eval'ed"),
+ OPT_END()
+ };
+
git_config(git_default_config, NULL);
init_revisions(&revs, prefix);
revs.abbrev = 0;
@@ -591,40 +613,16 @@ int cmd_rev_list(int argc, const char **argv, const char *prefix)
argc = setup_revisions(argc, argv, &revs, NULL);
quiet = DIFF_OPT_TST(&revs.diffopt, QUIET);
- for (i = 1 ; i < argc; i++) {
- const char *arg = argv[i];
+ argc = parse_options(argc, argv, options, rev_list_usage, 0);
- if (!strcmp(arg, "--header")) {
- revs.verbose_header = 1;
- continue;
- }
- if (!strcmp(arg, "--timestamp")) {
- show_timestamp = 1;
- continue;
- }
- if (!strcmp(arg, "--bisect")) {
- bisect_list = 1;
- continue;
- }
- if (!strcmp(arg, "--bisect-all")) {
- bisect_list = 1;
- bisect_find_all = 1;
- continue;
- }
- if (!strcmp(arg, "--bisect-vars")) {
- bisect_list = 1;
- bisect_show_vars = 1;
- continue;
- }
- if (!strcmp(arg, "--stdin")) {
- if (read_from_stdin++)
- die("--stdin given twice?");
- read_revisions_from_stdin(&revs);
- continue;
- }
- usage(rev_list_usage);
+ if (argc > 0)
+ usage_with_options(rev_list_usage, options);
+
+ if (bisect_find_all || bisect_show_vars)
+ bisect_list = 1;
+ if (read_from_stdin)
+ read_revisions_from_stdin(&revs);
- }
if (revs.commit_format != CMIT_FMT_UNSPECIFIED) {
/* The command line has a --pretty */
hdr_termination = '\n';
@@ -643,7 +641,7 @@ int cmd_rev_list(int argc, const char **argv, const char *prefix)
(!(revs.tag_objects||revs.tree_objects||revs.blob_objects) &&
!revs.pending.nr)) ||
revs.diff)
- usage(rev_list_usage);
+ usage_with_options(rev_list_usage, options);
save_commit_buffer = revs.verbose_header || revs.grep_filter;
if (bisect_list)
--
1.5.6.3
^ permalink raw reply related
* [PATCH 3/9] builtin-prune-packed.c: use parse_options()
From: Michele Ballabio @ 2008-07-23 21:42 UTC (permalink / raw)
To: git; +Cc: gitster
In-Reply-To: <1216849332-26813-1-git-send-email-barra_cuda@katamail.com>
Signed-off-by: Michele Ballabio <barra_cuda@katamail.com>
---
builtin-prune-packed.c | 38 ++++++++++++++++++--------------------
1 files changed, 18 insertions(+), 20 deletions(-)
diff --git a/builtin-prune-packed.c b/builtin-prune-packed.c
index 10cb8df..5866871 100644
--- a/builtin-prune-packed.c
+++ b/builtin-prune-packed.c
@@ -1,12 +1,15 @@
#include "builtin.h"
#include "cache.h"
#include "progress.h"
+#include "parse-options.h"
-static const char prune_packed_usage[] =
-"git prune-packed [-n] [-q]";
+static const char * const prune_packed_usage[] = {
+ "git prune-packed [-n] [-q]",
+ NULL
+};
#define DRY_RUN 01
-#define VERBOSE 02
+#define QUIET 02
static struct progress *progress;
@@ -43,7 +46,7 @@ void prune_packed_objects(int opts)
const char *dir = get_object_directory();
int len = strlen(dir);
- if (opts == VERBOSE)
+ if (!opts)
progress = start_progress_delay("Removing duplicate objects",
256, 95, 2);
@@ -67,24 +70,19 @@ void prune_packed_objects(int opts)
int cmd_prune_packed(int argc, const char **argv, const char *prefix)
{
- int i;
- int opts = VERBOSE;
+ int opts = 0;
- for (i = 1; i < argc; i++) {
- const char *arg = argv[i];
+ const struct option options[] = {
+ OPT_BIT('n', "dry-run", &opts, "dry run", DRY_RUN),
+ OPT_BIT('q', "quiet", &opts, "be quiet", QUIET),
+ OPT_END()
+ };
+
+ argc = parse_options(argc, argv, options, prune_packed_usage, 0);
+
+ if (argc > 0)
+ usage_with_options(prune_packed_usage, options);
- if (*arg == '-') {
- if (!strcmp(arg, "-n"))
- opts |= DRY_RUN;
- else if (!strcmp(arg, "-q"))
- opts &= ~VERBOSE;
- else
- usage(prune_packed_usage);
- continue;
- }
- /* Handle arguments here .. */
- usage(prune_packed_usage);
- }
prune_packed_objects(opts);
return 0;
}
--
1.5.6.3
^ permalink raw reply related
* [PATCH 4/9] builtin-ls-tree.c: use parse_options()
From: Michele Ballabio @ 2008-07-23 21:42 UTC (permalink / raw)
To: git; +Cc: gitster
In-Reply-To: <1216849332-26813-1-git-send-email-barra_cuda@katamail.com>
Signed-off-by: Michele Ballabio <barra_cuda@katamail.com>
---
builtin-ls-tree.c | 92 +++++++++++++++++++++--------------------------------
1 files changed, 36 insertions(+), 56 deletions(-)
diff --git a/builtin-ls-tree.c b/builtin-ls-tree.c
index d25767a..a0b17aa 100644
--- a/builtin-ls-tree.c
+++ b/builtin-ls-tree.c
@@ -9,6 +9,7 @@
#include "commit.h"
#include "quote.h"
#include "builtin.h"
+#include "parse-options.h"
static int line_termination = '\n';
#define LS_RECURSIVE 1
@@ -22,8 +23,10 @@ static const char **pathspec;
static int chomp_prefix;
static const char *ls_tree_prefix;
-static const char ls_tree_usage[] =
- "git ls-tree [-d] [-r] [-t] [-l] [-z] [--name-only] [--name-status] [--full-name] [--abbrev[=<n>]] <tree-ish> [path...]";
+static const char * const ls_tree_usage[] = {
+ "git ls-tree [options] <tree-ish> [path...]",
+ NULL
+};
static int show_recursive(const char *base, int baselen, const char *pathname)
{
@@ -122,70 +125,47 @@ int cmd_ls_tree(int argc, const char **argv, const char *prefix)
unsigned char sha1[20];
struct tree *tree;
+ const struct option options[] = {
+ OPT_SET_INT('z', NULL, &line_termination,
+ "\\0 line termination on output", 0),
+ OPT_BIT('r', NULL, &ls_options,
+ "recurse into sub-trees", LS_RECURSIVE),
+ OPT_BIT('d', NULL, &ls_options,
+ "show only the tree, not its children",
+ LS_TREE_ONLY),
+ OPT_BIT('t', NULL, &ls_options,
+ "show tree entries", LS_SHOW_TREES),
+ OPT_BIT('l', "long", &ls_options,
+ "show object size of blob (file) entries",
+ LS_SHOW_SIZE),
+ OPT_BIT(0, "name-only", &ls_options,
+ "list only filenames", LS_NAME_ONLY),
+ OPT_BIT(0, "name-status", &ls_options,
+ "same as --name-only", LS_NAME_ONLY),
+ OPT_SET_INT(0, "full-name", &chomp_prefix,
+ "show the full path name", 0),
+ OPT__ABBREV(&abbrev),
+ OPT_END()
+ };
+
git_config(git_default_config, NULL);
ls_tree_prefix = prefix;
if (prefix && *prefix)
chomp_prefix = strlen(prefix);
- while (1 < argc && argv[1][0] == '-') {
- switch (argv[1][1]) {
- case 'z':
- line_termination = 0;
- break;
- case 'r':
- ls_options |= LS_RECURSIVE;
- break;
- case 'd':
- ls_options |= LS_TREE_ONLY;
- break;
- case 't':
- ls_options |= LS_SHOW_TREES;
- break;
- case 'l':
- ls_options |= LS_SHOW_SIZE;
- break;
- case '-':
- if (!strcmp(argv[1]+2, "name-only") ||
- !strcmp(argv[1]+2, "name-status")) {
- ls_options |= LS_NAME_ONLY;
- break;
- }
- if (!strcmp(argv[1]+2, "long")) {
- ls_options |= LS_SHOW_SIZE;
- break;
- }
- if (!strcmp(argv[1]+2, "full-name")) {
- chomp_prefix = 0;
- break;
- }
- if (!prefixcmp(argv[1]+2, "abbrev=")) {
- abbrev = strtoul(argv[1]+9, NULL, 10);
- if (abbrev && abbrev < MINIMUM_ABBREV)
- abbrev = MINIMUM_ABBREV;
- else if (abbrev > 40)
- abbrev = 40;
- break;
- }
- if (!strcmp(argv[1]+2, "abbrev")) {
- abbrev = DEFAULT_ABBREV;
- break;
- }
- /* otherwise fallthru */
- default:
- usage(ls_tree_usage);
- }
- argc--; argv++;
- }
+
+ argc = parse_options(argc, argv, options, ls_tree_usage, 0);
+
/* -d -r should imply -t, but -d by itself should not have to. */
if ( (LS_TREE_ONLY|LS_RECURSIVE) ==
((LS_TREE_ONLY|LS_RECURSIVE) & ls_options))
ls_options |= LS_SHOW_TREES;
- if (argc < 2)
- usage(ls_tree_usage);
- if (get_sha1(argv[1], sha1))
- die("Not a valid object name %s", argv[1]);
+ if (argc < 1)
+ usage_with_options(ls_tree_usage, options);
+ if (get_sha1(argv[0], sha1))
+ die("Not a valid object name %s", argv[0]);
- pathspec = get_pathspec(prefix, argv + 2);
+ pathspec = get_pathspec(prefix, argv + 1);
tree = parse_tree_indirect(sha1);
if (!tree)
die("not a tree object");
--
1.5.6.3
^ permalink raw reply related
* [PATCH 2/9] builtin-write-tree.c: use parse_options()
From: Michele Ballabio @ 2008-07-23 21:42 UTC (permalink / raw)
To: git; +Cc: gitster
In-Reply-To: <1216849332-26813-1-git-send-email-barra_cuda@katamail.com>
Signed-off-by: Michele Ballabio <barra_cuda@katamail.com>
---
builtin-write-tree.c | 31 +++++++++++++++++--------------
1 files changed, 17 insertions(+), 14 deletions(-)
diff --git a/builtin-write-tree.c b/builtin-write-tree.c
index 52a3c01..25f3d8a 100644
--- a/builtin-write-tree.c
+++ b/builtin-write-tree.c
@@ -7,9 +7,12 @@
#include "cache.h"
#include "tree.h"
#include "cache-tree.h"
+#include "parse-options.h"
-static const char write_tree_usage[] =
-"git write-tree [--missing-ok] [--prefix=<prefix>/]";
+static const char * const write_tree_usage[] = {
+ "git write-tree [--missing-ok] [--prefix=<directory>/]",
+ NULL
+};
int cmd_write_tree(int argc, const char **argv, const char *unused_prefix)
{
@@ -19,19 +22,19 @@ int cmd_write_tree(int argc, const char **argv, const char *unused_prefix)
const char *me = "git-write-tree";
git_config(git_default_config, NULL);
- while (1 < argc) {
- const char *arg = argv[1];
- if (!strcmp(arg, "--missing-ok"))
- missing_ok = 1;
- else if (!prefixcmp(arg, "--prefix="))
- prefix = arg + 9;
- else
- usage(write_tree_usage);
- argc--; argv++;
- }
- if (argc > 2)
- die("too many options");
+ const struct option options[] = {
+ OPT_BOOLEAN(0, "missing-ok", &missing_ok,
+ "disable existence check"),
+ OPT_STRING(0, "prefix", &prefix, "directory",
+ "write a tree object for <directory>"),
+ OPT_END()
+ };
+
+ argc = parse_options(argc, argv, options, write_tree_usage, 0);
+
+ if (argc > 0)
+ usage_with_options(write_tree_usage, options);
ret = write_cache_as_tree(sha1, missing_ok, prefix);
switch (ret) {
--
1.5.6.3
^ permalink raw reply related
* [PATCH 0/9] Extend use of parse_options()
From: Michele Ballabio @ 2008-07-23 21:42 UTC (permalink / raw)
To: git; +Cc: gitster
These patches spread the use of parse_options() to some more commands.
I tried to come up with a short description for every option, but
I'm not sure I fully succeeded. In particular, the option "sparse"
in builtin-rev-list.c has no description.
Michele Ballabio (9):
builtin-verify-tag.c: use parse_options()
builtin-write-tree.c: use parse_options()
builtin-prune-packed.c: use parse_options()
builtin-ls-tree.c: use parse_options()
builtin-rev-list.c: use parse_options()
builtin-init-db.c: use parse_options()
builtin-checkout-index.c: use parse_options()
builtin-fetch-pack.c: use parse_options()
builtin-mailinfo.c: use parse_options()
builtin-checkout-index.c | 146 +++++++++++++++++++++++++---------------------
builtin-fetch-pack.c | 144 ++++++++++++++++++++++++++++-----------------
builtin-init-db.c | 56 +++++++++++-------
builtin-ls-tree.c | 92 +++++++++++------------------
builtin-mailinfo.c | 39 +++++++------
builtin-prune-packed.c | 38 ++++++------
builtin-rev-list.c | 132 ++++++++++++++++++++---------------------
builtin-verify-tag.c | 25 +++++---
builtin-write-tree.c | 31 +++++-----
9 files changed, 376 insertions(+), 327 deletions(-)
^ permalink raw reply
* [PATCH 1/9] builtin-verify-tag.c: use parse_options()
From: Michele Ballabio @ 2008-07-23 21:42 UTC (permalink / raw)
To: git; +Cc: gitster
In-Reply-To: <1216849332-26813-1-git-send-email-barra_cuda@katamail.com>
Signed-off-by: Michele Ballabio <barra_cuda@katamail.com>
---
builtin-verify-tag.c | 25 +++++++++++++++----------
1 files changed, 15 insertions(+), 10 deletions(-)
diff --git a/builtin-verify-tag.c b/builtin-verify-tag.c
index 7d837f0..590038b 100644
--- a/builtin-verify-tag.c
+++ b/builtin-verify-tag.c
@@ -9,10 +9,13 @@
#include "builtin.h"
#include "tag.h"
#include "run-command.h"
+#include "parse-options.h"
#include <signal.h>
-static const char builtin_verify_tag_usage[] =
- "git verify-tag [-v|--verbose] <tag>...";
+static const char * const builtin_verify_tag_usage[] = {
+ "git verify-tag [-v|--verbose] <tag>...",
+ NULL
+};
#define PGP_SIGNATURE "-----BEGIN PGP SIGNATURE-----"
@@ -88,23 +91,25 @@ static int verify_tag(const char *name, int verbose)
int cmd_verify_tag(int argc, const char **argv, const char *prefix)
{
- int i = 1, verbose = 0, had_error = 0;
+ int verbose = 0, had_error = 0;
git_config(git_default_config, NULL);
+ const struct option options[] = {
+ OPT__VERBOSE(&verbose),
+ OPT_END()
+ };
+
if (argc == 1)
- usage(builtin_verify_tag_usage);
+ usage_with_options(builtin_verify_tag_usage, options);
- if (!strcmp(argv[i], "-v") || !strcmp(argv[i], "--verbose")) {
- verbose = 1;
- i++;
- }
+ argc = parse_options(argc, argv, options, builtin_verify_tag_usage, 0);
/* sometimes the program was terminated because this signal
* was received in the process of writing the gpg input: */
signal(SIGPIPE, SIG_IGN);
- while (i < argc)
- if (verify_tag(argv[i++], verbose))
+ while (argc-- > 0)
+ if (verify_tag(*argv++, verbose))
had_error = 1;
return had_error;
}
--
1.5.6.3
^ permalink raw reply related
* [PATCH] bash completion: Add long options for 'git rm'
From: Lee Marlow @ 2008-07-23 21:21 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, Lee Marlow
Options added: --cached --dry-run --ignore-unmatch --quiet
Signed-off-by: Lee Marlow <lee.marlow@gmail.com>
---
contrib/completion/git-completion.bash | 15 +++++++++++++++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 2edb341..4b7ef69 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1170,6 +1170,20 @@ _git_reset ()
__gitcomp "$(__git_refs)"
}
+_git_rm ()
+{
+ __git_has_doubledash && return
+
+ local cur="${COMP_WORDS[COMP_CWORD]}"
+ case "$cur" in
+ --*)
+ __gitcomp "--cached --dry-run --ignore-unmatch --quiet"
+ return
+ ;;
+ esac
+ COMPREPLY=()
+}
+
_git_shortlog ()
{
__git_has_doubledash && return
@@ -1425,6 +1439,7 @@ _git ()
rebase) _git_rebase ;;
remote) _git_remote ;;
reset) _git_reset ;;
+ rm) _git_rm ;;
send-email) _git_send_email ;;
shortlog) _git_shortlog ;;
show) _git_show ;;
--
1.6.0.rc0.14.g95f8
^ permalink raw reply related
* Re: q: faster way to integrate/merge lots of topic branches?
From: Pierre Habouzit @ 2008-07-23 20:40 UTC (permalink / raw)
To: Linus Torvalds, Ingo Molnar, git
In-Reply-To: <20080723202722.GA18160@artemis.madism.org>
[-- Attachment #1: Type: text/plain, Size: 3120 bytes --]
On mer, jui 23, 2008 at 08:27:22 +0000, Pierre Habouzit wrote:
> On Wed, Jul 23, 2008 at 07:09:20PM +0000, Pierre Habouzit wrote:
> > On Wed, Jul 23, 2008 at 05:59:01PM +0000, Linus Torvalds wrote:
> > > In fact, the two top entries in a profile look roughly like:
> > >
> > > 102161 70.2727 libz.so.1.2.3 libz.so.1.2.3 (no symbols)
> > > 7685 5.2862 git git find_pack_entry_one
> > > ...
> > >
> > > ie 70% of the time is just purely unpacking the data, and another 5% is
> > > just finding it. We could perhaps improve on it, but not a whole lot.
> >
> > Well there is an easy way though, that could reduce that: using
> > adaptative compression. I proposed a patch once upon a time, that set
> > the compression strengh to 0 for "small" objects with a configurable
> > cut-off. If you do that, most trees, commits messages and so on aren't
> > compressed, and it will reduce (with IIRC a 5-liner) this time quite
> > dramatically.
> >
> > I could maybe resurect it to see if for people that do the kind of
> > things Ingo does it helps. By setting the cut-off at 1k, I had packs
> > being less than 1% bigger IIRC. I'll try to find it again and run your
> > tests with it to see how much it helps.
>
> Unsurprisingly with a 1024o cutoff, the numbers are (first run is
> forced cold-cache with /proc/.../drop_caches, second is the best run of 5):
>
> default git:
>
> 3.10user 0.16system 0:08.10elapsed 40%CPU (0avgtext+0avgdata 0maxresident)k
> 116152inputs+0outputs (671major+35286minor)pagefaults 0swaps
>
> 2.01user 0.11system 0:02.12elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
> 0inputs+0outputs (0major+35958minor)pagefaults 0swaps
>
> With a 1024k cutoff:
>
> 1.16user 0.13system 0:08.29elapsed 15%CPU (0avgtext+0avgdata 0maxresident)k
> 154208inputs+0outputs (947major+39777minor)pagefaults 0swaps
>
> 0.76user 0.06system 0:00.82elapsed 100%CPU (0avgtext+0avgdata 0maxresident)k
> 0inputs+0outputs (0major+40724minor)pagefaults 0swaps
With a 512o cutoff:
1.49user 0.17system 0:07.50elapsed 22%CPU (0avgtext+0avgdata 0maxresident)k
127648inputs+0outputs (780major+36687minor)pagefaults 0swaps
1.54user 0.07system 0:01.61elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+37467minor)pagefaults 0swaps
What I bench, I see I forgot to mention, is: git merge v2.6.14. And
the respective pack sizes:
214M .git-0/objects/pack/pack-bfeec11abed1ec6d046bc954b94d70ba81716356.pack
225M .git-512/objects/pack/pack-bfeec11abed1ec6d046bc954b94d70ba81716356.pack
243M .git-1024/objects/pack/pack-bfeec11abed1ec6d046bc954b94d70ba81716356.pack
.git-0 is cheating because it was generated with a way deeper window and
memory window that the other ones, but it allow to give rough
impressions.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] Rename ".dotest/" to ".git/rebase" and ".dotest-merge" to "rebase-merge"
From: Junio C Hamano @ 2008-07-23 20:40 UTC (permalink / raw)
To: Stephan Beyer
Cc: Olivier Marin, Theodore Tso, Nanako Shiraishi,
Johannes Schindelin, René Scharfe, Joe Fiorini, git,
Jari Aalto
In-Reply-To: <20080723011341.GE5904@leksak.fem-net>
Stephan Beyer <s-beyer@gmx.net> writes:
>> Just being a bit defensive -- in this case I think it might be Ok to say
>> "read-tree --reset -u ORIG_HEAD", but I haven't checked in a conflicted
>> case.
>
> Well, the test suite fails:
> ...
> So no reason to be defensive ;)
Ok, so it is not just being defensive but actually is necessary.
^ permalink raw reply
* Re: q: faster way to integrate/merge lots of topic branches?
From: Pierre Habouzit @ 2008-07-23 20:27 UTC (permalink / raw)
To: Linus Torvalds, Ingo Molnar, git
In-Reply-To: <20080723190920.GG20614@artemis.madism.org>
[-- Attachment #1: Type: text/plain, Size: 2398 bytes --]
On Wed, Jul 23, 2008 at 07:09:20PM +0000, Pierre Habouzit wrote:
> On Wed, Jul 23, 2008 at 05:59:01PM +0000, Linus Torvalds wrote:
> > In fact, the two top entries in a profile look roughly like:
> >
> > 102161 70.2727 libz.so.1.2.3 libz.so.1.2.3 (no symbols)
> > 7685 5.2862 git git find_pack_entry_one
> > ...
> >
> > ie 70% of the time is just purely unpacking the data, and another 5% is
> > just finding it. We could perhaps improve on it, but not a whole lot.
>
> Well there is an easy way though, that could reduce that: using
> adaptative compression. I proposed a patch once upon a time, that set
> the compression strengh to 0 for "small" objects with a configurable
> cut-off. If you do that, most trees, commits messages and so on aren't
> compressed, and it will reduce (with IIRC a 5-liner) this time quite
> dramatically.
>
> I could maybe resurect it to see if for people that do the kind of
> things Ingo does it helps. By setting the cut-off at 1k, I had packs
> being less than 1% bigger IIRC. I'll try to find it again and run your
> tests with it to see how much it helps.
Unsurprisingly with a 1024o cutoff, the numbers are (first run is
forced cold-cache with /proc/.../drop_caches, second is the best run of 5):
default git:
3.10user 0.16system 0:08.10elapsed 40%CPU (0avgtext+0avgdata 0maxresident)k
116152inputs+0outputs (671major+35286minor)pagefaults 0swaps
2.01user 0.11system 0:02.12elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+35958minor)pagefaults 0swaps
With a 1024k cutoff:
1.16user 0.13system 0:08.29elapsed 15%CPU (0avgtext+0avgdata 0maxresident)k
154208inputs+0outputs (947major+39777minor)pagefaults 0swaps
0.76user 0.06system 0:00.82elapsed 100%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+40724minor)pagefaults 0swaps
According to [0], a 1k cutoff meant something like a 10% larger pack. 512o
meant an almost identical pack in size, but with reduced performance
improvements.
[0] http://thread.gmane.org/gmane.comp.version-control.git/70019/focus=70250
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [RFC] Git User's Survey 2008
From: Dmitry Potapov @ 2008-07-23 20:09 UTC (permalink / raw)
To: Matthias Kestenholz; +Cc: Jakub Narebski, git, Stephan Beyer
In-Reply-To: <1216827806.9938.18.camel@localhost>
On Wed, Jul 23, 2008 at 05:43:26PM +0200, Matthias Kestenholz wrote:
> On Wed, 2008-07-23 at 18:38 +0400, Dmitry Potapov wrote:
> > On Wed, Jul 23, 2008 at 03:25:03AM +0200, Jakub Narebski wrote:
> > > 02. What is your preferred non-programming language?
> > > (or) What is the language you want computer communicate with you?
> >
> > IMHO, the later wording of the question is much better.
>
> I think these are two separate questions. In my case the first is
> (swiss) german, the second is english. I don't like localized software
> too much, I always have to think what a certain german term might mean
> in english to understand computing-specific texts.
Wellcome to the club of those who don't like localized software :)
>
> That being said I think that the first question is irrelevant for the
> git survey.
Exactly. That is why I said the later wording is better. I believe the
implied question was what language would you like Git to talk with you.
Dmitry
^ permalink raw reply
* [PATCH] svnimport: newer libsvn wants us to ask for the root with "", not "/"
From: P. Christeas @ 2008-07-23 20:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Gerrit Pape
In r27729, libsvn introduced an assert which explicitly
forbids searching the tree at "/". Luckily enough, it
still accepts an empty string "" as the starting point.
http://svn.collab.net/viewvc/svn/trunk/subversion/libsvn_ra/ra_loader.c?r1=27653&r2=27729
Tested against libsvn0-1.5.0-4mdv2009.0 (needs the fix),
libsvn0-1.4.6-5mdv2008.1 (works anyway)
Signed-off-by: P. Christeas <p_christ@hol.gr>
---
contrib/examples/git-svnimport.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/contrib/examples/git-svnimport.perl
b/contrib/examples/git-svnimport.perl
index ea8c1b2..a13bb6a 100755
--- a/contrib/examples/git-svnimport.perl
+++ b/contrib/examples/git-svnimport.perl
@@ -933,7 +933,7 @@ while ($to_rev < $opt_l) {
$to_rev = $from_rev + $repack_after;
$to_rev = $opt_l if $opt_l < $to_rev;
print "Fetching from $from_rev to $to_rev ...\n" if $opt_v;
- $svn->{'svn'}->get_log("/",$from_rev,$to_rev,0,1,1,\&commit_all);
+ $svn->{'svn'}->get_log("",$from_rev,$to_rev,0,1,1,\&commit_all);
my $pid = fork();
die "Fork: $!\n" unless defined $pid;
unless($pid) {
--
1.5.6
^ permalink raw reply related
* Re: [PATCH] Respect crlf attribute even if core.autocrlf has not been set
From: Johannes Schindelin @ 2008-07-23 20:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vhcagcsmj.fsf@gitster.siamese.dyndns.org>
Hi,
On Wed, 23 Jul 2008, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > On Wed, 23 Jul 2008, Junio C Hamano wrote:
> > ...
> >> If you are on a sane system, you do not even want to pay the price of
> >> conversion. Only people on systems with CRLF line endings should pay
> >> the price (because your aim is to convert on such systems). Are we
> >> throwing that out of the window when the project decides to use
> >> gitattributes?
> >
> > Well, if you do not want that, why do you set crlf in the
> > gitattributes to begin with?
>
> It is not _me_ but the project upstream that needs to interact also with
> Windows people who manages gitattributes. And me personally knows my
> editors are not helpful to add CR at the end of lines, so I do not need
> the conversion.
I know you do. And I know those users don't. They do not even know that
they should set autocrlf = input in their cygwin Git.
Or at least, now they do. After a few hundred commits that have been
published _after_ their broken checkins.
Sigh,
Dscho
^ permalink raw reply
* Re: q: faster way to integrate/merge lots of topic branches?
From: Junio C Hamano @ 2008-07-23 20:01 UTC (permalink / raw)
To: Ingo Molnar; +Cc: SZEDER Gábor, git
In-Reply-To: <20080723140441.GA9537@elte.hu>
Ingo Molnar <mingo@elte.hu> writes:
> hm, it's very slow:
>
> $ time git branch --no-merged
> [...]
>
> real 0m9.177s
> user 0m9.027s
> sys 0m0.129s
>
> when running it on tip/master:
>
> http://people.redhat.com/mingo/tip.git/README
Hmmm, does not reproduce for me with a copy of that repository.
$ time git branch -a --no-merged mingo/master
linus/master
mingo/acpi-for-len
mingo/auto-cpus4096-next
mingo/auto-kmemcheck-next
mingo/auto-test
mingo/auto-test-fixes
mingo/core/futex-64bit
mingo/core/kill-the-BKL
mingo/core/percpu-zerobased
mingo/cpus4096-for-linus
mingo/kmemcheck-for-linus
mingo/stackprotector-for-linus
mingo/timers/for-linus
mingo/tip
mingo/tracing/ftrace
mingo/tracing/immediates
mingo/tracing/markers
mingo/tracing/stopmachine-allcpus
mingo/tracing/textedit
mingo/x86/acpi-rename-acpi_nmi
mingo/x86/audit-speedup
mingo/x86/crashdump
mingo/x86/header-guards
mingo/x86/prototypes
mingo/x86/sparse-fixes
mingo/x86/unify-mce
mingo/x86/x2apic
real 0m1.442s
user 0m1.360s
sys 0m0.084s
With the patch I posted earlier, the time becomes:
real 0m0.600s
user 0m0.560s
sys 0m0.040s
^ permalink raw reply
* Re: [PATCH] Respect crlf attribute even if core.autocrlf has not been set
From: Eyvind Bernhardsen @ 2008-07-23 19:20 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Avery Pennarun, Joshua Jensen, Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0807231956280.8986@racer>
On 23. juli. 2008, at 20.57, Johannes Schindelin wrote:
> Hi,
>
> On Wed, 23 Jul 2008, Avery Pennarun wrote:
>
>> 1. always CRLF on all platforms (eg. for .bat files)
>> 2. always LF on all platforms (eg. for shell scripts and perl
>> scripts)
>> 3. just leave it alone no matter what (eg. for binary files)
>
> These are not different, but equal. "Do no harm to the contents of
> this
> file".
That is only true until someone edits the file in an editor which
prefers the wrong end-of-line marker, and converts to it when saving.
It will be obvious that this has happened if the user does a "git
diff" before committing, but I think the intent of nos. 1 and 2 is for
git to automatically convert the line endings back instead of kicking
up a fuss.
Might be too magical, though.
Eyvind Bernhardsen
^ permalink raw reply
* [FYI PATCH v2] Added a git search and replace command
From: Sverre Rabbelier @ 2008-07-23 19:55 UTC (permalink / raw)
To: git; +Cc: Sverre Rabbelier
A simple script that uses 'git ls-files' and a bash for
loop to search and replace (using sed) all the specified
files. There is a config option for the pathspec. This
allows the user to set 'sar.pathspec' and then specify only
the sed on the commandline.
---
Not meant for inclusion, just a simple script I wrote up
when I wanted to change a function name in my repository
but didn't want to figure out which magic argument to
find does what I want. Another advantage of using git
ls-files is that it will prevent that any unrevertable
changes will be made (since the script checks if the tree
is dirty or not). I'm sure there's plenty of room for
improvement here, it's probably not portable at all
either, so comments are welcome :).
Changes since v2, the use of xargs was taken out and
replaced by a bash for loop. Also I added a config value
because I'm too lazy to type the pathspec each time.
Interdiff below:
diff --git a/git-sar.sh b/git-sar.sh
index db6317b..e64b9bd 100755
--- a/git-sar.sh
+++ b/git-sar.sh
@@ -1,24 +1,26 @@
#!/bin/bash
-do_sed () {
- sed "$2" $3 > $3.replaced
- mv $3.replaced $3
-}
-
do_git_find() {
# Sanity check
if is_dirty_tree
then
echo "Refusing to work on a dirty tree"
+ exit 1
fi
files=`git ls-files "$1"`
+
+ # See if there were any matching files
if test -z "$files"
then
echo "Your pathspec did not match any files."
exit 1
fi
- echo "$files" | xargs -n 1 git-sar --replace $2
+
+ # Change them in-place
+ for file in $files; do
+ sed -i "$2" "$file";
+ done
}
is_dirty_tree () {
@@ -33,27 +35,28 @@ do_show_usage() {
do_main() {
# Verify argument size
- if test "$#" -le 1 -o "$#" -ge 4
+ if test "$#" -ge 3
then
do_show_usage
fi
- # Two argument form
- if test "$#" -eq 2
+ if test "$#" -eq 1
then
- do_git_find "$@"
- fi
+ glob=`git config --get sar.pathspec`
- # Three argument form, we're calling ourselves through sed
- if test "$#" -eq 3
- then
- # Double check if the user typoed or if we are indeed meta-calling
- if test "$1" != "--replace"
+ if test -z "$glob"
then
+ echo "No sar.pathspec set"
do_show_usage
fi
- do_sed "$@"
+ do_git_find "$glob" "$1"
+ fi
+
+ # Two argument form
+ if test "$#" -eq 2
+ then
+ do_git_find "$@"
fi
}
.gitignore | 1 +
Makefile | 1 +
git-sar.sh | 64 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 66 insertions(+), 0 deletions(-)
create mode 100755 git-sar.sh
diff --git a/.gitignore b/.gitignore
index a213e8e..451cb93 100644
--- a/.gitignore
+++ b/.gitignore
@@ -108,6 +108,7 @@ git-rev-list
git-rev-parse
git-revert
git-rm
+git-sar
git-send-email
git-send-pack
git-sh-setup
diff --git a/Makefile b/Makefile
index b01cf1c..979e9ea 100644
--- a/Makefile
+++ b/Makefile
@@ -252,6 +252,7 @@ SCRIPT_SH += git-sh-setup.sh
SCRIPT_SH += git-stash.sh
SCRIPT_SH += git-submodule.sh
SCRIPT_SH += git-web--browse.sh
+SCRIPT_SH += git-sar.sh
SCRIPT_PERL += git-add--interactive.perl
SCRIPT_PERL += git-archimport.perl
diff --git a/git-sar.sh b/git-sar.sh
new file mode 100755
index 0000000..e64b9bd
--- /dev/null
+++ b/git-sar.sh
@@ -0,0 +1,64 @@
+#!/bin/bash
+
+do_git_find() {
+ # Sanity check
+ if is_dirty_tree
+ then
+ echo "Refusing to work on a dirty tree"
+ exit 1
+ fi
+
+ files=`git ls-files "$1"`
+
+ # See if there were any matching files
+ if test -z "$files"
+ then
+ echo "Your pathspec did not match any files."
+ exit 1
+ fi
+
+ # Change them in-place
+ for file in $files; do
+ sed -i "$2" "$file";
+ done
+}
+
+is_dirty_tree () {
+ `git diff --quiet`
+ test $? -ne 0
+}
+
+do_show_usage() {
+ echo "usage: git-sar pathspec sed"
+ exit 128
+}
+
+do_main() {
+ # Verify argument size
+ if test "$#" -ge 3
+ then
+ do_show_usage
+ fi
+
+ if test "$#" -eq 1
+ then
+ glob=`git config --get sar.pathspec`
+
+ if test -z "$glob"
+ then
+ echo "No sar.pathspec set"
+ do_show_usage
+ fi
+
+ do_git_find "$glob" "$1"
+ fi
+
+ # Two argument form
+ if test "$#" -eq 2
+ then
+ do_git_find "$@"
+ fi
+}
+
+do_main "$@"
+
--
1.6.0.rc0.15.gc85d5
^ permalink raw reply related
* Re: git-svn - failed to clone repository
From: Avery Pennarun @ 2008-07-23 19:49 UTC (permalink / raw)
To: SZEDER Gábor; +Cc: Derek Fawcus, git
In-Reply-To: <20080723170838.GK22606@neumann>
On 7/23/08, SZEDER Gábor <szeder@fzi.de> wrote:
> It might not help you, but with svn version 1.4.6 (r28521) (from
> Ubuntu 8.04) and current git master the above command has just
> finished successfully.
I believe this was fixed by my patch
29c70e0b3e3183f86f93500882177d0c74069988, which was included in git
1.5.6.2.
Avery
^ permalink raw reply
* Re: [PATCH] Respect crlf attribute even if core.autocrlf has not been set
From: Johannes Schindelin @ 2008-07-23 19:44 UTC (permalink / raw)
To: Eyvind Bernhardsen; +Cc: Avery Pennarun, Joshua Jensen, Junio C Hamano, git
In-Reply-To: <FB7ABDC5-8505-4FD1-8082-9BB5013E73C6@orakel.ntnu.no>
Hi,
On Wed, 23 Jul 2008, Eyvind Bernhardsen wrote:
> On 23. juli. 2008, at 20.57, Johannes Schindelin wrote:
>
> >On Wed, 23 Jul 2008, Avery Pennarun wrote:
> >
> > >1. always CRLF on all platforms (eg. for .bat files)
> > >2. always LF on all platforms (eg. for shell scripts and perl scripts)
> > >3. just leave it alone no matter what (eg. for binary files)
> >
> >These are not different, but equal. "Do no harm to the contents of this
> >file".
>
> That is only true until someone edits the file in an editor which
> prefers the wrong end-of-line marker, and converts to it when saving.
> It will be obvious that this has happened if the user does a "git diff"
> before committing, but I think the intent of nos. 1 and 2 is for git to
> automatically convert the line endings back instead of kicking up a
> fuss.
>
> Might be too magical, though.
I deem it not, uhm, magical. By your reasoning there should be a way for
Git to convert a file to UTF-8 when some entertaining person converted the
working directory file to ISO-8859-15.
Really, either it is CR/LF on all platforms (and then the project members
have to live by it), or it is not. You cannot have both.
If it is CR/LF on all platforms, you just _commit_ it as CR/LF. No
conversion, not even a brain required.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Respect crlf attribute even if core.autocrlf has not been set
From: Johannes Schindelin @ 2008-07-23 19:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Robin Rosenberg, Joshua Jensen, git
In-Reply-To: <7vd4l4cs24.fsf@gitster.siamese.dyndns.org>
Hi,
On Wed, 23 Jul 2008, Junio C Hamano wrote:
> Robin Rosenberg <robin.rosenberg.lists@dewire.com> writes:
>
> >> There are certain file formats, such as a Visual Studio .sln file,
> >> that MUST be CRLF. When a .sln file is not CRLF, Visual Studio
> >> refuses to read it. I want to be able to set into the committed
> >> .gitattributes file the list of files that must be translated to the
> >> proper format regardless of the autocrlf setting. An example is
> >> below:
> >>
> >> *.bat crlf
> >...
> >> *.vcw crlf
> >
> > Wouldn't "*bat -crlf " etc be good for these, and thus store CRLF in
> > the repo.
>
> I'd agree. And I do not think we would want to introduce "crlf=force"
> that converts working tree files that could be LF terminated to CRLF
> upon checking in. That is as bad as some helpful editors that adds CR
> at the end of line without being asked.
You can say that only because you are not in the situation having a lot of
CR/LF files in your _public_ repository _in spite of_ setting the
gitattributes correctly.
That seriously sucks.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH v2] git daemon: avoid waking up too often
From: Johannes Schindelin @ 2008-07-23 19:39 UTC (permalink / raw)
To: Avery Pennarun; +Cc: Johannes Sixt, git, Junio C Hamano
In-Reply-To: <32541b130807231226m73fcc874ub72f69adeb5d26c3@mail.gmail.com>
Hi,
On Wed, 23 Jul 2008, Avery Pennarun wrote:
> On 7/23/08, Johannes Sixt <j.sixt@viscovery.net> wrote:
> > This makes porting this beast to Windows practically impossible
> > because we cannot have a poll() implementation that waits both on a
> > listening socket and a pipe. :-(
>
> I have worked around such problems in the past by having a thread whose
> job it is to read from the pipe and simply write it to a socket. The
> trick works for "console" objects, too, which in win32 are even less
> agreeable than pipes.
>
> (In case your life wasn't disgusting enough already today :))
Thanks. I thought the code I looked at today was ugly, but you convinced
me that there is no limit.
> Alternatively, you could use something like socketpair() instead of a
> pipe for this purpose. Naturally, Win32 helps you out here by somehow
> forgetting to include socketpair() in winsock, although it's sort of
> easy to emulate.
Or alternatively, you could read my response to Hannes where I explain
that the pipe() is not even needed with threaded start_async() (as opposed
to fork()ed one).
Ciao,
Dscho
^ permalink raw reply
* Re: git merge after git cherry-pick?
From: "Peter Valdemar Mørch (Lists)" @ 2008-07-23 19:35 UTC (permalink / raw)
To: SZEDER Gábor; +Cc: git
In-Reply-To: <20080723175600.GL22606@neumann>
SZEDER Gábor szeder-at-ira.uka.de |Lists| wrote:
> You could use 'git rebase' for that.
*Exactly* what I was looking for. Now I know what rebase is for! Thanks.
Peter
--
Peter Valdemar Mørch
http://www.morch.com
^ permalink raw reply
* Re: [PATCH] Respect crlf attribute even if core.autocrlf has not been set
From: Junio C Hamano @ 2008-07-23 19:35 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: Joshua Jensen, Johannes Schindelin, git
In-Reply-To: <200807232122.38471.robin.rosenberg.lists@dewire.com>
Robin Rosenberg <robin.rosenberg.lists@dewire.com> writes:
>> There are certain file formats, such as a Visual Studio .sln file, that
>> MUST be CRLF. When a .sln file is not CRLF, Visual Studio refuses to
>> read it. I want to be able to set into the committed .gitattributes
>> file the list of files that must be translated to the proper format
>> regardless of the autocrlf setting. An example is below:
>>
>> *.bat crlf
>...
>> *.vcw crlf
>
> Wouldn't "*bat -crlf " etc be good for these, and thus store CRLF in the repo.
I'd agree. And I do not think we would want to introduce "crlf=force"
that converts working tree files that could be LF terminated to CRLF upon
checking in. That is as bad as some helpful editors that adds CR at the
end of line without being asked.
^ permalink raw reply
* Re: [PATCH 2/2] sort_in_topological_order(): avoid setting a commit flag
From: Johannes Schindelin @ 2008-07-23 19:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: pasky, git
In-Reply-To: <7vprp4ctkp.fsf@gitster.siamese.dyndns.org>
Hi,
On Wed, 23 Jul 2008, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > @@ -494,7 +493,8 @@ void sort_in_topological_order(struct commit_list ** list, int lifo)
> > * when all their children have been emitted thereby
> > * guaranteeing topological order.
> > */
> > - if (!--parent->indegree) {
> > + if (--parent->indegree == 1) {
> > + parent->indegree = 0;
> > if (!lifo)
> > insert_by_date(parent, &work);
> > else
> > @@ -505,7 +505,6 @@ void sort_in_topological_order(struct commit_list ** list, int lifo)
> > * work_item is a commit all of whose children
> > * have already been emitted. we can emit it now.
> > */
> > - commit->object.flags &= ~TOPOSORT;
> > *pptr = work_item;
> > pptr = &work_item->next;
> > }
>
> These two hunks look suspicious.
>
> The "tips" used to enter that while() loop with zero indegree, its
> parents examined and then entered the final list pointed by pptr with
> the toposort scratch variables removed and indegree set to zero. Now
> with the new +1 based code, they enter the while() loop with 1 indegree,
> and enter the final list with indegree set to 1.
Almost correct. The way I did it the if() is entered with indegree ==
1, but is set indegree to 0 right away.
I did it this way because of these two lines before the if():
if (!parent->indegree)
continue;
These are the replacement for the previous
if (!(parent->object.flags & TOPOSORT))
continue;
Now, if indegree was not set to 0, that if () would not trigger, but in
the next one (the first hunk you quoted), indegree was decremented and
failed the test == 1.
However, that is correct only by pure chance; I certainly missed that.
The correct fix according to my thinking would be to set the indegree to 0
when the tips are inserted, too.
> A parent that has only one child that is "tip" is discovered in the
> while() loop, its indegree decremented (so it goes down to zero in the
> original code and 1 in yours) and enters work queue to be processed.
> It used to have the toposort scratch variable removed in the second hunk
> above, but that is done in the first hunk in your version.
>
> So after this patch, indegree will be all zero for non-tip commits but
> will be one for tip commits. Is this intended?
No.
> I'd suggest dropping the "parent->indegree = 0" assignment and turn the
> second hunk into "commit->indgree = 0" assignment.
Yeah, that is much simpler.
Thanks,
Dscho
^ permalink raw reply
* Re: [PATCH] Respect crlf attribute even if core.autocrlf has not been set
From: Dmitry Potapov @ 2008-07-23 19:33 UTC (permalink / raw)
To: Joshua Jensen; +Cc: Johannes Schindelin, Junio C Hamano, git
In-Reply-To: <488772BC.80207@workspacewhiz.com>
On Wed, Jul 23, 2008 at 10:04 PM, Joshua Jensen
<jjensen@workspacewhiz.com> wrote:
>
> There are certain file formats, such as a Visual Studio .sln file, that MUST
> be CRLF. When a .sln file is not CRLF, Visual Studio refuses to read it.
I wonder what exactly version of Visual Studio you use? All version that
I have seen had no problem reading .sln with LF ending, though they always
wrote it back with CRLF. In any case, you can define as binary, so Git will
not do anything about their EOLs.
Dmitry
^ permalink raw reply
* Re: [PATCH v2] git daemon: avoid waking up too often
From: Avery Pennarun @ 2008-07-23 19:26 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Johannes Schindelin, git, Junio C Hamano
In-Reply-To: <4886D503.7030106@viscovery.net>
On 7/23/08, Johannes Sixt <j.sixt@viscovery.net> wrote:
> This makes porting this beast to Windows practically impossible because we
> cannot have a poll() implementation that waits both on a listening socket
> and a pipe. :-(
I have worked around such problems in the past by having a thread
whose job it is to read from the pipe and simply write it to a socket.
The trick works for "console" objects, too, which in win32 are even
less agreeable than pipes.
(In case your life wasn't disgusting enough already today :))
Alternatively, you could use something like socketpair() instead of a
pipe for this purpose. Naturally, Win32 helps you out here by somehow
forgetting to include socketpair() in winsock, although it's sort of
easy to emulate.
Have fun,
Avery
^ 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