* [PATCH 5/5] Split out the actual commit creation from the option parsing etc.
From: Kristian Høgsberg @ 2007-07-30 21:28 UTC (permalink / raw)
To: git; +Cc: Kristian Høgsberg
In-Reply-To: <11858309322915-git-send-email-krh@redhat.com>
From: Kristian Høgsberg <krh@redhat.com>
The functionality is available inside git through the function
create_commit().
Signed-off-by: Kristian Høgsberg <krh@redhat.com>
---
builtin-commit-tree.c | 96 ++++++++++++++++++++++++++++++------------------
commit.h | 7 ++++
2 files changed, 67 insertions(+), 36 deletions(-)
diff --git a/builtin-commit-tree.c b/builtin-commit-tree.c
index 72884eb..e20f0b4 100644
--- a/builtin-commit-tree.c
+++ b/builtin-commit-tree.c
@@ -52,15 +52,59 @@ static const char commit_utf8_warn[] =
"You may want to amend it after fixing the message, or set the config\n"
"variable i18n.commitencoding to the encoding your project uses.\n";
+const unsigned char *
+create_commit(const unsigned char *tree_sha1,
+ unsigned char parent_sha1[][20], int parents,
+ const char *author_info, const char *committer_info,
+ const char *message, int length)
+{
+ static unsigned char commit_sha1[20];
+ int encoding_is_utf8, i;
+ struct strbuf sb;
+
+ /* Not having i18n.commitencoding is the same as having utf-8 */
+ encoding_is_utf8 = is_encoding_utf8(git_commit_encoding);
+
+ strbuf_init(&sb);
+ strbuf_printf(&sb, "tree %s\n", sha1_to_hex(tree_sha1));
+
+ /*
+ * NOTE! This ordering means that the same exact tree merged with a
+ * different order of parents will be a _different_ changeset even
+ * if everything else stays the same.
+ */
+ for (i = 0; i < parents; i++)
+ strbuf_printf(&sb, "parent %s\n", sha1_to_hex(parent_sha1[i]));
+
+ /* Person/date information */
+ strbuf_printf(&sb, "author %s\n", author_info);
+ strbuf_printf(&sb, "committer %s\n", committer_info);
+ if (!encoding_is_utf8)
+ strbuf_printf(&sb, "encoding %s\n", git_commit_encoding);
+ strbuf_printf(&sb, "\n");
+
+ /* And add the comment */
+ strbuf_add(&sb, message, length);
+
+ /* And check the encoding */
+ strbuf_add_char(&sb, '\0');
+ if (encoding_is_utf8 && !is_utf8(sb.buf))
+ fprintf(stderr, commit_utf8_warn);
+
+ if (!write_sha1_file(sb.buf, sb.len - 1, commit_type, commit_sha1))
+ return commit_sha1;
+
+ return NULL;
+}
+
int cmd_commit_tree(int argc, const char **argv, const char *prefix)
{
int i;
int parents = 0;
unsigned char tree_sha1[20];
- unsigned char commit_sha1[20];
- char comment[1000];
- struct strbuf sb;
- int encoding_is_utf8;
+ char *buffer;
+ unsigned long len;
+ const unsigned char *commit_sha1;
git_config(git_default_config);
@@ -85,40 +129,20 @@ int cmd_commit_tree(int argc, const char **argv, const char *prefix)
parents++;
}
- /* Not having i18n.commitencoding is the same as having utf-8 */
- encoding_is_utf8 = is_encoding_utf8(git_commit_encoding);
+ buffer = NULL;
+ if (read_fd(0, &buffer, &len))
+ die("Could not read commit message from standard input");
- strbuf_init(&sb);
- strbuf_printf(&sb, "tree %s\n", sha1_to_hex(tree_sha1));
+ commit_sha1 = create_commit(tree_sha1,
+ parent_sha1, parents,
+ xstrdup(git_author_info(1)),
+ xstrdup(git_committer_info(1)),
+ buffer, len);
- /*
- * NOTE! This ordering means that the same exact tree merged with a
- * different order of parents will be a _different_ changeset even
- * if everything else stays the same.
- */
- for (i = 0; i < parents; i++)
- strbuf_printf(&sb, "parent %s\n", sha1_to_hex(parent_sha1[i]));
-
- /* Person/date information */
- strbuf_printf(&sb, "author %s\n", git_author_info(1));
- strbuf_printf(&sb, "committer %s\n", git_committer_info(1));
- if (!encoding_is_utf8)
- strbuf_printf(&sb, "encoding %s\n", git_commit_encoding);
- strbuf_printf(&sb, "\n");
-
- /* And add the comment */
- while (fgets(comment, sizeof(comment), stdin) != NULL)
- strbuf_printf(&sb, "%s", comment);
+ if (!commit_sha1)
+ return 1;
- /* And check the encoding */
- strbuf_add_char(&sb, '\0');
- if (encoding_is_utf8 && !is_utf8(sb.buf))
- fprintf(stderr, commit_utf8_warn);
+ printf("%s\n", sha1_to_hex(commit_sha1));
- if (!write_sha1_file(sb.buf, sb.len - 1, commit_type, commit_sha1)) {
- printf("%s\n", sha1_to_hex(commit_sha1));
- return 0;
- }
- else
- return 1;
+ return 0;
}
diff --git a/commit.h b/commit.h
index 467872e..9f640ba 100644
--- a/commit.h
+++ b/commit.h
@@ -122,4 +122,11 @@ extern struct commit_list *get_shallow_commits(struct object_array *heads,
int depth, int shallow_flag, int not_shallow_flag);
int in_merge_bases(struct commit *, struct commit **, int);
+
+extern const unsigned char *
+create_commit(const unsigned char *tree_sha1,
+ unsigned char parent_sha1[][20], int parents,
+ const char *author_info, const char *committer_info,
+ const char *message, int length);
+
#endif /* COMMIT_H */
--
1.5.2.GIT
^ permalink raw reply related
* [PATCH 4/5] Make builtin-commit-tree use a strbuf instead of hand-rolled realloc buffer.
From: Kristian Høgsberg @ 2007-07-30 21:28 UTC (permalink / raw)
To: git; +Cc: Kristian Høgsberg
In-Reply-To: <11858309322006-git-send-email-krh@redhat.com>
From: Kristian Høgsberg <krh@redhat.com>
With the new strbuf_printf() function we can now just a strbuf for
building up the commit object.
Signed-off-by: Kristian Høgsberg <krh@redhat.com>
---
builtin-commit-tree.c | 57 +++++++++++-------------------------------------
1 files changed, 13 insertions(+), 44 deletions(-)
diff --git a/builtin-commit-tree.c b/builtin-commit-tree.c
index ccbcbe3..72884eb 100644
--- a/builtin-commit-tree.c
+++ b/builtin-commit-tree.c
@@ -8,42 +8,13 @@
#include "tree.h"
#include "builtin.h"
#include "utf8.h"
+#include "strbuf.h"
#define BLOCKING (1ul << 14)
/*
* FIXME! Share the code with "write-tree.c"
*/
-static void init_buffer(char **bufp, unsigned int *sizep)
-{
- *bufp = xmalloc(BLOCKING);
- *sizep = 0;
-}
-
-static void add_buffer(char **bufp, unsigned int *sizep, const char *fmt, ...)
-{
- char one_line[2048];
- va_list args;
- int len;
- unsigned long alloc, size, newsize;
- char *buf;
-
- va_start(args, fmt);
- len = vsnprintf(one_line, sizeof(one_line), fmt, args);
- va_end(args);
- size = *sizep;
- newsize = size + len + 1;
- alloc = (size + 32767) & ~32767;
- buf = *bufp;
- if (newsize > alloc) {
- alloc = (newsize + 32767) & ~32767;
- buf = xrealloc(buf, alloc);
- *bufp = buf;
- }
- *sizep = newsize - 1;
- memcpy(buf + size, one_line, len);
-}
-
static void check_valid(unsigned char *sha1, enum object_type expect)
{
enum object_type type = sha1_object_info(sha1, NULL);
@@ -88,8 +59,7 @@ int cmd_commit_tree(int argc, const char **argv, const char *prefix)
unsigned char tree_sha1[20];
unsigned char commit_sha1[20];
char comment[1000];
- char *buffer;
- unsigned int size;
+ struct strbuf sb;
int encoding_is_utf8;
git_config(git_default_config);
@@ -118,8 +88,8 @@ int cmd_commit_tree(int argc, const char **argv, const char *prefix)
/* Not having i18n.commitencoding is the same as having utf-8 */
encoding_is_utf8 = is_encoding_utf8(git_commit_encoding);
- init_buffer(&buffer, &size);
- add_buffer(&buffer, &size, "tree %s\n", sha1_to_hex(tree_sha1));
+ strbuf_init(&sb);
+ strbuf_printf(&sb, "tree %s\n", sha1_to_hex(tree_sha1));
/*
* NOTE! This ordering means that the same exact tree merged with a
@@ -127,26 +97,25 @@ int cmd_commit_tree(int argc, const char **argv, const char *prefix)
* if everything else stays the same.
*/
for (i = 0; i < parents; i++)
- add_buffer(&buffer, &size, "parent %s\n", sha1_to_hex(parent_sha1[i]));
+ strbuf_printf(&sb, "parent %s\n", sha1_to_hex(parent_sha1[i]));
/* Person/date information */
- add_buffer(&buffer, &size, "author %s\n", git_author_info(1));
- add_buffer(&buffer, &size, "committer %s\n", git_committer_info(1));
+ strbuf_printf(&sb, "author %s\n", git_author_info(1));
+ strbuf_printf(&sb, "committer %s\n", git_committer_info(1));
if (!encoding_is_utf8)
- add_buffer(&buffer, &size,
- "encoding %s\n", git_commit_encoding);
- add_buffer(&buffer, &size, "\n");
+ strbuf_printf(&sb, "encoding %s\n", git_commit_encoding);
+ strbuf_printf(&sb, "\n");
/* And add the comment */
while (fgets(comment, sizeof(comment), stdin) != NULL)
- add_buffer(&buffer, &size, "%s", comment);
+ strbuf_printf(&sb, "%s", comment);
/* And check the encoding */
- buffer[size] = '\0';
- if (encoding_is_utf8 && !is_utf8(buffer))
+ strbuf_add_char(&sb, '\0');
+ if (encoding_is_utf8 && !is_utf8(sb.buf))
fprintf(stderr, commit_utf8_warn);
- if (!write_sha1_file(buffer, size, commit_type, commit_sha1)) {
+ if (!write_sha1_file(sb.buf, sb.len - 1, commit_type, commit_sha1)) {
printf("%s\n", sha1_to_hex(commit_sha1));
return 0;
}
--
1.5.2.GIT
^ permalink raw reply related
* [PATCH 3/5] Add strbuf_printf() to do formatted printing to a strbuf.
From: Kristian Høgsberg @ 2007-07-30 21:28 UTC (permalink / raw)
To: git; +Cc: Kristian Høgsberg
In-Reply-To: <11858309311728-git-send-email-krh@redhat.com>
From: Kristian Høgsberg <krh@redhat.com>
Also, expose strbuf_add() and strbuf_add_char() to add raw data to the buffer.
Signed-off-by: Kristian Høgsberg <krh@redhat.com>
---
strbuf.c | 37 +++++++++++++++++++++++++++++++------
strbuf.h | 3 +++
2 files changed, 34 insertions(+), 6 deletions(-)
diff --git a/strbuf.c b/strbuf.c
index e33d06b..a0539db 100644
--- a/strbuf.c
+++ b/strbuf.c
@@ -11,16 +11,28 @@ static void strbuf_begin(struct strbuf *sb) {
strbuf_init(sb);
}
-static void inline strbuf_add(struct strbuf *sb, int ch) {
- if (sb->alloc <= sb->len) {
+static void inline strbuf_grow(struct strbuf *sb, size_t extra)
+{
+ while (sb->alloc < sb->len + extra)
sb->alloc = sb->alloc * 3 / 2 + 16;
- sb->buf = xrealloc(sb->buf, sb->alloc);
- }
+ sb->buf = xrealloc(sb->buf, sb->alloc);
+}
+
+void strbuf_add(struct strbuf *sb, const char *data, size_t len)
+{
+ strbuf_grow(sb, len);
+ memcpy(sb->buf + sb->len, data, len);
+ sb->len += len;
+}
+
+void strbuf_add_char(struct strbuf *sb, int ch)
+{
+ strbuf_grow(sb, 1);
sb->buf[sb->len++] = ch;
}
static void strbuf_end(struct strbuf *sb) {
- strbuf_add(sb, 0);
+ strbuf_add_char(sb, 0);
}
void read_line(struct strbuf *sb, FILE *fp, int term) {
@@ -33,9 +45,22 @@ void read_line(struct strbuf *sb, FILE *fp, int term) {
while ((ch = fgetc(fp)) != EOF) {
if (ch == term)
break;
- strbuf_add(sb, ch);
+ strbuf_add_char(sb, ch);
}
if (ch == EOF && sb->len == 0)
sb->eof = 1;
strbuf_end(sb);
}
+
+void strbuf_printf(struct strbuf *sb, const char *fmt, ...)
+{
+ char one_line[2048];
+ va_list args;
+ int len;
+
+ va_start(args, fmt);
+ len = vsnprintf(one_line, sizeof(one_line), fmt, args);
+ va_end(args);
+ strbuf_add(sb, one_line, len);
+}
+
diff --git a/strbuf.h b/strbuf.h
index 74cc012..1e5d09e 100644
--- a/strbuf.h
+++ b/strbuf.h
@@ -9,5 +9,8 @@ struct strbuf {
extern void strbuf_init(struct strbuf *);
extern void read_line(struct strbuf *, FILE *, int);
+extern void strbuf_add(struct strbuf *sb, const char *data, size_t len);
+extern void strbuf_add_char(struct strbuf *sb, int ch);
+extern void strbuf_printf(struct strbuf *sb, const char *fmt, ...);
#endif /* STRBUF_H */
--
1.5.2.GIT
^ permalink raw reply related
* [PATCH 2/5] Enable wt-status output to a given FILE pointer.
From: Kristian Høgsberg @ 2007-07-30 21:28 UTC (permalink / raw)
To: git; +Cc: Kristian Høgsberg
In-Reply-To: <11858309261111-git-send-email-krh@redhat.com>
From: Kristian Høgsberg <krh@redhat.com>
Still defaults to stdout, but you can now override wt_status.fp after
calling wt_status_prepare().
Signed-off-by: Kristian Høgsberg <krh@redhat.com>
---
color.c | 18 ++++++------
color.h | 4 +-
wt-status.c | 85 ++++++++++++++++++++++++++++++----------------------------
wt-status.h | 3 ++
4 files changed, 58 insertions(+), 52 deletions(-)
diff --git a/color.c b/color.c
index 09d82ee..124ba33 100644
--- a/color.c
+++ b/color.c
@@ -135,39 +135,39 @@ int git_config_colorbool(const char *var, const char *value)
return git_config_bool(var, value);
}
-static int color_vprintf(const char *color, const char *fmt,
+static int color_vfprintf(FILE *fp, const char *color, const char *fmt,
va_list args, const char *trail)
{
int r = 0;
if (*color)
- r += printf("%s", color);
- r += vprintf(fmt, args);
+ r += fprintf(fp, "%s", color);
+ r += vfprintf(fp, fmt, args);
if (*color)
- r += printf("%s", COLOR_RESET);
+ r += fprintf(fp, "%s", COLOR_RESET);
if (trail)
- r += printf("%s", trail);
+ r += fprintf(fp, "%s", trail);
return r;
}
-int color_printf(const char *color, const char *fmt, ...)
+int color_fprintf(FILE *fp, const char *color, const char *fmt, ...)
{
va_list args;
int r;
va_start(args, fmt);
- r = color_vprintf(color, fmt, args, NULL);
+ r = color_vfprintf(fp, color, fmt, args, NULL);
va_end(args);
return r;
}
-int color_printf_ln(const char *color, const char *fmt, ...)
+int color_fprintf_ln(FILE *fp, const char *color, const char *fmt, ...)
{
va_list args;
int r;
va_start(args, fmt);
- r = color_vprintf(color, fmt, args, "\n");
+ r = color_vfprintf(fp, color, fmt, args, "\n");
va_end(args);
return r;
}
diff --git a/color.h b/color.h
index 88bb8ff..6809800 100644
--- a/color.h
+++ b/color.h
@@ -6,7 +6,7 @@
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, ...);
-int color_printf_ln(const char *color, const char *fmt, ...);
+int color_fprintf(FILE *fp, const char *color, const char *fmt, ...);
+int color_fprintf_ln(FILE *fp, const char *color, const char *fmt, ...);
#endif /* COLOR_H */
diff --git a/wt-status.c b/wt-status.c
index 5205420..65a7259 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -52,31 +52,33 @@ void wt_status_prepare(struct wt_status *s)
head = resolve_ref("HEAD", sha1, 0, NULL);
s->branch = head ? xstrdup(head) : NULL;
s->reference = "HEAD";
+ s->fp = stdout;
}
-static void wt_status_print_cached_header(const char *reference)
+static void wt_status_print_cached_header(struct wt_status *s)
{
const char *c = color(WT_STATUS_HEADER);
- color_printf_ln(c, "# Changes to be committed:");
- if (reference) {
- color_printf_ln(c, "# (use \"git reset %s <file>...\" to unstage)", reference);
+ color_fprintf_ln(s->fp, c, "# Changes to be committed:");
+ if (s->reference) {
+ color_fprintf_ln(s->fp, c, "# (use \"git reset %s <file>...\" to unstage)", s->reference);
} else {
- color_printf_ln(c, "# (use \"git rm --cached <file>...\" to unstage)");
+ color_fprintf_ln(s->fp, c, "# (use \"git rm --cached <file>...\" to unstage)");
}
- color_printf_ln(c, "#");
+ color_fprintf_ln(s->fp, c, "#");
}
-static void wt_status_print_header(const char *main, const char *sub)
+static void wt_status_print_header(struct wt_status *s,
+ const char *main, const char *sub)
{
const char *c = color(WT_STATUS_HEADER);
- color_printf_ln(c, "# %s:", main);
- color_printf_ln(c, "# (%s)", sub);
- color_printf_ln(c, "#");
+ color_fprintf_ln(s->fp, c, "# %s:", main);
+ color_fprintf_ln(s->fp, c, "# (%s)", sub);
+ color_fprintf_ln(s->fp, c, "#");
}
-static void wt_status_print_trailer(void)
+static void wt_status_print_trailer(struct wt_status *s)
{
- color_printf_ln(color(WT_STATUS_HEADER), "#");
+ color_fprintf_ln(s->fp, color(WT_STATUS_HEADER), "#");
}
static const char *quote_crlf(const char *in, char *buf, size_t sz)
@@ -108,7 +110,8 @@ static const char *quote_crlf(const char *in, char *buf, size_t sz)
return ret;
}
-static void wt_status_print_filepair(int t, struct diff_filepair *p)
+static void wt_status_print_filepair(struct wt_status *s,
+ int t, struct diff_filepair *p)
{
const char *c = color(t);
const char *one, *two;
@@ -117,36 +120,36 @@ static void wt_status_print_filepair(int t, struct diff_filepair *p)
one = quote_crlf(p->one->path, onebuf, sizeof(onebuf));
two = quote_crlf(p->two->path, twobuf, sizeof(twobuf));
- color_printf(color(WT_STATUS_HEADER), "#\t");
+ color_fprintf(s->fp, color(WT_STATUS_HEADER), "#\t");
switch (p->status) {
case DIFF_STATUS_ADDED:
- color_printf(c, "new file: %s", one);
+ color_fprintf(s->fp, c, "new file: %s", one);
break;
case DIFF_STATUS_COPIED:
- color_printf(c, "copied: %s -> %s", one, two);
+ color_fprintf(s->fp, c, "copied: %s -> %s", one, two);
break;
case DIFF_STATUS_DELETED:
- color_printf(c, "deleted: %s", one);
+ color_fprintf(s->fp, c, "deleted: %s", one);
break;
case DIFF_STATUS_MODIFIED:
- color_printf(c, "modified: %s", one);
+ color_fprintf(s->fp, c, "modified: %s", one);
break;
case DIFF_STATUS_RENAMED:
- color_printf(c, "renamed: %s -> %s", one, two);
+ color_fprintf(s->fp, c, "renamed: %s -> %s", one, two);
break;
case DIFF_STATUS_TYPE_CHANGED:
- color_printf(c, "typechange: %s", one);
+ color_fprintf(s->fp, c, "typechange: %s", one);
break;
case DIFF_STATUS_UNKNOWN:
- color_printf(c, "unknown: %s", one);
+ color_fprintf(s->fp, c, "unknown: %s", one);
break;
case DIFF_STATUS_UNMERGED:
- color_printf(c, "unmerged: %s", one);
+ color_fprintf(s->fp, c, "unmerged: %s", one);
break;
default:
die("bug: unhandled diff status %c", p->status);
}
- printf("\n");
+ fprintf(s->fp, "\n");
}
static void wt_status_print_updated_cb(struct diff_queue_struct *q,
@@ -160,14 +163,14 @@ static void wt_status_print_updated_cb(struct diff_queue_struct *q,
if (q->queue[i]->status == 'U')
continue;
if (!shown_header) {
- wt_status_print_cached_header(s->reference);
+ wt_status_print_cached_header(s);
s->commitable = 1;
shown_header = 1;
}
- wt_status_print_filepair(WT_STATUS_UPDATED, q->queue[i]);
+ wt_status_print_filepair(s, WT_STATUS_UPDATED, q->queue[i]);
}
if (shown_header)
- wt_status_print_trailer();
+ wt_status_print_trailer(s);
}
static void wt_status_print_changed_cb(struct diff_queue_struct *q,
@@ -184,12 +187,12 @@ static void wt_status_print_changed_cb(struct diff_queue_struct *q,
msg = use_add_rm_msg;
break;
}
- wt_status_print_header("Changed but not updated", msg);
+ wt_status_print_header(s, "Changed but not updated", msg);
}
for (i = 0; i < q->nr; i++)
- wt_status_print_filepair(WT_STATUS_CHANGED, q->queue[i]);
+ wt_status_print_filepair(s, WT_STATUS_CHANGED, q->queue[i]);
if (q->nr)
- wt_status_print_trailer();
+ wt_status_print_trailer(s);
}
static void wt_read_cache(struct wt_status *s)
@@ -206,16 +209,16 @@ static void wt_status_print_initial(struct wt_status *s)
wt_read_cache(s);
if (active_nr) {
s->commitable = 1;
- wt_status_print_cached_header(NULL);
+ wt_status_print_cached_header(s);
}
for (i = 0; i < active_nr; i++) {
- color_printf(color(WT_STATUS_HEADER), "#\t");
- color_printf_ln(color(WT_STATUS_UPDATED), "new file: %s",
+ color_fprintf(s->fp, color(WT_STATUS_HEADER), "#\t");
+ color_fprintf_ln(s->fp, color(WT_STATUS_UPDATED), "new file: %s",
quote_crlf(active_cache[i]->name,
buf, sizeof(buf)));
}
if (active_nr)
- wt_status_print_trailer();
+ wt_status_print_trailer(s);
}
static void wt_status_print_updated(struct wt_status *s)
@@ -281,12 +284,12 @@ static void wt_status_print_untracked(struct wt_status *s)
}
if (!shown_header) {
s->workdir_untracked = 1;
- wt_status_print_header("Untracked files",
+ wt_status_print_header(s, "Untracked files",
use_add_to_include_msg);
shown_header = 1;
}
- color_printf(color(WT_STATUS_HEADER), "#\t");
- color_printf_ln(color(WT_STATUS_UNTRACKED), "%.*s",
+ color_fprintf(s->fp, color(WT_STATUS_HEADER), "#\t");
+ color_fprintf_ln(s->fp, color(WT_STATUS_UNTRACKED), "%.*s",
ent->len, ent->name);
}
}
@@ -316,14 +319,14 @@ void wt_status_print(struct wt_status *s)
branch_name = "";
on_what = "Not currently on any branch.";
}
- color_printf_ln(color(WT_STATUS_HEADER),
+ color_fprintf_ln(s->fp, color(WT_STATUS_HEADER),
"# %s%s", on_what, branch_name);
}
if (s->is_initial) {
- color_printf_ln(color(WT_STATUS_HEADER), "#");
- color_printf_ln(color(WT_STATUS_HEADER), "# Initial commit");
- color_printf_ln(color(WT_STATUS_HEADER), "#");
+ color_fprintf_ln(s->fp, color(WT_STATUS_HEADER), "#");
+ color_fprintf_ln(s->fp, color(WT_STATUS_HEADER), "# Initial commit");
+ color_fprintf_ln(s->fp, color(WT_STATUS_HEADER), "#");
wt_status_print_initial(s);
}
else {
@@ -337,7 +340,7 @@ void wt_status_print(struct wt_status *s)
wt_status_print_verbose(s);
if (!s->commitable) {
if (s->amend)
- printf("# No changes\n");
+ fprintf(s->fp, "# No changes\n");
else if (s->workdir_dirty)
printf("no changes added to commit (use \"git add\" and/or \"git commit -a\")\n");
else if (s->workdir_untracked)
diff --git a/wt-status.h b/wt-status.h
index cfea4ae..4f3a615 100644
--- a/wt-status.h
+++ b/wt-status.h
@@ -1,6 +1,8 @@
#ifndef STATUS_H
#define STATUS_H
+#include <stdio.h>
+
enum color_wt_status {
WT_STATUS_HEADER,
WT_STATUS_UPDATED,
@@ -19,6 +21,7 @@ struct wt_status {
int commitable;
int workdir_dirty;
int workdir_untracked;
+ FILE *fp;
};
int git_status_config(const char *var, const char *value);
--
1.5.2.GIT
^ permalink raw reply related
* [PATCH 1/5] Add test case for basic commit functionality.
From: Kristian Høgsberg @ 2007-07-30 21:28 UTC (permalink / raw)
To: git; +Cc: Kristian Høgsberg
Signed-off-by: Kristian Høgsberg <krh@redhat.com>
---
t/t7501-commit.sh | 126 +++++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 126 insertions(+), 0 deletions(-)
create mode 100644 t/t7501-commit.sh
diff --git a/t/t7501-commit.sh b/t/t7501-commit.sh
new file mode 100644
index 0000000..eba19da
--- /dev/null
+++ b/t/t7501-commit.sh
@@ -0,0 +1,126 @@
+#!/bin/sh
+#
+# Copyright (c) 2007 Kristian Høgsberg <krh@redhat.com>
+#
+
+# FIXME: Test the various index usages, -i and -o, test reflog,
+# signoff, hooks
+
+test_description='git-commit'
+. ./test-lib.sh
+
+# Pick a date so we get consistent commits. 7/7/07 means good luck!
+export GIT_AUTHOR_DATE="July 7, 2007"
+export GIT_COMMITTER_DATE="July 7, 2007"
+
+echo "bongo bongo" >file
+test_expect_success \
+ "initial status" \
+ "git-add file && \
+ git-status | grep 'Initial commit'"
+
+test_expect_failure \
+ "fail initial amend" \
+ "git-commit -m initial --amend"
+
+test_expect_success \
+ "initial commit" \
+ "git-commit -m initial"
+
+test_expect_failure \
+ "testing nothing to commit" \
+ "git-commit -m initial"
+
+echo "bongo bongo bongo" >file
+
+test_expect_success \
+ "next commit" \
+ "git-commit -m next -a"
+
+echo "more bongo: bongo bongo bongo bongo" >file
+
+test_expect_failure \
+ "commit message from non-existing file" \
+ "git-commit -F gah -a"
+
+cat >msg <<EOF
+
+
+
+Signed-off-by: hula
+EOF
+test_expect_failure \
+ "empty commit message" \
+ "git-commit -F msg -a"
+
+echo "this is the commit message, coming from a file" >msg
+test_expect_success \
+ "commit message from file" \
+ "git-commit -F msg -a"
+
+cat >editor <<\EOF
+#!/bin/sh
+sed -i -e "s/a file/an amend commit/g" $1
+EOF
+chmod 755 editor
+
+test_expect_success \
+ "amend commit" \
+ "VISUAL=./editor git-commit --amend"
+
+echo "enough with the bongos" >file
+test_expect_failure \
+ "passing --amend and -F" \
+ "git-commit -F msg --amend ."
+
+test_expect_success \
+ "using message from other commit" \
+ "git-commit -C HEAD^ ."
+
+cat >editor <<\EOF
+#!/bin/sh
+sed -i -e "s/amend/older/g" $1
+EOF
+chmod 755 editor
+
+echo "hula hula" >file
+test_expect_success \
+ "editing message from other commit" \
+ "VISUAL=./editor git-commit -c HEAD^ -a"
+
+echo "silly new contents" >file
+test_expect_success \
+ "message from stdin" \
+ "echo commit message from stdin | git-commit -F - -a"
+
+echo "gak" >file
+test_expect_success \
+ "overriding author from command line" \
+ "git-commit -m 'author' --author 'Rubber Duck <rduck@convoy.org>' -a"
+
+test_expect_success \
+ "interactive add" \
+ "echo 7 | git-commit --interactive | grep 'What now'"
+
+test_expect_success \
+ "showing committed revisions" \
+ "git-rev-list HEAD >current"
+
+# We could just check the head sha1, but checking each commit makes it
+# easier to isolate bugs.
+
+cat >expected <<\EOF
+b19013342b676054179a1685d62b07f56b354331
+763fd16cd476920986129b09672915be44847d90
+b97ce6debb52cbb541d798ce4c2cefa3c9f20332
+720cebf2e443885c6325a0a602ddb9922376452c
+19db513255cc049feee9c107e60297a48c6b0df4
+4cd324560cd9dcac18f17bac227b17238ad458f9
+821776fc6a0699927268feb5e157d245cdcd102a
+EOF
+
+test_expect_success \
+ 'validate git-rev-list output.' \
+ 'diff current expected'
+
+test_done
--
1.5.2.GIT
^ permalink raw reply related
* Re: Efficient way to import snapshots?
From: Junio C Hamano @ 2007-07-30 21:29 UTC (permalink / raw)
To: Craig Boston; +Cc: Linus Torvalds, Git Mailing List
In-Reply-To: <20070730201023.GC64467@nowhere>
Craig Boston <craig@olyun.gank.org> writes:
> 1) Have a separate repository clone for each branch that I want to
> import to and leave that branch permanently checked out. I lose the
> disk space for N working copies, but on the server I'm doing the import
> on, it's not a huge issue, especially with ZFS compression ;-)
>
> * This might not actually be so bad if I put the .git directory inside
> of the CVS checkout directory and used it as my "working copy". I
> just need to insure that git doesn't create any additional files in
> there, as cvsup is really picky about not deleting files that it
> didn't create, even if they were removed from CVS.
With one of the projects hosted on CVS I have to interoperate
with, that is what I do. For historical reasons I do not use
git-cvsimport/exportcommit for this one, but basically:
- "cvs co" to prime the working tree;
- "echo CVS >.gitignore";
- "git init && git add . && git commit";
- "git checkout -b mine";
then I work in "mine" branch. When other people have something
to say, I do:
- "git checkout master";
- "cvs up";
- "git add <whatever was added with the above cvs up>";
- "git commit -a";
- "git rebase master mine";
When feeding my own changes back to CVS, I would:
- "git checkout master";
- "cvs up" to make sure other people do not have any stuff;
- "git show-branch master mine" to see what I have;
- "git cherry-pick <whatever the change I want to feed back>";
- "cvs commit";
- repeat the last two steps for all the changes I want;
- "git rebase master mine";
I only need to make sure not to commit on "master", and not to
run "cvs up" while on "mine".
This can be extended to more than one CVS branches by using
different branches than "master".
> 2) Have one repository clone that gets re-used for each import, with the
> "checked out" branch getting changed before the import. As far as I can
> tell this means suffering the "git checkout" overhead for 30,000 files,
> which is conceptually inefficient but in real time only a minute or so.
That should only be "conceptually" in fact, as switching between
branches should not touch paths that are the same between
branches.
^ permalink raw reply
* Re: [RFC] Git User's Survey 2007
From: Nguyen Thai Ngoc Duy @ 2007-07-30 21:25 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Paolo Ciarrocchi
In-Reply-To: <200707271320.06313.jnareb@gmail.com>
On 7/27/07, Jakub Narebski <jnareb@gmail.com> wrote:
> It's been more than a year since last Git User's Survey. It would be
> interesting to find what changed since then. Therefore the idea to
> have another survey.
I am probably going a little far here. I think we should include
briefly in the survey announcement what git has achieved since the
last survey. We want to know what changed from users. Maybe users also
want to know what changed from git since then. Also it would be good
advertisement if it gets posted on online magazines and popular sites.
--
Duy
^ permalink raw reply
* Re: Efficient way to import snapshots?
From: Jakub Narebski @ 2007-07-30 21:22 UTC (permalink / raw)
To: git
In-Reply-To: <alpine.LFD.0.999.0707301144180.4161@woody.linux-foundation.org>
Linus Torvalds wrote:
> On Mon, 30 Jul 2007, Craig Boston wrote:
>>
>> So far the main snag I've found is that AFAIK there's no equivalent to
>> "svk import" to load a big tree (~37000 files) into a branch and commit
>> the changes. Here's the procedure I've come up with:
>>
>> cd /path/to/git/repo
>> git checkout vendor_branch_X
>> git rm -r .
>> cp -R /path/to/cvs/checkout_X/* ./
>> git add .
>> git commit -m"Import yyyymmdd snapshot"
>
> Ouch.
>
> What you want to do should fit git very well, but doing it that way is
> quite expensive.
>
> Might I suggest just doing the .git thing *directly* in the CVS checkout
> instead?
[...]
And you can try to use git-fast-import. Check out
contrib/fast-import/import-tars.perl script (adapting it to your purpose).
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* [RFC (take 2) Git User's Survey 2007
From: Jakub Narebski @ 2007-07-30 20:56 UTC (permalink / raw)
To: git; +Cc: Paolo Ciarrocchi
In-Reply-To: <200707250358.58637.jnareb@gmail.com>
It's been more than a year since last Git User's Survey. It would be
interesting to find what changed since then. Therefore the idea to
have another survey.
First there is a question about the form of survey. Should we use web
based survey, as the survey before (http://www.survey.net.nz), sending
emails with link to this survey, or perhaps do email based survey,
with email Reply-To: address put for this survey alone?
Second, what questions should be put in the survey, and in the case of
single choice and multiple choice questions what possible answers
should be? Below are slightly extended questions from the last
survey. Please comment on it.
Third, where to send survey to? I was thinking about git mailing list,
LKML, and mailing list for git projects found on GitProjects page on
GIT wiki. Do you want to add some address? Or should info about GIT
User's Survey 2007 be sent also to one of on-line magazines like
LinuxToday, or asked to put on some blog?
Those lists include:
wine-users, xmms2-devel, xcb (freedesktop), cairo, u-boot-users,
git mailing list, lklm (thanks to Paolo Ciarrocchi)
LWN, NewsForge, Slashdot, OSNews,
Those lists might include:
CRUX Linux, Source Mage Linux, DirectFB, GNU LilyPond, OLPC,
Thousands Parsec, X.Org, Mesa3D,
Other possibilities:
OpenOffice.org, Mozilla, SeaMonkey, KDE, GNOME
References:
http://marc.info/?l=git&m=115116592330648&w=2
http://marc.info/?l=git&m=115364303813936&w=2
http://git.or.cz/gitwiki/GitSurvey
----
About you
1. What country are you in?
2. What is your preferred non-programming language?
3. Which programming languages you are proficient with?
(The choices include programming languages used by git)
(zero or more: multiple choice)
- C, shell, Perl, Python, Tcl/Tk
4. How old are you?
Getting started with GIT
1. How did you hear about GIT?
2. Did you find GIT easy to learn?
- very easy/easy/reasonably/hard/very hard
3. What helped you most in learning to use it?
4. What did you find hardest?
5. When did you start using git? From which version?
* (date, or version, or both)
Other SCMs
1. What other SCM did you use?
2. What other SCM do you use currently?
3. What other SCM do you use as a main SCM for your project
instead of git, if any?
4. Why did you choose this SCM?
* example: better MS Windows support
5. What would you require from git to enable you to change,
if you use other SCM for your project?
6. Did you import your repository from foreign SCM?
7. What toold did you use for import?
8. Do your git repository interact with other SCM?
9. What tool did/do you use?
How you use GIT
1. Do you use GIT for work, unpaid projects, or both?
work/unpaid projects/both/none(*)
(*)I use git to interact with some project I'm interested in
2. How do you obtain GIT? Source tarball, binary package, or
pull the main repository?
- binary package/source tarball/pull from main repository
3. What hardware platforms do you use GIT on?
* examples: i386, x86_64, ARM, PowerPC, Alpha, g5, ...
4. What OS (please include the version) do you use GIT on?
* examples: Linux, MS Windows (Cygwin/MinGW/gitbox),
IRIX, HP-UX, Solaris, FreeBSD, ...
(please give kernel version and distribution for Linux)
5. How many people do you collaborate with using GIT?
6. How big are the repositories that you work on? (e.g. how many
files, how much disk space, how deep is the history?)
* number of files in repository: "git ls-tree -r HEAD | wc -l"
* largest file under version control
* pack size of freshly cloned fully packed repository
* number of commits in straight line, number of commits in branch
("git rev-list --first-parent HEAD | wc -l",
"git rev-list HEAD | wc -l")
7. How many different projects do you manage using GIT?
8. Which porcelains do you use?
(zero or more: multiple choice)
- core-git, cogito, StGIT, pg, guilt, egit (Eclipse), other
9. Which git GUI do you use
(zero or more: multiple choice)
- gitk, git-gui, qgit, gitview, giggle, tig, instaweb,
(h)gct, qct, KGit, other
10. Which (main) git web interface do you use for your projects?
- gitweb/cgit/wit (Ruby)/git-php/other
11. How do you publish/propagate your changes?
(zero or more: multiple choice)
- push, pull request, format-patch + email, bundle, other
12. Does git.git repository include code produced by you?
- yes/no
Internationalization
1. Is translating GIT required for wider adoption?
- yes/no/somewhat
2. What do you need translated?
* examples: git-gui, qgit, messages, manpages, user's manual
3. For what language do you need translation for?
What you think of GIT
1. Overall, how happy are you with GIT?
- unhappy/not so happy/happy/very happy/completely ecstatic
2. How does GIT compare to other SCM tools you have used?
- worse/equal (or comparable)/better
3. What do you like about using GIT?
4. What would you most like to see improved about GIT?
(features, bugs, plug-ins, documentation, ...)
5. If you want to see GIT more widely used, what do you
think we could do to make this happen?
Changes in GIT (since year ago, or since you started using it)
0. Did you participate in previous Git User's Survey?
- yes/no
1. What improvements you wanted got implemented?
2. What improvements you wanted didn't get implemented?
3. How do you compare current version iwth version from year ago?
- current version is: better/worse/no changes
4. Which of the new features do you use?
(zero or more: multiple choice)
- git-gui, bundle, eol conversion, gitattributes,
submodules, worktree, release notes, user's manual,
reflog, stash, shallow clone, detached HEAD, fast-import,
mergetool, other (not mentioned here)
5. If you selected "other", what are those features?
Documentation
1. Do you use the GIT wiki?
- yes/no
2. Do you find GIT wiki useful?
- yes/no/somewhat
3. Do you contribute to GIT wiki?
- yes/no/only corrections or spam removal
4. Do you find GIT's on-line help (homepage, documentation) useful?
- yes/no/somewhat
5. Do you find help distributed with GIT useful
(manpages, manual, tutorial, HOWTO, release notes)?
- yes/no/somewhat
6. Do you contribute to GIT documentation?
- yes/no
7. What could be improved on the GIT homepage?
8. What topics would you like to have on GIT wiki?
Getting help, staying in touch
1. Have you tried to get GIT help from other people?
- yes/no
2. If yes, did you get these problems resolved quickly
and to your liking?
- yes/no
3. Do you subscribe to the mailing list?
- yes/no
4. Do you read the mailing list? What method do you use?
- subscribed/news interface/RSS interface/archives/
/post + reply-to request/digests/I don't read it
5. If yes, do you find it useful?
- yes/no (optional)
6. Do you find traffic levels on GIT mailing list OK.
- yes/no? (optional)
7. Do you use the IRC channel (#git on irc.freenode.net)?
- yes/no
8. If yes, do you find IRC channel useful?
- yes/no (optional)
Open forum
1. What other comments or suggestions do you have that are not
covered by the questions above?
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [RFC] Git User's Survey 2007
From: Jakub Narebski @ 2007-07-30 13:40 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Paolo Ciarrocchi, git
In-Reply-To: <20070730033543.GP20052@spearce.org>
Shawn O. Pearce wrote:
> Jakub Narebski <jnareb@gmail.com> wrote:
>> Paolo Ciarrocchi wrote:
>>> git-gui ?
>>>
>>>> 9. Which git GUI do you use
>>>> (zero or more: multiple choice)
>>>> - gitk, git-gui, qgit, gitview, giggle, other
>> tig, instaweb, (h)gct, qct, KGit
>>
>> I consider git-gui an UI (like qgit or tig), not a porcelain. To be
>> a porcelains tool need to add some SCM functionality not present in
>> git-core.
>
> Odd. I consider git-gui to be a porcelain, just as I consider
> tig and qgit to also be porcelain. Though I think git-gui is more
> of a porcelain than the others, as it tries to rely *less* on the
> core porcelain and just on the plumbing. I don't always succeed,
> but I'm heading in that direction.
>
> To me a porcelain is any tool that layers over the plumbing and makes
> it easier for the end-user to operate it. Early git only had things
> like read-tree/write-tree/commit-tree. Tying that all up into a neat
> "Commit" command for the end-user is the job of porcelain.
>
> Anyway. Just so long as git-gui is included in the survey. I'm
> interested in seeing how many people use it, because I know it has
> a pretty decently sized userbase. Which is probably going to grow
> in the future with the i18n work going on.
Well, if we use the notion that porcelain are tools which provide
high level access to core git, making SCM from git plumbing, then
being porcelain and being git UI are not mutually exclusive.
Nevertheless I'd rather keep them separate, and put git-gui in UI
camp, while egit (which I have forgot about) in the porcelain camp.
Or should I use "version control interface layers" instead of
"porcelains"?
> Do we have any questions in the survey about the user's native
> language? About their desire to have git translated into their
> native language? Folks are now working on translating git-gui,
> and that work will be in git-gui 0.9.x, if not 0.8.1/2. So it may
> be nice to know what languages our users are interested in.
----
About you
1. What country are you in?
2. What is your preferred non-programming language?
[...]
Internationalization
1. Is translating GIT required for wider adoption?
- yes/no/somewhat
2. What do you need translated?
(zero or more: multiple choice)
- GUI (git-gui, gitk, qgit, ...), git-core messages,
manpages, other documentation
3. For what language do you need translation for?
----
Do you want other questions about internationalization and translating
git into one's native language?
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [RFC] Git User's Survey 2007
From: Jakub Narebski @ 2007-07-30 13:26 UTC (permalink / raw)
To: Paolo Ciarrocchi; +Cc: git
In-Reply-To: <4d8e3fd30707300044l79133442of45b37a8192f7bca@mail.gmail.com>
Paolo Ciarrocchi wrote:
> On 7/30/07, Jakub Narebski <jnareb@gmail.com> wrote:
>> Paolo Ciarrocchi wrote:
>>> On 7/27/07, Jakub Narebski <jnareb@gmail.com> wrote:
>>>> Third, where to send survey to? I was thinking about git mailing list,
>>>> LKML, and mailing list for git projects found on GitProjects page on
>>>> GIT wiki. Do you want to add some address? Or should info about GIT
>>>> User's Survey 2007 be sent also to one of on-line magazines like
>>>> LinuxToday, or asked to put on some blog?
>>>
>>> I think that one of the mistakes I did when I sent out the first
>>> survey was to not contact any magazines and blog.
>>
>> Any proposals? Besides LWN, NewsForge, Slashdot?
>
> www.osnews.com and I can contact a few Italian portals.
Thanks.
I try to send the information about Git User's Survey 2007
to few Polish Linux-related portals: 7thGuard, LinuxNews.pl,
Linux.pl.
[...]
> Just a general comment, let's try to avoid as much as possible
> multiple questions in a single question. It tends to confuse people
> when they are answering to the survey.
Thanks for the advice. Will apply.
I'll try to send revised version of survey here for final comments,
and try to send survey sometimes next week, with 3-4 weeks time to
fill survey.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [RFC] Git User's Survey 2007
From: Junio C Hamano @ 2007-07-30 21:12 UTC (permalink / raw)
To: David Kastrup; +Cc: Paolo Ciarrocchi, Jakub Narebski, git
In-Reply-To: <85myxdu206.fsf@lola.goethe.zz>
David Kastrup <dak@gnu.org> writes:
> "Paolo Ciarrocchi" <paolo.ciarrocchi@gmail.com> writes:
>
>> Fine with me. Thanks for you work Jakub.
>>
>> Just a general comment, let's try to avoid as much as possible
>> multiple questions in a single question. It tends to confuse people
>> when they are answering to the survey.
>
> I find that the survey lacking in community questions, like
>
> Do you frequently read the mailing list?
> Frequently post?
> Other sources of information?
> How helpful are the answers you get there?
> How pleasant is the atmosphere?
>
> And so on.
Good point, except that "answers" is probably not a community
question but a helpdesk question.
Also if they have visited #git channel at freenode.net might
also belong to this set of questions.
^ permalink raw reply
* Re: Efficient way to import snapshots?
From: Junio C Hamano @ 2007-07-30 21:04 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Craig Boston, Git Mailing List
In-Reply-To: <alpine.LFD.0.999.0707301240330.4161@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> That said, I just noticed something nasty: "git add ." is *horrible*. It
> does the full SHA1 re-computation even though the index is up-to-date.
> That's really nasty.
>
> So right now, due to this performance bug, it's actually much better to do
> something more complex, namely something like
>
> git ls-files -o | git update-index --add --stdin
> git commit -a
>
> which is a lot more efficient than just doing "git add .".
>
> Junio? I _thought_ we already took the index into account with "git add",
> but we obviously don't.
I do not know offhand.
By the way, the above "something more complex" may be a simple
"git add -u".
^ permalink raw reply
* Re: [RFC] per-user ignore file
From: Daniel Barkalow @ 2007-07-30 20:43 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: git
In-Reply-To: <20070730203605.GD2386@fieldses.org>
On Mon, 30 Jul 2007, J. Bruce Fields wrote:
> On Mon, Jul 30, 2007 at 04:28:13PM -0400, Daniel Barkalow wrote:
> > It would be nice to have a per-user ignore file, so that emacs users can
> > ignore "*~", "#*#", and ".#*". Probably this should be in the form of
> > having a config option for additional ignore file names, so that the user
> > can decide where to put it. (E.g., ~/.gitignore would be an issue if the
> > user is tracking their home directory with git and wants to ignore some
> > files in the home directory repository but track similarly named files in
> > some other repository). Are there any fundamental issues with this, or is
> > it just that nobody's been sufficiently motivated to do it?
>
> See 'man gitignore' or
>
> http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#ignoring-files
Ah, I was just looking at too old versions of the documentation.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [RFC] per-user ignore file
From: Jan Hudec @ 2007-07-30 20:41 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0707301612160.8054@iabervon.org>
[-- Attachment #1: Type: text/plain, Size: 1056 bytes --]
On Mon, Jul 30, 2007 at 16:28:13 -0400, Daniel Barkalow wrote:
> It would be nice to have a per-user ignore file, so that emacs users can
> ignore "*~", "#*#", and ".#*". Probably this should be in the form of
> having a config option for additional ignore file names, so that the user
> can decide where to put it. (E.g., ~/.gitignore would be an issue if the
> user is tracking their home directory with git and wants to ignore some
> files in the home directory repository but track similarly named files in
> some other repository). Are there any fundamental issues with this, or is
> it just that nobody's been sufficiently motivated to do it?
I believe the later. Though I also believe it would be useful.
An alternative to separate file would be to include it into .gitconfig
as multi-valued key. Something like:
[core]
ignore = *~
ignore = #*#
ignore = .#*
ignore = .*.sw[nop]
and so on. Could be reused in .git/config as replacement for
.git/info/exclude if desired.
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [RFC] per-user ignore file
From: J. Bruce Fields @ 2007-07-30 20:36 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0707301612160.8054@iabervon.org>
On Mon, Jul 30, 2007 at 04:28:13PM -0400, Daniel Barkalow wrote:
> It would be nice to have a per-user ignore file, so that emacs users can
> ignore "*~", "#*#", and ".#*". Probably this should be in the form of
> having a config option for additional ignore file names, so that the user
> can decide where to put it. (E.g., ~/.gitignore would be an issue if the
> user is tracking their home directory with git and wants to ignore some
> files in the home directory repository but track similarly named files in
> some other repository). Are there any fundamental issues with this, or is
> it just that nobody's been sufficiently motivated to do it?
See 'man gitignore' or
http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#ignoring-files
--b.
^ permalink raw reply
* [RFC] per-user ignore file
From: Daniel Barkalow @ 2007-07-30 20:28 UTC (permalink / raw)
To: git
It would be nice to have a per-user ignore file, so that emacs users can
ignore "*~", "#*#", and ".#*". Probably this should be in the form of
having a config option for additional ignore file names, so that the user
can decide where to put it. (E.g., ~/.gitignore would be an issue if the
user is tracking their home directory with git and wants to ignore some
files in the home directory repository but track similarly named files in
some other repository). Are there any fundamental issues with this, or is
it just that nobody's been sufficiently motivated to do it?
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: Efficient way to import snapshots?
From: Craig Boston @ 2007-07-30 20:10 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <alpine.LFD.0.999.0707301240330.4161@woody.linux-foundation.org>
On Mon, Jul 30, 2007 at 12:52:52PM -0700, Linus Torvalds wrote:
> On Mon, 30 Jul 2007, Craig Boston wrote:
> > 1. Will it notice deleted files?
>
> Yes, although I think you need to do "git commit -a" for that.
Ah, nice. I had underestimated how smart git is, that was the whole
reason I did the 'git rm -r .' dance at first :-)
> > 2. How can I tell it what branch to commit to?
>
> Whatever branch is checked out in the GIT_DIR will be the one that it
> commits to.
Hmm, ok. I tried it out and it was unhappy with GIT_DIR pointing at the
bare repository (no index file I presume), so I'll need a minimum of one
clone. With clone -s the repository itself shouldn't take up hardly any
space. It sounds like my options are:
1) Have a separate repository clone for each branch that I want to
import to and leave that branch permanently checked out. I lose the
disk space for N working copies, but on the server I'm doing the import
on, it's not a huge issue, especially with ZFS compression ;-)
* This might not actually be so bad if I put the .git directory inside
of the CVS checkout directory and used it as my "working copy". I
just need to insure that git doesn't create any additional files in
there, as cvsup is really picky about not deleting files that it
didn't create, even if they were removed from CVS.
2) Have one repository clone that gets re-used for each import, with the
"checked out" branch getting changed before the import. As far as I can
tell this means suffering the "git checkout" overhead for 30,000 files,
which is conceptually inefficient but in real time only a minute or so.
* Unless of course there's a way to forcibly change the state that the
repository thinks it's in without physically checking out the files.
I think it would still need to update index however.
I tried git reset --soft without success. If this is possible, it
also makes option 1 more attractive if I can safely delete the
working copy files that it won't be using anyway.
Craig
^ permalink raw reply
* Re: Efficient way to import snapshots?
From: Linus Torvalds @ 2007-07-30 19:52 UTC (permalink / raw)
To: Craig Boston, Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <20070730192922.GB64467@nowhere>
[ Junio added, because I think I noticed a performance bug ]
On Mon, 30 Jul 2007, Craig Boston wrote:
>
> A couple questions on that:
>
> 1. Will it notice deleted files?
Yes, although I think you need to do "git commit -a" for that.
"git add ." could (and perhaps _should_) notice them and remove them from
the cache, but doesn't. Whether that's the right behaviour or not (it does
seem a bit strange that "git add" would actually remove files from the
index too) is up for debate.
But with "git commit -a", it will be noticed at commit time, at least.
That said, I just noticed something nasty: "git add ." is *horrible*. It
does the full SHA1 re-computation even though the index is up-to-date.
That's really nasty.
So right now, due to this performance bug, it's actually much better to do
something more complex, namely something like
git ls-files -o | git update-index --add --stdin
git commit -a
which is a lot more efficient than just doing "git add .".
Junio? I _thought_ we already took the index into account with "git add",
but we obviously don't.
> 2. How can I tell it what branch to commit to?
Whatever branch is checked out in the GIT_DIR will be the one that it
commits to.
Linus
^ permalink raw reply
* Re: [GUILT PATCH 3/4] guilt-select: Select guards to apply when pushing patches
From: Josef Sipek @ 2007-07-30 19:34 UTC (permalink / raw)
To: Eric Lesh; +Cc: jsipek, git
In-Reply-To: <87fy36cr25.fsf@hubert.paunchy.net>
On Mon, Jul 30, 2007 at 12:02:26AM -0700, Eric Lesh wrote:
> Josef Sipek <jsipek@fsl.cs.sunysb.edu> writes:
>
> [...]
>
> >> +if [ $# == 0 ]; then
> >> + if [ -s "$guards_file" ]; then
> >> + cat "$guards_file"
> >
> > Later on, for the -s option processing, you sort (presumably to have uniq do
> > the right thing), should we sort here too to be consitent?
> >
>
> The $guards_file isn't really meant to be handed edited, and
> guilt-select itself sorts before it stores them in the guards file. I could
> sort it again on printing, but don't think it's necessary.
Duh. No need to re-sort.
> >> +
> >> +case $1 in
> >> + -n|--none)
> >> + rm -f "$guards_file"
> >> + touch "$guards_file"
> >
> > Since guilt-init doesn't create the guards file, I'm thinking that this
> > should be just a rm -f ...
>
> Should guilt-init create it? I added $guards_file to guilt(7), so not
> seeing it might freak Documentation-conscious readers out?
I'm thinking that it would be nice to have the file created when the first
guard is set, and removed when the last guard is removed. This way, if you
don't care about guards, you don't have to ignore the file (if you have your
patches dir under version control). This also happens to be the nicer way to
transition from pre-guard patch dirs to ones with guards - in a way it's
cheating around "upgrading" the repo :)
I'd like this lazy creation to be documented, of course to not confuse the
handful that actually read the docs :)
Jeff.
--
Linux, n.:
Generous programmers from around the world all join forces to help
you shoot yourself in the foot for free.
^ permalink raw reply
* Re: "git stash" is not known to git
From: David Kastrup @ 2007-07-30 19:30 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20070730110354.GA11676@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Mon, Jul 30, 2007 at 12:52:40PM +0200, David Kastrup wrote:
>
>> How does it calculate its exec path? It would appear that it would
>> not contain _either_ /usr/local/bin _or_ /opt/git/bin in my
>> installation if it can't find git-stash (which should be statable in
>> both places).
>
> See exec_cmd.c:execv_git_cmd. It checks in order:
> 1. --exec-path= on command line
> 2. $GIT_EXEC_PATH from environment
> 3. GIT_EXEC_PATH defined at compile-time (set by Makefile from
> $(gitexecdir), which is generally the same as $(bindir))
>
> So it should have /opt/git/bin in your case, but it's possible since
> that is a Makefile variable that you failed to recompile correctly after
> changing its value.
>
>> Have a command handy for checking the exec path?
>
> git --exec-path
dak@lola:/home/tmp/git$ git --exec-path
/opt/git/bin
dak@lola:/home/tmp/git$ git stash --help
Reformatting git-stash(1), please wait...
WARNING: terminal is not fully functional
- (press RETURN)q
dak@lola:/home/tmp/git$ git-stash --help
dak@lola:/home/tmp/git$ Usage: /usr/local/bin/git-stash [ | list | show | apply | clear]
I think I'll just soak my head in a bucket. Don't ask me _what_ I
imagined to be experiencing here.
Maybe missing out shell completion when not typing the hyphen or
similar nonsense. Sorry for the noise.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: [GUILT PATCH 2/4] guilt-guard: Assign guards to patches in series
From: Josef Sipek @ 2007-07-30 19:28 UTC (permalink / raw)
To: Eric Lesh; +Cc: jsipek, git
In-Reply-To: <87k5sics0f.fsf@hubert.paunchy.net>
On Sun, Jul 29, 2007 at 11:41:52PM -0700, Eric Lesh wrote:
> Josef Sipek <jsipek@fsl.cs.sunysb.edu> writes:
>
> [...]
>
> >> +get_guarded_series()
> >> +{
> >> + get_series | while read p
> >> + do
> >> + [ -z `check_guards $p` ] && echo "$p"
> >
> > Having check_guards return 0 or 1 makes things cleaner:
> >
> > check_guards "$p" && echo "$p"
> >
> >> + done
> >> +}
> >> +
> >> +# usage: check_guards <patch>
> >> +# Returns t if the patch should be skipped
> >> +check_guards()
> >> +{
> >> + get_guards "$1" | while read guard
> >> + do
> >> + pos=`echo $guard | grep -e "^+"`
> >> + guard=`echo $guard | sed -e 's/[+-]//'`
> >> + if [ $pos ]; then
> >> + # Push +guard *only if* guard selected
> >> + push=`grep -e "^$guard\$" "$guards_file" > /dev/null; echo $?`
> >> + [ $push -ne 0 ] && echo t
> >
> > [ $push -ne 0 ] && return 1
> >
>
> This returns from the subshell created by the pipe and the while loop,
> right?
Right, sorry.
> So I'm using:
>
> check_guards()
> {
> get_guards "$1" | while read guard
> do
> pos=`echo $guard | grep -e "^+"`
> guard=`echo $guard | sed -e 's/^[+-]//'`
> if [ $pos ]; then
> # Push +guard *only if* guard selected
> push=`grep -e "^$guard\$" "$guards_file" > /dev/null; echo $?`
> [ $push -ne 0 ] && return 1
> else
> # Push -guard *unless* guard selected
> push=`grep -e "^$guard\$" "$guards_file" > /dev/null; echo $?`
> [ $push -eq 0 ] && return 1
> fi
> return 0
Beware of whitespace :)
> done
> return $?
> }
>
> where 1 means push.
>
> >> +# usage: get_guards <patch>
> >> +get_guards()
> >> +{
> >> + grep -e "^$1[[:space:]]*#" < "$series" | sed -e "s/^$1 //" -e 's/#[^+-]*//g'
> >> +}
>
> Should this also be one sed script instead of a grep + sed?
I'm all for more complex sed/awk scripts to replace lots of forks and pipes.
> >> +
> >> +# usage: set_guards <patch> <guards>
> >
> > I'd try to make it clearer that multiple guards can be specified.
> >
>
> Done with <guards...> now.
>
> >> +set_guards()
> >> +{
> >> + p="$1"
> >> + shift
> >> + for x in "$@"; do
> >> + if [ -z $(echo "$x" | grep -e "^[+-]") ]; then
> >
> > Is that the only restriction on the guard name?
> >
>
> Yes. On patches, you put a '+guard' or '-guard'. When selecting with
> guilt-select, it's just 'guard'. The + or - just means 'apply when
> selected' or 'apply unless selected'. You can edit things manually to
> make guards with a space in the name, but the mechanism will work even
> in that case.
I am thinking that it _might_ make sense to have some validate_guard_name
function - I am not sure if it would be used enough to make it useful
instead of just obfuscating the code.
> >> + echo "'$x' is not a valid guard name"
> >> + else
> >> + sed -i -e "s/^\($p[[:space:]]*.*\)$/\1 #$x/" "$series"
> >> + fi
> >> + done
> >> +}
> >> +
> >> +# usage: unset_guards <patch> <guards>
> >
>
> [...]
>
> The rest I'll do. Thanks for the review.
Thanks for the patches :)
Jeff.
--
The obvious mathematical breakthrough would be development of an easy way to
factor large prime numbers.
- Bill Gates, The Road Ahead, pg. 265
^ permalink raw reply
* Re: (Resend)[PATCH] git-svn: Translate invalid characters in refname
From: Eric Wong @ 2007-07-30 19:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Robert Ewald, git
In-Reply-To: <7v6442kxvu.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <gitster@pobox.com> wrote:
> Robert Ewald <robert.ewald@nov.com> writes:
>
> > +sub refname {
> > + my ($refname) = "refs/remotes/$_[0]->{ref_id}" ;
> > +
> > + # It cannot end with a slash /, we'll throw up on this because
> > + # SVN can't have directories with a slash in their name, either:
> > + if ($refname =~ m{/$}) {
> > + die "ref: '$refname' ends with a trailing slash, this is ",
> > + "not permitted by git nor Subversion\n";
> > + }
> > +
> > + # It cannot have ASCII control character space, tilde ~, caret ^,
> > + # colon :, question-mark ?, asterisk *, space, or open bracket [
> > + # anywhere.
> > + #
> > + # Additionally, % must be escaped because it is used for escaping
> > + # and we want our escaped refname to be reversible
> > + $refname =~ s{([ \%~\^:\?\*\[\t])}{uc sprintf('%%%02x',ord($1))}eg;
>
> uc of sprintf()? You meant "%%%02X"?
Ah, I wasn't sure if X was portable enough, but then again this sprintf
is in Perl.
> Other than that, looks sane to me. I presume that SVN branches
> whose name would be mangled with this patch would not have been
> successfully imported with older git-svn anyway, so this won't
> introduce any regressions?
Seems alright to me, I haven't had a chance to look at it too hard. I'm
out of town and haven't been following the mailing list lately.
Acked-by: Eric Wong <normalperson@yhbt.net>
--
Eric Wong
^ permalink raw reply
* Re: Efficient way to import snapshots?
From: Craig Boston @ 2007-07-30 19:29 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <alpine.LFD.0.999.0707301144180.4161@woody.linux-foundation.org>
On Mon, Jul 30, 2007 at 11:56:56AM -0700, Linus Torvalds wrote:
> It should literally be as easy as doing something like
>
> cd /path/to/cvs/checkout_X
> export GIT_DIR=/path/to/git/repo
> git add .
> git commit -m"Import yyyymmdd snapshot"
Aha! I didn't know that you could point to a repository with GIT_DIR
and do useful operations without a working directory. My "master" repo
that gets backed up and cloned everywhere is a bare repo anyway; I had
been cloning it with -s and then using 'git push' to get changes back
into it.
A couple questions on that:
1. Will it notice deleted files?
2. How can I tell it what branch to commit to?
> You'd have to make sure that you have the CVS directories ignored, of
> course, and if you don't want to change the CVS directory at all (which is
> a good idea!) you'd need to do that by using the "ignore" file in your
> GIT_DIR, and just having the CVS entry there, instead of adding a
> ".gitignore" file to the working tree and checking it in.
Not a problem, I'm using cvsup in checkout mode so there are no CVS
dirs. The checkout directory is an exact snapshot of "What The
Repository Should Look Like."
> The above is totally untested, of course, but I think that's the easiest
> way to do things like this. In general, it should be *trivial* to do
> snapshots with git using just about _any_ legacy SCM, exactly because you
> can keep the whole git setup away from the legacy SCM directories with
> that "GIT_DIR=.." thing.
I'll make a backup of my repo and give it a try.
Thanks!
Craig
^ permalink raw reply
* Re: [RFC] Git User's Survey 2007
From: David Kastrup @ 2007-07-30 19:26 UTC (permalink / raw)
To: Paolo Ciarrocchi; +Cc: Jakub Narebski, git
In-Reply-To: <4d8e3fd30707300044l79133442of45b37a8192f7bca@mail.gmail.com>
"Paolo Ciarrocchi" <paolo.ciarrocchi@gmail.com> writes:
> Fine with me. Thanks for you work Jakub.
>
> Just a general comment, let's try to avoid as much as possible
> multiple questions in a single question. It tends to confuse people
> when they are answering to the survey.
I find that the survey lacking in community questions, like
Do you frequently read the mailing list?
Frequently post?
Other sources of information?
How helpful are the answers you get there?
How pleasant is the atmosphere?
And so on.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ 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