* [PATCH 4/9] resolve-undo: allow plumbing to clear the information
From: Junio C Hamano @ 2009-12-29 21:42 UTC (permalink / raw)
To: git
In-Reply-To: <1262122958-9378-1-git-send-email-gitster@pobox.com>
At the Porcelain level, operations such as merge that populate an
initially cleanly merged index with conflicted entries clear the
resolve-undo information upfront. Give scripted Porcelains a way
to do the same, by implementing "update-index --clear-resolve-info".
With this, a scripted Porcelain may "update-index --clear-resolve-info"
first and repeatedly run "update-index --cacheinfo" to stuff unmerged
entries to the index, to be resolved by the user with "git add" and
stuff.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
builtin-update-index.c | 5 +++++
t/t2030-unresolve-info.sh | 12 ++++++++++++
2 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/builtin-update-index.c b/builtin-update-index.c
index a6b7f2d..a19e786 100644
--- a/builtin-update-index.c
+++ b/builtin-update-index.c
@@ -9,6 +9,7 @@
#include "tree-walk.h"
#include "builtin.h"
#include "refs.h"
+#include "resolve-undo.h"
/*
* Default to not allowing changes to the list of files. The
@@ -703,6 +704,10 @@ int cmd_update_index(int argc, const char **argv, const char *prefix)
verbose = 1;
continue;
}
+ if (!strcmp(path, "--clear-resolve-undo")) {
+ resolve_undo_clear();
+ continue;
+ }
if (!strcmp(path, "-h") || !strcmp(path, "--help"))
usage(update_index_usage);
die("unknown option %s", path);
diff --git a/t/t2030-unresolve-info.sh b/t/t2030-unresolve-info.sh
index 785c8b3..9844802 100755
--- a/t/t2030-unresolve-info.sh
+++ b/t/t2030-unresolve-info.sh
@@ -85,4 +85,16 @@ test_expect_success 'rm records reset clears' '
check_resolve_undo discarded
'
+test_expect_success 'plumbing clears' '
+ prime_resolve_undo &&
+ test_tick &&
+ git commit -m merged &&
+ echo committing keeps &&
+ check_resolve_undo kept file initial:file second:file third:file &&
+
+ echo plumbing clear &&
+ git update-index --clear-resolve-undo &&
+ check_resolve_undo cleared
+'
+
test_done
--
1.6.6
^ permalink raw reply related
* [PATCH 3/9] resolve-undo: basic tests
From: Junio C Hamano @ 2009-12-29 21:42 UTC (permalink / raw)
To: git
In-Reply-To: <1262122958-9378-1-git-send-email-gitster@pobox.com>
Make sure that resolving a failed merge with git add records
the conflicted state, committing the result keeps that state,
and checking out another commit clears the state.
"git ls-files" learns a new option --resolve-undo to show the
recorded information.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
builtin-ls-files.c | 43 +++++++++++++++++++++-
t/t2030-unresolve-info.sh | 88 +++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 130 insertions(+), 1 deletions(-)
create mode 100755 t/t2030-unresolve-info.sh
diff --git a/builtin-ls-files.c b/builtin-ls-files.c
index c9a03e5..ef3a068 100644
--- a/builtin-ls-files.c
+++ b/builtin-ls-files.c
@@ -11,6 +11,8 @@
#include "builtin.h"
#include "tree.h"
#include "parse-options.h"
+#include "resolve-undo.h"
+#include "string-list.h"
static int abbrev;
static int show_deleted;
@@ -18,6 +20,7 @@ static int show_cached;
static int show_others;
static int show_stage;
static int show_unmerged;
+static int show_resolve_undo;
static int show_modified;
static int show_killed;
static int show_valid_bit;
@@ -37,6 +40,7 @@ static const char *tag_removed = "";
static const char *tag_other = "";
static const char *tag_killed = "";
static const char *tag_modified = "";
+static const char *tag_resolve_undo = "";
static void show_dir_entry(const char *tag, struct dir_entry *ent)
{
@@ -155,6 +159,38 @@ static void show_ce_entry(const char *tag, struct cache_entry *ce)
write_name_quoted(ce->name + offset, stdout, line_terminator);
}
+static int show_one_ru(struct string_list_item *item, void *cbdata)
+{
+ int offset = prefix_offset;
+ const char *path = item->string;
+ struct resolve_undo_info *ui = item->util;
+ int i, len;
+
+ len = strlen(path);
+ if (len < prefix_len)
+ return 0; /* outside of the prefix */
+ if (!match_pathspec(pathspec, path, len, prefix_len, ps_matched))
+ return 0; /* uninterested */
+ for (i = 0; i < 3; i++) {
+ if (!ui->mode[i])
+ continue;
+ printf("%s%06o %s %d\t", tag_resolve_undo, ui->mode[i],
+ abbrev
+ ? find_unique_abbrev(ui->sha1[i], abbrev)
+ : sha1_to_hex(ui->sha1[i]),
+ i + 1);
+ write_name_quoted(path + offset, stdout, line_terminator);
+ }
+ return 0;
+}
+
+static void show_ru_info(const char *prefix)
+{
+ if (!the_index.resolve_undo)
+ return;
+ for_each_string_list(show_one_ru, the_index.resolve_undo, NULL);
+}
+
static void show_files(struct dir_struct *dir, const char *prefix)
{
int i;
@@ -454,6 +490,8 @@ int cmd_ls_files(int argc, const char **argv, const char *prefix)
DIR_HIDE_EMPTY_DIRECTORIES),
OPT_BOOLEAN('u', "unmerged", &show_unmerged,
"show unmerged files in the output"),
+ OPT_BOOLEAN(0, "resolve-undo", &show_resolve_undo,
+ "show resolve-undo information"),
{ OPTION_CALLBACK, 'x', "exclude", &dir.exclude_list[EXC_CMDL], "pattern",
"skip files matching pattern",
0, option_parse_exclude },
@@ -490,6 +528,7 @@ int cmd_ls_files(int argc, const char **argv, const char *prefix)
tag_modified = "C ";
tag_other = "? ";
tag_killed = "K ";
+ tag_resolve_undo = "U ";
}
if (show_modified || show_others || show_deleted || (dir.flags & DIR_SHOW_IGNORED) || show_killed)
require_work_tree = 1;
@@ -529,7 +568,7 @@ int cmd_ls_files(int argc, const char **argv, const char *prefix)
/* With no flags, we default to showing the cached files */
if (!(show_stage | show_deleted | show_others | show_unmerged |
- show_killed | show_modified))
+ show_killed | show_modified | show_resolve_undo))
show_cached = 1;
if (prefix)
@@ -544,6 +583,8 @@ int cmd_ls_files(int argc, const char **argv, const char *prefix)
overlay_tree_on_cache(with_tree, prefix);
}
show_files(&dir, prefix);
+ if (show_resolve_undo)
+ show_ru_info(prefix);
if (ps_matched) {
int bad;
diff --git a/t/t2030-unresolve-info.sh b/t/t2030-unresolve-info.sh
new file mode 100755
index 0000000..785c8b3
--- /dev/null
+++ b/t/t2030-unresolve-info.sh
@@ -0,0 +1,88 @@
+#!/bin/sh
+
+test_description='undoing resolution'
+
+. ./test-lib.sh
+
+check_resolve_undo () {
+ msg=$1
+ shift
+ while case $# in
+ 0) break ;;
+ 1|2|3) die "Bug in check-resolve-undo test" ;;
+ esac
+ do
+ path=$1
+ shift
+ for stage in 1 2 3
+ do
+ sha1=$1
+ shift
+ case "$sha1" in
+ '') continue ;;
+ esac
+ sha1=$(git rev-parse --verify "$sha1")
+ printf "100644 %s %s\t%s\n" $sha1 $stage $path
+ done
+ done >"$msg.expect" &&
+ git ls-files --resolve-undo >"$msg.actual" &&
+ test_cmp "$msg.expect" "$msg.actual"
+}
+
+prime_resolve_undo () {
+ git reset --hard &&
+ git checkout second^0 &&
+ test_tick &&
+ test_must_fail git merge third^0 &&
+ echo merge does not leave anything &&
+ check_resolve_undo empty &&
+ echo different >file &&
+ git add file &&
+ echo resolving records &&
+ check_resolve_undo recorded file initial:file second:file third:file
+}
+
+test_expect_success setup '
+ test_commit initial file first &&
+ git branch side &&
+ git branch another &&
+ test_commit second file second &&
+ git checkout side &&
+ test_commit third file third &&
+ git checkout another &&
+ test_commit fourth file fourth &&
+ git checkout master
+'
+
+test_expect_success 'add records switch clears' '
+ prime_resolve_undo &&
+ test_tick &&
+ git commit -m merged &&
+ echo committing keeps &&
+ check_resolve_undo kept file initial:file second:file third:file &&
+ git checkout second^0 &&
+ echo switching clears &&
+ check_resolve_undo cleared
+'
+
+test_expect_success 'rm records reset clears' '
+ prime_resolve_undo &&
+ test_tick &&
+ git commit -m merged &&
+ echo committing keeps &&
+ check_resolve_undo kept file initial:file second:file third:file &&
+
+ echo merge clears upfront &&
+ test_must_fail git merge fourth^0 &&
+ check_resolve_undo nuked &&
+
+ git rm -f file &&
+ echo resolving records &&
+ check_resolve_undo recorded file initial:file HEAD:file fourth:file &&
+
+ git reset --hard &&
+ echo resetting discards &&
+ check_resolve_undo discarded
+'
+
+test_done
--
1.6.6
^ permalink raw reply related
* [PATCH 2/9] resolve-undo: record resolved conflicts in a new index extension section
From: Junio C Hamano @ 2009-12-29 21:42 UTC (permalink / raw)
To: git
In-Reply-To: <1262122958-9378-1-git-send-email-gitster@pobox.com>
When resolving a conflict using "git add" to create a stage #0 entry, or
"git rm" to remove entries at higher stages, remove_index_entry_at()
function is eventually called to remove unmerged (i.e. higher stage)
entries from the index. Introduce a "resolve_undo_info" structure and
keep track of the removed cache entries, and save it in a new index
extension section in the index_state.
Operations like "read-tree -m", "merge", "checkout [-m] <branch>" and
"reset" are signs that recorded information in the index is no longer
necessary. The data is removed from the index extension when operations
start; they may leave conflicted entries in the index, and later user
actions like "git add" will record their conflicted states afresh.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Makefile | 2 +
builtin-checkout.c | 2 +
builtin-merge.c | 4 +-
builtin-read-tree.c | 2 +
cache.h | 2 +
read-cache.c | 18 ++++++++
resolve-undo.c | 117 +++++++++++++++++++++++++++++++++++++++++++++++++++
resolve-undo.h | 14 ++++++
8 files changed, 160 insertions(+), 1 deletions(-)
create mode 100644 resolve-undo.c
create mode 100644 resolve-undo.h
diff --git a/Makefile b/Makefile
index 4a1e5bc..762898a 100644
--- a/Makefile
+++ b/Makefile
@@ -483,6 +483,7 @@ LIB_H += reflog-walk.h
LIB_H += refs.h
LIB_H += remote.h
LIB_H += rerere.h
+LIB_H += resolve-undo.h
LIB_H += revision.h
LIB_H += run-command.h
LIB_H += sha1-lookup.h
@@ -578,6 +579,7 @@ LIB_OBJS += refs.o
LIB_OBJS += remote.o
LIB_OBJS += replace_object.o
LIB_OBJS += rerere.o
+LIB_OBJS += resolve-undo.o
LIB_OBJS += revision.o
LIB_OBJS += run-command.o
LIB_OBJS += server-info.o
diff --git a/builtin-checkout.c b/builtin-checkout.c
index 64f3a11..a0fe7a4 100644
--- a/builtin-checkout.c
+++ b/builtin-checkout.c
@@ -17,6 +17,7 @@
#include "blob.h"
#include "xdiff-interface.h"
#include "ll-merge.h"
+#include "resolve-undo.h"
static const char * const checkout_usage[] = {
"git checkout [options] <branch>",
@@ -370,6 +371,7 @@ static int merge_working_tree(struct checkout_opts *opts,
if (read_cache_preload(NULL) < 0)
return error("corrupt index file");
+ resolve_undo_clear();
if (opts->force) {
ret = reset_tree(new->commit->tree, opts, 1);
if (ret)
diff --git a/builtin-merge.c b/builtin-merge.c
index 6cb804b..6bc2f7a 100644
--- a/builtin-merge.c
+++ b/builtin-merge.c
@@ -24,6 +24,7 @@
#include "rerere.h"
#include "help.h"
#include "merge-recursive.h"
+#include "resolve-undo.h"
#define DEFAULT_TWOHEAD (1<<0)
#define DEFAULT_OCTOPUS (1<<1)
@@ -604,6 +605,7 @@ static int try_merge_strategy(const char *strategy, struct commit_list *common,
discard_cache();
if (read_cache() < 0)
die("failed to read the cache");
+ resolve_undo_clear();
return ret;
}
}
@@ -851,7 +853,7 @@ int cmd_merge(int argc, const char **argv, const char *prefix)
if (read_cache_unmerged())
die("You are in the middle of a conflicted merge."
" (index unmerged)");
-
+ resolve_undo_clear();
/*
* Check if we are _not_ on a detached HEAD, i.e. if there is a
* current branch.
diff --git a/builtin-read-tree.c b/builtin-read-tree.c
index 2a3a32c..7d378b7 100644
--- a/builtin-read-tree.c
+++ b/builtin-read-tree.c
@@ -13,6 +13,7 @@
#include "dir.h"
#include "builtin.h"
#include "parse-options.h"
+#include "resolve-undo.h"
static int nr_trees;
static struct tree *trees[MAX_UNPACK_TREES];
@@ -122,6 +123,7 @@ int cmd_read_tree(int argc, const char **argv, const char *unused_prefix)
die("You need to resolve your current index first");
stage = opts.merge = 1;
}
+ resolve_undo_clear();
for (i = 0; i < argc; i++) {
const char *arg = argv[i];
diff --git a/cache.h b/cache.h
index bf468e5..310d9e6 100644
--- a/cache.h
+++ b/cache.h
@@ -282,6 +282,7 @@ static inline int ce_to_dtype(const struct cache_entry *ce)
struct index_state {
struct cache_entry **cache;
unsigned int cache_nr, cache_alloc, cache_changed;
+ struct string_list *resolve_undo;
struct cache_tree *cache_tree;
struct cache_time timestamp;
void *alloc;
@@ -336,6 +337,7 @@ static inline void remove_name_hash(struct cache_entry *ce)
#define ce_modified(ce, st, options) ie_modified(&the_index, (ce), (st), (options))
#define cache_name_exists(name, namelen, igncase) index_name_exists(&the_index, (name), (namelen), (igncase))
#define cache_name_is_other(name, namelen) index_name_is_other(&the_index, (name), (namelen))
+#define resolve_undo_clear() resolve_undo_clear_index(&the_index)
#endif
enum object_type {
diff --git a/read-cache.c b/read-cache.c
index 1bbaf1c..9e0fb04 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -14,6 +14,7 @@
#include "diffcore.h"
#include "revision.h"
#include "blob.h"
+#include "resolve-undo.h"
/* Index extensions.
*
@@ -26,6 +27,7 @@
#define CACHE_EXT(s) ( (s[0]<<24)|(s[1]<<16)|(s[2]<<8)|(s[3]) )
#define CACHE_EXT_TREE 0x54524545 /* "TREE" */
+#define CACHE_EXT_RESOLVE_UNDO 0x52455543 /* "REUN" */
struct index_state the_index;
@@ -449,6 +451,7 @@ int remove_index_entry_at(struct index_state *istate, int pos)
{
struct cache_entry *ce = istate->cache[pos];
+ record_resolve_undo(istate, ce);
remove_name_hash(ce);
istate->cache_changed = 1;
istate->cache_nr--;
@@ -1170,6 +1173,9 @@ static int read_index_extension(struct index_state *istate,
case CACHE_EXT_TREE:
istate->cache_tree = cache_tree_read(data, sz);
break;
+ case CACHE_EXT_RESOLVE_UNDO:
+ istate->resolve_undo = resolve_undo_read(data, sz);
+ break;
default:
if (*ext < 'A' || 'Z' < *ext)
return error("index uses %.4s extension, which we do not understand",
@@ -1349,6 +1355,7 @@ int is_index_unborn(struct index_state *istate)
int discard_index(struct index_state *istate)
{
+ resolve_undo_clear_index(istate);
istate->cache_nr = 0;
istate->cache_changed = 0;
istate->timestamp.sec = 0;
@@ -1574,6 +1581,17 @@ int write_index(struct index_state *istate, int newfd)
if (err)
return -1;
}
+ if (istate->resolve_undo) {
+ struct strbuf sb = STRBUF_INIT;
+
+ resolve_undo_write(&sb, istate->resolve_undo);
+ err = write_index_ext_header(&c, newfd, CACHE_EXT_RESOLVE_UNDO,
+ sb.len) < 0
+ || ce_write(&c, newfd, sb.buf, sb.len) < 0;
+ strbuf_release(&sb);
+ if (err)
+ return -1;
+ }
if (ce_flush(&c, newfd) || fstat(newfd, &st))
return -1;
diff --git a/resolve-undo.c b/resolve-undo.c
new file mode 100644
index 0000000..86e8547
--- /dev/null
+++ b/resolve-undo.c
@@ -0,0 +1,117 @@
+#include "cache.h"
+#include "resolve-undo.h"
+#include "string-list.h"
+
+/* The only error case is to run out of memory in string-list */
+void record_resolve_undo(struct index_state *istate, struct cache_entry *ce)
+{
+ struct string_list_item *lost;
+ struct resolve_undo_info *ui;
+ struct string_list *resolve_undo;
+ int stage = ce_stage(ce);
+
+ if (!stage)
+ return;
+
+ if (!istate->resolve_undo) {
+ resolve_undo = xcalloc(1, sizeof(*resolve_undo));
+ resolve_undo->strdup_strings = 1;
+ istate->resolve_undo = resolve_undo;
+ }
+ resolve_undo = istate->resolve_undo;
+ lost = string_list_insert(ce->name, resolve_undo);
+ if (!lost->util)
+ lost->util = xcalloc(1, sizeof(*ui));
+ ui = lost->util;
+ hashcpy(ui->sha1[stage - 1], ce->sha1);
+ ui->mode[stage - 1] = ce->ce_mode;
+}
+
+static int write_one(struct string_list_item *item, void *cbdata)
+{
+ struct strbuf *sb = cbdata;
+ struct resolve_undo_info *ui = item->util;
+ int i;
+
+ if (!ui)
+ return 0;
+ strbuf_addstr(sb, item->string);
+ strbuf_addch(sb, 0);
+ for (i = 0; i < 3; i++)
+ strbuf_addf(sb, "%o%c", ui->mode[i], 0);
+ for (i = 0; i < 3; i++) {
+ if (!ui->mode[i])
+ continue;
+ strbuf_add(sb, ui->sha1[i], 20);
+ }
+ return 0;
+}
+
+void resolve_undo_write(struct strbuf *sb, struct string_list *resolve_undo)
+{
+ for_each_string_list(write_one, resolve_undo, sb);
+}
+
+struct string_list *resolve_undo_read(void *data, unsigned long size)
+{
+ struct string_list *resolve_undo;
+ size_t len;
+ char *endptr;
+ int i;
+
+ resolve_undo = xcalloc(1, sizeof(*resolve_undo));
+ resolve_undo->strdup_strings = 1;
+
+ while (size) {
+ struct string_list_item *lost;
+ struct resolve_undo_info *ui;
+
+ len = strlen(data) + 1;
+ if (size <= len)
+ goto error;
+ lost = string_list_insert(data, resolve_undo);
+ if (!lost->util)
+ lost->util = xcalloc(1, sizeof(*ui));
+ ui = lost->util;
+ size -= len;
+ data += len;
+
+ for (i = 0; i < 3; i++) {
+ ui->mode[i] = strtoul(data, &endptr, 8);
+ if (!endptr || endptr == data || *endptr)
+ goto error;
+ len = (endptr + 1) - (char*)data;
+ if (size <= len)
+ goto error;
+ size -= len;
+ data += len;
+ }
+
+ for (i = 0; i < 3; i++) {
+ if (!ui->mode[i])
+ continue;
+ if (size < 20)
+ goto error;
+ hashcpy(ui->sha1[i], data);
+ size -= 20;
+ data += 20;
+ }
+ }
+ return resolve_undo;
+
+error:
+ string_list_clear(resolve_undo, 1);
+ error("Index records invalid resolve-undo information");
+ return NULL;
+}
+
+void resolve_undo_clear_index(struct index_state *istate)
+{
+ struct string_list *resolve_undo = istate->resolve_undo;
+ if (!resolve_undo)
+ return;
+ string_list_clear(resolve_undo, 1);
+ free(resolve_undo);
+ istate->resolve_undo = NULL;
+ istate->cache_changed = 1;
+}
diff --git a/resolve-undo.h b/resolve-undo.h
new file mode 100644
index 0000000..74194d0
--- /dev/null
+++ b/resolve-undo.h
@@ -0,0 +1,14 @@
+#ifndef RESOLVE_UNDO_H
+#define RESOLVE_UNDO_H
+
+struct resolve_undo_info {
+ unsigned int mode[3];
+ unsigned char sha1[3][20];
+};
+
+extern void record_resolve_undo(struct index_state *, struct cache_entry *);
+extern void resolve_undo_write(struct strbuf *, struct string_list *);
+extern struct string_list *resolve_undo_read(void *, unsigned long);
+extern void resolve_undo_clear_index(struct index_state *);
+
+#endif
--
1.6.6
^ permalink raw reply related
* [PATCH 1/9] builtin-merge.c: use standard active_cache macros
From: Junio C Hamano @ 2009-12-29 21:42 UTC (permalink / raw)
To: git
In-Reply-To: <1262122958-9378-1-git-send-email-gitster@pobox.com>
Instead of using the low-level index_state interface, use the bog standard
active_cache and active_nr macros to access the cache entries when using the
default one.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
builtin-merge.c | 5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/builtin-merge.c b/builtin-merge.c
index f1c84d7..6cb804b 100644
--- a/builtin-merge.c
+++ b/builtin-merge.c
@@ -618,11 +618,10 @@ static void count_diff_files(struct diff_queue_struct *q,
static int count_unmerged_entries(void)
{
- const struct index_state *state = &the_index;
int i, ret = 0;
- for (i = 0; i < state->cache_nr; i++)
- if (ce_stage(state->cache[i]))
+ for (i = 0; i < active_nr; i++)
+ if (ce_stage(active_cache[i]))
ret++;
return ret;
--
1.6.6
^ permalink raw reply related
* [PATCH 0/9] Undoing conflict resolution
From: Junio C Hamano @ 2009-12-29 21:42 UTC (permalink / raw)
To: git
In-Reply-To: <7v6393mfqz.fsf@alter.siamese.dyndns.org>
This series resurrects the topic we discussed later November.
I wrote a bit about this in http://gitster.livejournal.com/43665.html but
as usual with my patches, they do come with minimum set of tests but it
contains no documentation updates. The user visible changes are:
- ls-files has a new option primarily for debugging;
- update-index has a new option --clear-resolve-undo;
- rerere has a new subcommand forget.
Junio C Hamano (9):
builtin-merge.c: use standard active_cache macros
resolve-undo: record resolved conflicts in a new index extension
section
resolve-undo: basic tests
resolve-undo: allow plumbing to clear the information
resolve-undo: "checkout -m path" uses resolve-undo information
resolve-undo: teach "update-index --unresolve" to use resolve-undo
info
rerere: remove silly 1024-byte line limit
rerere: refactor rerere logic to make it independent from I/O
rerere forget path: forget recorded resolution
Makefile | 2 +
builtin-checkout.c | 6 +
builtin-ls-files.c | 43 +++++++-
builtin-merge.c | 9 +-
builtin-read-tree.c | 2 +
builtin-rerere.c | 2 +
builtin-update-index.c | 18 +++-
cache.h | 4 +
read-cache.c | 18 +++
rerere.c | 259 +++++++++++++++++++++++++++++++++++++-------
rerere.h | 1 +
resolve-undo.c | 176 ++++++++++++++++++++++++++++++
resolve-undo.h | 16 +++
t/t2030-unresolve-info.sh | 140 ++++++++++++++++++++++++
14 files changed, 648 insertions(+), 48 deletions(-)
create mode 100644 resolve-undo.c
create mode 100644 resolve-undo.h
create mode 100755 t/t2030-unresolve-info.sh
^ permalink raw reply
* Re: signing tags: user.name assumed to be gpg uid?
From: Junio C Hamano @ 2009-12-29 21:12 UTC (permalink / raw)
To: Peter Vereshagin; +Cc: git
In-Reply-To: <20091229203637.GA3036@screwed.box>
Peter Vereshagin <peter@vereshagin.org> writes:
> I notice that after I init and config user.name and user.email the
> user.comment gets taken from ~/.gpg automatically.
What is "user.comment"?
> Is it a correct behaviour?
Yes, matching with user.name/user.email (actually committer information)
is often the most convenient thing to do.
You can use user.signingkey configuration to use a key that doesn't match
your name, too.
^ permalink raw reply
* Re: [PATCH 2/2] MinGW: Add missing file mode bit defines
From: Johannes Sixt @ 2009-12-29 21:10 UTC (permalink / raw)
To: Sebastian Schuberth; +Cc: git
In-Reply-To: <hhblfa$di8$2@ger.gmane.org>
Sebastian Schuberth schrieb:
> MinGW: Add missing file mode bit defines
Why this? What's the problem with the status quo?
-- Hannes
^ permalink raw reply
* Re: [PATCH 1/2] MinGW: Use pid_t more consequently, introduce uid_t for greater compatibility
From: Johannes Sixt @ 2009-12-29 21:09 UTC (permalink / raw)
To: Sebastian Schuberth; +Cc: git
In-Reply-To: <hhbldr$di8$1@ger.gmane.org>
Sebastian Schuberth schrieb:
> MinGW: Use pid_t more consequently, introduce uid_t for greater compatibility
Why this? Compatibility with what? What's the problem with the status quo?
-- Hannes
^ permalink raw reply
* Re: Possible bug in 1.6.6 with reset --hard and $GIT_WORK_TREE
From: Fyn Fynn @ 2009-12-29 21:09 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Nanako Shiraishi, git, Jeff King
In-Reply-To: <fcaeb9bf0912290336m69303c3es8138c4e6497b801a@mail.gmail.com>
I went over the 952dfc6 patch, and it seems like it was designed to
fix a specific bug - the one demonstrated by Nanako Shiraishi above.
Nowhere there do I see an intention to prevent the action described in
the original post. And even if there was such intention, it should
have been made explicit by providing a proper error message: the
current one simply ignores the fact that we provided GIT_WORK_TREE,
and is thus incorrect since the work tree can be found.
Moreover, if there is an intention to prevent resetting from outside
the worktree (why?), then probably "checkout -f" should be limited as
well.
But it is more likely that the breaking of the original action between
1.6.4 and 1.6.6 came about as an untended consequence of 952dfc6,
which oversimplified by assuming that the worktree can only be found
if we're inside it, ignoring the possibility that GIT_WORK_TREE was
provided.
Thus, the current state should be considered a bug.
--
Fynn
On Tue, Dec 29, 2009 at 3:36 AM, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
> On 12/29/09, Nanako Shiraishi <nanako3@lavabit.com> wrote:
>> Quoting Nguyen Thai Ngoc Duy <pclouds@gmail.com>:
>>
>> > On 12/29/09, Fyn Fynn <fynfynn@gmail.com> wrote:
>> >> The exact same git reset command that works in 1.6.4, fails to work
>> >> under 1.6.6:
>> >>
>> >> $ GIT_WORK_TREE=$HOME/rawdata/ GIT_DIR=$HOME/rawdata/.git
>> >> /usr/local/git-1.6.6/bin/git reset --hard
>> >> fatal: hard reset requires a work tree
>> >> $ GIT_WORK_TREE=$HOME/rawdata/ GIT_DIR=$HOME/rawdata/.git
>> >> /usr/local/git-1.6.4/bin/git reset --hard
>> >> HEAD is now at 77ec73f...
>> >>
>> >> What gives?
>> >
>> > A recent patch by Jeff (952dfc6 (reset: improve worktree safety valves
>> > - 2009-12-04)) makes sure that "git reset --hard" will not work
>> > outside worktree (which is right).
>>
>>
>> Sorry, but I don't understand why it is *right*. Isn't 'git reset --hard' supposed to make all the files in the working tree match the HEAD, no matter where you start from?
>
> It is generally "right" to work from inside worktree, the way Git
> worked before GIT_WORK_TREE came. In case of "git reset --hard", yes
> it'd be best if Git could just go to worktree and reset it. I forgot
> that "git reset --hard" does not take pathspec. The situation may be a
> bit more complicated with "git status" (which also handles worktree as
> a whole) because you may need to represent the filename output to be
> relative to current working directory, not the GIT_WORK_TREE. Using
> GIT_WORK_TREE from outside worktree is imo stretching git to its
> limits.
> --
> Duy
>
^ permalink raw reply
* Re: Help on CGIT
From: Jorge Bastos @ 2009-12-29 20:54 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git
In-Reply-To: <5b4ce0d0c1dd830782397602a71bb4f6@192.168.1.222>
Guys!
I changed on /etc/cgitrc:
css=cgit.css
logo=cgit.png
to:
css=/cgit/cgit.css
logo=/cgit/cgit.png
Forcing the path for the files to be from the root did the trick!
Thanks you all this the help!
^ permalink raw reply
* signing tags: user.name assumed to be gpg uid?
From: Peter Vereshagin @ 2009-12-29 20:36 UTC (permalink / raw)
To: git
Como esta, git?
I notice that after I init and config user.name and user.email the user.comment gets taken from ~/.gpg automatically. Is it a correct behaviour?
And, when I try
git tag v0.1 -s
I get :
===
gpg: skipped "Peter Vereshagin <peter@vereshagin.org>": secret key not available
===
and this is because I need to config user.name with the gpg comment: when I
===
git config --global user.name "Peter Vereshagin (http://vereshagin.org)"
===
the git tag signs well. But is it a correct behaviour to need the comment as a user's name? On key editing the gpg makes difference between (N)ame and (C)omment by far.
73! Peter pgp: A0E26627 (4A42 6841 2871 5EA7 52AB 12F8 0CE1 4AAC A0E2 6627)
--
http://vereshagin.org
^ permalink raw reply
* [PATCH] git count-objects: handle packs bigger than 4G
From: Andreas Schwab @ 2009-12-29 19:09 UTC (permalink / raw)
To: git
Use off_t to count sizes of packs and objects to avoid overflow after
4Gb.
Signed-off-by: Andreas Schwab <schwab@linux-m68k.org>
---
builtin-count-objects.c | 12 ++++++------
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/builtin-count-objects.c b/builtin-count-objects.c
index 1b0b6c8..2bdd8eb 100644
--- a/builtin-count-objects.c
+++ b/builtin-count-objects.c
@@ -11,7 +11,7 @@
static void count_objects(DIR *d, char *path, int len, int verbose,
unsigned long *loose,
- unsigned long *loose_size,
+ off_t *loose_size,
unsigned long *packed_loose,
unsigned long *garbage)
{
@@ -77,7 +77,7 @@ int cmd_count_objects(int argc, const char **argv, const char *prefix)
int len = strlen(objdir);
char *path = xmalloc(len + 50);
unsigned long loose = 0, packed = 0, packed_loose = 0, garbage = 0;
- unsigned long loose_size = 0;
+ off_t loose_size = 0;
struct option opts[] = {
OPT__VERBOSE(&verbose),
OPT_END(),
@@ -103,7 +103,7 @@ int cmd_count_objects(int argc, const char **argv, const char *prefix)
if (verbose) {
struct packed_git *p;
unsigned long num_pack = 0;
- unsigned long size_pack = 0;
+ off_t size_pack = 0;
if (!packed_git)
prepare_packed_git();
for (p = packed_git; p; p = p->next) {
@@ -116,15 +116,15 @@ int cmd_count_objects(int argc, const char **argv, const char *prefix)
num_pack++;
}
printf("count: %lu\n", loose);
- printf("size: %lu\n", loose_size / 1024);
+ printf("size: %lu\n", (unsigned long) (loose_size / 1024));
printf("in-pack: %lu\n", packed);
printf("packs: %lu\n", num_pack);
- printf("size-pack: %lu\n", size_pack / 1024);
+ printf("size-pack: %lu\n", (unsigned long) (size_pack / 1024));
printf("prune-packable: %lu\n", packed_loose);
printf("garbage: %lu\n", garbage);
}
else
printf("%lu objects, %lu kilobytes\n",
- loose, loose_size / 1024);
+ loose, (unsigned long) (loose_size / 1024));
return 0;
}
--
1.6.6
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply related
* Re: config for merging master to test branch
From: Junio C Hamano @ 2009-12-29 18:32 UTC (permalink / raw)
To: Daniel Convissor; +Cc: Git Mailing List
In-Reply-To: <20091229175607.GA3683@panix.com>
Daniel Convissor <danielc@analysisandsolutions.com> writes:
> Excellent. Initially, I wasn't sure what the following commands did:
>
> git config branch.test.remote origin
> git config branch.test.merge refs/heads/master
>
> Between further reading and your explanation I now understand it better.
> "refs/heads/master" refers items displayed by "git show-ref".
Not quite. refs/heads/master there refers to the _local_ master branch,
but it is _local_ with respect to the origin repository, not your
repository. "git show-ref" is about showing refs in _your_ repository.
> So what is "refs/remotes/origin/master", please?
http://gitster.livejournal.com/30313.html
If you read Japanese, you may also want to read Ch.13 of my book ;-)
The refs/remotes/ hierarchy is used to store a copy of the branch tips
fetched from the named remotes (like "origin").
^ permalink raw reply
* Re: config for merging master to test branch
From: Daniel Convissor @ 2009-12-29 17:56 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <7vvdfphgbu.fsf@alter.siamese.dyndns.org>
Hi Junio:
> Good. That is how it was designed to be used ;-)
Thanks for the reassurance.
> [branch "test"]
> remote = origin
> merge = refs/heads/master
>
> When on branch "test", "pull" and "fetch" by default interact with the
> "origin" repository, and "pull" integrates what was found on the
> 'master' branch from that remote into your history.
Excellent. Initially, I wasn't sure what the following commands did:
git config branch.test.remote origin
git config branch.test.merge refs/heads/master
Between further reading and your explanation I now understand it better.
"refs/heads/master" refers items displayed by "git show-ref".
So what is "refs/remotes/origin/master", please?
Thanks,
--Dan
--
T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y
data intensive web and database programming
http://www.AnalysisAndSolutions.com/
4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409
^ permalink raw reply
* Re: [PATCH] Documentation: always respect core.worktree if set
From: Robin Rosenberg @ 2009-12-29 17:05 UTC (permalink / raw)
To: Junio C Hamano
Cc: Nguyễn Thái Ngọc Duy, git, Johannes Schindelin,
Robin Rosenberg
In-Reply-To: <7v7hs5hg46.fsf@alter.siamese.dyndns.org>
tisdagen den 29 december 2009 17.58.17 skrev Junio C Hamano:
> Thanks; I'll take this "match documentation to reality with caveats" patch
> for now, but I personally think we should revisit the issue someday.
>
I'm happy with this.
-- robin
^ permalink raw reply
* Re: [PATCH] pull: refuse complete src:dst fetchspec arguments
From: Junio C Hamano @ 2009-12-29 16:58 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Thomas Rast, git
In-Reply-To: <20091229200513.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
> Junio, could you tell us what happened to this thread?
>
> The patch rejects "git pull repo A:B" because it is almost always a mistake;
> I think it makes sense.
It seems that we got sidetracked into a long thread on different (but
interesting) side topics. I think what the patch attempts to do is quite
sane, and the implementation is very straightforward. Perhaps we should
resurrect it, but with a proper "declare deprecation now, first warn then
refuse in two releases" steps. I.e. the actual refusal would happen in
1.7.1 or later.
One side topic was Daniel wondering if we should restrict the value of B
for "git fetch repo A:B" so that "fetch" is not used to update the refs
outside refs/remotes namespace. I personally think it is an unwarranted
restriction, and also it is more or less an unrelated issue anyway.
Another side topic that distracted us was about the difference between the
autogenerated commit log messages for "git pull origin topic" and "git
fetch && git merge origin/topic". I personally think it is very good that
the latter already says "Merge remote branch 'origin/topic'" and there is
no need to turn that into "Merge 'topic' of ..." (actually I'd prefer it
the way it is).
^ permalink raw reply
* Re: [PATCH] Wrap completions in `type git' conditional statement.
From: Junio C Hamano @ 2009-12-29 16:58 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Nanako Shiraishi, Junio C Hamano, Sung Pae, git
In-Reply-To: <20091229150217.GB6152@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> Nanako Shiraishi <nanako3@lavabit.com> wrote:
>> Junio, could you tell us what happened to this thread?
>>
>> The patch avoids failing completion script when git is not there.
>> No discussion.
>
> Actually, that's probably my fault. I never sent an ack or nak,
> or anything else really, on this thread.
>
> Originally this was because the completion was trying to run git
> as it loaded. In 1.6.6 this is no longer true, the completion list
> is generated lazily on demand during the first completion attempt.
>
> With the lazy loading, I didn't see a reason to add this ugly block
> around the entire script.
Thanks, both.
^ permalink raw reply
* Re: [PATCH RFC v2] builtin-push: add --delete as syntactic sugar for :foo
From: Junio C Hamano @ 2009-12-29 16:58 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Jan Krüger, Git ML, Sverre Rabbelier
In-Reply-To: <20091229200523.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
> Junio, could you tell us what happened to this thread?
>
> The patch implements "git push repo --delete branch" and rejects
> --delete used with other options like --all and --tags, as suggested in
> the initial review. I think it makes sense, but nothing happens after
> that.
Sverre cited an old discussion and the discussion stalled. I just re-read
the thread, and think the "this is a wrong idea" objection was primarily
about allowing --delete with non-delete kinds of refspecs, so in that
sense Jan's patch is a perfected form of the Sverre's patch from that old
discussion.
As a summary of the lesson learned and concensus from the old discussion,
I agree with this from Sverre:
http://article.gmane.org/gmane.comp.version-control.git/125901
namely, (1) barf and abort if src:dst is given; (2) touch only refs given
from the command line, "push there --delete" without any refspec is an
error; (3) be careful about "git push there tag v1.0.0" form.
So if Jan or Sverre want to resurrect the topic, I am all for it.
^ permalink raw reply
* Re: Allowing push --dry-run through fetch url
From: Junio C Hamano @ 2009-12-29 16:58 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: git, Mike Hommey
In-Reply-To: <20091229200517.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
> Junio, could you tell us what happened to this thread?
>
> After discussing "git push --dry-run" that looks at URL used for
> fetching, because pushURL might require authentication, the
> maintainer recalls an earlier "git push --confirm" patch
>
> http://thread.gmane.org/gmane.comp.version-control.git/128426/focus=128429
>
> but nothing happens after that.
Your analysis is correct --- nothing happened after that ;-)
I think it is probably worthwhile to revisit Owen's patch, though. Back
then I was worried too much about giving IDE authors (who need to scrape
the output and interact with the "confirm" interface) enough flexibility
and wanted to see an interface to allow plugging a more machine readable
interaction before proceeding, but I changed my mind.
We can have --confirm with two output styles, one that is for consumption
by human sitting in front of a terminal (and is prone to future UI
tinkering like coloring), and the other with machine readable interaction,
that is more or less frozen (or "extensible"). And it is perfectly Ok to
start only with the human readable one, clearly documented that it is not
(yet) for use by IDE via scraping.
But I won't be the person with the --confirm itch, so interested people
need to help to make that happen.
Thanks for a stream of reminders, by the way.
^ permalink raw reply
* Re: [PATCH] Documentation: always respect core.worktree if set
From: Junio C Hamano @ 2009-12-29 16:58 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy
Cc: git, Johannes Schindelin, Robin Rosenberg
In-Reply-To: <1262072921-11280-1-git-send-email-pclouds@gmail.com>
Thanks; I'll take this "match documentation to reality with caveats" patch
for now, but I personally think we should revisit the issue someday.
^ permalink raw reply
* Re: config for merging master to test branch
From: Junio C Hamano @ 2009-12-29 16:53 UTC (permalink / raw)
To: Daniel Convissor; +Cc: Git Mailing List
In-Reply-To: <20091229164343.GA17546@panix.com>
Daniel Convissor <danielc@analysisandsolutions.com> writes:
> On Mon, Dec 28, 2009 at 06:38:39PM -0500, Daniel Convissor wrote:
>>
>> Now, here's the question. I want to go back into the testing directory
>> and do a "git pull" and have the changes from master automatically merged
>> into my test branch in one step, without having to do an explicit set of
>> checkouts and merges.
>
> I found this is possible by being in the "test" checkout and calling
> "git pull origin master". Is this the best way to do it?
Good. That is how it was designed to be used ;-)
If you feel lazy and want to omit typing " origin master", you could add a
few configuration items in your .git/config in the test repository.
[branch "test"]
remote = origin
merge = refs/heads/master
That configures git in such a way that...
When on branch "test", "pull" and "fetch" by default interact with the
"origin" repository, and "pull" integrates what was found on the
'master' branch from that remote into your history.
^ permalink raw reply
* Re: config for merging master to test branch
From: Daniel Convissor @ 2009-12-29 16:43 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <20091228233838.GA28052@panix.com>
Hello Again Folks:
On Mon, Dec 28, 2009 at 06:38:39PM -0500, Daniel Convissor wrote:
>
> Now, here's the question. I want to go back into the testing directory
> and do a "git pull" and have the changes from master automatically merged
> into my test branch in one step, without having to do an explicit set of
> checkouts and merges.
I found this is possible by being in the "test" checkout and calling
"git pull origin master". Is this the best way to do it?
Thanks,
--Dan
--
T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y
data intensive web and database programming
http://www.AnalysisAndSolutions.com/
4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409
^ permalink raw reply
* Re: Help on CGIT
From: Jorge Bastos @ 2009-12-29 15:29 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git
In-Reply-To: <94a0d4530912290658m70075ad1u95e3692c01fb44b7@mail.gmail.com>
> This is what I do:
> ScriptAlias /cgit /var/www/cgit-files/cgit.cgi
>
> You need a new cgit to use that properly, I use 0.8.3.
Forgot to say, i'm running the last git version so i believe i'm updated
for that.
^ permalink raw reply
* Re: Help on CGIT
From: Jorge Bastos @ 2009-12-29 15:21 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git
In-Reply-To: <94a0d4530912290658m70075ad1u95e3692c01fb44b7@mail.gmail.com>
> This is what I do:
> ScriptAlias /cgit /var/www/cgit-files/cgit.cgi
>
> You need a new cgit to use that properly, I use 0.8.3.
I tried that way, no luck, apache always show on the errors that cannot
create the lock slot and it show all unconfigured on the page.
^ permalink raw reply
* Re: [PATCH] Add --path-prefix option to git-fast-import
From: Shawn O. Pearce @ 2009-12-29 15:08 UTC (permalink / raw)
To: Gisle Aas; +Cc: git, gitster, Gisle Aas
In-Reply-To: <1262091083-25401-1-git-send-email-gisle.aas@it.uib.no>
Gisle Aas <gisle.aas@it.uib.no> wrote:
> I found this useful when import multiple external repositories to be merged
> into a single git repo. Not having the files be renamed during the merge
> made it easier to follow the history of the individual files.
>
> Signed-off-by: Gisle Aas <gisle@aas.no>
> ---
> Documentation/git-fast-import.txt | 6 ++++++
> fast-import.c | 24 ++++++++++++++++++++++++
> 2 files changed, 30 insertions(+), 0 deletions(-)
Interesting. Test cases?
> +static const char *path_prefix_prepend(struct strbuf *sb, const char *p)
> +{
> + if (p != sb->buf) {
> + strbuf_reset(sb);
> + strbuf_addstr(sb, p);
> + }
I'd be a bit happier about the change if you could check not only
that p != sb->buf, but that p is not within sb->buf + sb->alloc.
I can't remember if all of the cases below are safe such that
any time you call the function with a p that p isn't pointing to
something within the strbuf you are handing in.
--
Shawn.
^ 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