* Cygwin install howto
From: Martin Langhoff @ 2006-09-07 5:19 UTC (permalink / raw)
To: git
A friend wants to work with us on a git project but is Trapped In
Windows right now. He does have a cywgin install, and I was hoping to find
a cygwin install howto. Alas, I couldn't find any (is there one and
Google doesn't know about it?).
Now, I am a bit at a loss, as I don't have access to windows. So for
you cygwin knights in the woods, a few questions...
- What cygwin packages are needed?
- Makefile tweaks?
- How do I install for personal use?
- How do I install in /usr/local?
- Anything else I should know?
I'll be more than happy to shape the replies in a nice wiki page...
(Mercurial has one already
http://www.selenic.com/mercurial/wiki/index.cgi/WindowsInstall )
cheers,
martin
^ permalink raw reply
* Re: Cygwin playbook?
From: Junio C Hamano @ 2006-09-07 6:59 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git
In-Reply-To: <46a038f90609062159v3858a771t38355ed60867ccfc@mail.gmail.com>
"Martin Langhoff" <martin.langhoff@gmail.com> writes:
> - What cygwin packages are needed?
I am not in front of Windows machine so I need to check later if
nobody beats me to this, but essentially it is the same as on
sane Unix systems. Cygwin folks did a good job providing
necessary libraries readily available from their Setup.exe.
> - Need to fudge makefile?
No; not even autoconf was needed and it installed out of the box
for me (w2k).
> - How do I install for personal use?
make install would install under whereever you call ~/bin in
Cygwin environment, and that is how I have mine.
> - How do I install in /usr/local?
I do not think of a reason why "make prefix=/usr/local" would
not work but I haven't tried it myself so don't quote me on
this.
> - Anything else I should know?
You would probably have great pain if on vfat. It appears to
work Ok on NTFS. It appears to be quite slow, judging from
the way it runs our standard test suite.
^ permalink raw reply
* Cygwin playbook?
From: Martin Langhoff @ 2006-09-07 4:59 UTC (permalink / raw)
To: git
A colleage wants to work with us on a git project but is Trapped In
Windows (TM). He does have a cywgin install, and I was hoping to find
a cygwin install howto. Alas, I couldn't find any (is there one and
Google doesn't know about it?).
Now, I am a bit at a loss, as I don't have access to windows. So for
you cygwin knights in the woods, a few questions...
- What cygwin packages are needed?
- Need to fudge makefile?
- How do I install for personal use?
- How do I install in /usr/local?
- Anything else I should know?
I'll be more than happy to shape the replies in a nice wiki page...
(Mercurial has one already
http://www.selenic.com/mercurial/wiki/index.cgi/WindowsInstall )
cheers,
martin
^ permalink raw reply
* Re: Why is there a --binary option needed for git-apply?
From: Junio C Hamano @ 2006-09-07 6:45 UTC (permalink / raw)
To: Carl Worth; +Cc: git, Shawn Pearce
In-Reply-To: <874pvmxikq.wl%cworth@cworth.org>
Carl Worth <cworth@cworth.org> writes:
> Shawn Pearce was kind enough to direct me to the --binary option for
> git-apply which solved my problem. But that left me wondering why
> git-apply requires this extra command-line option to do its
> job. Shouldn't git-apply simply apply the patch it is given?
There is no reason it shouldn't.
Initially it was done that way only because doing something
unusual should be done under explicit user permission. Binary
patch is not "unusual" anymore, I guess ;-).
-- >8 --
[PATCH] Make apply --binary a no-op.
Historically we did not allow binary patch applied without an
explicit permission from the user, and this flag was the way to
do so. This makes the flag a no-op by always allowing binary
patch application.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
Documentation/git-apply.txt | 13 ++++---------
builtin-apply.c | 19 +++++--------------
t/t4103-apply-binary.sh | 4 ++--
3 files changed, 11 insertions(+), 25 deletions(-)
diff --git a/Documentation/git-apply.txt b/Documentation/git-apply.txt
index c76cfff..0a6f7b3 100644
--- a/Documentation/git-apply.txt
+++ b/Documentation/git-apply.txt
@@ -110,15 +110,10 @@ OPTIONS
deletion part but not addition part.
--allow-binary-replacement, --binary::
- When applying a patch, which is a git-enhanced patch
- that was prepared to record the pre- and post-image object
- name in full, and the path being patched exactly matches
- the object the patch applies to (i.e. "index" line's
- pre-image object name is what is in the working tree),
- and the post-image object is available in the object
- database, use the post-image object as the patch
- result. This allows binary files to be patched in a
- very limited way.
+ Historically we did not allow binary patch applied
+ without an explicit permission from the user, and this
+ flag was the way to do so. Currently we always allow binary
+ patch application, so this is a no-op.
--exclude=<path-pattern>::
Don't apply changes to files matching the given path pattern. This can
diff --git a/builtin-apply.c b/builtin-apply.c
index 872c800..6e0864c 100644
--- a/builtin-apply.c
+++ b/builtin-apply.c
@@ -28,7 +28,6 @@ static int prefix_length = -1;
static int newfd = -1;
static int p_value = 1;
-static int allow_binary_replacement;
static int check_index;
static int write_index;
static int cached;
@@ -1228,14 +1227,12 @@ static int parse_chunk(char *buffer, uns
}
}
- /* Empty patch cannot be applied if:
- * - it is a binary patch and we do not do binary_replace, or
- * - text patch without metadata change
+ /* Empty patch cannot be applied if it is a text patch
+ * without metadata change. A binary patch appears
+ * empty to us here.
*/
if ((apply || check) &&
- (patch->is_binary
- ? !allow_binary_replacement
- : !metadata_changes(patch)))
+ (!patch->is_binary && !metadata_changes(patch)))
die("patch with only garbage at line %d", linenr);
}
@@ -1676,11 +1673,6 @@ static int apply_binary(struct buffer_de
unsigned char hdr[50];
int hdrlen;
- if (!allow_binary_replacement)
- return error("cannot apply binary patch to '%s' "
- "without --allow-binary-replacement",
- name);
-
/* For safety, we require patch index line to contain
* full 40-byte textual SHA1 for old and new, at least for now.
*/
@@ -2497,8 +2489,7 @@ int cmd_apply(int argc, const char **arg
}
if (!strcmp(arg, "--allow-binary-replacement") ||
!strcmp(arg, "--binary")) {
- allow_binary_replacement = 1;
- continue;
+ continue; /* now no-op */
}
if (!strcmp(arg, "--numstat")) {
apply = 0;
diff --git a/t/t4103-apply-binary.sh b/t/t4103-apply-binary.sh
index ff05269..e2b1124 100755
--- a/t/t4103-apply-binary.sh
+++ b/t/t4103-apply-binary.sh
@@ -94,11 +94,11 @@ test_expect_failure 'apply binary diff (
'do_reset
git-apply --index C.diff'
-test_expect_failure 'apply binary diff without replacement -- should fail.' \
+test_expect_success 'apply binary diff without replacement.' \
'do_reset
git-apply BF.diff'
-test_expect_failure 'apply binary diff without replacement (copy) -- should fail.' \
+test_expect_success 'apply binary diff without replacement (copy).' \
'do_reset
git-apply CF.diff'
--
1.4.2.gfce41
^ permalink raw reply related
* [PATCH 3/3] git-commit.sh: convert run_status to a C builtin
From: Jeff King @ 2006-09-07 6:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <64c62cc942e872b29d7225999e74a07be586674a.1157610743.git.peff@peff.net>
This creates a new git-runstatus which should do roughly the same thing
as the run_status function from git-commit.sh. Except for color support,
the main focus has been to keep the output identical, so that it can be
verified as correct and then used as a C platform for other improvements to
the status printing code.
---
.gitignore | 1
Makefile | 3 -
builtin-runstatus.c | 34 ++++++
builtin.h | 1
dir.c | 7 +
dir.h | 1
git-commit.sh | 106 +------------------
git.c | 1
status.c | 283 +++++++++++++++++++++++++++++++++++++++++++++++++++
status.h | 31 ++++++
10 files changed, 368 insertions(+), 100 deletions(-)
diff --git a/.gitignore b/.gitignore
index 78cb671..f014ad3 100644
--- a/.gitignore
+++ b/.gitignore
@@ -94,6 +94,7 @@ git-rev-list
git-rev-parse
git-revert
git-rm
+git-runstatus
git-send-email
git-send-pack
git-sh-setup
diff --git a/Makefile b/Makefile
index 78748cb..d0ba3b5 100644
--- a/Makefile
+++ b/Makefile
@@ -252,7 +252,7 @@ LIB_OBJS = \
fetch-clone.o revision.o pager.o tree-walk.o xdiff-interface.o \
write_or_die.o trace.o \
alloc.o merge-file.o path-list.o help.o unpack-trees.o $(DIFF_OBJS) \
- color.o
+ color.o status.o
BUILTIN_OBJS = \
builtin-add.o \
@@ -286,6 +286,7 @@ BUILTIN_OBJS = \
builtin-rev-list.o \
builtin-rev-parse.o \
builtin-rm.o \
+ builtin-runstatus.o \
builtin-show-branch.o \
builtin-stripspace.o \
builtin-symbolic-ref.o \
diff --git a/builtin-runstatus.c b/builtin-runstatus.c
new file mode 100644
index 0000000..f3e44de
--- /dev/null
+++ b/builtin-runstatus.c
@@ -0,0 +1,34 @@
+#include "status.h"
+#include "cache.h"
+
+extern int status_use_color;
+
+static const char runstatus_usage[] =
+"git-runstatus [--color|--nocolor] [--amend] [--verbose]";
+
+int cmd_runstatus(int argc, const char **argv, const char *prefix)
+{
+ struct status s;
+ int i;
+
+ git_config(git_status_config);
+ status_prepare(&s);
+
+ for (i = 1; i < argc; i++) {
+ if (!strcmp(argv[i], "--color"))
+ status_use_color = 1;
+ else if (!strcmp(argv[i], "--nocolor"))
+ status_use_color = 0;
+ else if (!strcmp(argv[i], "--amend")) {
+ s.amend = 1;
+ s.reference = "HEAD^1";
+ }
+ else if (!strcmp(argv[i], "--verbose"))
+ s.verbose = 1;
+ else
+ usage(runstatus_usage);
+ }
+
+ status_print(&s);
+ return s.commitable ? 0 : 1;
+}
diff --git a/builtin.h b/builtin.h
index 25431d7..53a896c 100644
--- a/builtin.h
+++ b/builtin.h
@@ -47,6 +47,7 @@ extern int cmd_repo_config(int argc, con
extern int cmd_rev_list(int argc, const char **argv, const char *prefix);
extern int cmd_rev_parse(int argc, const char **argv, const char *prefix);
extern int cmd_rm(int argc, const char **argv, const char *prefix);
+extern int cmd_runstatus(int argc, const char **argv, const char *prefix);
extern int cmd_show_branch(int argc, const char **argv, const char *prefix);
extern int cmd_show(int argc, const char **argv, const char *prefix);
extern int cmd_stripspace(int argc, const char **argv, const char *prefix);
diff --git a/dir.c b/dir.c
index 5a40d8f..e2f472b 100644
--- a/dir.c
+++ b/dir.c
@@ -397,3 +397,10 @@ int read_directory(struct dir_struct *di
qsort(dir->entries, dir->nr, sizeof(struct dir_entry *), cmp_name);
return dir->nr;
}
+
+int
+file_exists(const char *f)
+{
+ struct stat sb;
+ return stat(f, &sb) == 0;
+}
diff --git a/dir.h b/dir.h
index 56a1b7f..313f8ab 100644
--- a/dir.h
+++ b/dir.h
@@ -47,5 +47,6 @@ extern int excluded(struct dir_struct *,
extern void add_excludes_from_file(struct dir_struct *, const char *fname);
extern void add_exclude(const char *string, const char *base,
int baselen, struct exclude_list *which);
+extern int file_exists(const char *);
#endif
diff --git a/git-commit.sh b/git-commit.sh
index 4cf3fab..10c269a 100755
--- a/git-commit.sh
+++ b/git-commit.sh
@@ -60,26 +60,6 @@ #
}
run_status () {
- (
- # We always show status for the whole tree.
- cd "$TOP"
-
- IS_INITIAL="$initial_commit"
- REFERENCE=HEAD
- case "$amend" in
- t)
- # If we are amending the initial commit, there
- # is no HEAD^1.
- if git-rev-parse --verify "HEAD^1" >/dev/null 2>&1
- then
- REFERENCE="HEAD^1"
- IS_INITIAL=
- else
- IS_INITIAL=t
- fi
- ;;
- esac
-
# If TMP_INDEX is defined, that means we are doing
# "--only" partial commit, and that index file is used
# to build the tree for the commit. Otherwise, if
@@ -96,85 +76,13 @@ run_status () {
export GIT_INDEX_FILE
fi
- case "$branch" in
- refs/heads/master) ;;
- *) echo "# On branch $branch" ;;
- esac
-
- if test -z "$IS_INITIAL"
- then
- git-diff-index -M --cached --name-status \
- --diff-filter=MDTCRA $REFERENCE |
- sed -e '
- s/\\/\\\\/g
- s/ /\\ /g
- ' |
- report "Updated but not checked in" "will commit"
- committable="$?"
- else
- echo '#
-# Initial commit
-#'
- git-ls-files |
- sed -e '
- s/\\/\\\\/g
- s/ /\\ /g
- s/^/A /
- ' |
- report "Updated but not checked in" "will commit"
-
- committable="$?"
- fi
-
- git-diff-files --name-status |
- sed -e '
- s/\\/\\\\/g
- s/ /\\ /g
- ' |
- report "Changed but not updated" \
- "use git-update-index to mark for commit"
-
- option=""
- if test -z "$untracked_files"; then
- option="--directory --no-empty-directory"
- fi
- hdr_shown=
- if test -f "$GIT_DIR/info/exclude"
- then
- git-ls-files --others $option \
- --exclude-from="$GIT_DIR/info/exclude" \
- --exclude-per-directory=.gitignore
- else
- git-ls-files --others $option \
- --exclude-per-directory=.gitignore
- fi |
- while read line; do
- if [ -z "$hdr_shown" ]; then
- echo '#'
- echo '# Untracked files:'
- echo '# (use "git add" to add to commit)'
- echo '#'
- hdr_shown=1
- fi
- echo "# $line"
- done
-
- if test -n "$verbose" -a -z "$IS_INITIAL"
- then
- git-diff-index --cached -M -p --diff-filter=MDTCRA $REFERENCE
- fi
- case "$committable" in
- 0)
- case "$amend" in
- t)
- echo "# No changes" ;;
- *)
- echo "nothing to commit" ;;
- esac
- exit 1 ;;
- esac
- exit 0
- )
+ case "$status_only" in
+ t) color= ;;
+ *) color=--nocolor ;;
+ esac
+ git-runstatus ${color} \
+ ${verbose:+--verbose} \
+ ${amend:+--amend}
}
trap '
diff --git a/git.c b/git.c
index 335f405..495b39a 100644
--- a/git.c
+++ b/git.c
@@ -252,6 +252,7 @@ static void handle_internal_command(int
{ "rev-list", cmd_rev_list, RUN_SETUP },
{ "rev-parse", cmd_rev_parse, RUN_SETUP },
{ "rm", cmd_rm, RUN_SETUP },
+ { "runstatus", cmd_runstatus, RUN_SETUP },
{ "show-branch", cmd_show_branch, RUN_SETUP },
{ "show", cmd_show, RUN_SETUP | USE_PAGER },
{ "stripspace", cmd_stripspace },
diff --git a/status.c b/status.c
new file mode 100644
index 0000000..82aa881
--- /dev/null
+++ b/status.c
@@ -0,0 +1,283 @@
+#include "status.h"
+#include "color.h"
+#include "cache.h"
+#include "object.h"
+#include "dir.h"
+#include "commit.h"
+#include "diff.h"
+#include "revision.h"
+#include "diffcore.h"
+
+int status_use_color = 0;
+static char status_colors[][COLOR_MAXLEN] = {
+ "", /* STATUS_HEADER: normal */
+ "\033[32m", /* STATUS_UPDATED: green */
+ "\033[31m", /* STATUS_CHANGED: red */
+ "\033[31m", /* STATUS_UNTRACKED: red */
+};
+
+static int
+parse_status_slot(const char *var, int offset) {
+ if (!strcasecmp(var+offset, "header"))
+ return STATUS_HEADER;
+ if (!strcasecmp(var+offset, "updated"))
+ return STATUS_UPDATED;
+ if (!strcasecmp(var+offset, "changed"))
+ return STATUS_CHANGED;
+ if (!strcasecmp(var+offset, "untracked"))
+ return STATUS_UNTRACKED;
+ die("bad config variable '%s'", var);
+}
+
+static const char*
+color(int slot)
+{
+ return status_use_color ? status_colors[slot] : "";
+}
+
+void
+status_prepare(struct status *s)
+{
+ unsigned char sha1[20];
+ const char *head;
+
+ s->is_initial = get_sha1("HEAD", sha1) ? 1 : 0;
+
+ head = resolve_ref(git_path("HEAD"), sha1, 0);
+ s->branch = head ?
+ strdup(head + strlen(get_git_dir()) + 1) :
+ NULL;
+
+ s->reference = "HEAD";
+ s->amend = 0;
+ s->verbose = 0;
+ s->commitable = 0;
+}
+
+static void
+status_print_header(const char *main, const char *sub)
+{
+ const char *c = color(STATUS_HEADER);
+ color_printf(c, "# %s:\n", main);
+ color_printf(c, "# (%s)\n", sub);
+ color_printf(c, "#\n");
+}
+
+static void
+status_print_trailer(void)
+{
+ color_printf(color(STATUS_HEADER), "#\n");
+}
+
+static void
+status_print_filepair(int t, struct diff_filepair *p)
+{
+ const char *c = color(t);
+ color_printf(color(STATUS_HEADER), "#\t");
+ switch (p->status) {
+ case DIFF_STATUS_ADDED:
+ color_printf(c, "new file: %s\n", p->one->path); break;
+ case DIFF_STATUS_COPIED:
+ color_printf(c, "copied: %s -> %s\n",
+ p->one->path, p->two->path);
+ break;
+ case DIFF_STATUS_DELETED:
+ color_printf(c, "deleted: %s\n", p->one->path); break;
+ case DIFF_STATUS_MODIFIED:
+ color_printf(c, "modified: %s\n", p->one->path); break;
+ case DIFF_STATUS_RENAMED:
+ color_printf(c, "renamed: %s -> %s\n",
+ p->one->path, p->two->path);
+ break;
+ case DIFF_STATUS_TYPE_CHANGED:
+ color_printf(c, "typechange: %s\n", p->one->path); break;
+ case DIFF_STATUS_UNKNOWN:
+ color_printf(c, "unknown: %s\n", p->one->path); break;
+ case DIFF_STATUS_UNMERGED:
+ color_printf(c, "unmerged: %s\n", p->one->path); break;
+ default:
+ die("bug: unhandled diff status %c", p->status);
+ }
+}
+
+static void
+status_print_updated_cb(struct diff_queue_struct *q,
+ struct diff_options *options,
+ void *data)
+{
+ struct status *s = data;
+ int shown_header = 0;
+ int i;
+ if (q->nr) {
+ }
+ for (i = 0; i < q->nr; i++) {
+ if (q->queue[i]->status == 'U')
+ continue;
+ if (!shown_header) {
+ status_print_header("Updated but not checked in",
+ "will commit");
+ s->commitable = 1;
+ }
+ status_print_filepair(STATUS_UPDATED, q->queue[i]);
+ }
+ if (shown_header)
+ status_print_trailer();
+}
+
+static void
+status_print_changed_cb(struct diff_queue_struct *q,
+ struct diff_options *options,
+ void *data)
+{
+ int i;
+ if (q->nr)
+ status_print_header("Changed but not updated",
+ "use git-update-index to mark for commit");
+ for (i = 0; i < q->nr; i++)
+ status_print_filepair(STATUS_CHANGED, q->queue[i]);
+ if (q->nr)
+ status_print_trailer();
+}
+
+void
+status_print_initial(struct status *s)
+{
+ int i;
+ read_cache();
+ if (active_nr) {
+ s->commitable = 1;
+ status_print_header("Updated but not checked in",
+ "will commit");
+ }
+ for (i = 0; i < active_nr; i++) {
+ color_printf(color(STATUS_HEADER), "#\t");
+ color_printf(color(STATUS_UPDATED), "new file: %s\n",
+ active_cache[i]->name);
+ }
+ if (active_nr)
+ status_print_trailer();
+}
+
+static void
+status_print_updated(struct status *s)
+{
+ struct rev_info rev;
+ const char *argv[] = { NULL, NULL, NULL };
+ argv[1] = s->reference;
+ init_revisions(&rev, NULL);
+ setup_revisions(2, argv, &rev, NULL);
+ rev.diffopt.output_format |= DIFF_FORMAT_CALLBACK;
+ rev.diffopt.format_callback = status_print_updated_cb;
+ rev.diffopt.format_callback_data = s;
+ rev.diffopt.detect_rename = 1;
+ run_diff_index(&rev, 1);
+}
+
+static void
+status_print_changed(struct status *s)
+{
+ struct rev_info rev;
+ const char *argv[] = { NULL, NULL };
+ init_revisions(&rev, "");
+ setup_revisions(1, argv, &rev, NULL);
+ rev.diffopt.output_format |= DIFF_FORMAT_CALLBACK;
+ rev.diffopt.format_callback = status_print_changed_cb;
+ rev.diffopt.format_callback_data = s;
+ run_diff_files(&rev, 0);
+}
+
+static void
+status_print_untracked(const struct status *s)
+{
+ struct dir_struct dir;
+ const char *x;
+ int i;
+ int shown_header = 0;
+
+ memset(&dir, 0, sizeof(dir));
+
+ dir.exclude_per_dir = ".gitignore";
+ x = git_path("info/exclude");
+ if (file_exists(x))
+ add_excludes_from_file(&dir, x);
+
+ read_directory(&dir, ".", "", 0);
+ for(i = 0; i < dir.nr; i++) {
+ /* check for matching entry, which is unmerged; lifted from
+ * builtin-ls-files:show_other_files */
+ struct dir_entry *ent = dir.entries[i];
+ int pos = cache_name_pos(ent->name, ent->len);
+ struct cache_entry *ce;
+ if (0 <= pos)
+ die("bug in status_print_untracked");
+ pos = -pos - 1;
+ if (pos < active_nr) {
+ ce = active_cache[pos];
+ if (ce_namelen(ce) == ent->len &&
+ !memcmp(ce->name, ent->name, ent->len))
+ continue;
+ }
+ if (!shown_header) {
+ status_print_header("Untracked files",
+ "use \"git add\" to add to commit");
+ shown_header = 1;
+ }
+ color_printf(color(STATUS_HEADER), "#\t");
+ color_printf(color(STATUS_UNTRACKED), "%.*s\n",
+ ent->len, ent->name);
+ }
+}
+
+static void
+status_print_verbose(struct status *s)
+{
+ struct rev_info rev;
+ const char *argv[] = { NULL, NULL, NULL };
+ argv[1] = s->reference;
+ init_revisions(&rev, NULL);
+ setup_revisions(2, argv, &rev, NULL);
+ rev.diffopt.output_format |= DIFF_FORMAT_PATCH;
+ rev.diffopt.detect_rename = 1;
+ run_diff_index(&rev, 1);
+}
+
+void
+status_print(struct status *s)
+{
+ if (s->branch && strcmp(s->branch, "refs/heads/master"))
+ color_printf(color(STATUS_HEADER),
+ "# On branch %s\n", s->branch);
+
+ if (s->is_initial) {
+ color_printf(color(STATUS_HEADER), "#\n");
+ color_printf(color(STATUS_HEADER), "# Initial commit\n");
+ color_printf(color(STATUS_HEADER), "#\n");
+ status_print_initial(s);
+ }
+ else {
+ status_print_updated(s);
+ discard_cache();
+ }
+
+ status_print_changed(s);
+ status_print_untracked(s);
+
+ if (s->verbose && !s->is_initial)
+ status_print_verbose(s);
+ if (!s->commitable)
+ printf("%s\n", s->amend ? "# No changes" : "nothing to commit");
+}
+
+int
+git_status_config(const char *k, const char *v)
+{
+ if (!strcmp(k, "status.color")) {
+ status_use_color = git_config_colorbool(k, v);
+ return 0;
+ }
+ if (!strncmp(k, "status.color.", 13)) {
+ int slot = parse_status_slot(k, 13);
+ color_parse(v, k, status_colors[slot]);
+ }
+ return git_default_config(k, v);
+}
diff --git a/status.h b/status.h
new file mode 100644
index 0000000..3e60146
--- /dev/null
+++ b/status.h
@@ -0,0 +1,31 @@
+#ifndef STATUS_H
+#define STATUS_H
+
+enum color_status {
+ STATUS_HEADER,
+ STATUS_UPDATED,
+ STATUS_CHANGED,
+ STATUS_UNTRACKED,
+};
+
+struct status {
+ int is_initial;
+ char *branch;
+ const char *reference;
+ int commitable;
+ int verbose;
+ int amend;
+};
+
+int git_status_config(const char *var, const char *value);
+void status_prepare(struct status *s);
+void status_print(struct status *s);
+
+struct cache_entry;
+typedef void (*status_cb)(struct cache_entry *);
+int status_foreach_cached(status_cb cb);
+int status_foreach_updated(status_cb cb);
+int status_foreach_changed(status_cb cb);
+int status_foreach_untracked(status_cb cb);
+
+#endif /* STATUS_H */
--
1.4.2.ge490e-dirty
^ permalink raw reply related
* [PATCH 2/3] Move color option parsing out of diff.c and into color.[ch]
From: Jeff King @ 2006-09-07 6:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <2ec783f6a8e8a901f7c30947e8c0eb50f71bc185.1157610743.git.peff@peff.net>
The intent is to lib-ify colorizing code so it can be reused.
---
Makefile | 3 +
color.c | 158 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
color.h | 11 ++++
diff.c | 136 ++---------------------------------------------------
4 files changed, 175 insertions(+), 133 deletions(-)
diff --git a/Makefile b/Makefile
index 7b3114f..78748cb 100644
--- a/Makefile
+++ b/Makefile
@@ -251,7 +251,8 @@ LIB_OBJS = \
tag.o tree.o usage.o config.o environment.o ctype.o copy.o \
fetch-clone.o revision.o pager.o tree-walk.o xdiff-interface.o \
write_or_die.o trace.o \
- alloc.o merge-file.o path-list.o help.o unpack-trees.o $(DIFF_OBJS)
+ alloc.o merge-file.o path-list.o help.o unpack-trees.o $(DIFF_OBJS) \
+ color.o
BUILTIN_OBJS = \
builtin-add.o \
diff --git a/color.c b/color.c
new file mode 100644
index 0000000..563ef70
--- /dev/null
+++ b/color.c
@@ -0,0 +1,158 @@
+#include "color.h"
+#include "cache.h"
+#include "git-compat-util.h"
+
+#include <stdarg.h>
+
+#define COLOR_RESET "\033[m"
+
+static int
+parse_color(const char *name, int len)
+{
+ static const char * const color_names[] = {
+ "normal", "black", "red", "green", "yellow",
+ "blue", "magenta", "cyan", "white"
+ };
+ char *end;
+ int i;
+ for (i = 0; i < ARRAY_SIZE(color_names); i++) {
+ const char *str = color_names[i];
+ if (!strncasecmp(name, str, len) && !str[len])
+ return i - 1;
+ }
+ i = strtol(name, &end, 10);
+ if (*name && !*end && i >= -1 && i <= 255)
+ return i;
+ return -2;
+}
+
+static int
+parse_attr(const char *name, int len)
+{
+ static const int attr_values[] = { 1, 2, 4, 5, 7 };
+ static const char * const attr_names[] = {
+ "bold", "dim", "ul", "blink", "reverse"
+ };
+ int i;
+ for (i = 0; i < ARRAY_SIZE(attr_names); i++) {
+ const char *str = attr_names[i];
+ if (!strncasecmp(name, str, len) && !str[len])
+ return attr_values[i];
+ }
+ return -1;
+}
+
+void
+color_parse(const char *value, const char *var, char *dst)
+{
+ const char *ptr = value;
+ int attr = -1;
+ int fg = -2;
+ int bg = -2;
+
+ if (!strcasecmp(value, "reset")) {
+ strcpy(dst, "\033[m");
+ return;
+ }
+
+ /* [fg [bg]] [attr] */
+ while (*ptr) {
+ const char *word = ptr;
+ int val, len = 0;
+
+ while (word[len] && !isspace(word[len]))
+ len++;
+
+ ptr = word + len;
+ while (*ptr && isspace(*ptr))
+ ptr++;
+
+ val = parse_color(word, len);
+ if (val >= -1) {
+ if (fg == -2) {
+ fg = val;
+ continue;
+ }
+ if (bg == -2) {
+ bg = val;
+ continue;
+ }
+ goto bad;
+ }
+ val = parse_attr(word, len);
+ if (val < 0 || attr != -1)
+ goto bad;
+ attr = val;
+ }
+
+ if (attr >= 0 || fg >= 0 || bg >= 0) {
+ int sep = 0;
+
+ *dst++ = '\033';
+ *dst++ = '[';
+ if (attr >= 0) {
+ *dst++ = '0' + attr;
+ sep++;
+ }
+ if (fg >= 0) {
+ if (sep++)
+ *dst++ = ';';
+ if (fg < 8) {
+ *dst++ = '3';
+ *dst++ = '0' + fg;
+ } else {
+ dst += sprintf(dst, "38;5;%d", fg);
+ }
+ }
+ if (bg >= 0) {
+ if (sep++)
+ *dst++ = ';';
+ if (bg < 8) {
+ *dst++ = '4';
+ *dst++ = '0' + bg;
+ } else {
+ dst += sprintf(dst, "48;5;%d", bg);
+ }
+ }
+ *dst++ = 'm';
+ }
+ *dst = 0;
+ return;
+bad:
+ die("bad config value '%s' for variable '%s'", value, var);
+}
+
+int
+git_config_colorbool(const char *var, const char *value)
+{
+ if (!value)
+ return 1;
+ if (!strcasecmp(value, "auto")) {
+ if (isatty(1) || (pager_in_use && pager_use_color)) {
+ char *term = getenv("TERM");
+ if (term && strcmp(term, "dumb"))
+ return 1;
+ }
+ return 0;
+ }
+ if (!strcasecmp(value, "never"))
+ return 0;
+ if (!strcasecmp(value, "always"))
+ return 1;
+ return git_config_bool(var, value);
+}
+
+int
+color_printf(const char *color, const char *fmt, ...) {
+ va_list args;
+ int r;
+
+ if (*color)
+ printf("%s", color);
+ va_start(args, fmt);
+ r = vprintf(fmt, args);
+ va_end(args);
+ if (*color)
+ printf("%s", COLOR_RESET);
+ return r;
+}
diff --git a/color.h b/color.h
new file mode 100644
index 0000000..37a737a
--- /dev/null
+++ b/color.h
@@ -0,0 +1,11 @@
+#ifndef COLOR_H
+#define COLOR_H
+
+/* "\033[1;38;5;2xx;48;5;2xxm\0" is 23 bytes */
+#define COLOR_MAXLEN 24
+
+int git_config_colorbool(const char *var, const char *value);
+void color_parse(const char *var, const char *value, char *dst);
+int color_printf(const char *color, const char *fmt, ...);
+
+#endif /* COLOR_H */
diff --git a/diff.c b/diff.c
index a3ebc62..8178c11 100644
--- a/diff.c
+++ b/diff.c
@@ -10,6 +10,7 @@ #include "diff.h"
#include "diffcore.h"
#include "delta.h"
#include "xdiff-interface.h"
+#include "color.h"
static int use_size_cache;
@@ -17,8 +18,7 @@ static int diff_detect_rename_default;
static int diff_rename_limit_default = -1;
static int diff_use_color_default;
-/* "\033[1;38;5;2xx;48;5;2xxm\0" is 23 bytes */
-static char diff_colors[][24] = {
+static char diff_colors[][COLOR_MAXLEN] = {
"\033[m", /* reset */
"", /* normal */
"\033[1m", /* bold */
@@ -45,119 +45,6 @@ static int parse_diff_color_slot(const c
die("bad config variable '%s'", var);
}
-static int parse_color(const char *name, int len)
-{
- static const char * const color_names[] = {
- "normal", "black", "red", "green", "yellow",
- "blue", "magenta", "cyan", "white"
- };
- char *end;
- int i;
- for (i = 0; i < ARRAY_SIZE(color_names); i++) {
- const char *str = color_names[i];
- if (!strncasecmp(name, str, len) && !str[len])
- return i - 1;
- }
- i = strtol(name, &end, 10);
- if (*name && !*end && i >= -1 && i <= 255)
- return i;
- return -2;
-}
-
-static int parse_attr(const char *name, int len)
-{
- static const int attr_values[] = { 1, 2, 4, 5, 7 };
- static const char * const attr_names[] = {
- "bold", "dim", "ul", "blink", "reverse"
- };
- int i;
- for (i = 0; i < ARRAY_SIZE(attr_names); i++) {
- const char *str = attr_names[i];
- if (!strncasecmp(name, str, len) && !str[len])
- return attr_values[i];
- }
- return -1;
-}
-
-static void parse_diff_color_value(const char *value, const char *var, char *dst)
-{
- const char *ptr = value;
- int attr = -1;
- int fg = -2;
- int bg = -2;
-
- if (!strcasecmp(value, "reset")) {
- strcpy(dst, "\033[m");
- return;
- }
-
- /* [fg [bg]] [attr] */
- while (*ptr) {
- const char *word = ptr;
- int val, len = 0;
-
- while (word[len] && !isspace(word[len]))
- len++;
-
- ptr = word + len;
- while (*ptr && isspace(*ptr))
- ptr++;
-
- val = parse_color(word, len);
- if (val >= -1) {
- if (fg == -2) {
- fg = val;
- continue;
- }
- if (bg == -2) {
- bg = val;
- continue;
- }
- goto bad;
- }
- val = parse_attr(word, len);
- if (val < 0 || attr != -1)
- goto bad;
- attr = val;
- }
-
- if (attr >= 0 || fg >= 0 || bg >= 0) {
- int sep = 0;
-
- *dst++ = '\033';
- *dst++ = '[';
- if (attr >= 0) {
- *dst++ = '0' + attr;
- sep++;
- }
- if (fg >= 0) {
- if (sep++)
- *dst++ = ';';
- if (fg < 8) {
- *dst++ = '3';
- *dst++ = '0' + fg;
- } else {
- dst += sprintf(dst, "38;5;%d", fg);
- }
- }
- if (bg >= 0) {
- if (sep++)
- *dst++ = ';';
- if (bg < 8) {
- *dst++ = '4';
- *dst++ = '0' + bg;
- } else {
- dst += sprintf(dst, "48;5;%d", bg);
- }
- }
- *dst++ = 'm';
- }
- *dst = 0;
- return;
-bad:
- die("bad config value '%s' for variable '%s'", value, var);
-}
-
/*
* These are to give UI layer defaults.
* The core-level commands such as git-diff-files should
@@ -171,22 +58,7 @@ int git_diff_ui_config(const char *var,
return 0;
}
if (!strcmp(var, "diff.color")) {
- if (!value)
- diff_use_color_default = 1; /* bool */
- else if (!strcasecmp(value, "auto")) {
- diff_use_color_default = 0;
- if (isatty(1) || (pager_in_use && pager_use_color)) {
- char *term = getenv("TERM");
- if (term && strcmp(term, "dumb"))
- diff_use_color_default = 1;
- }
- }
- else if (!strcasecmp(value, "never"))
- diff_use_color_default = 0;
- else if (!strcasecmp(value, "always"))
- diff_use_color_default = 1;
- else
- diff_use_color_default = git_config_bool(var, value);
+ diff_use_color_default = git_config_colorbool(var, value);
return 0;
}
if (!strcmp(var, "diff.renames")) {
@@ -201,7 +73,7 @@ int git_diff_ui_config(const char *var,
}
if (!strncmp(var, "diff.color.", 11)) {
int slot = parse_diff_color_slot(var, 11);
- parse_diff_color_value(value, var, diff_colors[slot]);
+ color_parse(value, var, diff_colors[slot]);
return 0;
}
return git_default_config(var, value);
--
1.4.2.ge490e-dirty
^ permalink raw reply related
* [PATCH 1/3] diff: support custom callbacks for output
From: Jeff King @ 2006-09-07 6:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20060907062917.GA16969@coredump.intra.peff.net>
Users can request the DIFF_FORMAT_CALLBACK output format to get a callback
consisting of the whole diff_queue_struct.
---
diff.c | 3 +++
diff.h | 8 ++++++++
2 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/diff.c b/diff.c
index 9dcbda3..a3ebc62 100644
--- a/diff.c
+++ b/diff.c
@@ -2587,6 +2587,9 @@ void diff_flush(struct diff_options *opt
}
}
+ if (output_format & DIFF_FORMAT_CALLBACK)
+ options->format_callback(q, options, options->format_callback_data);
+
for (i = 0; i < q->nr; i++)
diff_free_filepair(q->queue[i]);
free_queue:
diff --git a/diff.h b/diff.h
index b007240..b60a02e 100644
--- a/diff.h
+++ b/diff.h
@@ -8,6 +8,7 @@ #include "tree-walk.h"
struct rev_info;
struct diff_options;
+struct diff_queue_struct;
typedef void (*change_fn_t)(struct diff_options *options,
unsigned old_mode, unsigned new_mode,
@@ -20,6 +21,9 @@ typedef void (*add_remove_fn_t)(struct d
const unsigned char *sha1,
const char *base, const char *path);
+typedef void (*diff_format_fn_t)(struct diff_queue_struct *q,
+ struct diff_options *options, void *data);
+
#define DIFF_FORMAT_RAW 0x0001
#define DIFF_FORMAT_DIFFSTAT 0x0002
#define DIFF_FORMAT_SUMMARY 0x0004
@@ -35,6 +39,8 @@ #define DIFF_FORMAT_CHECKDIFF 0x0040
*/
#define DIFF_FORMAT_NO_OUTPUT 0x0080
+#define DIFF_FORMAT_CALLBACK 0x0100
+
struct diff_options {
const char *filter;
const char *orderfile;
@@ -68,6 +74,8 @@ struct diff_options {
int *pathlens;
change_fn_t change;
add_remove_fn_t add_remove;
+ diff_format_fn_t format_callback;
+ void *format_callback_data;
};
enum color_diff {
--
1.4.2.ge490e-dirty
^ permalink raw reply related
* Re: [PATCH 1/2] Add git-archive
From: Franck Bui-Huu @ 2006-09-07 6:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vac5c7jty.fsf@assigned-by-dhcp.cox.net>
2006/9/6, Junio C Hamano <junkio@cox.net>:
> Franck Bui-Huu <vagabon.xyz@gmail.com> writes:
>
> > Interesting, could you explain why static variables are not nice ?
>
> Mostly taste and a little bit of re-entrancy worries.
>
OK.
> > You might have missed my second patch:
> >
> > "[PATCH 2/2] Add git-upload-archive"
> >
> > Basically the server can also use 'reason' to report a failure
> > description during NACK. I find it more useful than the simple
> > "server sent EOF" error message.
>
> That's a good intention, but we would also need to convey the
> "server side found problem and died with these error() output"
> anyway,
OK.
>
> > One bad side is that we need to malloc this embedded structure.
>
> Not at all, if you read the example I did you would notice that
> I changed parse_extra for each backend to return this structure
> allocated for that particular backend.
>
sorry I wasn't clear. My point was that the structure need to be
'mallocated'. Which funtion allocate it doesn't matter, we will need
to free it later. That's what I tried to avoid with the alternative I
sent you in my previous email. Do you think we could use it ?
> >>> +static int run_remote_archiver(struct archiver_struct *ar, int argc,
> >>> + const char **argv)
> >>> +{
> >>> + char *url, buf[1024];
> >>> + pid_t pid;
> >>> + int fd[2];
> >>> + int len, rv;
> >>> +
> >>> + sprintf(buf, "git-upload-%s", ar->name);
> >>
> >> Are you calling git-upload-{tar,zip,rar,...} here?
> >
> > yes. Actually git-upload-{tar,zip,...} commands are going to be
> > removed, but git-daemon know them as a daemon service.
>
> That would break "git-archive --remove=ssh://site/repo treeish"
> wouldn't it?
>
Yes. But couldn't we make some alias like:
alias git-upload-tar='git-upload-archive --format=tar'
alias git-upload-zip='git-upload-zip --format=zip'
and the same could be done if we plan to remote git-tar-tree command:
alias git-tar-tree='git-archive --format=tar'
These alias would be internal to git (always defined)
--
Franck
^ permalink raw reply
* [PATCH 0/3] Convert run_status to a builtin
From: Jeff King @ 2006-09-07 6:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
This series of patches converts the run_status function from
git-commit.sh to a C builtin. Hopefully we can use this as a starting
point for further improvements (the only feature I added was
colorization). I haven't had a chance to look closely at the
simultaneous traversal code in pu, but that would be the nice next place
to take this concept.
Patch 1/3 adds the necessary diff callback infrastructure, which may be
of value regardless of whether the final patch is accepted.
Patch 2/3 lib-ifies the diff color support so it can be reused by
run-status. Again, I think this is worth doing anyway from a code
cleanup standpoint.
Patch 3/3 does the actual conversion.
-Peff
^ permalink raw reply
* Re: A look at some alternative PACK file encodings
From: Shawn Pearce @ 2006-09-07 5:34 UTC (permalink / raw)
To: A Large Angry SCM; +Cc: Jon Smirl, git
In-Reply-To: <44FF5C27.2040300@gmail.com>
A Large Angry SCM <gitzilla@gmail.com> wrote:
> Just looking at the structures in non-BLOBS, I see a lot of potential
> for the use of a set dictionaries when deflating TREEs and another set
> of dictionaries when deflating COMMITs and TAGs. The low hanging fruit
> is to create dictionaries of the most referenced IDs across all TREE or
> COMMIT/TAG objects.
The most referenced IDs should be getting reused through deltas.
That is IDs which are highly referenced are probably referenced
in the same tree over many versions of that tree. Since the data
isn't changing it should be getting copied by a delta copy command
rather than appearing as a literal.
The Mozilla pack appears to have the bulk of its storage taken up
by blobs (both bases and deltas). I suspect this is because the
bases compress to approx. 50% of their original size but share a
lot of common tokens. Those common tokens are being repeated in
every private zlib dictionary. The same thing happens in a delta,
except here we are probably copying a lot from the base so the
average size is greatly reduced but we are still repeating tokens
in the zlib dictionary for anything that is a literal in the delta
(as it didn't appear in the base).
A large dictionary containing all tokens for the project should
greatly reduce the size of each blob, base and delta alike. It also
lends itself to creating an efficient full text index.
--
Shawn.
^ permalink raw reply
* Re: A look at some alternative PACK file encodings
From: Shawn Pearce @ 2006-09-07 5:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vslj4455z.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Shawn Pearce <spearce@spearce.org> writes:
>
> > And I'm half-way done with the 64 bit mmap sliding window. You,
> > Junio and I are all hacking on the same tiny bit of core code for
> > different reasons. :-)
>
> Which makes me quite nervous, actually.
What order do you want the patches in then?
I'm willing to go before or after Nico's offset changes, and before
or after your 64 bit index changes.
Either way two of us are going to have to redo our work on top of
the others. I'm finding that I'm basically rewriting the sliding
window code onto your 64 bit version - there's no easy merge here.
And Nico's got the same problem, he's in unpack_delta_entry too.
--
Shawn.
^ permalink raw reply
* Re: A look at some alternative PACK file encodings
From: Shawn Pearce @ 2006-09-07 5:41 UTC (permalink / raw)
To: Jon Smirl; +Cc: gitzilla, git
In-Reply-To: <9e4733910609061704s429c449etcf0475841556c26b@mail.gmail.com>
Jon Smirl <jonsmirl@gmail.com> wrote:
> The repack code could build a model of the tree as it is repacking,
> that is what fast-import does. If you have a model of the tree then
> when you change a TREE node you track the last sha1 that corresponded
> to that directory path. Now you know what to diff to.
Right. But that's horribly expensive. For the most part
pack-objects does a good job estimating this by hashing the trees
by their name and size into the same hash bucket. And its fast.
Besides its better to store reverse deltas (like what CVS does)
as faster access to the more recent stuff is more interesting than
faster access to the older stuff. pack-objects tries to do this
based on the order given by rev-list.
--
Shawn.
^ permalink raw reply
* Re: A look at some alternative PACK file encodings
From: A Large Angry SCM @ 2006-09-07 5:39 UTC (permalink / raw)
To: Jon Smirl, git
In-Reply-To: <9e4733910609061617m6783d6c4xaca2f9575e12d455@mail.gmail.com>
Jon Smirl wrote:
> If you need more data to play with you can download the Mozilla pack
> file from here.
Results are about the same as for the other pack files.
pack-a80bec5339b6c50e9f3c8b0dce3e2175cd89b12f.pack
BLOB : 49860
COMMIT: 197613
DELTA : 1560153
TAG : 1203
TREE : 154496
====== ==========
Total : 1963325
Gitzilla_1: 443428349 32 443428317 -7775014 -3.9601
-4.9835
Gitzilla_2: 442177053 32 442177021 -9026310 -4.5975
-5.7855
Pack_2 : 451203363 32 451203331 0 0.0000
0.0000
Pack_3 : 451010859 32 451010827 -192504 -0.0980
-0.1234
^ permalink raw reply
* Re: A look at some alternative PACK file encodings
From: Junio C Hamano @ 2006-09-07 5:27 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <20060907043300.GA31376@spearce.org>
Shawn Pearce <spearce@spearce.org> writes:
> And I'm half-way done with the 64 bit mmap sliding window. You,
> Junio and I are all hacking on the same tiny bit of core code for
> different reasons. :-)
Which makes me quite nervous, actually.
^ permalink raw reply
* Re: A look at some alternative PACK file encodings
From: Shawn Pearce @ 2006-09-07 5:21 UTC (permalink / raw)
To: Jon Smirl; +Cc: gitzilla, git
In-Reply-To: <9e4733910609061623k73086dbey4a600ecf2852c024@mail.gmail.com>
Jon Smirl <jonsmirl@gmail.com> wrote:
> Shawn is doing some prototype work on true dictionary based
> compression. I don't know how far along he is but it has potential for
> taking 30% off the Mozilla pack.
Not very far. I've put some work into it but got distracted by the
sliding mmap window bit. So I don't have anything worth sharing yet.
Which is why I've been quiet on the subject. :-)
--
Shawn.
^ permalink raw reply
* Re: A look at some alternative PACK file encodings
From: Shawn Pearce @ 2006-09-07 4:33 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Jon Smirl, gitzilla, git
In-Reply-To: <Pine.LNX.4.64.0609062037560.18635@xanadu.home>
Nicolas Pitre <nico@cam.org> wrote:
> On Wed, 6 Sep 2006, Jon Smirl wrote:
>
> > Shawn is doing some prototype work on true dictionary based
> > compression. I don't know how far along he is but it has potential for
> > taking 30% off the Mozilla pack.
>
> BTW I'm half-way done with support for deltas which base object is
> referenced with an offset in the pack instead of a hash. It is quite
> messy though since it touches pretty core code all over the place when
> it comes to fetching objects out of a pack.
And I'm half-way done with the 64 bit mmap sliding window. You,
Junio and I are all hacking on the same tiny bit of core code for
different reasons. :-)
Right now I'm struggling with merging my 32 bit sliding window onto
Junio's 64 bit index in pu. The merge is almost done, but so is
my dinner. So dinner first. I don't think I'm going to get the
sliding window code out tonight.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] Fix memory leak in "connect.c".
From: Junio C Hamano @ 2006-09-07 4:09 UTC (permalink / raw)
To: Christian Couder; +Cc: git
In-Reply-To: <20060907055952.dafffe2b.chriscool@tuxfamily.org>
Christian Couder <chriscool@tuxfamily.org> writes:
> sq_quote allocates some memory that should be freed.
That's technically correct, but the code you are touching is
immediately before exec() or die() so I chose to be sloppy and
short ;-).
With sq_quote_buf() (which was introduced with 77d604 Oct 10
2005), you should be able to directly write into the command[]
buffer, I think. The code you touched predates that function
(b10d0e July 8 2005).
^ permalink raw reply
* [PATCH] Fix memory leak in "connect.c".
From: Christian Couder @ 2006-09-07 3:59 UTC (permalink / raw)
To: Junio Hamano; +Cc: git
sq_quote allocates some memory that should be freed.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
connect.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/connect.c b/connect.c
index 1c6429b..40a1c28 100644
--- a/connect.c
+++ b/connect.c
@@ -697,8 +697,9 @@ int git_connect(int fd[2], char *url, co
if (pid < 0)
die("unable to fork");
if (!pid) {
- snprintf(command, sizeof(command), "%s %s", prog,
- sq_quote(path));
+ char *sq_path = sq_quote(path);
+ snprintf(command, sizeof(command), "%s %s", prog, sq_path);
+ free(sq_path);
dup2(pipefd[1][0], 0);
dup2(pipefd[0][1], 1);
close(pipefd[0][0]);
--
1.4.2.g1ccae49
^ permalink raw reply related
* Re: A look at some alternative PACK file encodings
From: Nicolas Pitre @ 2006-09-07 2:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1wqo5vlz.fsf@assigned-by-dhcp.cox.net>
On Wed, 6 Sep 2006, Junio C Hamano wrote:
> Nicolas Pitre <nico@cam.org> writes:
>
> > BTW I'm half-way done with support for deltas which base object is
> > referenced with an offset in the pack instead of a hash. It is quite
> > messy though since it touches pretty core code all over the place when
> > it comes to fetching objects out of a pack.
>
> I wonder how you made unpack-objects to work with it. Do you
> store an extra bit in the packed stream to say "this object will
> be used as a delta base for later objects so remember its offset
> and resulting SHA1", or do you just remember every entry as you
> unpack?
Every entries. Much simpler that way.
And the client must ask explicitly whether or not a fetched pack can
have base objects referenced by sha1 or offset. So if you're really
really tight on memory (like if you cannot afford the extra 50MB of RAM
or so for the Mozilla repo for example) then this could be turned off.
But if we decide to not explode packs upon a fetch but keep the
downloaded pack as is (after validation) then index generation will come
for free.
Nicolas
^ permalink raw reply
* Re: A look at some alternative PACK file encodings
From: A Large Angry SCM @ 2006-09-07 2:33 UTC (permalink / raw)
To: Jon Smirl; +Cc: Nicolas Pitre, git
In-Reply-To: <9e4733910609061759m2aae9e31ja146e309dc449628@mail.gmail.com>
Jon Smirl wrote:
> On 9/6/06, Nicolas Pitre <nico@cam.org> wrote:
>> On Wed, 6 Sep 2006, Jon Smirl wrote:
>>
>> > Shawn is doing some prototype work on true dictionary based
>> > compression. I don't know how far along he is but it has potential for
>> > taking 30% off the Mozilla pack.
>>
>> BTW I'm half-way done with support for deltas which base object is
>> referenced with an offset in the pack instead of a hash. It is quite
>> messy though since it touches pretty core code all over the place when
>> it comes to fetching objects out of a pack.
>
> Would it help to change all of the references in the pack from sha1 to
> encoded relative offsets? Then collect all of the object fetch code
> into a single subroutine which would change it algorithm depending on
> which type of pack it is operating on. Now the pack wouldn't mix
> reference types, they would all be encoded relative or sha1.
>
Support for 'thin' packs would pretty much require mixing IDs and
(relative) offsets in the same pack file.
^ permalink raw reply
* Re: A look at some alternative PACK file encodings
From: Nicolas Pitre @ 2006-09-07 2:30 UTC (permalink / raw)
To: Jon Smirl; +Cc: gitzilla, git
In-Reply-To: <9e4733910609061759m2aae9e31ja146e309dc449628@mail.gmail.com>
On Wed, 6 Sep 2006, Jon Smirl wrote:
> On 9/6/06, Nicolas Pitre <nico@cam.org> wrote:
> > On Wed, 6 Sep 2006, Jon Smirl wrote:
> >
> > > Shawn is doing some prototype work on true dictionary based
> > > compression. I don't know how far along he is but it has potential for
> > > taking 30% off the Mozilla pack.
> >
> > BTW I'm half-way done with support for deltas which base object is
> > referenced with an offset in the pack instead of a hash. It is quite
> > messy though since it touches pretty core code all over the place when
> > it comes to fetching objects out of a pack.
>
> Would it help to change all of the references in the pack from sha1 to
> encoded relative offsets? Then collect all of the object fetch code
> into a single subroutine which would change it algorithm depending on
> which type of pack it is operating on. Now the pack wouldn't mix
> reference types, they would all be encoded relative or sha1.
No. The problem is more about sha1_file.c using a mix of sha1 refs
and/or pack,offset tuples to reference deltas. I converted most of them
to pack,offset tuples. This also has a mnice side effect of having less
stack usage when recursing down a delta chain.
When a delta with sha1 reference is encountered the code turns that
reference into the appropriate offset with a binary search in the pack
index. When a delta with offset reference is encountered then no search
in the index is needed.
This is not really complicated but only spread all over so that the
diffstat is a bit scary.
Nicolas
^ permalink raw reply
* Re: GitWiki lost ability to parse macros
From: Petr Baudis @ 2006-09-07 1:42 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <edmvsn$lt7$3@sea.gmane.org>
Dear diary, on Wed, Sep 06, 2006 at 07:18:37PM CEST, I got a letter
where Jakub Narebski <jnareb@gmail.com> said that...
> Julian Phillips wrote:
>
> > On Wed, 6 Sep 2006, Jakub Narebski wrote:
> >
> >> Hmm... I still get for http://git.or.cz/gitwiki/RecentChanges
> >>
> >> {{RandomQuote()}}
> >>
> >> {{RecentChanges}}
> >>
> >>
> >
> > MoinMoin caches a copy of the generated html page, which is automatically
> > updated when you edit the page. Since fixing the macros doesn't mean
> > updating the page you have to manually delete the cache - this can be done
> > from the "More Actions:" list.
>
> Could admin of GitWiki then delete cache of all files?
I did that originally, but it looks like I've missed some bit. Hopefully
now all is in order. :-)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Snow falling on Perl. White noise covering line noise.
Hides all the bugs too. -- J. Putnam
^ permalink raw reply
* Re: A look at some alternative PACK file encodings
From: Junio C Hamano @ 2006-09-07 1:11 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0609062037560.18635@xanadu.home>
Nicolas Pitre <nico@cam.org> writes:
> On Wed, 6 Sep 2006, Jon Smirl wrote:
>
>> Shawn is doing some prototype work on true dictionary based
>> compression. I don't know how far along he is but it has potential for
>> taking 30% off the Mozilla pack.
>
> BTW I'm half-way done with support for deltas which base object is
> referenced with an offset in the pack instead of a hash. It is quite
> messy though since it touches pretty core code all over the place when
> it comes to fetching objects out of a pack.
I wonder how you made unpack-objects to work with it. Do you
store an extra bit in the packed stream to say "this object will
be used as a delta base for later objects so remember its offset
and resulting SHA1", or do you just remember every entry as you
unpack?
^ permalink raw reply
* Re: A look at some alternative PACK file encodings
From: Jon Smirl @ 2006-09-07 0:59 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: gitzilla, git
In-Reply-To: <Pine.LNX.4.64.0609062037560.18635@xanadu.home>
On 9/6/06, Nicolas Pitre <nico@cam.org> wrote:
> On Wed, 6 Sep 2006, Jon Smirl wrote:
>
> > Shawn is doing some prototype work on true dictionary based
> > compression. I don't know how far along he is but it has potential for
> > taking 30% off the Mozilla pack.
>
> BTW I'm half-way done with support for deltas which base object is
> referenced with an offset in the pack instead of a hash. It is quite
> messy though since it touches pretty core code all over the place when
> it comes to fetching objects out of a pack.
Would it help to change all of the references in the pack from sha1 to
encoded relative offsets? Then collect all of the object fetch code
into a single subroutine which would change it algorithm depending on
which type of pack it is operating on. Now the pack wouldn't mix
reference types, they would all be encoded relative or sha1.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: file rename causes history to disappear
From: Junio C Hamano @ 2006-09-07 0:52 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: Linus Torvalds, git
In-Reply-To: <86bqpsvfd3.fsf@blue.stonehenge.com>
merlyn@stonehenge.com (Randal L. Schwartz) writes:
>>>>>> "Junio" == Junio C Hamano <junkio@cox.net> writes:
>
> Junio> The only people who will get burnt by this change are the ones
> Junio> with metacharacters in their pathnames, so it is relative safe
> Junio> change.
>
> But does that mean you'll provide the equivalent to "fgrep" for "grep",
> as in a switch that turns this off, or a seperate command?
>
> I can think of times when I might be trying to track a file with a square
> bracket in the name.
If your path is "foo.c[1]" then "foo.c[1]" as fnmatch() pattern
would not obviously match it, which is sad.
However, we do try to match the path literally before falling
back to fnmatch() so in practice I do not think it is so bad.
$ git ls-files -s ;# everybody has "hello world".
100644 3b18e512dba79e4c8300dd08aeb37f8e728b8dad 0 foo.c
100644 3b18e512dba79e4c8300dd08aeb37f8e728b8dad 0 foo/bar[1]/baz/boa.c
100644 3b18e512dba79e4c8300dd08aeb37f8e728b8dad 0 foo/bar[2].c
$ git grep hello -- 'foo/bar[1]'
foo/bar[1]/baz/boa.c:hello world
$ git grep hello -- 'foo/bar[[]*[]]*'
foo/bar[1]/baz/boa.c:hello world
foo/bar[2].c:hello world
$ git grep hello -- 'fo*'
foo.c:hello world
foo/bar[1]/baz/boa.c:hello world
foo/bar[2].c:hello world
$ exit
^ 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