* [PATCH v2 0/4] delete_ref: support reflog messages
From: Kyle Meyer @ 2017-02-21 1:10 UTC (permalink / raw)
To: Junio C Hamano, Jeff King; +Cc: Kyle Meyer, git
In-Reply-To: <20170217035800.13214-1-kyle@kyleam.com>
Thanks to Junio and Peff for their feedback on v1.
https://public-inbox.org/git/20170217035800.13214-1-kyle@kyleam.com/T/#u
Changes from v1:
* "msg" is now positioned as the first argument to delete_ref() to
match update_ref().
20170217081205.zn7j6d5cffgdvfbn@sigill.intra.peff.net
* A "delete by head" test case has been added for the update-ref
change.
20170217082253.kxjezkxfqkfxjhzr@sigill.intra.peff.net
* The added tests no longer send grep's output to /dev/null.
20170217082253.kxjezkxfqkfxjhzr@sigill.intra.peff.net
* Renaming the current branch is represented by two entries in HEAD's
log, both which reuse the log message passed to rename_ref().
20170217083112.vn7m4udsopmlvnn5@sigill.intra.peff.net,
20170217195549.z6uyy7hbbhj5avh7@sigill.intra.peff.net
* Corrected a few places in the commit messages where "delete_refs"
was written instead of "delete_ref".
Kyle Meyer (4):
delete_ref: accept a reflog message argument
update-ref: pass reflog message to delete_ref()
rename_ref: replace empty message in HEAD's log
branch: record creation of renamed branch in HEAD's log
branch.c | 5 +++--
branch.h | 3 ++-
builtin/am.c | 4 ++--
builtin/branch.c | 7 ++++---
builtin/notes.c | 4 ++--
builtin/remote.c | 4 ++--
builtin/replace.c | 2 +-
builtin/reset.c | 2 +-
builtin/symbolic-ref.c | 2 +-
builtin/tag.c | 2 +-
builtin/update-ref.c | 2 +-
fast-import.c | 2 +-
refs.c | 6 +++---
refs.h | 7 ++++---
refs/files-backend.c | 10 +++++-----
t/t1400-update-ref.sh | 18 ++++++++++++++++++
t/t3200-branch.sh | 6 ++++++
transport.c | 2 +-
18 files changed, 58 insertions(+), 30 deletions(-)
--
2.11.1
^ permalink raw reply
* [PATCH v2 1/4] delete_ref: accept a reflog message argument
From: Kyle Meyer @ 2017-02-21 1:10 UTC (permalink / raw)
To: Junio C Hamano, Jeff King; +Cc: Kyle Meyer, git
In-Reply-To: <20170221011035.847-1-kyle@kyleam.com>
When the current branch is renamed with 'git branch -m/-M' or deleted
with 'git update-ref -m<msg> -d', the event is recorded in HEAD's log
with an empty message. In preparation for adding a more meaningful
message to HEAD's log in these cases, update delete_ref() to take a
message argument and pass it along to ref_transaction_delete().
Modify all callers to pass NULL for the new message argument; no
change in behavior is intended.
Note that this is relevant for HEAD's log but not for the deleted
ref's log, which is currently deleted along with the ref. Even if it
were not, an entry for the deletion wouldn't be present in the deleted
ref's log. files_transaction_commit() writes to the log if
REF_NEEDS_COMMIT or REF_LOG_ONLY are set, but lock_ref_for_update()
doesn't set REF_NEEDS_COMMIT for the deleted ref because REF_DELETING
is set. In contrast, the update for HEAD has REF_LOG_ONLY set by
split_head_update(), resulting in the deletion being logged.
Signed-off-by: Kyle Meyer <kyle@kyleam.com>
---
builtin/am.c | 4 ++--
builtin/branch.c | 2 +-
builtin/notes.c | 4 ++--
builtin/remote.c | 4 ++--
builtin/replace.c | 2 +-
builtin/reset.c | 2 +-
builtin/symbolic-ref.c | 2 +-
builtin/tag.c | 2 +-
builtin/update-ref.c | 2 +-
fast-import.c | 2 +-
refs.c | 6 +++---
refs.h | 4 ++--
refs/files-backend.c | 6 +++---
transport.c | 2 +-
14 files changed, 22 insertions(+), 22 deletions(-)
diff --git a/builtin/am.c b/builtin/am.c
index 31fb60578..f7a7a971f 100644
--- a/builtin/am.c
+++ b/builtin/am.c
@@ -1049,7 +1049,7 @@ static void am_setup(struct am_state *state, enum patch_format patch_format,
} else {
write_state_text(state, "abort-safety", "");
if (!state->rebasing)
- delete_ref("ORIG_HEAD", NULL, 0);
+ delete_ref(NULL, "ORIG_HEAD", NULL, 0);
}
/*
@@ -2172,7 +2172,7 @@ static void am_abort(struct am_state *state)
has_curr_head ? &curr_head : NULL, 0,
UPDATE_REFS_DIE_ON_ERR);
else if (curr_branch)
- delete_ref(curr_branch, NULL, REF_NODEREF);
+ delete_ref(NULL, curr_branch, NULL, REF_NODEREF);
free(curr_branch);
am_destroy(state);
diff --git a/builtin/branch.c b/builtin/branch.c
index 9d30f55b0..8f8242e07 100644
--- a/builtin/branch.c
+++ b/builtin/branch.c
@@ -251,7 +251,7 @@ static int delete_branches(int argc, const char **argv, int force, int kinds,
goto next;
}
- if (delete_ref(name, is_null_sha1(sha1) ? NULL : sha1,
+ if (delete_ref(NULL, name, is_null_sha1(sha1) ? NULL : sha1,
REF_NODEREF)) {
error(remote_branch
? _("Error deleting remote-tracking branch '%s'")
diff --git a/builtin/notes.c b/builtin/notes.c
index 5248a9bad..4b492abd4 100644
--- a/builtin/notes.c
+++ b/builtin/notes.c
@@ -681,9 +681,9 @@ static int merge_abort(struct notes_merge_options *o)
* notes_merge_abort() to remove .git/NOTES_MERGE_WORKTREE.
*/
- if (delete_ref("NOTES_MERGE_PARTIAL", NULL, 0))
+ if (delete_ref(NULL, "NOTES_MERGE_PARTIAL", NULL, 0))
ret += error(_("failed to delete ref NOTES_MERGE_PARTIAL"));
- if (delete_ref("NOTES_MERGE_REF", NULL, REF_NODEREF))
+ if (delete_ref(NULL, "NOTES_MERGE_REF", NULL, REF_NODEREF))
ret += error(_("failed to delete ref NOTES_MERGE_REF"));
if (notes_merge_abort(o))
ret += error(_("failed to remove 'git notes merge' worktree"));
diff --git a/builtin/remote.c b/builtin/remote.c
index 5339ed6ad..2b415911b 100644
--- a/builtin/remote.c
+++ b/builtin/remote.c
@@ -691,7 +691,7 @@ static int mv(int argc, const char **argv)
read_ref_full(item->string, RESOLVE_REF_READING, oid.hash, &flag);
if (!(flag & REF_ISSYMREF))
continue;
- if (delete_ref(item->string, NULL, REF_NODEREF))
+ if (delete_ref(NULL, item->string, NULL, REF_NODEREF))
die(_("deleting '%s' failed"), item->string);
}
for (i = 0; i < remote_branches.nr; i++) {
@@ -1248,7 +1248,7 @@ static int set_head(int argc, const char **argv)
head_name = xstrdup(states.heads.items[0].string);
free_remote_ref_states(&states);
} else if (opt_d && !opt_a && argc == 1) {
- if (delete_ref(buf.buf, NULL, REF_NODEREF))
+ if (delete_ref(NULL, buf.buf, NULL, REF_NODEREF))
result |= error(_("Could not delete %s"), buf.buf);
} else
usage_with_options(builtin_remote_sethead_usage, options);
diff --git a/builtin/replace.c b/builtin/replace.c
index b58c714cb..226d0f952 100644
--- a/builtin/replace.c
+++ b/builtin/replace.c
@@ -121,7 +121,7 @@ static int for_each_replace_name(const char **argv, each_replace_name_fn fn)
static int delete_replace_ref(const char *name, const char *ref,
const unsigned char *sha1)
{
- if (delete_ref(ref, sha1, 0))
+ if (delete_ref(NULL, ref, sha1, 0))
return 1;
printf("Deleted replace ref '%s'\n", name);
return 0;
diff --git a/builtin/reset.c b/builtin/reset.c
index 8ab915bfc..fc3b906c4 100644
--- a/builtin/reset.c
+++ b/builtin/reset.c
@@ -256,7 +256,7 @@ static int reset_refs(const char *rev, const struct object_id *oid)
update_ref_oid(msg.buf, "ORIG_HEAD", orig, old_orig, 0,
UPDATE_REFS_MSG_ON_ERR);
} else if (old_orig)
- delete_ref("ORIG_HEAD", old_orig->hash, 0);
+ delete_ref(NULL, "ORIG_HEAD", old_orig->hash, 0);
set_reflog_message(&msg, "updating HEAD", rev);
update_ref_status = update_ref_oid(msg.buf, "HEAD", oid, orig, 0,
UPDATE_REFS_MSG_ON_ERR);
diff --git a/builtin/symbolic-ref.c b/builtin/symbolic-ref.c
index 96eed9446..70addef15 100644
--- a/builtin/symbolic-ref.c
+++ b/builtin/symbolic-ref.c
@@ -58,7 +58,7 @@ int cmd_symbolic_ref(int argc, const char **argv, const char *prefix)
die("Cannot delete %s, not a symbolic ref", argv[0]);
if (!strcmp(argv[0], "HEAD"))
die("deleting '%s' is not allowed", argv[0]);
- return delete_ref(argv[0], NULL, REF_NODEREF);
+ return delete_ref(NULL, argv[0], NULL, REF_NODEREF);
}
switch (argc) {
diff --git a/builtin/tag.c b/builtin/tag.c
index e40c4a967..c23d6d4bc 100644
--- a/builtin/tag.c
+++ b/builtin/tag.c
@@ -97,7 +97,7 @@ static int for_each_tag_name(const char **argv, each_tag_name_fn fn,
static int delete_tag(const char *name, const char *ref,
const unsigned char *sha1, const void *cb_data)
{
- if (delete_ref(ref, sha1, 0))
+ if (delete_ref(NULL, ref, sha1, 0))
return 1;
printf(_("Deleted tag '%s' (was %s)\n"), name, find_unique_abbrev(sha1, DEFAULT_ABBREV));
return 0;
diff --git a/builtin/update-ref.c b/builtin/update-ref.c
index 7f30d3a76..86d006d36 100644
--- a/builtin/update-ref.c
+++ b/builtin/update-ref.c
@@ -433,7 +433,7 @@ int cmd_update_ref(int argc, const char **argv, const char *prefix)
* For purposes of backwards compatibility, we treat
* NULL_SHA1 as "don't care" here:
*/
- return delete_ref(refname,
+ return delete_ref(NULL, refname,
(oldval && !is_null_sha1(oldsha1)) ? oldsha1 : NULL,
flags);
else
diff --git a/fast-import.c b/fast-import.c
index 64fe602f0..6c13472c4 100644
--- a/fast-import.c
+++ b/fast-import.c
@@ -1752,7 +1752,7 @@ static int update_branch(struct branch *b)
if (is_null_sha1(b->sha1)) {
if (b->delete)
- delete_ref(b->name, NULL, 0);
+ delete_ref(NULL, b->name, NULL, 0);
return 0;
}
if (read_ref(b->name, old_sha1))
diff --git a/refs.c b/refs.c
index cd36b64ed..053d23a90 100644
--- a/refs.c
+++ b/refs.c
@@ -591,8 +591,8 @@ static int delete_pseudoref(const char *pseudoref, const unsigned char *old_sha1
return 0;
}
-int delete_ref(const char *refname, const unsigned char *old_sha1,
- unsigned int flags)
+int delete_ref(const char *msg, const char *refname,
+ const unsigned char *old_sha1, unsigned int flags)
{
struct ref_transaction *transaction;
struct strbuf err = STRBUF_INIT;
@@ -603,7 +603,7 @@ int delete_ref(const char *refname, const unsigned char *old_sha1,
transaction = ref_transaction_begin(&err);
if (!transaction ||
ref_transaction_delete(transaction, refname, old_sha1,
- flags, NULL, &err) ||
+ flags, msg, &err) ||
ref_transaction_commit(transaction, &err)) {
error("%s", err.buf);
ref_transaction_free(transaction);
diff --git a/refs.h b/refs.h
index 9fbff90e7..5880886a7 100644
--- a/refs.h
+++ b/refs.h
@@ -276,8 +276,8 @@ int reflog_exists(const char *refname);
* exists, regardless of its old value. It is an error for old_sha1 to
* be NULL_SHA1. flags is passed through to ref_transaction_delete().
*/
-int delete_ref(const char *refname, const unsigned char *old_sha1,
- unsigned int flags);
+int delete_ref(const char *msg, const char *refname,
+ const unsigned char *old_sha1, unsigned int flags);
/*
* Delete the specified references. If there are any problems, emit
diff --git a/refs/files-backend.c b/refs/files-backend.c
index c041d4ba2..299eb4d8a 100644
--- a/refs/files-backend.c
+++ b/refs/files-backend.c
@@ -2489,7 +2489,7 @@ static int files_delete_refs(struct ref_store *ref_store,
for (i = 0; i < refnames->nr; i++) {
const char *refname = refnames->items[i].string;
- if (delete_ref(refname, NULL, flags))
+ if (delete_ref(NULL, refname, NULL, flags))
result |= error(_("could not remove reference %s"), refname);
}
@@ -2616,7 +2616,7 @@ static int files_rename_ref(struct ref_store *ref_store,
return error("unable to move logfile logs/%s to "TMP_RENAMED_LOG": %s",
oldrefname, strerror(errno));
- if (delete_ref(oldrefname, orig_sha1, REF_NODEREF)) {
+ if (delete_ref(NULL, oldrefname, orig_sha1, REF_NODEREF)) {
error("unable to delete old %s", oldrefname);
goto rollback;
}
@@ -2630,7 +2630,7 @@ static int files_rename_ref(struct ref_store *ref_store,
*/
if (!read_ref_full(newrefname, RESOLVE_REF_READING | RESOLVE_REF_NO_RECURSE,
sha1, NULL) &&
- delete_ref(newrefname, NULL, REF_NODEREF)) {
+ delete_ref(NULL, newrefname, NULL, REF_NODEREF)) {
if (errno==EISDIR) {
struct strbuf path = STRBUF_INIT;
int result;
diff --git a/transport.c b/transport.c
index d72e08948..269352b22 100644
--- a/transport.c
+++ b/transport.c
@@ -299,7 +299,7 @@ void transport_update_tracking_ref(struct remote *remote, struct ref *ref, int v
if (verbose)
fprintf(stderr, "updating local tracking ref '%s'\n", rs.dst);
if (ref->deletion) {
- delete_ref(rs.dst, NULL, 0);
+ delete_ref(NULL, rs.dst, NULL, 0);
} else
update_ref("update by push", rs.dst,
ref->new_oid.hash, NULL, 0, 0);
--
2.11.1
^ permalink raw reply related
* [PATCH v2 2/4] update-ref: pass reflog message to delete_ref()
From: Kyle Meyer @ 2017-02-21 1:10 UTC (permalink / raw)
To: Junio C Hamano, Jeff King; +Cc: Kyle Meyer, git
In-Reply-To: <20170221011035.847-1-kyle@kyleam.com>
Now that delete_ref() accepts a reflog message, pass the user-provided
message to delete_ref() rather than silently dropping it.
Signed-off-by: Kyle Meyer <kyle@kyleam.com>
---
builtin/update-ref.c | 2 +-
t/t1400-update-ref.sh | 18 ++++++++++++++++++
2 files changed, 19 insertions(+), 1 deletion(-)
diff --git a/builtin/update-ref.c b/builtin/update-ref.c
index 86d006d36..0b2ecf41a 100644
--- a/builtin/update-ref.c
+++ b/builtin/update-ref.c
@@ -433,7 +433,7 @@ int cmd_update_ref(int argc, const char **argv, const char *prefix)
* For purposes of backwards compatibility, we treat
* NULL_SHA1 as "don't care" here:
*/
- return delete_ref(NULL, refname,
+ return delete_ref(msg, refname,
(oldval && !is_null_sha1(oldsha1)) ? oldsha1 : NULL,
flags);
else
diff --git a/t/t1400-update-ref.sh b/t/t1400-update-ref.sh
index b0ffc0b57..6e112fb5f 100755
--- a/t/t1400-update-ref.sh
+++ b/t/t1400-update-ref.sh
@@ -85,6 +85,24 @@ test_expect_success "delete $m (by HEAD)" '
'
rm -f .git/$m
+test_expect_success "deleting current branch adds message to HEAD's log" '
+ git update-ref $m $A &&
+ git symbolic-ref HEAD $m &&
+ git update-ref -m delete-$m -d $m &&
+ ! test -f .git/$m &&
+ grep "delete-$m$" .git/logs/HEAD
+'
+rm -f .git/$m
+
+test_expect_success "deleting by HEAD adds message to HEAD's log" '
+ git update-ref $m $A &&
+ git symbolic-ref HEAD $m &&
+ git update-ref -m delete-by-head -d HEAD &&
+ ! test -f .git/$m &&
+ grep "delete-by-head$" .git/logs/HEAD
+'
+rm -f .git/$m
+
test_expect_success 'update-ref does not create reflogs by default' '
test_when_finished "git update-ref -d $outside" &&
git update-ref $outside $A &&
--
2.11.1
^ permalink raw reply related
* [PATCH v2 4/4] branch: record creation of renamed branch in HEAD's log
From: Kyle Meyer @ 2017-02-21 1:10 UTC (permalink / raw)
To: Junio C Hamano, Jeff King; +Cc: Kyle Meyer, git
In-Reply-To: <20170221011035.847-1-kyle@kyleam.com>
Renaming the current branch adds an event to the current branch's log
and to HEAD's log. However, the logged entries differ. The entry in
the branch's log represents the entire renaming operation (the old and
new hash are identical), whereas the entry in HEAD's log represents
the deletion only (the new sha1 is null).
Extend replace_each_worktree_head_symref(), whose only caller is
branch_rename(), to take a reflog message argument. This allows the
creation of the new ref to be recorded in HEAD's log. As a result,
the renaming event is represented by two entries (a deletion and a
creation entry) in HEAD's log.
It's a bit unfortunate that the branch's log and HEAD's log now
represent the renaming event in different ways. Given that the
renaming operation is not atomic, the two-entry form is a more
accurate representation of the operation and is more useful for
debugging purposes if a failure occurs between the deletion and
creation events. It would make sense to move the branch's log to the
two-entry form, but this would involve changes to how the rename is
carried out and to how the update flags and reflogs are processed for
deletions, so it may not be worth the effort.
Based-on-patch-by: Jeff King <peff@peff.net>
Signed-off-by: Kyle Meyer <kyle@kyleam.com>
---
branch.c | 5 +++--
branch.h | 3 ++-
builtin/branch.c | 5 +++--
refs.h | 3 ++-
refs/files-backend.c | 4 ++--
t/t3200-branch.sh | 5 +++--
6 files changed, 15 insertions(+), 10 deletions(-)
diff --git a/branch.c b/branch.c
index b955d4f31..5c12036b0 100644
--- a/branch.c
+++ b/branch.c
@@ -345,7 +345,8 @@ void die_if_checked_out(const char *branch, int ignore_current_worktree)
branch, wt->path);
}
-int replace_each_worktree_head_symref(const char *oldref, const char *newref)
+int replace_each_worktree_head_symref(const char *oldref, const char *newref,
+ const char *logmsg)
{
int ret = 0;
struct worktree **worktrees = get_worktrees(0);
@@ -358,7 +359,7 @@ int replace_each_worktree_head_symref(const char *oldref, const char *newref)
continue;
if (set_worktree_head_symref(get_worktree_git_dir(worktrees[i]),
- newref)) {
+ newref, logmsg)) {
ret = -1;
error(_("HEAD of working tree %s is not updated"),
worktrees[i]->path);
diff --git a/branch.h b/branch.h
index 3103eb9ad..b07788558 100644
--- a/branch.h
+++ b/branch.h
@@ -71,6 +71,7 @@ extern void die_if_checked_out(const char *branch, int ignore_current_worktree);
* This will be used when renaming a branch. Returns 0 if successful, non-zero
* otherwise.
*/
-extern int replace_each_worktree_head_symref(const char *oldref, const char *newref);
+extern int replace_each_worktree_head_symref(const char *oldref, const char *newref,
+ const char *logmsg);
#endif
diff --git a/builtin/branch.c b/builtin/branch.c
index 8f8242e07..e1f97dcfc 100644
--- a/builtin/branch.c
+++ b/builtin/branch.c
@@ -579,14 +579,15 @@ static void rename_branch(const char *oldname, const char *newname, int force)
if (rename_ref(oldref.buf, newref.buf, logmsg.buf))
die(_("Branch rename failed"));
- strbuf_release(&logmsg);
if (recovery)
warning(_("Renamed a misnamed branch '%s' away"), oldref.buf + 11);
- if (replace_each_worktree_head_symref(oldref.buf, newref.buf))
+ if (replace_each_worktree_head_symref(oldref.buf, newref.buf, logmsg.buf))
die(_("Branch renamed to %s, but HEAD is not updated!"), newname);
+ strbuf_release(&logmsg);
+
strbuf_addf(&oldsection, "branch.%s", oldref.buf + 11);
strbuf_release(&oldref);
strbuf_addf(&newsection, "branch.%s", newref.buf + 11);
diff --git a/refs.h b/refs.h
index 5880886a7..e529f4c3a 100644
--- a/refs.h
+++ b/refs.h
@@ -334,7 +334,8 @@ int create_symref(const char *refname, const char *target, const char *logmsg);
* $GIT_DIR points to.
* Return 0 if successful, non-zero otherwise.
* */
-int set_worktree_head_symref(const char *gitdir, const char *target);
+int set_worktree_head_symref(const char *gitdir, const char *target,
+ const char *logmsg);
enum action_on_err {
UPDATE_REFS_MSG_ON_ERR,
diff --git a/refs/files-backend.c b/refs/files-backend.c
index f6e7c192c..42b137bb1 100644
--- a/refs/files-backend.c
+++ b/refs/files-backend.c
@@ -3055,7 +3055,7 @@ static int files_create_symref(struct ref_store *ref_store,
return ret;
}
-int set_worktree_head_symref(const char *gitdir, const char *target)
+int set_worktree_head_symref(const char *gitdir, const char *target, const char *logmsg)
{
static struct lock_file head_lock;
struct ref_lock *lock;
@@ -3083,7 +3083,7 @@ int set_worktree_head_symref(const char *gitdir, const char *target)
lock->lk = &head_lock;
lock->ref_name = xstrdup(head_rel);
- ret = create_symref_locked(lock, head_rel, target, NULL);
+ ret = create_symref_locked(lock, head_rel, target, logmsg);
unlock_ref(lock); /* will free lock */
strbuf_release(&head_path);
diff --git a/t/t3200-branch.sh b/t/t3200-branch.sh
index 0dbc54003..d84837d08 100755
--- a/t/t3200-branch.sh
+++ b/t/t3200-branch.sh
@@ -139,9 +139,10 @@ test_expect_success 'git branch -M baz bam should succeed when baz is checked ou
test $(git rev-parse --abbrev-ref HEAD) = bam
'
-test_expect_success 'git branch -M baz bam should add entry to .git/logs/HEAD' '
+test_expect_success 'git branch -M baz bam should add entries to .git/logs/HEAD' '
msg="Branch: renamed refs/heads/baz to refs/heads/bam" &&
- grep " 0\{40\}.*$msg$" .git/logs/HEAD
+ grep " 0\{40\}.*$msg$" .git/logs/HEAD &&
+ grep "^0\{40\}.*$msg$" .git/logs/HEAD
'
test_expect_success 'git branch -M baz bam should succeed when baz is checked out as linked working tree' '
--
2.11.1
^ permalink raw reply related
* [PATCH v2 3/4] rename_ref: replace empty message in HEAD's log
From: Kyle Meyer @ 2017-02-21 1:10 UTC (permalink / raw)
To: Junio C Hamano, Jeff King; +Cc: Kyle Meyer, git
In-Reply-To: <20170221011035.847-1-kyle@kyleam.com>
When the current branch is renamed, the deletion of the old ref is
recorded in HEAD's log with an empty message. Now that delete_ref()
accepts a reflog message, provide a more descriptive message by
passing along the log message that is given to rename_ref().
The next step will be to extend HEAD's log to also include the second
part of the rename, the creation of the new branch.
Helped-by: Jeff King <peff@peff.net>
Signed-off-by: Kyle Meyer <kyle@kyleam.com>
---
refs/files-backend.c | 2 +-
t/t3200-branch.sh | 5 +++++
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/refs/files-backend.c b/refs/files-backend.c
index 299eb4d8a..f6e7c192c 100644
--- a/refs/files-backend.c
+++ b/refs/files-backend.c
@@ -2616,7 +2616,7 @@ static int files_rename_ref(struct ref_store *ref_store,
return error("unable to move logfile logs/%s to "TMP_RENAMED_LOG": %s",
oldrefname, strerror(errno));
- if (delete_ref(NULL, oldrefname, orig_sha1, REF_NODEREF)) {
+ if (delete_ref(logmsg, oldrefname, orig_sha1, REF_NODEREF)) {
error("unable to delete old %s", oldrefname);
goto rollback;
}
diff --git a/t/t3200-branch.sh b/t/t3200-branch.sh
index 8a833f354..0dbc54003 100755
--- a/t/t3200-branch.sh
+++ b/t/t3200-branch.sh
@@ -139,6 +139,11 @@ test_expect_success 'git branch -M baz bam should succeed when baz is checked ou
test $(git rev-parse --abbrev-ref HEAD) = bam
'
+test_expect_success 'git branch -M baz bam should add entry to .git/logs/HEAD' '
+ msg="Branch: renamed refs/heads/baz to refs/heads/bam" &&
+ grep " 0\{40\}.*$msg$" .git/logs/HEAD
+'
+
test_expect_success 'git branch -M baz bam should succeed when baz is checked out as linked working tree' '
git checkout master &&
git worktree add -b baz bazdir &&
--
2.11.1
^ permalink raw reply related
* Re: [PATCH v4 03/19] builtin/diff-tree: convert to struct object_id
From: brian m. carlson @ 2017-02-21 1:10 UTC (permalink / raw)
To: Jeff King; +Cc: git, Michael Haggerty, Junio C Hamano, Ramsay Jones
In-Reply-To: <20170221010836.nuv6uvyzatql2yyu@sigill.intra.peff.net>
[-- Attachment #1: Type: text/plain, Size: 822 bytes --]
On Mon, Feb 20, 2017 at 08:08:36PM -0500, Jeff King wrote:
> On Tue, Feb 21, 2017 at 12:25:19AM +0000, brian m. carlson wrote:
>
> > On Mon, Feb 20, 2017 at 03:09:02AM -0500, Jeff King wrote:
> > > It's a little disturbing that we do not seem to have even a basic test
> > > of:
> > >
> > > git rev-list --parents HEAD | git diff-tree --stdin
> > >
> > > which would exercise this code.
> >
> > I'm unsure, so I'll add a test. The only way to know if it works is to
> > test it.
>
> Not to spoil the ending, but I did test and it does not work. :)
Well, then I suppose I'll also end up sending out a new patch series. :)
--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | https://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: https://keybase.io/bk2204
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 868 bytes --]
^ permalink raw reply
* Re: slightly confusing message
From: Leon George @ 2017-02-21 2:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Brandon Williams
In-Reply-To: <xmqq1susk43m.fsf@gitster.mtv.corp.google.com>
Hello
and thank you for your time.
On 20/02/17 21:19, Junio C Hamano wrote:
> This sounds vaguely familiar and indeed I think it is this one:
> https://public-inbox.org/git/CAEnOLdvG=SoKFxeJ_pLmamGj_8osC+28TSg+pbFLLTr+ZLcpQA@mail.gmail.com/
> which was from late last year.
Which means I should have found it before bothering you.
> I suspect that the issue may already be fixed at the tip of 'master'
> (aka Git 2.12-rc2).
You're absolutely right. Took a while to build, but here goes:
£ git gitss
?? test
£ git --version
git version 2.11.0
£ git add -p .
warning: empty strings as pathspecs will be made invalid in upcoming
releases. please use . instead if you meant to match all paths
No changes.
£ git --version
git version 2.12.0-rc2
£ git add -p .
No changes.
Splendid!
have a wonderfull day :-)
^ permalink raw reply
* Re: slightly confusing message
From: Junio C Hamano @ 2017-02-21 2:22 UTC (permalink / raw)
To: Leon George; +Cc: git, Brandon Williams
In-Reply-To: <8e66c3be-7cd9-d72c-123f-308b63ddc1bd@georgemail.eu>
Leon George <leon@georgemail.eu> writes:
> On 20/02/17 21:19, Junio C Hamano wrote:
>> This sounds vaguely familiar and indeed I think it is this one:
>> https://public-inbox.org/git/CAEnOLdvG=SoKFxeJ_pLmamGj_8osC+28TSg+pbFLLTr+ZLcpQA@mail.gmail.com/
>> which was from late last year.
> Which means I should have found it before bothering you.
It means no such thing, though. It just means that I happen to be
more familiar with what has gone on the development recently than
you were ;-)
>> I suspect that the issue may already be fixed at the tip of 'master'
>> (aka Git 2.12-rc2).
> You're absolutely right. Took a while to build, but here goes:
> ...
> Splendid!
Thanks for confirming.
^ permalink raw reply
* git svn find-rev -- search for nearest SVN rev
From: Craig McQueen @ 2017-02-21 2:54 UTC (permalink / raw)
To: git@vger.kernel.org
I'm using git svn with a project that uses SubWCRev.exe to incorporate the SVN revision into the build number.
I've updated it to use 'git svn find-rev HEAD' in git svn usage, to achieve the same effect.
This works until I have a local commit that hasn't yet been pushed to SVN with 'git svn dcommit'. Then, 'git svn find-rev HEAD' returns nothing.
It would be really great if the '--before' and '--after' switches would work in this case. Then I could use 'git svn find-rev --before HEAD'.
--
Craig McQueen
^ permalink raw reply
* Re: [PATCH] git-svn: escape backslashes in refnames
From: Eric Wong @ 2017-02-21 4:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Michael Fladischer
In-Reply-To: <20161223014202.GA8327@starla>
Junio: ping?
https://public-inbox.org/git/20161223014202.GA8327@starla/raw
Thanks.
^ permalink raw reply
* Re: url.<base>.insteadOf vs. submodules
From: Toolforger @ 2017-02-21 5:11 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20170220205243.lynnmxouwq7jelld@sigill.intra.peff.net>
On 20.02.2017 21:52, Jeff King wrote:
> I think if there is a doc bug, it is that the repo boundary between the
> submodule and the super-project is not made more clear.
It's not mentioned anywhere I'm aware of, particularly not on the
insteadOf docs.
> That said, I do think it would be a useful feature for the super-project
> to rewrite URLs before handing them off to the submodule. But I do not
> really work on submodules nor use them myself, so there may be
> complications.
Agreed.
> I suppose you could argue that failing to rewrite violates the "any" in
> the quoted text. It doesn't say when the rewriting occurs, but it is
> essentially "when the URL is accessed". So the super-project feeds the
> raw URL to the submodule `git clone`, which then applies any URL
> rewriting.
>>> but one workaround is to set the config in ~/.gitconfig.
>>
>> No can do - that's under version control.
>> My personal setup does not belong there I think ;-)
>
> I'm not sure I understand. You have a project policy to use certain
> URLs. But you, the user, want to override that. Why isn't the
> user-specific config file the right place to put that?
Ah right, I mistook ~/ for "project root" instead of "home dir".
Sorry for the confusion.
> (I think there _is_ a mismatch, in that the change is specific not just
> to your user, but to the repo. So you would not want to rewrite other
> references to the same URL in other repos.
Indeed, and that's actually a problem.
The setup I'm aiming for is
github -> local bare repo -> local clones with worktrees
If I place insteadOf rules in ~/.gitconfig, I will be unable to pull
from github to my local bare repos.
Mmm... I could try to undo the insteadOf configuration from ~/.gitconfig
in the local bare repos. Not sure whether I have to redirect from the
github URL to itself.
Downside is that I'll have to remember to modify ~/.gitconfig whenever
the upstream project changes its dependencies. Or whenever I want to
reorganize my local project directory structure.
It's not totally out of the window, but right now it does not seem very
attractive to me, and it's certainly not a good solution for everyone.
Regards,
Jo
^ permalink raw reply
* Re: Sending informational messages from upload-pack
From: Lukas Fleischer @ 2017-02-21 5:59 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20170220192103.6v66lpghgir3erhn@sigill.intra.peff.net>
On Mon, 20 Feb 2017 at 20:21:03, Jeff King wrote:
> On Mon, Feb 20, 2017 at 07:38:02PM +0100, Lukas Fleischer wrote:
>
> > It would be handy to be able to show a message to the user when
> > cloning/fetching from a repository (e.g. to show a warning if a
> > repository is deprecated). This should technically already be possible
> > using the current pack protocol and sidebands. However, to my knowledge,
> > there is no easy way to configure this on the server side; writing a
> > wrapper around git-upload-pack(1) or replacing git-upload-pack(1) seem
> > to be the only options.
>
> I wouldn't recommend wrapping upload-pack. You don't know you have a
> sideband until partway through the upload-pack conversation. And clients
> do not expect sideband at all until we get to the pack-sending part of
> the protocol (I think; I just quickly verified the location of the
> demuxer async code in fetch-pack.c, but I didn't dig into it in depth).
By wrapper I meant something that understands the pack protocol itself,
intercepts the traffic, forwards most of it to git-upload-pack(1) and
injects the message at the right time. I agree that it is a fairly ugly
workaround, though.
> [...]
> If my fetch-pack assertion above is right, technically the hook added by
> 20b20a22f is sufficient for your purposes, if your hook looks like:
>
> echo >&2 "pre-pack message"
> git pack-objects "$@"
> echo >72 "post-pack message"
>
> but I would not be opposed to having pre-/post- hooks that run
> separately, if only for the convenience of the admin.
> [...]
I will give it a try. And I agree that it would still be convenient to
have pre-upload-pack and post-upload-pack hooks.
Regards,
Lukas
^ permalink raw reply
* Re: [PATCH] git-svn: escape backslashes in refnames
From: Junio C Hamano @ 2017-02-21 6:02 UTC (permalink / raw)
To: Eric Wong; +Cc: git, Michael Fladischer
In-Reply-To: <20170221045420.GA24048@whir>
Eric Wong <e@80x24.org> writes:
> Junio: ping?
>
> https://public-inbox.org/git/20161223014202.GA8327@starla/raw
>
> Thanks.
Thanks for reminding. This indeed fell thru cracks.
^ permalink raw reply
* Re: Inconsistent results of git blame --porcelain when detecting copies from other files
From: Junio C Hamano @ 2017-02-21 6:08 UTC (permalink / raw)
To: Jeff King; +Cc: Sokolov, Konstantin, git@vger.kernel.org
In-Reply-To: <20170220221540.6vemjdvyvwonpqyt@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> The simplest way (IMHO) to parse --porcelain output is:
>
> - maintain a mapping of commit sha1s to the commit's details
>
> - whenever you see a "<sha1> <line_nr> <orig_nr> [<size-of-hunk>]"
> line, any key-value fields which follow impact _only_ that sha1, and
> you should update the details for that map entry
>
> - when you see the actual tab-indented line content, you have gotten
> all of the key-value updates for that sha1. You can now safely do
> what you like with the line entry.
Yup, that was how the output was meant to be read. At least in the
mind of the person who designed the output format ;-)
^ permalink raw reply
* Re: [PATCH] fetch: print an error when declining to request an unadvertised object
From: Junio C Hamano @ 2017-02-21 6:36 UTC (permalink / raw)
To: Matt McCutchen; +Cc: git
In-Reply-To: <1487470080.3570.8.camel@mattmccutchen.net>
Matt McCutchen <matt@mattmccutchen.net> writes:
> Currently "git fetch REMOTE SHA1" silently exits 1 if the server doesn't
> allow requests for unadvertised objects by sha1. The more common case
> of requesting a nonexistent ref normally triggers a die() in
> get_fetch_map, so "git fetch" wasn't bothering to check after the fetch
> that it got all the refs it sought, like "git fetch-pack" does near the
> end of cmd_fetch_pack.
>
> Move the code from cmd_fetch_pack to a new function,
> report_unmatched_refs, that is called by fetch_refs_via_pack as part of
> "git fetch". Also, change filter_refs (which checks whether a request
> for an unadvertised object should be sent to the server) to set a new
> match status on the "struct ref" when the request is not allowed, and
> have report_unmatched_refs check for this status and print a special
> error message, "Server does not allow request for unadvertised object".
>
> Finally, add a simple test case for "git fetch REMOTE SHA1".
>
> Signed-off-by: Matt McCutchen <matt@mattmccutchen.net>
> ---
Hmph, I would have expected this to be done as a three-patch series,
* move the loop at the end of cmd_fetch_pack() to a separate helper
function report_unmatched_refs() and call it;
* add a call to report_unmatched_refs() to the transport layer;
* enhance report_unmatched_refs() by introducing match_status
field and adding new code to filter_refs() to diagnose other
kinds of errors.
The result looks reasonable from a cursory read, though.
Thanks for following it up to the completion.
^ permalink raw reply
* Re: url.<base>.insteadOf vs. submodules
From: Jeff King @ 2017-02-21 7:06 UTC (permalink / raw)
To: Toolforger; +Cc: git
In-Reply-To: <28fb85d4-89cd-1f32-3063-2f48d8b935be@durchholz.org>
On Tue, Feb 21, 2017 at 06:11:51AM +0100, Toolforger wrote:
> > I'm not sure I understand. You have a project policy to use certain
> > URLs. But you, the user, want to override that. Why isn't the
> > user-specific config file the right place to put that?
>
> Ah right, I mistook ~/ for "project root" instead of "home dir".
> Sorry for the confusion.
Ah, OK, that makes more sense.
> > (I think there _is_ a mismatch, in that the change is specific not just
> > to your user, but to the repo. So you would not want to rewrite other
> > references to the same URL in other repos.
>
> Indeed, and that's actually a problem.
>
> The setup I'm aiming for is
> github -> local bare repo -> local clones with worktrees
>
> If I place insteadOf rules in ~/.gitconfig, I will be unable to pull from
> github to my local bare repos.
> Mmm... I could try to undo the insteadOf configuration from ~/.gitconfig in
> the local bare repos. Not sure whether I have to redirect from the github
> URL to itself.
Yeah, I think you would probably have to do a redirect-to-self to
override the global one.
At one point we discussed having conditional-config that would kick in
based on path-matching. I think it would be another way to do what you
want, but there's nothing merged.
I think anything involving ~/.gitconfig is basically a hack, though.
What you really want is for submodules to better support your
URL-rewriting case, and that's not an unreasonable thing to want.
We'll see if the submodule folks have any ideas on how to implement
that.
-Peff
^ permalink raw reply
* Re: [PATCH v2 0/4] delete_ref: support reflog messages
From: Jeff King @ 2017-02-21 7:12 UTC (permalink / raw)
To: Kyle Meyer; +Cc: Junio C Hamano, git
In-Reply-To: <20170221011035.847-1-kyle@kyleam.com>
On Mon, Feb 20, 2017 at 08:10:31PM -0500, Kyle Meyer wrote:
> Kyle Meyer (4):
> delete_ref: accept a reflog message argument
> update-ref: pass reflog message to delete_ref()
> rename_ref: replace empty message in HEAD's log
> branch: record creation of renamed branch in HEAD's log
These look good to me. I think you did a nice job of summarizing the
discussion in the commit messages.
-Peff
^ permalink raw reply
* Re: [PATCH v2 0/4] delete_ref: support reflog messages
From: Junio C Hamano @ 2017-02-21 7:18 UTC (permalink / raw)
To: Kyle Meyer; +Cc: Jeff King, git
In-Reply-To: <20170221011035.847-1-kyle@kyleam.com>
Kyle Meyer <kyle@kyleam.com> writes:
> Kyle Meyer (4):
> delete_ref: accept a reflog message argument
> update-ref: pass reflog message to delete_ref()
> rename_ref: replace empty message in HEAD's log
> branch: record creation of renamed branch in HEAD's log
These looked reasonable. I had to resolve conflicts with another
topic in flight that removed set_worktree_head_symref() function
while queuing, and I think I resolved it correctly, but please
double check what is pushed out on 'pu'.
Thanks.
^ permalink raw reply
* Re: [PATCH] config: preserve <subsection> case for one-shot config on the command line
From: Jeff King @ 2017-02-21 7:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Lars Schneider, Jonathan Tan, git, sbeller
In-Reply-To: <xmqqino5jia8.fsf@gitster.mtv.corp.google.com>
On Mon, Feb 20, 2017 at 01:58:07AM -0800, Junio C Hamano wrote:
> Since nothing seems to have happened in the meantime, here is what
> I'll queue so that we won't forget for now. Lars's tests based on
> how the scripted "git submodule" uses "git config" may still be
> valid, but it is somewhat a roundabout way to demonstrate the
> breakage and not very effective way to protect the fix, so I added a
> new test that directly tests "git -c <var>=<val> <command>".
Yeah, I agree that is the best way to cover this code.
> I am not sure if this updated one is worth doing, or the previous
> "strchr and strrchr" I originally wrote was easier to understand.
I think either is OK. I would actually have written it halfway in
between, like:
static void canonicalize_config_variable_name(char *varname)
{
const char *p;
/* downcase the first segment */
for (p = varname; *p; p++) {
if (*p == '.')
break;
*p = tolower(*p);
}
/* locate end of middle segment, if there is one */
p = strrchr(p, '.');
if (!p)
return; /* invalid single-level var, but let it pass */
for (; *p; p++)
*p = tolower(*p);
}
You can toss that on the bikeshed heap. :)
The other change from yours is that it flips the order of the strrchr
and return. Yours is more efficient in the sense that we know there is
no dot, so we do not have to keep searching at all (though of course
this case is invalid and we would not expect to see it in practice).
But it did take me a minute in yours to figure out why last_dot was
always set to a dot (the answer is that it starts at "cp", which must
itself be a dot, because we would already have returned otherwise).
> One thing I noticed is that "git config --get X" will correctly
> diagnose that a dot-less X is not a valid variable name, but we do
> not seem to diagnose "git -c X=V <cmd>" as invalid.
I don't think that was intentional. We just never caught the case. It
might be reasonable to do so (and it's easy to catch here while
canonicalizing). I think there are probably some other cases we _could_
catch, too (e.g., invalid characters for keynames). But I'm not excited
about duplicating the logic from the file-parser.
> Perhaps we should, but it is not the focus of this topic.
Definitely.
> diff --git a/t/t1351-config-cmdline.sh b/t/t1351-config-cmdline.sh
> new file mode 100755
> index 0000000000..acb8dc3b15
> --- /dev/null
> +++ b/t/t1351-config-cmdline.sh
> @@ -0,0 +1,48 @@
> +#!/bin/sh
> +
> +test_description='git -c var=val'
> +
> +. ./test-lib.sh
There are a bunch of other "git -c" tests inside t1300. I don't know if
it would be better to put them all together.
Arguably, those other ones should get pulled out here to the new script.
More scripts means that the tests have fewer hidden dependencies, and we
can parallelize the run more. I admit I've shied away from new scripts
in the past because the number allocation is such a pain.
> +test_expect_success 'last one wins: two level vars' '
> + echo VAL >expect &&
> +
> + # sec.var and sec.VAR are the same variable, as the first
> + # and the last level of a configuration variable name is
> + # case insensitive. Test both setting and querying.
I assume by "setting and querying" here you mean "setting via -c,
querying via git-config".
> + git -c sec.var=val -c sec.VAR=VAL config --get sec.var >actual &&
> + test_cmp expect actual &&
> + git -c SEC.var=val -c sec.var=VAL config --get sec.var >actual &&
> + test_cmp expect actual &&
> +
> + git -c sec.var=val -c sec.VAR=VAL config --get SEC.var >actual &&
> + test_cmp expect actual &&
> + git -c SEC.var=val -c sec.var=VAL config --get sec.VAR >actual &&
> + test_cmp expect actual
Looks good.
> +test_expect_success 'last one wins: three level vars' '
> + echo val >expect &&
> +
> + # v.a.r and v.A.r are not the same variable, as the middle
> + # level of a three-level configuration variable name is
> + # case sensitive. Test both setting and querying.
> +
> + git -c v.a.r=val -c v.A.r=VAL config --get v.a.r >actual &&
> + test_cmp expect actual &&
> + git -c v.a.r=val -c v.A.r=VAL config --get V.a.R >actual &&
> + test_cmp expect actual &&
> +
> + echo VAL >expect &&
> + git -c v.a.r=val -c v.a.R=VAL config --get v.a.r >actual &&
> + test_cmp expect actual &&
> + git -c v.a.r=val -c V.a.r=VAL config --get v.a.r >actual &&
> + test_cmp expect actual &&
> + git -c v.a.r=val -c v.a.R=VAL config --get V.a.R >actual &&
> + test_cmp expect actual &&
> + git -c v.a.r=val -c V.a.r=VAL config --get V.a.R >actual &&
> + test_cmp expect actual
> +'
There are two blocks of tests, each with their own "expect" value.
Should the top "expect" here be moved down with its block to make that
more clear?
Other than that nit, the tests look good to me.
-Peff
^ permalink raw reply
* Not expected merge conflict output
From: KES @ 2017-02-21 9:24 UTC (permalink / raw)
To: git
Hi. I have merge conflict and this output:
--- a/crypto/lib/Crypto/Routes.pm
+++ b/crypto/lib/Crypto/Routes.pm
@@@ -98,17 -94,16 +98,36 @@@ sub register
,payment_cancel_landing => '/payment-cancel'
}});
# Route configuration is moved from plugin:
++<<<<<<< ours
+ $rn->get( '/stripe/payment_success' )->to( 'Stripe#payment_success' )->name( 'stripe_payment_s
+ $rn->get( '/stripe/payment_cancel' )->to( 'Stripe#payment_cancel' )->name( 'stripe_payment_c
+ $rn->options( '/stripe' )->to( 'Stripe#options' )->name( 'stripe_options' );
+ $rn->post( '/stripe/payment/create', { required_level => 'user' } )->to( 'Stripe#payment_creat
+ $rn->post( '/stripe/payment/execute', { required_level => 'user' } )->to( 'Stripe#payment_exec
++||||||| base
++ $guest->get( '/stripe/payment_success' )->to( 'Stripe#payment_success' )->name( 'stripe_paymen
++ $guest->get( '/stripe/payment_cancel' )->to( 'Stripe#payment_cancel' )->name( 'stripe_paymen
++ $guest->options( '/stripe' )->to( 'Stripe#options' )->name( 'stripe_options' );
++ $user->post( '/stripe/payment/create' )->to( 'Stripe#payment_create' )->name( 'stripe_paymen
++ $user->post( '/stripe/payment/execute' )->to( 'Stripe#payment_execute' )->name( 'stripe_paymen
++
++ $guest->post( '/stripe/hook' )->to( 'Stripe#hook' )->name( 'stripe_hook' );
++=======
+ $guest->get( '/stripe/payment_success' )->to( 'Stripe#payment_success' )->name( 'stripe_paymen
+ $guest->get( '/stripe/payment_cancel' )->to( 'Stripe#payment_cancel' )->name( 'stripe_paymen
+ $guest->options( '/stripe' )->to( 'Stripe#options' )->name( 'stripe_options' );
+ $user->post( '/stripe/payment/create' )->to( 'Stripe#payment_create' )->name( 'stripe_paymen
+ $user->post( '/stripe/payment/execute' )->to( 'Stripe#payment_execute' )->name( 'stripe_paymen
+
+ $guest->post( '/stripe/hook' )->to( 'Stripe#hook' )->name( 'stripe_hook' );
+ $guest->get ( '/stripe/:form' )->to( 'Stripe#button' );
++>>>>>>> theirs
+ $rn->post( '/stripe/hook' )->to( 'Stripe#hook' )->name( 'stripe_hook' );
+ # Static routes
+ # QR code dowlnload url
+ $app->routes->get('/uploads/qrcode/:file')->name('qr_url');
But I expect this output:
--- a/crypto/lib/Crypto/Routes.pm
+++ b/crypto/lib/Crypto/Routes.pm
@@@ -98,17 -94,16 +98,36 @@@ sub register
,payment_cancel_landing => '/payment-cancel'
}});
# Route configuration is moved from plugin:
++<<<<<<< ours
+ $rn->get( '/stripe/payment_success' )->to( 'Stripe#payment_success' )->name( 'stripe_payment_s
+ $rn->get( '/stripe/payment_cancel' )->to( 'Stripe#payment_cancel' )->name( 'stripe_payment_c
+ $rn->options( '/stripe' )->to( 'Stripe#options' )->name( 'stripe_options' );
+ $rn->post( '/stripe/payment/create', { required_level => 'user' } )->to( 'Stripe#payment_creat
+ $rn->post( '/stripe/payment/execute', { required_level => 'user' } )->to( 'Stripe#payment_exec
+ $rn->post( '/stripe/hook' )->to( 'Stripe#hook' )->name( 'stripe_hook' );
++||||||| base
++ $guest->get( '/stripe/payment_success' )->to( 'Stripe#payment_success' )->name( 'stripe_paymen
++ $guest->get( '/stripe/payment_cancel' )->to( 'Stripe#payment_cancel' )->name( 'stripe_paymen
++ $guest->options( '/stripe' )->to( 'Stripe#options' )->name( 'stripe_options' );
++ $user->post( '/stripe/payment/create' )->to( 'Stripe#payment_create' )->name( 'stripe_paymen
++ $user->post( '/stripe/payment/execute' )->to( 'Stripe#payment_execute' )->name( 'stripe_paymen
++
++ $guest->post( '/stripe/hook' )->to( 'Stripe#hook' )->name( 'stripe_hook' );
++=======
+ $guest->get( '/stripe/payment_success' )->to( 'Stripe#payment_success' )->name( 'stripe_paymen
+ $guest->get( '/stripe/payment_cancel' )->to( 'Stripe#payment_cancel' )->name( 'stripe_paymen
+ $guest->options( '/stripe' )->to( 'Stripe#options' )->name( 'stripe_options' );
+ $user->post( '/stripe/payment/create' )->to( 'Stripe#payment_create' )->name( 'stripe_paymen
+ $user->post( '/stripe/payment/execute' )->to( 'Stripe#payment_execute' )->name( 'stripe_paymen
+
+ $guest->post( '/stripe/hook' )->to( 'Stripe#hook' )->name( 'stripe_hook' );
+ $guest->get ( '/stripe/:form' )->to( 'Stripe#button' );
++>>>>>>> theirs
+ # Static routes
+ # QR code dowlnload url
+ $app->routes->get('/uploads/qrcode/:file')->name('qr_url');
Because this diff has less difference between ours&&base, Also
This (second expected patch)
+ # Static routes
+ # QR code dowlnload url
+ $app->routes->get('/uploads/qrcode/:file')->name('qr_url');
is less in compare to (first not expected):
+ $rn->post( '/stripe/hook' )->to( 'Stripe#hook' )->name( 'stripe_hook' );
+ # Static routes
+ # QR code dowlnload url
+ $app->routes->get('/uploads/qrcode/:file')->name('qr_url');
Did I wrong and first output is right thing or maybe I right and I should open new bug report.
Please explain me
^ permalink raw reply
* [RFC] Subtle differences in passing configs to git clone
From: Lars Schneider @ 2017-02-21 11:36 UTC (permalink / raw)
To: Git List; +Cc: Jeff King
Hi,
I stumbled across the following today:
(1) git -c foo.bar="foobar" clone <URL>
--> uses the config temporarily
(2) git clone -c foo.bar="foobar" <URL>
--> uses the config and writes it to .git/config
This was introduced in 84054f7 ("clone: accept config options on the
command line") and it makes total sense. However, I think this subtitle
difference can easily confuse users.
I think we should tell the users that we've written to .git/config.
Maybe something like this:
git clone -c foo.bar="foobar" <URL>
Cloning into 'test'...
Writing foo.bar="foobar" to local config...
remote: Counting objects: 2152, done.
remote: Compressing objects: 100% (33/33), done.
remote: Total 2152 (delta 19), reused 0 (delta 0), pack-reused 2119
Receiving objects: 100% (2152/2152), 328.66 KiB | 217.00 KiB/s, done.
Resolving deltas: 100% (1289/1289), done.
What do you think?
Thanks,
Lars
^ permalink raw reply
* Partnership with Git
From: Nikita Malikov @ 2017-02-21 11:21 UTC (permalink / raw)
To: git
Hello,
My name is Nikita and I'm from Devart https://www.devart.com/.
I would like to contact someone from executive staff of Git. I would be very
thankful for some information how to do this or if someone contacts me.
Thanks for attention and sorry if I disturbed someone.
Best regards
Nikita Malikov
^ permalink raw reply
* Re: Partnership with Git
From: Konstantin Khomoutov @ 2017-02-21 12:22 UTC (permalink / raw)
To: Nikita Malikov; +Cc: git
In-Reply-To: <02FFA5DBB1C64A8DA1BF45F11EBF9930@datasoft.local>
On Tue, 21 Feb 2017 13:21:38 +0200
"Nikita Malikov" <nikitam@devart.com> wrote:
> My name is Nikita and I'm from Devart https://www.devart.com/.
> I would like to contact someone from executive staff of Git. I would
> be very thankful for some information how to do this or if someone
> contacts me.
Git is a free software volunteer project and as such, it has no
"executive staff" in the sense enterprises put into it.
Can you maybe state your actual goals please?
Say, if you're looking for commercial support, we could possibly
suggests a couple of pointers.
^ permalink raw reply
* AW: Inconsistent results of git blame --porcelain when detecting copies from other files
From: Sokolov, Konstantin @ 2017-02-21 12:25 UTC (permalink / raw)
To: peff@peff.net, gitster@pobox.com; +Cc: git@vger.kernel.org
In-Reply-To: <20170220221540.6vemjdvyvwonpqyt@sigill.intra.peff.net>
Thanks for going into the issue. As far as I understand 2.12 won't change the discussed behavior of --procelain. We will switch to --line-procelain. After the current discussion it seems to be less error prone, more future-proof and our current parser can handle it without any changes.
Regards
Konstantin
-----Ursprüngliche Nachricht-----
Von: Jeff King [mailto:peff@peff.net]
Gesendet: Montag, 20. Februar 2017 23:16
An: Junio C Hamano
Cc: Sokolov, Konstantin (ext) (CT RDA SSI ADM-DE); git@vger.kernel.org
Betreff: Re: Inconsistent results of git blame --porcelain when detecting copies from other files
On Mon, Feb 20, 2017 at 01:30:29PM -0800, Junio C Hamano wrote:
> "Sokolov, Konstantin" <konstantin.sokolov.ext@siemens.com> writes:
>
> > However, when using --porcelain DirectoryReader.java is reported as the origin of lines 502-504:
> > ...
> > This is not only inconsistent with the other outputs but the output is also inconsistent in itself because lines 496 -498 do not even exist in a previous version of DirectoryReader.java.
>
> Hmph, this sounds vaguely familiar with
>
>
> http://public-inbox.org/git/20170106042051.nwjiuyyp7ljhs4sr@sigill.int
> ra.peff.net
>
> which is part of Git 2.12-rc0
Yeah, I had the same thought while reading Konstantin's report.
I'm not sure Git is wrong, though. I think it's just the way the porcelain output works.
Here's a minimal reproduction; the interesting thing is when a commit is mentioned twice (as happens on lines 1 and 5 here):
git init repo
cd repo
# use long lines to make sure we trigger content-movement detection
for i in $(seq 1 5); do
echo this is really long line number $i
done >file
git add file
git commit -m initial
sed 's/1/one/; s/5/five/' <file >renamed
git rm file
git add renamed
git commit -m 'rename and use english'
git blame renamed
git blame --line-porcelain renamed
git blame --porcelain renamed
The first blame output looks something like this:
bab03701 renamed ... line number 1
^dda1349 file ... line number 2
^dda1349 file ... line number 3
^dda1349 file ... line number 4
bab03701 renamed ... line number 5
so we can see it's the same case. The --line-porcelain similarly matches the commits and filenames.
But the --porcelain output is:
bab037010dcabaf0509db27bf232d25659b180fa 1 1 1
...
filename renamed
this is really long line number one
dda1349d41da859f4c37e018dbed714ba6c1aa18 2 2 3
...
filename file
this is really long line number 2
dda1349d41da859f4c37e018dbed714ba6c1aa18 3 3
this is really long line number 3
dda1349d41da859f4c37e018dbed714ba6c1aa18 4 4
this is really long line number 4
bab037010dcabaf0509db27bf232d25659b180fa 5 5 1
this is really long line number five
You might be tempted to say that the fifth line comes from "filename file", because that was the last "filename" entry we saw. But that's _not_ how the porcelain output works. That "filename" entry was associated with dda1349, but the line comes from bab0370 here.
The simplest way (IMHO) to parse --porcelain output is:
- maintain a mapping of commit sha1s to the commit's details
- whenever you see a "<sha1> <line_nr> <orig_nr> [<size-of-hunk>]"
line, any key-value fields which follow impact _only_ that sha1, and
you should update the details for that map entry
- when you see the actual tab-indented line content, you have gotten
all of the key-value updates for that sha1. You can now safely do
what you like with the line entry.
Another way, if you don't want to update your mapping, is to actually pay attention to the size-of-hunk headers. In this case the middle three lines come in their own hunk (which you can see from the "2 2 3" header on the second line). The "filename" field we get applies to that hunk, but once we switch to a different one, the filename field needs to be looked up in the commit mapping.
But it's definitely not correct to blindly apply one "filename" field to subsequent lines in other hunks.
And yes, I do think this is probably more complex than it needs to be.
I didn't write it. And I don't think it is worth the backwards compatibility headache of trying to change it now. It's possible this could be better documented (I didn't look at the documentation to write that explanation; I happened to puzzle it out for somebody else recently who had a similar case. That's what led to the bug-fix in the message you linked).
-Peff
^ permalink raw reply
* Re: [PATCH v4 14/15] files-backend: remove submodule_allowed from files_downcast()
From: Duy Nguyen @ 2017-02-21 13:25 UTC (permalink / raw)
To: Michael Haggerty
Cc: Git Mailing List, Junio C Hamano, Johannes Schindelin,
Ramsay Jones, Stefan Beller, David Turner
In-Reply-To: <25fcb527-595a-7865-41e3-ee7c4c1ad668@alum.mit.edu>
On Mon, Feb 20, 2017 at 7:11 PM, Michael Haggerty <mhagger@alum.mit.edu> wrote:
> On 02/18/2017 02:33 PM, Nguyễn Thái Ngọc Duy wrote:
>> Since submodule or not is irrelevant to files-backend after the last
>> patch, remove the parameter from files_downcast() and kill
>> files_assert_main_repository().
>>
>> PS. This implies that all ref operations are allowed for submodules. But
>> we may need to look more closely to see if that's really true...
>
> I think you are jumping the gun here.
>
> Even after your changes, there is still a significant difference between
> the main repository and submodules: we have access to the object
> database for the main repository, but not for submodules.
I did jump the gun for another reason: files-backend makes function
calls to the frontend, which unconditionally target the main ref store
(e.g. resolve_ref_unsafe, delete_ref...). Of course, because
store-aware api does not exist. My decision (off-list) to add
test-ref-store was the right call. I would not have seen these because
I was not (and still am not) familiar with files-backend.c enough to
see its dark corners.
files-backend.c is not all unicorn and rainbow :(
--
Duy
^ 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