* Re: [PATCH v3 0/2] The move to sequencer.c
From: Jonathan Nieder @ 2012-01-11 18:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ramkumar Ramachandra, Git List, Christian Couder
In-Reply-To: <1326305757-27525-1-git-send-email-artagnon@gmail.com>
Ramkumar Ramachandra wrote:
> Ramkumar Ramachandra (2):
> revert: prepare to move replay_action to header
> sequencer: factor code out of revert builtin
Ah. "git diff HEAD^:builtin/revert.c HEAD:sequencer.c" gives a sane
diff, and the remaining stuff in builtin/revert.c feels pleasant.
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Here's a patchlet for squashing into patch 2/2.
---
builtin/revert.c | 2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/builtin/revert.c b/builtin/revert.c
index 4116f2d3..e6840f23 100644
--- a/builtin/revert.c
+++ b/builtin/revert.c
@@ -30,8 +30,6 @@ static const char * const cherry_pick_usage[] = {
NULL
};
-#define GIT_REFLOG_ACTION "GIT_REFLOG_ACTION"
-
static const char *action_name(const struct replay_opts *opts)
{
return opts->action == REPLAY_REVERT ? "revert" : "cherry-pick";
--
^ permalink raw reply related
* Re: Regulator updates for 3.3
From: Paul Gortmaker @ 2012-01-11 18:40 UTC (permalink / raw)
To: Linus Torvalds
Cc: Mark Brown, Liam Girdwood, linux-kernel, Junio C Hamano,
Git Mailing List
In-Reply-To: <CA+55aFxvQF=Bm4ae6euB_UO8otMCuN9Lv37Zn3TpE-L7JH3Kzw@mail.gmail.com>
[Re: Regulator updates for 3.3] On 10/01/2012 (Tue 14:54) Linus Torvalds wrote:
[...]
> So right now "git merge" (and "git pull") make it too easy to make
> those meaningless merge commits. If instead of seven pointless merges
It looks like the editor-by-default solution is a go, but there still
might be value in increasing the visibility of the pointless merges
via. the patch below.
Paul.
> you had (say) had two merges that had messages about *why* they
> weren't pointless, I'd be perfectly happy.
>
> Addid junio and git to the cc just to bring up this issue of bad UI
> once again. I realize it could break old scripts to start up an editor
> window, but still..
>
> Linus
>From 1a548fa97b78cebcded15d2b00ee3d826f731abd Mon Sep 17 00:00:00 2001
From: Paul Gortmaker <paul.gortmaker@windriver.com>
Date: Wed, 11 Jan 2012 10:33:45 -0500
Subject: [PATCH] merge: Make merge strategy message follow the diffstat
One of the common problems I've seen with people who are
somewhat new to git is that they don't realize that a pull
is a fetch+merge. They simply decide they want all the
latest stuff and issue a git pull without really thinking
if they are on a branch with local commits or on master,
where a fast forward can take place.
But the one line message that tells you whether you got a fast
forward or a real merge commit is usually pushed off the
screen by all the diffstat information. So these users won't
even know that their pull has created a merge, and chances
are they will never change their workflow.
By moving the message after the diffstat, there is a better
chance that people will be aware they've done a pointless
merge commit.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
diff --git a/builtin/merge.c b/builtin/merge.c
index 3a45172..9471588 100644
--- a/builtin/merge.c
+++ b/builtin/merge.c
@@ -370,12 +370,12 @@ static void finish(struct commit *head_commit,
{
struct strbuf reflog_message = STRBUF_INIT;
const unsigned char *head = head_commit->object.sha1;
+ int automsg = 0;
- if (!msg)
+ if (!msg) {
+ automsg = 1;
strbuf_addstr(&reflog_message, getenv("GIT_REFLOG_ACTION"));
- else {
- if (verbosity >= 0)
- printf("%s\n", msg);
+ } else {
strbuf_addf(&reflog_message, "%s: %s",
getenv("GIT_REFLOG_ACTION"), msg);
}
@@ -409,6 +409,9 @@ static void finish(struct commit *head_commit,
diff_flush(&opts);
}
+ if (!automsg && verbosity >= 0)
+ printf("%s\n", msg);
+
/* Run a post-merge hook */
run_hook(NULL, "post-merge", squash ? "1" : "0", NULL);
--
1.7.4.4
^ permalink raw reply related
* Re: [PATCH v3 06/10] clone: delay cloning until after remote HEAD checking
From: Junio C Hamano @ 2012-01-11 19:36 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git, Jeff King
In-Reply-To: <1326189427-20800-7-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> This gives us an opportunity to abort the command during remote HEAD
> check without wasting much bandwidth.
>
> Cloning with remote-helper remains before the check because the remote
> helper updates mapped_refs, which is necessary for remote ref checks.
>
> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
> ---
> I'm not familiar with remote-helper to see if there's any better way
> to do this..
> ...
> + refs = transport_get_remote_refs(transport);
> + mapped_refs = refs ? wanted_peer_refs(refs, refspec) : NULL;
> +
> + /*
> + * mapped_refs may be updated if transport-helper is used so
> + * we need fetch it early because remote_head code below
> + * relies on it.
> + *
> + * for normal clones, transport_get_remote_refs() should
> + * return reliable ref set, we can delay cloning until after
> + * remote HEAD check.
> + */
> + if (!is_local && remote->foreign_vcs && refs)
> + transport_fetch_refs(transport, mapped_refs);
> +
I like the goal of this change, but wouldn't remote->url indicate it is a
remote that needs a helper invocation by having double-colon in it,
without having an explicit value in foreign_vcs field?
Would it be cleaner if transport_get() learned to mark the transport as
needing special treatment (i.e. we won't know the final ref mapping until
we fetch the data from the other side) and check is made on that mark left
in the transport, instead of foreign_vcs in remote?
> diff --git a/transport.c b/transport.c
> index a99b7c9..aae9889 100644
> --- a/transport.c
> +++ b/transport.c
> @@ -895,8 +895,10 @@ struct transport *transport_get(struct remote *remote, const char *url)
>
> while (is_urlschemechar(p == url, *p))
> p++;
> - if (!prefixcmp(p, "::"))
> + if (!prefixcmp(p, "::")) {
> helper = xstrndup(url, p - url);
> + remote->foreign_vcs = helper;
> + }
> }
>
> if (helper) {
Ahhh, Ok. You are reusing the existing "foreign_vcs" field exactly for
that purpose. Earlier the field was strictly for configured .vcs value,
but now you use it also for the helper embedded within the URL, which
sounds like the right change to me.
> @@ -938,6 +940,7 @@ struct transport *transport_get(struct remote *remote, const char *url)
> char *handler = xmalloc(len + 1);
> handler[len] = 0;
> strncpy(handler, url, len);
> + remote->foreign_vcs = helper;
> transport_helper_init(ret, handler);
> }
This I am not sure. What value does "helper" variable have at this point
in the flow? Wouldn't it be a NULL? Or did you mean "handler"?
^ permalink raw reply
* Re: [PATCH] archive: re-allow HEAD:Documentation on a remote invocation
From: Jeff King @ 2012-01-11 19:39 UTC (permalink / raw)
To: Carlos Martín Nieto; +Cc: git, Albert Astals Cid
In-Reply-To: <1326283958-30271-1-git-send-email-cmn@elego.de>
On Wed, Jan 11, 2012 at 01:12:38PM +0100, Carlos Martín Nieto wrote:
> The tightening done in (ee27ca4a: archive: don't let remote clients
> get unreachable commits, 2011-11-17) went too far and disallowed
> HEAD:Documentation as it would try to find "HEAD:Documentation" as a
> ref.
>
> Only DWIM the "HEAD" part to see if it exists as a ref. Once we're
> sure that we've been given a valid ref, we follow the normal code
> path. This still disallows attempts to access commits which are not
> branch tips.
I'd rather not do this kind of ad-hoc parsing of sha1s in the archive
code, and instead let the regular resolution process tell us more about
what it did, so we can make a policy decision at the upper level.
Patches to follow:
[1/2]: get_sha1_with_context: report features used in resolution
[2/2]: archive: loosen restrictions on remote object lookup
> AFAICT this should still be safe. Using HEAD^:Documentation or
> <sha1>:Documentation still complains that HEAD^ and <sha1> aren't
> refs.
My patches enable things like HEAD^, but disallow a raw sha1. The only
way to safely allow a raw sha1 is to check its connectivity from the
tips, which can be somewhat expensive (you have to traverse every tree
of every commit in the worst case).
-Peff
^ permalink raw reply
* [PATCH 1/2] get_sha1_with_context: report features used in resolution
From: Jeff King @ 2012-01-11 19:42 UTC (permalink / raw)
To: Carlos Martín Nieto; +Cc: git, Albert Astals Cid
In-Reply-To: <20120111193916.GA12333@sigill.intra.peff.net>
Most callers generally treat get_sha1 as a black box, giving
it a string from the user and expecting to get a sha1 in
return. The get_sha1_with_context function gives callers
more information about what happened while resolving the
object name so they can make better decisions about how to
use the result. We currently use this only to provide
information about the path entry used to find a blob.
We don't currently provide any information about the
resolution rules that were used to reach the final object.
Some callers may want these in order to enforce a policy
that a particular subset of the lookup rules are used (e.g.,
when serving remote requests).
This patch adds a set of bit-fields that document the use of
particular features during an object lookup.
Signed-off-by: Jeff King <peff@peff.net>
---
The diffstat looks a little scary, but it is mostly just the internal
get_sha1 functions learning to pass the object_context around.
cache.h | 7 +++++
sha1_name.c | 73 +++++++++++++++++++++++++++++++++++++---------------------
2 files changed, 53 insertions(+), 27 deletions(-)
diff --git a/cache.h b/cache.h
index 10afd71..ac25a37 100644
--- a/cache.h
+++ b/cache.h
@@ -809,6 +809,13 @@ struct object_context {
unsigned char tree[20];
char path[PATH_MAX];
unsigned mode;
+ unsigned used_ref:1,
+ used_reflog:1,
+ used_index:1,
+ used_nth_checkout:1,
+ used_describe_name:1,
+ used_oneline:1,
+ used_raw_hex:1;
};
extern int get_sha1(const char *str, unsigned char *sha1);
diff --git a/sha1_name.c b/sha1_name.c
index 03ffc2c..ad7c52a 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -7,7 +7,8 @@
#include "refs.h"
#include "remote.h"
-static int get_sha1_oneline(const char *, unsigned char *, struct commit_list *);
+static int get_sha1_oneline(const char *, unsigned char *, struct commit_list *,
+ struct object_context *);
static int find_short_object_filename(int len, const char *name, unsigned char *sha1)
{
@@ -158,7 +159,7 @@ static int find_unique_short_object(int len, char *canonical,
}
static int get_short_sha1(const char *name, int len, unsigned char *sha1,
- int quietly)
+ int quietly, struct object_context *oc)
{
int i, status;
char canonical[40];
@@ -190,6 +191,8 @@ static int get_short_sha1(const char *name, int len, unsigned char *sha1,
status = find_unique_short_object(i, canonical, res, sha1);
if (!quietly && (status == SHORT_NAME_AMBIGUOUS))
return error("short SHA1 %.*s is ambiguous.", len, canonical);
+ if (!status)
+ oc->used_raw_hex = 1;
return status;
}
@@ -204,7 +207,8 @@ const char *find_unique_abbrev(const unsigned char *sha1, int len)
return hex;
while (len < 40) {
unsigned char sha1_ret[20];
- status = get_short_sha1(hex, len, sha1_ret, 1);
+ struct object_context unused;
+ status = get_short_sha1(hex, len, sha1_ret, 1, &unused);
if (exists
? !status
: status == SHORT_NAME_NOT_FOUND) {
@@ -255,17 +259,21 @@ static inline int upstream_mark(const char *string, int len)
return 0;
}
-static int get_sha1_1(const char *name, int len, unsigned char *sha1);
+static int get_sha1_1(const char *name, int len, unsigned char *sha1,
+ struct object_context *oc);
-static int get_sha1_basic(const char *str, int len, unsigned char *sha1)
+static int get_sha1_basic(const char *str, int len, unsigned char *sha1,
+ struct object_context *oc)
{
static const char *warn_msg = "refname '%.*s' is ambiguous.";
char *real_ref = NULL;
int refs_found = 0;
int at, reflog_len;
- if (len == 40 && !get_sha1_hex(str, sha1))
+ if (len == 40 && !get_sha1_hex(str, sha1)) {
+ oc->used_raw_hex = 1;
return 0;
+ }
/* basic@{time or number or -number} format to query ref-log */
reflog_len = at = 0;
@@ -292,7 +300,8 @@ static int get_sha1_basic(const char *str, int len, unsigned char *sha1)
ret = interpret_branch_name(str+at, &buf);
if (ret > 0) {
/* substitute this branch name and restart */
- return get_sha1_1(buf.buf, buf.len, sha1);
+ oc->used_nth_checkout = 1;
+ return get_sha1_1(buf.buf, buf.len, sha1, oc);
} else if (ret == 0) {
return -1;
}
@@ -305,6 +314,7 @@ static int get_sha1_basic(const char *str, int len, unsigned char *sha1)
if (!refs_found)
return -1;
+ oc->used_ref = 1;
if (warn_ambiguous_refs && refs_found > 1)
warning(warn_msg, len, str);
@@ -352,6 +362,7 @@ static int get_sha1_basic(const char *str, int len, unsigned char *sha1)
len, str, co_cnt);
}
}
+ oc->used_reflog = 1;
}
free(real_ref);
@@ -359,10 +370,11 @@ static int get_sha1_basic(const char *str, int len, unsigned char *sha1)
}
static int get_parent(const char *name, int len,
- unsigned char *result, int idx)
+ unsigned char *result, int idx,
+ struct object_context *oc)
{
unsigned char sha1[20];
- int ret = get_sha1_1(name, len, sha1);
+ int ret = get_sha1_1(name, len, sha1, oc);
struct commit *commit;
struct commit_list *p;
@@ -389,13 +401,14 @@ static int get_parent(const char *name, int len,
}
static int get_nth_ancestor(const char *name, int len,
- unsigned char *result, int generation)
+ unsigned char *result, int generation,
+ struct object_context *oc)
{
unsigned char sha1[20];
struct commit *commit;
int ret;
- ret = get_sha1_1(name, len, sha1);
+ ret = get_sha1_1(name, len, sha1, oc);
if (ret)
return ret;
commit = lookup_commit_reference(sha1);
@@ -436,7 +449,8 @@ struct object *peel_to_type(const char *name, int namelen,
}
}
-static int peel_onion(const char *name, int len, unsigned char *sha1)
+static int peel_onion(const char *name, int len, unsigned char *sha1,
+ struct object_context *oc)
{
unsigned char outer[20];
const char *sp;
@@ -476,7 +490,7 @@ static int peel_onion(const char *name, int len, unsigned char *sha1)
else
return -1;
- if (get_sha1_1(name, sp - name - 2, outer))
+ if (get_sha1_1(name, sp - name - 2, outer, oc))
return -1;
o = parse_object(outer);
@@ -515,14 +529,15 @@ static int peel_onion(const char *name, int len, unsigned char *sha1)
prefix = xstrndup(sp + 1, name + len - 1 - (sp + 1));
commit_list_insert((struct commit *)o, &list);
- ret = get_sha1_oneline(prefix, sha1, list);
+ ret = get_sha1_oneline(prefix, sha1, list, oc);
free(prefix);
return ret;
}
return 0;
}
-static int get_describe_name(const char *name, int len, unsigned char *sha1)
+static int get_describe_name(const char *name, int len, unsigned char *sha1,
+ struct object_context *oc)
{
const char *cp;
@@ -535,14 +550,15 @@ static int get_describe_name(const char *name, int len, unsigned char *sha1)
if (ch == 'g' && cp[-1] == '-') {
cp++;
len -= cp - name;
- return get_short_sha1(cp, len, sha1, 1);
+ return get_short_sha1(cp, len, sha1, 1, oc);
}
}
}
return -1;
}
-static int get_sha1_1(const char *name, int len, unsigned char *sha1)
+static int get_sha1_1(const char *name, int len, unsigned char *sha1,
+ struct object_context *oc)
{
int ret, has_suffix;
const char *cp;
@@ -569,25 +585,25 @@ static int get_sha1_1(const char *name, int len, unsigned char *sha1)
if (!num && len1 == len - 1)
num = 1;
if (has_suffix == '^')
- return get_parent(name, len1, sha1, num);
+ return get_parent(name, len1, sha1, num, oc);
/* else if (has_suffix == '~') -- goes without saying */
- return get_nth_ancestor(name, len1, sha1, num);
+ return get_nth_ancestor(name, len1, sha1, num, oc);
}
- ret = peel_onion(name, len, sha1);
+ ret = peel_onion(name, len, sha1, oc);
if (!ret)
return 0;
- ret = get_sha1_basic(name, len, sha1);
+ ret = get_sha1_basic(name, len, sha1, oc);
if (!ret)
return 0;
/* It could be describe output that is "SOMETHING-gXXXX" */
- ret = get_describe_name(name, len, sha1);
+ ret = get_describe_name(name, len, sha1, oc);
if (!ret)
return 0;
- return get_short_sha1(name, len, sha1, 0);
+ return get_short_sha1(name, len, sha1, 0, oc);
}
/*
@@ -619,7 +635,8 @@ static int handle_one_ref(const char *path,
}
static int get_sha1_oneline(const char *prefix, unsigned char *sha1,
- struct commit_list *list)
+ struct commit_list *list,
+ struct object_context *oc)
{
struct commit_list *backup = NULL, *l;
int found = 0;
@@ -672,6 +689,7 @@ static int get_sha1_oneline(const char *prefix, unsigned char *sha1,
for (l = backup; l; l = l->next)
clear_commit_marks(l->item, ONELINE_SEEN);
free_commit_list(backup);
+ oc->used_oneline = found;
return found ? 0 : -1;
}
@@ -1029,7 +1047,7 @@ int get_sha1_with_context_1(const char *name, unsigned char *sha1,
memset(oc, 0, sizeof(*oc));
oc->mode = S_IFINVALID;
- ret = get_sha1_1(name, namelen, sha1);
+ ret = get_sha1_1(name, namelen, sha1, oc);
if (!ret)
return ret;
/* sha1:path --> object name of path in ent sha1
@@ -1046,7 +1064,7 @@ int get_sha1_with_context_1(const char *name, unsigned char *sha1,
if (!only_to_die && namelen > 2 && name[1] == '/') {
struct commit_list *list = NULL;
for_each_ref(handle_one_ref, &list);
- return get_sha1_oneline(name + 2, sha1, list);
+ return get_sha1_oneline(name + 2, sha1, list, oc);
}
if (namelen < 3 ||
name[2] != ':' ||
@@ -1081,6 +1099,7 @@ int get_sha1_with_context_1(const char *name, unsigned char *sha1,
if (ce_stage(ce) == stage) {
hashcpy(sha1, ce->sha1);
oc->mode = ce->ce_mode;
+ oc->used_index = 1;
free(new_path);
return 0;
}
@@ -1107,7 +1126,7 @@ int get_sha1_with_context_1(const char *name, unsigned char *sha1,
strncpy(object_name, name, cp-name);
object_name[cp-name] = '\0';
}
- if (!get_sha1_1(name, cp-name, tree_sha1)) {
+ if (!get_sha1_1(name, cp-name, tree_sha1, oc)) {
const char *filename = cp+1;
char *new_filename = NULL;
--
1.7.9.rc0.33.gd3c17
^ permalink raw reply related
* [PATCH 2/2] archive: loosen restrictions on remote object lookup
From: Jeff King @ 2012-01-11 19:42 UTC (permalink / raw)
To: Carlos Martín Nieto; +Cc: git, Albert Astals Cid
In-Reply-To: <20120111193916.GA12333@sigill.intra.peff.net>
Initially, "git upload-archive" would feed the tree
specification from the remote side directly into get_sha1,
giving the remote user the full power of the object name
resolver. This was convenient, but it also meant that remote
users could fetch disconnected trees by their sha1s, which
violates the long-standing behavior of upload-pack not to
make such objects available.
Later, commit ee27ca4 tightened this to use dwim_ref instead
of get_sha1 for the remote case, allowing only the use of
actual refs. Unfortunately, this broke some existing use
cases, like fetching sub-trees with "$ref:subdir".
This patch loosens the restrictions to re-enable those use
cases. It does this by using get_sha1_with_context for the
object lookup, and checking that only allowable features
were used.
Signed-off-by: Jeff King <peff@peff.net>
---
archive.c | 34 ++++++++++++++-------
t/t5002-archive-resolution.sh | 66 +++++++++++++++++++++++++++++++++++++++++
2 files changed, 89 insertions(+), 11 deletions(-)
create mode 100755 t/t5002-archive-resolution.sh
diff --git a/archive.c b/archive.c
index 164bbd0..a031bde 100644
--- a/archive.c
+++ b/archive.c
@@ -246,6 +246,25 @@ static void parse_pathspec_arg(const char **pathspec,
}
}
+static int check_object_context(int remote, const struct object_context *oc)
+{
+ /* For local requests, allow anything */
+ if (!remote)
+ return 1;
+ /*
+ * Otherwise, require that we accessed the object through a ref,
+ * but not have used any of the advanced features like looking in
+ * the reflog.
+ */
+ return oc->used_ref &&
+ !oc->used_reflog &&
+ !oc->used_index &&
+ !oc->used_nth_checkout &&
+ !oc->used_describe_name &&
+ !oc->used_oneline &&
+ !oc->used_raw_hex;
+}
+
static void parse_treeish_arg(const char **argv,
struct archiver_args *ar_args, const char *prefix,
int remote)
@@ -256,18 +275,11 @@ static void parse_treeish_arg(const char **argv,
struct tree *tree;
const struct commit *commit;
unsigned char sha1[20];
+ struct object_context oc;
- /* Remotes are only allowed to fetch actual refs */
- if (remote) {
- char *ref = NULL;
- if (!dwim_ref(name, strlen(name), sha1, &ref))
- die("no such ref: %s", name);
- free(ref);
- }
- else {
- if (get_sha1(name, sha1))
- die("Not a valid object name");
- }
+ if (get_sha1_with_context(name, sha1, &oc) ||
+ !check_object_context(remote, &oc))
+ die("Not a valid object name");
commit = lookup_commit_reference_gently(sha1, 1);
if (commit) {
diff --git a/t/t5002-archive-resolution.sh b/t/t5002-archive-resolution.sh
new file mode 100755
index 0000000..bf2b55c
--- /dev/null
+++ b/t/t5002-archive-resolution.sh
@@ -0,0 +1,66 @@
+#!/bin/sh
+
+test_description='test object resolution methods for local and remote archive'
+. ./test-lib.sh
+
+test_expect_success 'setup' '
+ echo a >a &&
+ git add . &&
+ git commit -m one &&
+ sha1_one=`git rev-parse HEAD` &&
+ mkdir subdir &&
+ echo b >subdir/b &&
+ git add . &&
+ git commit -m two &&
+ git checkout -b other &&
+ git checkout master
+'
+
+while read desc where what expect; do
+ cmd="git archive --format=tar -o result.tar"
+ test "$where" = "remote" && cmd="$cmd --remote=."
+ cmd="$cmd $what"
+
+ if test "$expect" = "deny"; then
+ test_expect_success "archive $desc ($where, should deny)" "
+ test_must_fail $cmd
+ "
+ else
+ test_expect_success "archive $desc ($where, should work)" '
+ '"$cmd"' &&
+ for i in '"$expect"'; do
+ echo "$i:`basename $i`"
+ done >expect &&
+ rm -rf result &&
+ mkdir result &&
+ (cd result &&
+ tar xf ../result.tar &&
+ for i in `find * -type f`; do
+ echo "$i:`cat $i`"
+ done >../actual
+ ) &&
+ test_cmp expect actual
+ '
+ fi
+done <<EOF
+ref local master a subdir/b
+ref remote master a subdir/b
+parent local master^ a
+parent remote master^ a
+tree local master^{tree} a subdir/b
+tree remote master^{tree} a subdir/b
+subtree local master:subdir b
+subtree remote master:subdir b
+sha1 local $sha1_one a
+sha1 remote $sha1_one deny
+reflog local master@{1} a
+reflog remote master@{1} deny
+oneline local :/one a
+oneline remote :/one deny
+oneline-ref local master^{/one} a
+oneline-ref remote master^{/one} deny
+nth-checkout local @{-1} a subdir/b
+nth-checkout remote @{-1} deny
+EOF
+
+test_done
--
1.7.9.rc0.33.gd3c17
^ permalink raw reply related
* Re: leaky cherry-pick
From: Jeff King @ 2012-01-11 19:56 UTC (permalink / raw)
To: Ramkumar Ramachandra
Cc: Junio C Hamano, Pete Wyckoff, git,
Nguyễn Thái Ngọc
In-Reply-To: <CALkWK0m+okqJk05BMQAEMww6FNLxaLVhAM92WmUDeA_J-drOdg@mail.gmail.com>
On Wed, Jan 11, 2012 at 02:30:16PM +0530, Ramkumar Ramachandra wrote:
> > I somehow have a feeling that you did not read the conclusion in Peff's
> > message correctly. The code only keeps data from one active path of
> > per-directory .gitattributes files to the leaf of a working tree and
> > releases unneeded data (IOW, it "pops" the attr_stack elements) when it
> > goes on to look at the next path, so my understanding is that there is
> > nothing to "try implementing" here.
>
> My bad- I thought the current implementation doesn't release the
> unneeded data. So, does the entire 7 KB of leaked data come from one
> active path?
Hmm. Actually, I think there is a leak. Because the strategy I described
leaves the memory reachable from the global attr_stack variable, which
means valgrind will only show it if "--show-reachable" is turned on.
Maybe this?
diff --git a/attr.c b/attr.c
index 76b079f..1656db4 100644
--- a/attr.c
+++ b/attr.c
@@ -301,6 +301,7 @@ static void free_attr_elem(struct attr_stack *e)
}
free(a);
}
+ free(e->attrs);
free(e);
}
-Peff
^ permalink raw reply related
* Re: [PATCH v3 07/10] clone: --branch=<branch> always means refs/heads/<branch>
From: Junio C Hamano @ 2012-01-11 20:01 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git, Jeff King
In-Reply-To: <1326189427-20800-8-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> It does not make sense to look outside refs/heads for HEAD's target
> (src_ref_prefix can be set to "refs/" if --mirror is used) because ref
> code only allows symref in form refs/heads/...
>
> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
> ---
> builtin/clone.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/builtin/clone.c b/builtin/clone.c
> index 05224d7..960242f 100644
> --- a/builtin/clone.c
> +++ b/builtin/clone.c
> @@ -463,7 +463,7 @@ static void update_remote_refs(const struct ref *refs,
> static void update_head(const struct ref *our, const struct ref *remote,
> const char *msg)
> {
> - if (our) {
> + if (our && !prefixcmp(our->name, "refs/heads/")) {
> /* Local default branch link */
> create_symref("HEAD", our->name, NULL);
> if (!option_bare) {
I think this makes sense. In the following three casees:
- When cloning without --branch, if we could not find a branch that match
HEAD at the remote;
- When cloning with --branch, if we did not see such a branch at the
remote; or
- When cloning from an empty repository
we come here with "our" set to NULL. Additionally, if the remote HEAD
points outside refs/heads/ and the transport could detect that case
(e.g. a helper that reads from ls-remote output), we can see our->name
outside refs/heads/. Is there any other case where our is not NULL and
our->name does not start with refs/heads/?
The "else if (remote)" clause (not shown, outside the context) that
follows still has comments that says it is a case for "Source had detached
HEAD pointing somewhere", and needs to be adjusted for this change, no? It
is "(1) we know the HEAD points at a non-branch, (2) HEAD may point at a
branch but we do not know which one, or (3) we asked for a specific branch
but it did not exist there" (cloning from an empty will have NULL in
remote and the comment would not apply to that case).
> @@ -760,7 +760,7 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
>
> if (option_branch) {
> struct strbuf head = STRBUF_INIT;
> - strbuf_addstr(&head, src_ref_prefix);
> + strbuf_addstr(&head, "refs/heads/");
> strbuf_addstr(&head, option_branch);
> our_head_points_at =
> find_ref_by_name(mapped_refs, head.buf);
^ permalink raw reply
* Re: [PATCH 2/2] diff --word-diff: use non-whitespace regex by default
From: Thomas Rast @ 2012-01-11 20:05 UTC (permalink / raw)
To: Tay Ray Chuan; +Cc: Git Mailing List, Junio C Hamano
In-Reply-To: <1326302702-4536-2-git-send-email-rctay89@gmail.com>
Tay Ray Chuan <rctay89@gmail.com> writes:
> Factor out the comprehensive non-whitespace regex in use by PATTERNS and
> IPATTERN and use it as the word-diff regex for the default diff driver.
Why?
I seem to recall that the motivation for keeping the original code as-is
instead of just emulating its behavior with a default regex was that it
is faster. So disabling the default mode should at least have an
advantage?
</devils-advocate>
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* [PATCH 1/3] mailinfo documentation: accurately describe non -k case
From: Thomas Rast @ 2012-01-11 20:13 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
Since its very first description of -k, the documentation for
git-mailinfo claimed that (in the case without -k) after cleaning up
bracketed strings [blah], it would insert [PATCH].
It doesn't; on the contrary, one of the important jobs of mailinfo is
to remove those strings.
Since we're already there, rewrite the paragraph to give a complete
enumeration of all the transformations. Specifically, it was missing
the whitespace normalization (run of isspace(c) -> ' ') and the
removal of leading ':'.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
Documentation/git-mailinfo.txt | 25 ++++++++++++++++++-------
1 files changed, 18 insertions(+), 7 deletions(-)
diff --git a/Documentation/git-mailinfo.txt b/Documentation/git-mailinfo.txt
index 51dc325..97e7a8e 100644
--- a/Documentation/git-mailinfo.txt
+++ b/Documentation/git-mailinfo.txt
@@ -25,13 +25,24 @@ command directly. See linkgit:git-am[1] instead.
OPTIONS
-------
-k::
- Usually the program 'cleans up' the Subject: header line
- to extract the title line for the commit log message,
- among which (1) remove 'Re:' or 're:', (2) leading
- whitespaces, (3) '[' up to ']', typically '[PATCH]', and
- then prepends "[PATCH] ". This flag forbids this
- munging, and is most useful when used to read back
- 'git format-patch -k' output.
+ Usually the program removes email cruft from the Subject:
+ header line to extract the title line for the commit log
+ message. This option prevents this munging, and is most
+ useful when used to read back 'git format-patch -k' output.
++
+Specifically, the following are removed until none of them remain:
++
+--
+* Leading and trailing whitespace.
+
+* Leading `Re:`, `re:`, and `:`.
+
+* Leading bracketed strings (between `[` and `]`, usually
+ `[PATCH]`).
+--
++
+Finally, runs of whitespace are normalized to a single ASCII space
+character.
-b::
When -k is not in effect, all leading strings bracketed with '['
--
1.7.9.rc0.168.g3847c
^ permalink raw reply related
* [PATCH 3/3] mailinfo: with -b, keep space after [foo]
From: Thomas Rast @ 2012-01-11 20:13 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <e915a551c9bbf12f4d8fd929e9ed24f3223790ee.1326312730.git.trast@student.ethz.ch>
The logic for the -b mode, where [PATCH] is dropped but [foo] is not,
silently ate all spaces after the ].
Fix this by keeping the next isspace() character, if there is any.
Being more thorough is pointless, as the later cleanup_space() call
will normalize any sequence of whitespace to a single ' '.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
builtin/mailinfo.c | 11 ++++++++++-
t/t4150-am.sh | 2 +-
2 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/builtin/mailinfo.c b/builtin/mailinfo.c
index bfb32b7..eaf9e15 100644
--- a/builtin/mailinfo.c
+++ b/builtin/mailinfo.c
@@ -250,8 +250,17 @@ static void cleanup_subject(struct strbuf *subject)
(7 <= remove &&
memmem(subject->buf + at, remove, "PATCH", 5)))
strbuf_remove(subject, at, remove);
- else
+ else {
at += remove;
+ /*
+ * If the input had a space after the ], keep
+ * it. We don't bother with finding the end of
+ * the space, since we later normalize it
+ * anyway.
+ */
+ if (isspace(subject->buf[at]))
+ at += 1;
+ }
continue;
}
break;
diff --git a/t/t4150-am.sh b/t/t4150-am.sh
index 7e7c83c..8807b60 100755
--- a/t/t4150-am.sh
+++ b/t/t4150-am.sh
@@ -262,7 +262,7 @@ test_expect_success 'am --keep really keeps the subject' '
grep "Re: Re: Re: \[PATCH 1/5 v2\] \[foo\] third" actual
'
-test_expect_failure 'am --keep-non-patch really keeps the non-patch part' '
+test_expect_success 'am --keep-non-patch really keeps the non-patch part' '
rm -fr .git/rebase-apply &&
git reset --hard &&
git checkout HEAD^ &&
--
1.7.9.rc0.168.g3847c
^ permalink raw reply related
* [PATCH 2/3] am: learn passing -b to mailinfo
From: Thomas Rast @ 2012-01-11 20:13 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <e915a551c9bbf12f4d8fd929e9ed24f3223790ee.1326312730.git.trast@student.ethz.ch>
git-am could pass -k to mailinfo, but not -b. Introduce an option
that does so. We change the meaning of the 'keep' state file, but are
careful not to cause a problem unless you downgrade in the middle of
an 'am' run.
This uncovers a bug in mailinfo -b, hence the failing test.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
Someone on IRC asked about git-am support for passing through the -b
flag to mailinfo. And so it began...
Documentation/git-am.txt | 3 +++
git-am.sh | 11 +++++++----
t/t4150-am.sh | 14 ++++++++++++--
3 files changed, 22 insertions(+), 6 deletions(-)
diff --git a/Documentation/git-am.txt b/Documentation/git-am.txt
index 887466d..ee6cca2 100644
--- a/Documentation/git-am.txt
+++ b/Documentation/git-am.txt
@@ -40,6 +40,9 @@ OPTIONS
--keep::
Pass `-k` flag to 'git mailinfo' (see linkgit:git-mailinfo[1]).
+--keep-non-patch::
+ Pass `-b` flag to 'git mailinfo' (see linkgit:git-mailinfo[1]).
+
--keep-cr::
--no-keep-cr::
With `--keep-cr`, call 'git mailsplit' (see linkgit:git-mailsplit[1])
diff --git a/git-am.sh b/git-am.sh
index 1c13b13..8dfad7a 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -15,6 +15,7 @@ q,quiet be quiet
s,signoff add a Signed-off-by line to the commit message
u,utf8 recode into utf8 (default)
k,keep pass -k flag to git-mailinfo
+keep-non-patch pass -b flag to git-mailinfo
keep-cr pass --keep-cr flag to git-mailsplit for mbox format
no-keep-cr do not pass --keep-cr flag to git-mailsplit independent of am.keepcr
c,scissors strip everything before a scissors line
@@ -386,7 +387,9 @@ do
--no-utf8)
utf8= ;;
-k|--keep)
- keep=t ;;
+ keep=-k ;;
+ --keep-non-patch)
+ keep=-b ;;
-c|--scissors)
scissors=t ;;
--no-scissors)
@@ -398,7 +401,7 @@ do
--abort)
abort=t ;;
--rebasing)
- rebasing=t threeway=t keep=t scissors=f no_inbody_headers=t ;;
+ rebasing=t threeway=t keep=-k scissors=f no_inbody_headers=t ;;
-d|--dotest)
die "$(gettext "-d option is no longer supported. Do not use.")"
;;
@@ -571,8 +574,8 @@ then
else
utf8=-n
fi
-if test "$(cat "$dotest/keep")" = t
-then
+keep=$(cat "$dotest/keep")
+if test "$keep" = t
keep=-k
fi
case "$(cat "$dotest/scissors")" in
diff --git a/t/t4150-am.sh b/t/t4150-am.sh
index d7d9ccc..7e7c83c 100755
--- a/t/t4150-am.sh
+++ b/t/t4150-am.sh
@@ -237,7 +237,7 @@ test_expect_success 'am stays in branch' '
test_expect_success 'am --signoff does not add Signed-off-by: line if already there' '
git format-patch --stdout HEAD^ >patch3 &&
- sed -e "/^Subject/ s,\[PATCH,Re: Re: Re: & 1/5 v2," patch3 >patch4 &&
+ sed -e "/^Subject/ s,\[PATCH,Re: Re: Re: & 1/5 v2] [foo," patch3 >patch4 &&
rm -fr .git/rebase-apply &&
git reset --hard &&
git checkout HEAD^ &&
@@ -259,7 +259,17 @@ test_expect_success 'am --keep really keeps the subject' '
git am --keep patch4 &&
! test -d .git/rebase-apply &&
git cat-file commit HEAD >actual &&
- grep "Re: Re: Re: \[PATCH 1/5 v2\] third" actual
+ grep "Re: Re: Re: \[PATCH 1/5 v2\] \[foo\] third" actual
+'
+
+test_expect_failure 'am --keep-non-patch really keeps the non-patch part' '
+ rm -fr .git/rebase-apply &&
+ git reset --hard &&
+ git checkout HEAD^ &&
+ git am --keep-non-patch patch4 &&
+ ! test -d .git/rebase-apply &&
+ git cat-file commit HEAD >actual &&
+ grep "^\[foo\] third" actual
'
test_expect_success 'am -3 falls back to 3-way merge' '
--
1.7.9.rc0.168.g3847c
^ permalink raw reply related
* Re: [PATCH 3/3] diff-index: pass pathspec down to unpack-trees machinery
From: Junio C Hamano @ 2012-01-11 20:40 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Jonathan Nieder, git, Linus Torvalds
In-Reply-To: <CACsJy8D7EnOebAxBYF8ua7htu-81nKY=ghUMgg=JOe4Fc1uigQ@mail.gmail.com>
Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
> This seems to fix this.
>
> diff --git a/unpack-trees.c b/unpack-trees.c
> index 7c9ecf6..5cf58b6 100644
> --- a/unpack-trees.c
> +++ b/unpack-trees.c
> @@ -1042,6 +1042,7 @@ int unpack_trees(unsigned len, struct tree_desc
> *t, struct unpack_trees_options
> info.data = o;
> info.show_all_errors = o->show_all_errors;
> info.pathspec = o->pathspec;
> + info.pathspec->recursive = 1;
>
> if (o->prefix) {
> /*
>
> Still scratching my head why this flag is zero by default, which would
> affect all other places.
Ahh, thanks for diagnosing.
> ... Or perhaps the right fix would be this
> instead
>
> diff --git a/tree-walk.c b/tree-walk.c
> index f82dba6..0345938 100644
> --- a/tree-walk.c
> +++ b/tree-walk.c
> @@ -634,7 +634,7 @@ enum interesting tree_entry_interesting(const
> struct name_entry *entry,
> * Match all directories. We'll try to
> * match files later on.
> */
> - if (ps->recursive && S_ISDIR(entry->mode))
> + if (S_ISDIR(entry->mode))
> return entry_interesting;
> }
>
> @@ -662,7 +662,7 @@ match_wildcards:
> * Match all directories. We'll try to match files
> * later on.
> */
> - if (ps->recursive && S_ISDIR(entry->mode))
> + if (S_ISDIR(entry->mode))
> return entry_interesting;
> }
> return never_interesting; /* No matches */
Doesn't that break "git diff-tree A B" without the "-r" option?
^ permalink raw reply
* Re: [PATCH RFC] commit: allow to commit even if there are intent-to-add entries
From: Junio C Hamano @ 2012-01-11 21:08 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Nguyễn Thái Ngọc Duy, git, Jeff King,
Will Palmer
In-Reply-To: <20120111110222.GA32173@burratino>
Jonathan Nieder <jrnieder@gmail.com> writes:
>> When running "commit" and "status" with files marked with "intent to add",
>> I think there are three possible interpretations of what the user
>> wants to do.
> [ (1) thanks for stopping me, I had forgotten about that file;
> (2) I changed my mind, please leave that file out; or (3) please
> dwim and add the file ]
>
> I think (3) was a trick --- no one that does not use the "-a" option
> would want that. :)
I really wish it were the case, but I doubt it.
People from other VCS background seem to still think that "commit" without
paths should commit everything; after getting told that "what you add to
the index is what you will commit", I can easily see this commint: but but
but I told Git that I _want_ to add with -N! Why aren't you committing it?
> At the time, I did not understand what (2) meant. Now I see why ---
> in interpretation (2), the user did not change her mind at all.
You are correct. "I still cannot make up my mind" is what is happening in
that situation.
The user explicitly said "I cannot decide about this path right now" when
she said "add -N". And we haven't heard from the user what should happen
to the path. Now we have to make a commit so somebody needs to decide.
> She
> said "I will be adding this file at some point, so please keep track
> of it along with the others for the sake of commands like 'git diff'
> and 'git add -u', but that does not mean "I will be adding this file
> at some point _before the next commit_".
Correct. She only said "I cannot decide right now" when she said "add -N"
and hasn't gave us any more hint as to what should happen now we have to
make a commit.
It is _wrong_ for us to unilaterally decide for the user that she does not
want the path in the commit. The last we heard from her was that she does
not know what should happen to the path.
> (2) makes intent-to-add entries just like any other tracked index
> entry with some un-added content.
You are comparing files edited in the working tree without the user
telling anything about them to Git (both tracked and untracked) and files
the user explicitly told Git that the user hasn't made up her mind
about. Why is it a good thing to make the latter behave "just like any
other"?
^ permalink raw reply
* Re: git svn clone terminating prematurely (I think)
From: Steven Line @ 2012-01-11 21:52 UTC (permalink / raw)
To: Ramkumar Ramachandra; +Cc: git
In-Reply-To: <CALkWK0nyc6NVE7Qpvbc0dXb1UHGM_=uYbCS+a53HZxiBRG9HvQ@mail.gmail.com>
Hi Ram, thank you for the reply. Se below . . .
>
>> I need some help getting my subversion repository cloned over to git.
>> Our svn repository has about 12,000 commits, when I run
>> git svn clone -s -A authors.txt
>> svn+ssh://csvn <at> source.res.ourdomain.com/home/svn/sem sem
>> It runs for about 2h 15m then completes with no error messages. I have
>> also cloned starting at revision 6300, about the middle of the svn
>> repository, and I get the same results as below.
>
>> $ git branch -a # shows only about half the branches that should have
>> been cloned
>
> Interesting. From the git-svn-id of the most recent commit, can you
> tell if there's anything especially fishy about the revision where
> git-svn stops? Your Subversion repository is probably broken in some
> way, but git-svn should not use that as an excuse for appearing to
> finish successfully while failing in reality.
Well by your question it seems you expect this clone to fail at the
same svn revision number
each time. I spent all day today trying to figure out what that
revision was. However it doesn't
seem to be failing at the same svn revision each time.
There are about 12813 revisions in our svn repository so I started
attempting clones from successively later
and later revisions both to figure which revision they repeatedly
failed on (it was never the same one) and to see
if I could coax a successful clone to occur. Originally I started at
revision 1, then incremented to 6300, then 8000, then 10000, then
12,500, then finally 12,700. Finally the attempt starting at svn
revision 12,700 succeeded and the resulting git repository
seems to work. All the attempts prior to 12,700 (starting at 1, 6300,
8000, 10000, and 12,500) failed while
importing different revisions, none of them showed error messages.
One thing that I am suspect of is that I'm not able to log directly
into the machine running git, it's on a remote server in
Atlanta while I'm in Colorado. I'm running the 'git svn clone' using
nohup, but in every case of a corrupt git repository
the connection between me and the server dies before the git completes
(the connection dies, but I log in again and run
ps -ef and I see the multiple git processes still running. They run
for up to several hours longer, then terminate). I should be
ok since I'm using nohup, but coincidentally the only clone that
succeeded was the one where the network connection
never disconnected during the clone
Not sure if this helps but here are some numbers:
Both the svn repository and git machine are Solaris 10
Svn revision 1.6.12 CollabNet
Git version 1.7.6.1
Thank you.
--
Steven Line
303-910-1212
sline00@gmail.com
^ permalink raw reply
* Re: git svn clone terminating prematurely (I think)
From: Jonathan Nieder @ 2012-01-11 22:48 UTC (permalink / raw)
To: Ramkumar Ramachandra; +Cc: Steven Line, git
In-Reply-To: <CALkWK0nyc6NVE7Qpvbc0dXb1UHGM_=uYbCS+a53HZxiBRG9HvQ@mail.gmail.com>
Ramkumar Ramachandra wrote:
> Interesting. From the git-svn-id of the most recent commit, can you
> tell if there's anything especially fishy about the revision where
> git-svn stops? Your Subversion repository is probably broken in some
> way,
I wouldn't necessarily assume that. My first hunch would have been
that this is some variation on the SIGPIPE bug[1]. The usual
workaround for that[2] is to get git-svn to continue by running "git
svn fetch" again. Nobody's fixed it because nobody's stared at the
SVN perl bindings for long enough to find the cause.
Modern git versions produce a message in that case, though:
error: git-svn died of signal 13
So you are probably running into something else. I only mention this
for context.
Does svnsync work for making a local copy of whatever subset of the
repository is relevant? Alternatively (this is basically the same),
is the network connection stable enough for e.g. svnrdump[3] to get a
dump?
Sorry for the trouble, and hope that helps,
Jonathan
[1] http://thread.gmane.org/gmane.comp.version-control.git/134936/focus=134940
[2] Maybe it deserves a note in the manpage.
[3] http://repo.or.cz/w/svnrdump.git
^ permalink raw reply
* [PATCH 0/5] git-p4: view spec review fixes
From: Pete Wyckoff @ 2012-01-11 23:31 UTC (permalink / raw)
To: git; +Cc: Gary Gibbons
I received some helpful review comments offline regarding the
series recently merged into master (8cbfc11
(Merge branch 'pw/p4-view-updates', 2012-01-06)).
It would be nice to see these go into 1.7.9 as well.
Even though they belong there logically, they are
minor fixes, and not critical.
I added a bunch of new tests documenting further problems,
but will not fix those here as the changes will be more
invasive.
Thanks,
Pete Wyckoff (5):
git-p4: only a single ... wildcard is supported
git-p4: fix verbose comment typo
git-p4: clarify comment
git-p4: adjust test to adhere to stricter useClientSpec
git-p4: add tests demonstrating spec overlay ambiguities
Documentation/git-p4.txt | 5 +
contrib/fast-import/git-p4 | 9 +-
t/t9806-git-p4-options.sh | 4 +-
t/t9809-git-p4-client-view.sh | 395 ++++++++++++++++++++++++++++++++++++++++-
4 files changed, 406 insertions(+), 7 deletions(-)
--
1.7.8.1.409.g3e338.dirty
^ permalink raw reply
* [PATCH 1/5] git-p4: only a single ... wildcard is supported
From: Pete Wyckoff @ 2012-01-11 23:31 UTC (permalink / raw)
To: git; +Cc: Gary Gibbons
In-Reply-To: <1326324670-15967-1-git-send-email-pw@padd.com>
Catch the case where a ... exists at the end, and also elsehwere.
Reported-by: Gary Gibbons <ggibbons@perforce.com>
Signed-off-by: Pete Wyckoff <pw@padd.com>
---
contrib/fast-import/git-p4 | 4 ++--
t/t9809-git-p4-client-view.sh | 8 +++++++-
2 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
index 3e1aa27..20208bf 100755
--- a/contrib/fast-import/git-p4
+++ b/contrib/fast-import/git-p4
@@ -1207,8 +1207,8 @@ class View(object):
die("Can't handle * wildcards in view: %s" % self.path)
triple_dot_index = self.path.find("...")
if triple_dot_index >= 0:
- if not self.path.endswith("..."):
- die("Can handle ... wildcard only at end of path: %s" %
+ if triple_dot_index != len(self.path) - 3:
+ die("Can handle only single ... wildcard, at end: %s" %
self.path)
self.ends_triple_dot = True
diff --git a/t/t9809-git-p4-client-view.sh b/t/t9809-git-p4-client-view.sh
index c9471d5..54204af 100755
--- a/t/t9809-git-p4-client-view.sh
+++ b/t/t9809-git-p4-client-view.sh
@@ -101,12 +101,18 @@ test_expect_success 'unsupported view wildcard *' '
test_must_fail "$GITP4" clone --use-client-spec --dest="$git" //depot
'
-test_expect_success 'wildcard ... only supported at end of spec' '
+test_expect_success 'wildcard ... only supported at end of spec 1' '
client_view "//depot/.../file11 //client/.../file11" &&
test_when_finished cleanup_git &&
test_must_fail "$GITP4" clone --use-client-spec --dest="$git" //depot
'
+test_expect_success 'wildcard ... only supported at end of spec 2' '
+ client_view "//depot/.../a/... //client/.../a/..." &&
+ test_when_finished cleanup_git &&
+ test_must_fail "$GITP4" clone --use-client-spec --dest="$git" //depot
+'
+
test_expect_success 'basic map' '
client_view "//depot/dir1/... //client/cli1/..." &&
files="cli1/file11 cli1/file12" &&
--
1.7.8.1.409.g3e338.dirty
^ permalink raw reply related
* [PATCH 2/5] git-p4: fix verbose comment typo
From: Pete Wyckoff @ 2012-01-11 23:31 UTC (permalink / raw)
To: git; +Cc: Gary Gibbons
In-Reply-To: <1326324670-15967-1-git-send-email-pw@padd.com>
Signed-off-by: Pete Wyckoff <pw@padd.com>
---
contrib/fast-import/git-p4 | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
index 20208bf..e267f31 100755
--- a/contrib/fast-import/git-p4
+++ b/contrib/fast-import/git-p4
@@ -1263,7 +1263,7 @@ class View(object):
if self.exclude:
c = "-"
return "View.Mapping: %s%s -> %s" % \
- (c, self.depot_side, self.client_side)
+ (c, self.depot_side.path, self.client_side.path)
def map_depot_to_client(self, depot_path):
"""Calculate the client path if using this mapping on the
--
1.7.8.1.409.g3e338.dirty
^ permalink raw reply related
* [PATCH 3/5] git-p4: clarify comment
From: Pete Wyckoff @ 2012-01-11 23:31 UTC (permalink / raw)
To: git; +Cc: Gary Gibbons
In-Reply-To: <1326324670-15967-1-git-send-email-pw@padd.com>
Signed-off-by: Pete Wyckoff <pw@padd.com>
---
contrib/fast-import/git-p4 | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
index e267f31..e11e15b 100755
--- a/contrib/fast-import/git-p4
+++ b/contrib/fast-import/git-p4
@@ -1363,7 +1363,8 @@ class View(object):
else:
# This mapping matched; no need to search any further.
# But, the mapping could be rejected if the client path
- # has already been claimed by an earlier mapping.
+ # has already been claimed by an earlier mapping (i.e.
+ # one later in the list, which we are walking backwards).
already_mapped_in_client = False
for f in paths_filled:
# this is View.Path.match
--
1.7.8.1.409.g3e338.dirty
^ permalink raw reply related
* [PATCH 4/5] git-p4: adjust test to adhere to stricter useClientSpec
From: Pete Wyckoff @ 2012-01-11 23:31 UTC (permalink / raw)
To: git; +Cc: Gary Gibbons
In-Reply-To: <1326324670-15967-1-git-send-email-pw@padd.com>
This test relied on what now is seen as broken behavior
in --use-client-spec. Change it to make sure it works
according to the new behavior as described in
ecb7cf9 (git-p4: rewrite view handling, 2012-01-02) and
c700b68 (git-p4: test client view handling, 2012-01-02).
Signed-off-by: Pete Wyckoff <pw@padd.com>
---
t/t9806-git-p4-options.sh | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/t/t9806-git-p4-options.sh b/t/t9806-git-p4-options.sh
index 1f1952a..0571602 100755
--- a/t/t9806-git-p4-options.sh
+++ b/t/t9806-git-p4-options.sh
@@ -146,7 +146,7 @@ test_expect_success 'clone --use-client-spec' '
(
cd "$git" &&
test_path_is_file bus/dir/f4 &&
- test_path_is_file file1
+ test_path_is_missing file1
) &&
cleanup_git &&
@@ -159,7 +159,7 @@ test_expect_success 'clone --use-client-spec' '
"$GITP4" sync //depot/... &&
git checkout -b master p4/master &&
test_path_is_file bus/dir/f4 &&
- test_path_is_file file1
+ test_path_is_missing file1
)
'
--
1.7.8.1.409.g3e338.dirty
^ permalink raw reply related
* [PATCH 5/5] git-p4: add tests demonstrating spec overlay ambiguities
From: Pete Wyckoff @ 2012-01-11 23:31 UTC (permalink / raw)
To: git; +Cc: Gary Gibbons
In-Reply-To: <1326324670-15967-1-git-send-email-pw@padd.com>
Introduce new tests that look more closely at overlay situations
when there are conflicting files. Five of these are broken.
Document the brokenness.
This is a fundamental problem with how git-p4 only "borrows" a
client spec. At some sync operation, a new change can contain
a file which is already in the repo or explicitly deleted through
another mapping. To sort this out would involve listing all the
files in the client spec to find one with a higher priority.
While this is not too hard for the initial import, subsequent
sync operations would be very costly.
Signed-off-by: Pete Wyckoff <pw@padd.com>
---
Documentation/git-p4.txt | 5 +
t/t9809-git-p4-client-view.sh | 387 +++++++++++++++++++++++++++++++++++++++++
2 files changed, 392 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-p4.txt b/Documentation/git-p4.txt
index 78938b2..8b92cc0 100644
--- a/Documentation/git-p4.txt
+++ b/Documentation/git-p4.txt
@@ -314,6 +314,11 @@ around whitespace. Of the possible wildcards, git-p4 only handles
'...', and only when it is at the end of the path. Git-p4 will complain
if it encounters an unhandled wildcard.
+Bugs in the implementation of overlap mappings exist. If multiple depot
+paths map through overlays to the same location in the repository,
+git-p4 can choose the wrong one. This is hard to solve without
+dedicating a client spec just for git-p4.
+
The name of the client can be given to git-p4 in multiple ways. The
variable 'git-p4.client' takes precedence if it exists. Otherwise,
normal p4 mechanisms of determining the client are used: environment
diff --git a/t/t9809-git-p4-client-view.sh b/t/t9809-git-p4-client-view.sh
index 54204af..ae9145e 100755
--- a/t/t9809-git-p4-client-view.sh
+++ b/t/t9809-git-p4-client-view.sh
@@ -247,6 +247,393 @@ test_expect_success 'quotes on rhs only' '
'
#
+# What happens when two files of the same name are overlayed together?
+# The last-listed file should take preference.
+#
+# //depot
+# - dir1
+# - file11
+# - file12
+# - filecollide
+# - dir2
+# - file21
+# - file22
+# - filecollide
+#
+test_expect_success 'overlay collision setup' '
+ client_view "//depot/... //client/..." &&
+ (
+ cd "$cli" &&
+ p4 sync &&
+ echo dir1/filecollide >dir1/filecollide &&
+ p4 add dir1/filecollide &&
+ p4 submit -d dir1/filecollide &&
+ echo dir2/filecollide >dir2/filecollide &&
+ p4 add dir2/filecollide &&
+ p4 submit -d dir2/filecollide
+ )
+'
+
+test_expect_success 'overlay collision 1 to 2' '
+ client_view "//depot/dir1/... //client/..." \
+ "+//depot/dir2/... //client/..." &&
+ files="file11 file12 file21 file22 filecollide" &&
+ echo dir2/filecollide >actual &&
+ client_verify $files &&
+ test_cmp actual "$cli"/filecollide &&
+ test_when_finished cleanup_git &&
+ "$GITP4" clone --use-client-spec --dest="$git" //depot &&
+ git_verify $files &&
+ test_cmp actual "$git"/filecollide
+'
+
+test_expect_failure 'overlay collision 2 to 1' '
+ client_view "//depot/dir2/... //client/..." \
+ "+//depot/dir1/... //client/..." &&
+ files="file11 file12 file21 file22 filecollide" &&
+ echo dir1/filecollide >actual &&
+ client_verify $files &&
+ test_cmp actual "$cli"/filecollide &&
+ test_when_finished cleanup_git &&
+ "$GITP4" clone --use-client-spec --dest="$git" //depot &&
+ git_verify $files &&
+ test_cmp actual "$git"/filecollide
+'
+
+test_expect_success 'overlay collision delete 2' '
+ client_view "//depot/... //client/..." &&
+ (
+ cd "$cli" &&
+ p4 sync &&
+ p4 delete dir2/filecollide &&
+ p4 submit -d "remove dir2/filecollide"
+ )
+'
+
+# no filecollide, got deleted with dir2
+test_expect_failure 'overlay collision 1 to 2, but 2 deleted' '
+ client_view "//depot/dir1/... //client/..." \
+ "+//depot/dir2/... //client/..." &&
+ files="file11 file12 file21 file22" &&
+ client_verify $files &&
+ test_when_finished cleanup_git &&
+ "$GITP4" clone --use-client-spec --dest="$git" //depot &&
+ git_verify $files
+'
+
+test_expect_success 'overlay collision update 1' '
+ client_view "//depot/dir1/... //client/dir1/..." &&
+ (
+ cd "$cli" &&
+ p4 sync &&
+ p4 open dir1/filecollide &&
+ echo dir1/filecollide update >dir1/filecollide &&
+ p4 submit -d "update dir1/filecollide"
+ )
+'
+
+# still no filecollide, dir2 still wins with the deletion even though the
+# change to dir1 is more recent
+test_expect_failure 'overlay collision 1 to 2, but 2 deleted, then 1 updated' '
+ client_view "//depot/dir1/... //client/..." \
+ "+//depot/dir2/... //client/..." &&
+ files="file11 file12 file21 file22" &&
+ client_verify $files &&
+ test_when_finished cleanup_git &&
+ "$GITP4" clone --use-client-spec --dest="$git" //depot &&
+ git_verify $files
+'
+
+test_expect_success 'overlay collision delete filecollides' '
+ client_view "//depot/... //client/..." &&
+ (
+ cd "$cli" &&
+ p4 sync &&
+ p4 delete dir1/filecollide dir2/filecollide &&
+ p4 submit -d "remove filecollides"
+ )
+'
+
+#
+# Overlays as part of sync, rather than initial checkout:
+# 1. add a file in dir1
+# 2. sync to include it
+# 3. add same file in dir2
+# 4. sync, make sure content switches as dir2 has priority
+# 5. add another file in dir1
+# 6. sync
+# 7. add/delete same file in dir2
+# 8. sync, make sure it disappears, again dir2 wins
+# 9. cleanup
+#
+# //depot
+# - dir1
+# - file11
+# - file12
+# - colA
+# - colB
+# - dir2
+# - file21
+# - file22
+# - colA
+# - colB
+#
+test_expect_success 'overlay sync: add colA in dir1' '
+ client_view "//depot/dir1/... //client/dir1/..." &&
+ (
+ cd "$cli" &&
+ p4 sync &&
+ echo dir1/colA >dir1/colA &&
+ p4 add dir1/colA &&
+ p4 submit -d dir1/colA
+ )
+'
+
+test_expect_success 'overlay sync: initial git checkout' '
+ client_view "//depot/dir1/... //client/..." \
+ "+//depot/dir2/... //client/..." &&
+ files="file11 file12 file21 file22 colA" &&
+ echo dir1/colA >actual &&
+ client_verify $files &&
+ test_cmp actual "$cli"/colA &&
+ "$GITP4" clone --use-client-spec --dest="$git" //depot &&
+ git_verify $files &&
+ test_cmp actual "$git"/colA
+'
+
+test_expect_success 'overlay sync: add colA in dir2' '
+ client_view "//depot/dir2/... //client/dir2/..." &&
+ (
+ cd "$cli" &&
+ p4 sync &&
+ echo dir2/colA >dir2/colA &&
+ p4 add dir2/colA &&
+ p4 submit -d dir2/colA
+ )
+'
+
+test_expect_success 'overlay sync: colA content switch' '
+ client_view "//depot/dir1/... //client/..." \
+ "+//depot/dir2/... //client/..." &&
+ files="file11 file12 file21 file22 colA" &&
+ echo dir2/colA >actual &&
+ client_verify $files &&
+ test_cmp actual "$cli"/colA &&
+ (
+ cd "$git" &&
+ "$GITP4" sync --use-client-spec &&
+ git merge --ff-only p4/master
+ ) &&
+ git_verify $files &&
+ test_cmp actual "$git"/colA
+'
+
+test_expect_success 'overlay sync: add colB in dir1' '
+ client_view "//depot/dir1/... //client/dir1/..." &&
+ (
+ cd "$cli" &&
+ p4 sync &&
+ echo dir1/colB >dir1/colB &&
+ p4 add dir1/colB &&
+ p4 submit -d dir1/colB
+ )
+'
+
+test_expect_success 'overlay sync: colB appears' '
+ client_view "//depot/dir1/... //client/..." \
+ "+//depot/dir2/... //client/..." &&
+ files="file11 file12 file21 file22 colA colB" &&
+ echo dir1/colB >actual &&
+ client_verify $files &&
+ test_cmp actual "$cli"/colB &&
+ (
+ cd "$git" &&
+ "$GITP4" sync --use-client-spec &&
+ git merge --ff-only p4/master
+ ) &&
+ git_verify $files &&
+ test_cmp actual "$git"/colB
+'
+
+test_expect_success 'overlay sync: add/delete colB in dir2' '
+ client_view "//depot/dir2/... //client/dir2/..." &&
+ (
+ cd "$cli" &&
+ p4 sync &&
+ echo dir2/colB >dir2/colB &&
+ p4 add dir2/colB &&
+ p4 submit -d dir2/colB &&
+ p4 delete dir2/colB &&
+ p4 submit -d "delete dir2/colB"
+ )
+'
+
+test_expect_success 'overlay sync: colB disappears' '
+ client_view "//depot/dir1/... //client/..." \
+ "+//depot/dir2/... //client/..." &&
+ files="file11 file12 file21 file22 colA" &&
+ client_verify $files &&
+ test_when_finished cleanup_git &&
+ (
+ cd "$git" &&
+ "$GITP4" sync --use-client-spec &&
+ git merge --ff-only p4/master
+ ) &&
+ git_verify $files
+'
+
+test_expect_success 'overlay sync: cleanup' '
+ client_view "//depot/... //client/..." &&
+ (
+ cd "$cli" &&
+ p4 sync &&
+ p4 delete dir1/colA dir2/colA dir1/colB &&
+ p4 submit -d "remove overlay sync files"
+ )
+'
+
+#
+# Overlay tests again, but swapped so dir1 has priority.
+# 1. add a file in dir1
+# 2. sync to include it
+# 3. add same file in dir2
+# 4. sync, make sure content does not switch
+# 5. add another file in dir1
+# 6. sync
+# 7. add/delete same file in dir2
+# 8. sync, make sure it is still there
+# 9. cleanup
+#
+# //depot
+# - dir1
+# - file11
+# - file12
+# - colA
+# - colB
+# - dir2
+# - file21
+# - file22
+# - colA
+# - colB
+#
+test_expect_success 'overlay sync swap: add colA in dir1' '
+ client_view "//depot/dir1/... //client/dir1/..." &&
+ (
+ cd "$cli" &&
+ p4 sync &&
+ echo dir1/colA >dir1/colA &&
+ p4 add dir1/colA &&
+ p4 submit -d dir1/colA
+ )
+'
+
+test_expect_success 'overlay sync swap: initial git checkout' '
+ client_view "//depot/dir2/... //client/..." \
+ "+//depot/dir1/... //client/..." &&
+ files="file11 file12 file21 file22 colA" &&
+ echo dir1/colA >actual &&
+ client_verify $files &&
+ test_cmp actual "$cli"/colA &&
+ "$GITP4" clone --use-client-spec --dest="$git" //depot &&
+ git_verify $files &&
+ test_cmp actual "$git"/colA
+'
+
+test_expect_success 'overlay sync swap: add colA in dir2' '
+ client_view "//depot/dir2/... //client/dir2/..." &&
+ (
+ cd "$cli" &&
+ p4 sync &&
+ echo dir2/colA >dir2/colA &&
+ p4 add dir2/colA &&
+ p4 submit -d dir2/colA
+ )
+'
+
+test_expect_failure 'overlay sync swap: colA no content switch' '
+ client_view "//depot/dir2/... //client/..." \
+ "+//depot/dir1/... //client/..." &&
+ files="file11 file12 file21 file22 colA" &&
+ echo dir1/colA >actual &&
+ client_verify $files &&
+ test_cmp actual "$cli"/colA &&
+ (
+ cd "$git" &&
+ "$GITP4" sync --use-client-spec &&
+ git merge --ff-only p4/master
+ ) &&
+ git_verify $files &&
+ test_cmp actual "$git"/colA
+'
+
+test_expect_success 'overlay sync swap: add colB in dir1' '
+ client_view "//depot/dir1/... //client/dir1/..." &&
+ (
+ cd "$cli" &&
+ p4 sync &&
+ echo dir1/colB >dir1/colB &&
+ p4 add dir1/colB &&
+ p4 submit -d dir1/colB
+ )
+'
+
+test_expect_success 'overlay sync swap: colB appears' '
+ client_view "//depot/dir2/... //client/..." \
+ "+//depot/dir1/... //client/..." &&
+ files="file11 file12 file21 file22 colA colB" &&
+ echo dir1/colB >actual &&
+ client_verify $files &&
+ test_cmp actual "$cli"/colB &&
+ (
+ cd "$git" &&
+ "$GITP4" sync --use-client-spec &&
+ git merge --ff-only p4/master
+ ) &&
+ git_verify $files &&
+ test_cmp actual "$git"/colB
+'
+
+test_expect_success 'overlay sync swap: add/delete colB in dir2' '
+ client_view "//depot/dir2/... //client/dir2/..." &&
+ (
+ cd "$cli" &&
+ p4 sync &&
+ echo dir2/colB >dir2/colB &&
+ p4 add dir2/colB &&
+ p4 submit -d dir2/colB &&
+ p4 delete dir2/colB &&
+ p4 submit -d "delete dir2/colB"
+ )
+'
+
+test_expect_failure 'overlay sync swap: colB no change' '
+ client_view "//depot/dir2/... //client/..." \
+ "+//depot/dir1/... //client/..." &&
+ files="file11 file12 file21 file22 colA colB" &&
+ echo dir1/colB >actual &&
+ client_verify $files &&
+ test_cmp actual "$cli"/colB &&
+ test_when_finished cleanup_git &&
+ (
+ cd "$git" &&
+ "$GITP4" sync --use-client-spec &&
+ git merge --ff-only p4/master
+ ) &&
+ git_verify $files &&
+ test_cmp actual "$cli"/colB
+'
+
+test_expect_success 'overlay sync swap: cleanup' '
+ client_view "//depot/... //client/..." &&
+ (
+ cd "$cli" &&
+ p4 sync &&
+ p4 delete dir1/colA dir2/colA dir1/colB &&
+ p4 submit -d "remove overlay sync files"
+ )
+'
+
+#
# Rename directories to test quoting in depot-side mappings
# //depot
# - "dir 1"
--
1.7.8.1.409.g3e338.dirty
^ permalink raw reply related
* Re: [PATCHv3 10/13] credentials: add "cache" helper
From: Jonathan Nieder @ 2012-01-11 23:50 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20120110175312.GA7289@sigill.intra.peff.net>
Jeff King wrote:
> Still, it would be slightly more robust. I wonder how portable fchdir
> is in practice (I guess we could always fall back to the getcwd code
> path). Do you want to prepare a patch on top?
I've been wanting to get around to doing something similar for setup.c
for a while. I'm happy enough to forget about it for now. ;-)
Thanks again for the fix. Here's another quick nit.
-- >8 --
Subject: unix-socket: do not let close() or chdir() clobber errno during cleanup
unix_stream_connect and unix_stream_listen return -1 on error, with
errno set by the failing underlying call to allow the caller to write
a useful diagnosis.
Unfortunately the error path involves a few system calls itself, such
as close(), that can themselves touch errno.
This is not as worrisome as it might sound. If close() fails, this
just means substituting one meaningful error message for another,
which is perfectly fine. However, when the call _succeeds_, it is
allowed to (and sometimes might) clobber errno along the way with some
undefined value, so it is good higiene to save errno and restore it
immediately before returning to the caller. Do so.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
unix-socket.c | 39 ++++++++++++++++++++++-----------------
1 files changed, 22 insertions(+), 17 deletions(-)
diff --git a/unix-socket.c b/unix-socket.c
index 7d8bec61..01f119f9 100644
--- a/unix-socket.c
+++ b/unix-socket.c
@@ -73,25 +73,29 @@ static int unix_sockaddr_init(struct sockaddr_un *sa, const char *path,
int unix_stream_connect(const char *path)
{
- int fd;
+ int fd, saved_errno;
struct sockaddr_un sa;
struct unix_sockaddr_context ctx;
if (unix_sockaddr_init(&sa, path, &ctx) < 0)
return -1;
fd = unix_stream_socket();
- if (connect(fd, (struct sockaddr *)&sa, sizeof(sa)) < 0) {
- unix_sockaddr_cleanup(&ctx);
- close(fd);
- return -1;
- }
+ if (connect(fd, (struct sockaddr *)&sa, sizeof(sa)) < 0)
+ goto fail;
unix_sockaddr_cleanup(&ctx);
return fd;
+
+fail:
+ saved_errno = errno;
+ unix_sockaddr_cleanup(&ctx);
+ close(fd);
+ errno = saved_errno;
+ return -1;
}
int unix_stream_listen(const char *path)
{
- int fd;
+ int fd, saved_errno;
struct sockaddr_un sa;
struct unix_sockaddr_context ctx;
@@ -100,18 +104,19 @@ int unix_stream_listen(const char *path)
fd = unix_stream_socket();
unlink(path);
- if (bind(fd, (struct sockaddr *)&sa, sizeof(sa)) < 0) {
- unix_sockaddr_cleanup(&ctx);
- close(fd);
- return -1;
- }
+ if (bind(fd, (struct sockaddr *)&sa, sizeof(sa)) < 0)
+ goto fail;
- if (listen(fd, 5) < 0) {
- unix_sockaddr_cleanup(&ctx);
- close(fd);
- return -1;
- }
+ if (listen(fd, 5) < 0)
+ goto fail;
unix_sockaddr_cleanup(&ctx);
return fd;
+
+fail:
+ saved_errno = errno;
+ unix_sockaddr_cleanup(&ctx);
+ close(fd);
+ errno = saved_errno;
+ return -1;
}
--
1.7.8.3
^ permalink raw reply related
* Re: [PATCH 1/2] cache-tree: update API to take abitrary flags
From: Junio C Hamano @ 2012-01-11 23:48 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git
In-Reply-To: <1326275982-29866-2-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> ---
Thanks; this one looks very sensible regardless of what follows (or does
not follow). Forgot to sign-off?
^ permalink raw reply
* Re: [PATCH 2/2] commit: add --skip-intent-to-add to allow commit with i-t-a entries in index
From: Junio C Hamano @ 2012-01-11 23:55 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git
In-Reply-To: <1326275982-29866-3-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> ---
> builtin/commit.c | 10 +++++++---
> cache-tree.c | 8 +++++---
> cache-tree.h | 1 +
> t/t2203-add-intent.sh | 17 +++++++++++++++++
> 4 files changed, 30 insertions(+), 6 deletions(-)
>
> diff --git a/builtin/commit.c b/builtin/commit.c
> index bf42bb3..021206e 100644
> --- a/builtin/commit.c
> +++ b/builtin/commit.c
> @@ -86,6 +86,7 @@ static int all, also, interactive, patch_interactive, only, amend, signoff;
> static int edit_flag = -1; /* unspecified */
> static int quiet, verbose, no_verify, allow_empty, dry_run, renew_authorship;
> static int no_post_rewrite, allow_empty_message;
> +static int cache_tree_flags, skip_intent_to_add;
> static char *untracked_files_arg, *force_date, *ignore_submodule_arg;
> static char *sign_commit;
>
> @@ -170,6 +171,7 @@ static struct option builtin_commit_options[] = {
> OPT_BOOLEAN(0, "amend", &amend, "amend previous commit"),
> OPT_BOOLEAN(0, "no-post-rewrite", &no_post_rewrite, "bypass post-rewrite hook"),
> { OPTION_STRING, 'u', "untracked-files", &untracked_files_arg, "mode", "show untracked files, optional modes: all, normal, no. (Default: all)", PARSE_OPT_OPTARG, NULL, (intptr_t)"all" },
> + OPT_BOOL(0, "skip-intent-to-add", &skip_intent_to_add, "allow intent-to-add entries in index"),
This is more like "ignore", not "allow", from end user's point of view,
no? The user earlier said "I cannot decide what contents to put in the
commit yet for this path", and normally we catch it and remind the user
that she needs to decide. This option gives her a quick way to say "I
decide that I do not want to add this path at all to this commit I am
creating, so please ignore it in the meantime."
> @@ -1088,6 +1090,8 @@ static int parse_and_validate_options(int argc, const char *argv[],
> cleanup_mode = CLEANUP_ALL;
> else
> die(_("Invalid cleanup mode %s"), cleanup_arg);
> + if (skip_intent_to_add)
> + cache_tree_flags = WRITE_TREE_INTENT_TO_ADD_OK;
The name WRITE_TREE_INTENT_TO_ADD_OK says "it is OK to call write-tree
with i-t-a entries in the index, please do not barf", but I think "when
writing a tree, ignore i-t-a entries" would be a more appropriate way to
say the same thing, i.e. WRITE_TREE_IGNORE_INTENT_TO_ADD.
Other than that, I do not see an issue in the implementation of the
patch. It is a separate design level issue if we want to worsen
proliferation of the options, though.
Thanks.
^ 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