[PATCH] git-log: added --none-match option
Implements a inverted match for "git log", like in the case of
"git grep -v", which is useful from time to time to e.g. filter
FIXUP message out of "git log".
Internally, a new bol 'none_match' has been introduces as
revs->grep_filter.invert inverts the match line-wise, which cannot
work as i.e. empty line always not match the pattern given.
Signed-off-by: Christoph Junghans
---
Documentation/rev-list-options.txt | 4
contrib/completion/git-completion.bash | 2 +-
grep.c | 2 ++
grep.h | 1 +
revision.c | 4
5 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/Documentation/rev-list-options.txt
b/Documentation/rev-list-options.txt
index afccfdc..08e4ed8 100644
--- a/Documentation/rev-list-options.txt
+++ b/Documentation/rev-list-options.txt
@@ -66,6 +66,10 @@ if it is part of the log message.
Limit the commits output to ones that match all given `--grep`,
instead of ones that match at least one.
+--none-match::
+ Limit the commits output to ones that do not match any of the
+ given `--grep`, instead of ones that match at least one.
+
-i::
--regexp-ignore-case::
Match the regular expression limiting patterns without regard to letter
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index 23988ec..b0720e9 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1425,7 +1425,7 @@ __git_log_gitk_options="
# Options that go well for log and shortlog (not gitk)
__git_log_shortlog_options="
--author= --committer= --grep=
- --all-match
+ --all-match --none-match
"
__git_log_pretty_formats="oneline short medium full fuller email raw format:"
diff --git a/grep.c b/grep.c
index 6e085f8..eadf8d9 100644
--- a/grep.c
+++ b/grep.c
@@ -1622,6 +1622,8 @@ static int chk_hit_marker(struct grep_expr *x)
int grep_source(struct grep_opt *opt, struct grep_source *gs)
{
+ if(opt->none_match)
+ return !grep_source_1(opt, gs, 0);
/*
* we do not have to do the two-pass grep when we do not check
* buffer-wide "all-match".
diff --git a/grep.h b/grep.h
index 95f197a..8e50c95 100644
--- a/grep.h
+++ b/grep.h
@@ -102,6 +102,7 @@ struct grep_opt {
int word_regexp;
int fixed;
int all_match;
+ int none_match;
int debug;
#define GREP_BINARY_DEFAULT0
#define GREP_BINARY_NOMATCH1
diff --git a/revision.c b/revision.c
index 75dda92..d43779e 100644
--- a/revision.c
+++ b/revision.c
@@ -2011,6 +2011,8 @@ static int handle_revision_opt(struct rev_info *revs, int
argc, const char **arg
grep_set_pattern_type_option(GREP_PATTERN_TYPE_PCRE,
&revs->grep_filter);
} else if (!strcmp(arg, "--all-match")) {
revs->grep_filter.all_match = 1;
+ } else if (!strcmp(arg, "--none-match")) {
+ revs->grep_filter.none_match = 1;
} else if ((argcount = parse_long_opt("encoding", argv, &optarg))) {
if (strcmp(optarg, "none"))
git_log_output_encoding = xstrdup(optarg);
@@ -2333,6 +2335,8 @@ int setup_revisions(int argc, const char **argv, struct
rev_info *revs, struct s
die("cannot combine --walk-reflogs with --graph");
if (!revs->reflog_info && revs->grep_filter.use_reflog_filter)
die("cannot use --grep-reflog without --walk-reflogs");
+ if (revs->grep_filter.all_match && revs->grep_filter.none_match)
+ die("cannot combine --all-match with --none-match");
return left;
}
--
2.0.5
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
git stash fails on symlinked directory
Hello, I’ve just run into this issue described earlier elsewhere: * http://permalink.gmane.org/gmane.comp.version-control.git/241909 * https://groups.google.com/forum/#!topic/git-users/hbhf7-QTbFM Is this a bug (it certainly seems like one to me). Is this something developers are aware of? Thanks, Ádám -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RFC: web UI for commit dependency inference tool
Hi all, Thanks to my employer's generous "Hack Week" policy[0], I have the luxury of being able to spend most of next week hacking on a git commit dependency inference tool which I built 14 months ago but never got round to polishing up or publically announcing. In this email I'll briefly explain the tool and some ideas I have for adding a web-based UI to it next week - any feedback is most welcome. [0] https://hackweek.suse.com/ Background theory = It is fairly clear that two git commits within a single repo can be considered "independent" from each other in a certain sense, if they do not change the same files, or if they do not change overlapping parts of the same file(s). In contrast, when a commit changes a line, it is "dependent" on not only the commit which last changed that line, but also any commits which were responsible for providing the surrounding lines of context, because without those previous versions of the line and its context, the commit's diff might not cleanly apply[1]. So all dependencies of a commit can be programmatically inferred by running git-blame on the lines the commit changes, plus however many lines of context make sense for the use case of this particular dependency analysis. Therefore the dependency calculation is impacted by a "fuzz" factor (c.f. patch(1)) parameter, i.e. the number of lines of context which are considered necessary for the commit's diff to cleanly apply. As with many dependency relationships, these dependencies form edges in a DAG (directed acyclic graph) whose nodes correspond to commits. Note that a node can only depend on a subset of its ancestors. [1] Depending on how it's being applied, of course. Motivation == Sometimes it is useful to understand the nature of parts of this DAG, as its nature will impact the success or failure of operations including merge, rebase, cherry-pick etc. For example when porting a commit "A" between git branches via git cherry-pick, it can be useful to programmatically determine in advance the minimum number of other dependent commits which would also need to be cherry-picked to provide the context for commit "A" to cleanly apply. Another use case might be to better understand levels of specialism / cross-functionality within an agile team. If I author a commit which modifies (say) lines 34-37 and 102-109 of a file, the authors of the dependent commits forms a list which indicates the group of people I should potentially consider asking to review my commit, since I'm effectively changing "their" code. Monitoring those relationships over time might shed some light on how agile teams should best coordinate efforts on shared code bases. I'm sure there are other use cases I haven't yet thought of. At first I thought that it might provide a useful way to programmatically predict whether operations such as merge / rebase / cherry-pick would succeed, but actually it's probably cheaper and more reliable simply to perform the operation and then roll back. BTW the dependency graph is likely to be semantically incomplete; for example it would not auto-detect dependencies between a commit A which changes code and another commit B which changes documentation or tests to reflect the code changes in commit A. (Although of course it's usually best practice to logically group such changes together in a single commit.) But this should not stop it from being useful. Current status == I have written a tool called git-deps which automatically walks this graph: https://github.com/aspiers/git-config/blob/master/bin/git-deps I haven't yet documented it or formally announced it until now, but it's a single Python script, and usage is fairly self-explanatory: $ git deps -h usage: git-deps [options] COMMIT-ISH [COMMIT-ISH...] Auto-detects commits which the given commit(s) depend on. optional arguments: -h, --helpshow this help message and exit -l, --log Show commit logs for calculated dependencies [False] -r, --recurse Follow dependencies recursively [False] -e COMMITISH, --exclude-commits COMMITISH Exclude commits which are ancestors of the given COMMITISH (can be repeated) -c NUM, --context-lines NUM Number of lines of diff context to use [1] -d, --debug Show debugging [False] By default it will list all dependencies of the given commit-ish(s), but with --recurse it will one dependency (i.e. two SHA1s representing a graph edge) per line. There is still plenty of scope for optimization, e.g. it only takes partial advantage of pygit2. Future plans 1. Interactive graph visualization Currently the output is text only, but I think it would be more useful to visualise the dependencies as an interactive graph where you could zoom in/out, pan around, hover o
Re: [PATCH v2] remote-curl: fall back to Basic auth if Negotiate fails
On Sat, Jan 03, 2015 at 05:45:09PM +, brian m. carlson wrote:
> >+{
> >+int flags = CURLAUTH_ANY;
>
> I think this needs to be unsigned long or it can cause undefined behavior,
> since libcurl uses unsigned long in the flags. I'll fix that up when I
> reroll. I'll need your sign-off since it will essentially be your work.
I think curl typically uses signed "long" for flags, but certainly
check the docs to be sure.
I was thinking it would be integer-promoted in this case, but I'm not
sure that works always (certainly it does not if CURLAUTH_ANY needs high
bits, but depending on how curl_easy_setopt is implemented, it may also
be implicitly cast as a pointer or something).
And certainly you can have my signoff:
Signed-off-by: Jeff King
-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] for-each-ref: Always check stat_tracking_info()'s return value.
Jeff King writes: > I think you could minimize this quite a bit as: > > diff --git a/t/t6300-for-each-ref.sh b/t/t6300-for-each-ref.sh > index cba3454..f259c22 100755 > --- a/t/t6300-for-each-ref.sh > +++ b/t/t6300-for-each-ref.sh > @@ -340,12 +340,11 @@ cat >expected < EOF > > test_expect_success 'Check that :track[short] works when upstream is gone' ' > - git branch --track to_delete master && > - git branch --track parent_gone to_delete && > - test_when_finished "git branch -D parent_gone" && > - git branch -D to_delete && > - git for-each-ref --format="%(upstream:track)" refs/heads/parent_gone > >actual && > - git for-each-ref --format="%(upstream:trackshort)" > refs/heads/parent_gone >>actual && > + test_when_finished "git config branch.master.merge refs/heads/master" && > + git config branch.master.merge refs/heads/does-not-exist && > + git for-each-ref \ > + --format="%(upstream:track)$LF%(upstream:trackshort)" \ > + refs/heads/master >actual && > test_cmp expected actual > ' Thanks Jeff (and Eric!) for the reviews so far. That does look much better (the original test case was a reduction of a failure in a Chromium test case). One question about this suggestion: this test case actually depends on the remote manipulations done in the setup test to work, as otherwise we don't even test stat_tracking_info() because populate_value() would bail out earlier on branch_get() returning NULL due to the branch's remote not being set. Is it OK to continue assuming that? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] remote-curl: fall back to Basic auth if Negotiate fails
On Sat, Jan 03, 2015 at 06:19:23AM -0500, Jeff King wrote:
This pattern gets repeated in several places. Now that
http_passwordless_auth is a global, can we handle it automatically for
the callers, as below (which, aside from compiling, is completely
untested by me)?
This looks good (although I haven't tested it).
Note that this is in a slightly different boat than credential_fill.
Ideally we would also handle picking up credentials on behalf of the
callers of get_curl_handle/handle_curl_result. But that may involve
significant work and/or prompting the user, which we _must_ avoid if we
do not know if we are going to retry the request (and only the caller
knows that for sure). However, in the case of http_passwordless_auth, we
are just setting a flag, so it's OK to do it preemptively.
Right. We already prompt the user for a username and password in that
case, so we already have the credentials that we need.
diff --git a/http.c b/http.c
index 040f362..2bbcdf1 100644
--- a/http.c
+++ b/http.c
@@ -62,6 +62,8 @@ static const char *user_agent;
static struct credential cert_auth = CREDENTIAL_INIT;
static int ssl_cert_password_required;
+/* Should we allow non-password-based authentication (e.g. GSSAPI)? */
+static int http_passwordless_auth = 1;
static struct curl_slist *pragma_header;
static struct curl_slist *no_pragma_header;
@@ -318,7 +320,12 @@ static CURL *get_curl_handle(void)
curl_easy_setopt(result, CURLOPT_NETRC, CURL_NETRC_OPTIONAL);
#endif
#ifdef LIBCURL_CAN_HANDLE_AUTH_ANY
- curl_easy_setopt(result, CURLOPT_HTTPAUTH, CURLAUTH_ANY);
+ {
+ int flags = CURLAUTH_ANY;
I think this needs to be unsigned long or it can cause undefined
behavior, since libcurl uses unsigned long in the flags. I'll fix that
up when I reroll. I'll need your sign-off since it will essentially be
your work.
+ if (!http_passwordless_auth)
+ flags &= ~CURLAUTH_GSSNEGOTIATE;
+ curl_easy_setopt(result, CURLOPT_HTTPAUTH, flags);
+ }
#endif
if (http_proactive_auth)
@@ -870,6 +877,7 @@ int handle_curl_result(struct slot_results *results)
credential_reject(&http_auth);
return HTTP_NOAUTH;
} else {
+ http_passwordless_auth = 0;
return HTTP_REAUTH;
}
} else {
Note that you could probably drop http_passwordless_auth completely, and
just keep a:
static int http_auth_methods = CURLAUTH_ANY;
and then drop CURLAUTH_GSSNEGOTIATE from it instead of setting the
passwordless_auth flag to 0 (again, it happens in one place, so I don't
know that it needs an extra layer of abstraction).
This does seem to handle both cases well. It also has the pleasant
side effect of being static.
--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187
signature.asc
Description: Digital signature
Re: [PATCH v3] for-each-ref: Always check stat_tracking_info()'s return value.
On Fri, Jan 02, 2015 at 11:01:53PM +0200, Raphael Kubo da Costa wrote:
> In this case, num_ours and num_theirs had undefined values and a call to
> `git for-each-ref --format="%(upstream:track)"` could print spurious
> values such as
>
> [behind -111794512]
> [ahead 38881640, behind 5103867]
>
> even for repositories with one single commit.
>
> We now properly verify stat_tracking_info()'s return value and do not
> print anything if it returns -1. This behavior also matches the
> documentation ("has no effect if the ref does not have tracking
> information associated with it").
Thanks, this iteration looks good to me, and this is definitely a bug
worth fixing.
> +test_expect_success 'Check that :track[short] works when upstream is gone' '
> + git branch --track to_delete master &&
> + git branch --track parent_gone to_delete &&
> + test_when_finished "git branch -D parent_gone" &&
> + git branch -D to_delete &&
> + git for-each-ref --format="%(upstream:track)" refs/heads/parent_gone
> >actual &&
> + git for-each-ref --format="%(upstream:trackshort)"
> refs/heads/parent_gone >>actual &&
> + test_cmp expected actual
> +'
I think you could minimize this quite a bit as:
diff --git a/t/t6300-for-each-ref.sh b/t/t6300-for-each-ref.sh
index cba3454..f259c22 100755
--- a/t/t6300-for-each-ref.sh
+++ b/t/t6300-for-each-ref.sh
@@ -340,12 +340,11 @@ cat >expected >actual &&
+ test_when_finished "git config branch.master.merge refs/heads/master" &&
+ git config branch.master.merge refs/heads/does-not-exist &&
+ git for-each-ref \
+ --format="%(upstream:track)$LF%(upstream:trackshort)" \
+ refs/heads/master >actual &&
test_cmp expected actual
'
which IMHO makes it a little more obvious what the setup is doing. But I
am OK with it either way.
-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] remote-curl: fall back to Basic auth if Negotiate fails
On Thu, Jan 01, 2015 at 07:56:27PM +, brian m. carlson wrote:
> +void disable_passwordless_auth(struct active_request_slot *slot)
> +{
> +#ifdef LIBCURL_CAN_HANDLE_AUTH_ANY
> +#define HTTP_AUTH_PASSWORDLESS (CURLAUTH_GSSNEGOTIATE)
> + curl_easy_setopt(slot->curl, CURLOPT_HTTPAUTH,
> + CURLAUTH_ANY & ~HTTP_AUTH_PASSWORDLESS);
> +#endif
> +}
I like that you are trying to put a layer of abstraction around what
"passwordless" means here, but it seems like there are two layers. The
function itself abstracts the idea, and then there is an extra
HTTP_AUTH_PASSWORDLESS macro. Since the concept is already confined to
this function and used only once, it might be more readable to simply
get rid of HTTP_AUTH_PASSWORD.
> @@ -1035,6 +1047,9 @@ static int http_request(const char *url,
> curl_easy_setopt(slot->curl, CURLOPT_HTTPHEADER, headers);
> curl_easy_setopt(slot->curl, CURLOPT_ENCODING, "gzip");
>
> + if (!http_passwordless_auth)
> + disable_passwordless_auth(slot);
> +
> ret = run_one_slot(slot, &results);
>
> if (options && options->content_type) {
> @@ -1139,6 +1154,7 @@ static int http_request_reauth(const char *url,
> }
>
> credential_fill(&http_auth);
> + http_passwordless_auth = 0;
>
> return http_request(url, result, target, options);
> }
This pattern gets repeated in several places. Now that
http_passwordless_auth is a global, can we handle it automatically for
the callers, as below (which, aside from compiling, is completely
untested by me)?
Note that this is in a slightly different boat than credential_fill.
Ideally we would also handle picking up credentials on behalf of the
callers of get_curl_handle/handle_curl_result. But that may involve
significant work and/or prompting the user, which we _must_ avoid if we
do not know if we are going to retry the request (and only the caller
knows that for sure). However, in the case of http_passwordless_auth, we
are just setting a flag, so it's OK to do it preemptively.
diff --git a/http.c b/http.c
index 040f362..2bbcdf1 100644
--- a/http.c
+++ b/http.c
@@ -62,6 +62,8 @@ static const char *user_agent;
static struct credential cert_auth = CREDENTIAL_INIT;
static int ssl_cert_password_required;
+/* Should we allow non-password-based authentication (e.g. GSSAPI)? */
+static int http_passwordless_auth = 1;
static struct curl_slist *pragma_header;
static struct curl_slist *no_pragma_header;
@@ -318,7 +320,12 @@ static CURL *get_curl_handle(void)
curl_easy_setopt(result, CURLOPT_NETRC, CURL_NETRC_OPTIONAL);
#endif
#ifdef LIBCURL_CAN_HANDLE_AUTH_ANY
- curl_easy_setopt(result, CURLOPT_HTTPAUTH, CURLAUTH_ANY);
+ {
+ int flags = CURLAUTH_ANY;
+ if (!http_passwordless_auth)
+ flags &= ~CURLAUTH_GSSNEGOTIATE;
+ curl_easy_setopt(result, CURLOPT_HTTPAUTH, flags);
+ }
#endif
if (http_proactive_auth)
@@ -870,6 +877,7 @@ int handle_curl_result(struct slot_results *results)
credential_reject(&http_auth);
return HTTP_NOAUTH;
} else {
+ http_passwordless_auth = 0;
return HTTP_REAUTH;
}
} else {
Note that you could probably drop http_passwordless_auth completely, and
just keep a:
static int http_auth_methods = CURLAUTH_ANY;
and then drop CURLAUTH_GSSNEGOTIATE from it instead of setting the
passwordless_auth flag to 0 (again, it happens in one place, so I don't
know that it needs an extra layer of abstraction).
-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv9 1/9] receive-pack.c: shorten the execute_commands loop over all commands
On Sat, Jan 3, 2015 at 9:20 AM, Jonathan Nieder wrote:
>> - if (shallow_update && !checked_connectivity)
>> - error("BUG: run 'git fsck' for safety.\n"
>> - "If there are errors, try to remove "
>> - "the reported refs above");
>> + if (shallow_update)
>> + check_shallow_bugs(commands, si);
>
> In the same spirit of saving the reader from having to look at the
> body of check_shallow_bugs, would it make sense for the part that reacts
> to an error to be kept in the caller? E.g.:
>
> if (shallow_update && warn_if_skipped_connectivity_check(commands,
> si))
> error("BUG: run 'git fsck for safety.\n"
> "If there are errors, try removing the refs reported
> above");
>
> Is this error possible, by the way?
That code is to prevent bugs in future. The whole operation is spread
out in many functions/steps and people may overlook.
> update() does not return success
> unless it has reached the bottom block in the function. In the
> !is_null_sha1(new_sha1) case that means it calls update_shallow_ref(),
> which performs the connectivity check. In the is_null_sha1(new_sha1)
> case, update_shallow_info() does not set cmd->index and
> si->shallow_ref[cmd->index] cannot be set.
>
> Perhaps this error message could be written in a way that makes it
> clearer that we really expect it not to happen, like
>
> die("BUG: connectivity check skipped in shallow push???");
>
> (die() instead of error() to prevent refs from updating and pointing
> to a disconnected history).
If connectivity test is not done, we don't know if history is really
disconnected. But yeah die() may be better (err on the safe side).
--
Duy
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] checkout: add --ignore-other-wortrees
Noticed-by: Mark Levedahl
Signed-off-by: Nguyễn Thái Ngọc Duy
---
Documentation/git-checkout.txt | 6 ++
builtin/checkout.c | 6 +-
t/t2025-checkout-to.sh | 7 +++
3 files changed, 18 insertions(+), 1 deletion(-)
diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt
index 0c13825..52eaa48 100644
--- a/Documentation/git-checkout.txt
+++ b/Documentation/git-checkout.txt
@@ -232,6 +232,12 @@ section of linkgit:git-add[1] to learn how to operate the
`--patch` mode.
specific files such as HEAD, index... See "MULTIPLE WORKING
TREES" section for more information.
+--ignore-other-worktrees::
+ `git checkout` refuses when the wanted ref is already checked
+ out by another worktree. This option makes it check the ref
+ out anyway. In other words, the ref can be held by more than one
+ worktree.
+
::
Branch to checkout; if it refers to a branch (i.e., a name that,
when prepended with "refs/heads/", is a valid ref), then that
diff --git a/builtin/checkout.c b/builtin/checkout.c
index d8717ef..8b2bf20 100644
--- a/builtin/checkout.c
+++ b/builtin/checkout.c
@@ -37,6 +37,7 @@ struct checkout_opts {
int writeout_stage;
int overwrite_ignore;
int ignore_skipworktree;
+ int ignore_other_worktrees;
const char *new_branch;
const char *new_branch_force;
@@ -1210,7 +1211,8 @@ static int parse_branchname_arg(int argc, const char
**argv,
int flag;
char *head_ref = resolve_refdup("HEAD", 0, sha1, &flag);
if (head_ref &&
- (!(flag & REF_ISSYMREF) || strcmp(head_ref, new->path)))
+ (!(flag & REF_ISSYMREF) || strcmp(head_ref, new->path)) &&
+ !opts->ignore_other_worktrees)
check_linked_checkouts(new);
free(head_ref);
}
@@ -1341,6 +1343,8 @@ int cmd_checkout(int argc, const char **argv, const char
*prefix)
N_("second guess 'git checkout
no-such-branch'")),
OPT_FILENAME(0, "to", &opts.new_worktree,
N_("check a branch out in a separate working
directory")),
+ OPT_BOOL(0, "ignore-other-worktrees",
&opts.ignore_other_worktrees,
+N_("do not check if another worktree is holding the
given ref")),
OPT_END(),
};
diff --git a/t/t2025-checkout-to.sh b/t/t2025-checkout-to.sh
index 915b506..f8e4df4 100755
--- a/t/t2025-checkout-to.sh
+++ b/t/t2025-checkout-to.sh
@@ -79,6 +79,13 @@ test_expect_success 'die the same branch is already checked
out' '
)
'
+test_expect_success 'not die the same branch is already checked out' '
+ (
+ cd here &&
+ git checkout --ignore-other-worktrees --to anothernewmaster
newmaster
+ )
+'
+
test_expect_success 'not die on re-checking out current branch' '
(
cd there &&
--
2.2.0.84.ge9c7a8a
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] git-checkout.txt: a note about multiple checkout support for submodules
The goal seems to be using multiple checkouts to reduce disk space. But we have not reached an agreement how things should be. There are a couple options. - You may want to keep $SUB repos elsewhere (perhaps in a central place) outside $SUPER. This is also true for nested submodules where a superproject may be a submodule of another superproject. - You may want to keep all $SUB repos in $SUPER/modules (or some other place in $SUPER) - We could even push it further and merge all $SUB repos into $SUPER instead of storing them separately. But that would at least require ref namespace enabled. On top of that, git-submodule.sh expects $GIT_DIR/config to be per-worktree, at least for the submodule.* part. Here I think we have two options, either update config.c to also read $GIT_DIR/config.worktree (which is per worktree) in addition to $GIT_DIR/config (shared) and store worktree-specific vars in the new place, or update git-submodule.sh to read/write submodule.* directly from $GIT_DIR/config.submodule (per worktree). These take time to address properly. Meanwhile, make a note to the user that they should not use multiple worktrees in submodule context. Signed-off-by: Nguyễn Thái Ngọc Duy --- Documentation/git-checkout.txt | 3 +++ 1 file changed, 3 insertions(+) diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt index 52eaa48..72def5b 100644 --- a/Documentation/git-checkout.txt +++ b/Documentation/git-checkout.txt @@ -463,6 +463,9 @@ to `/path/main/.git/worktrees/test-next` then a file named `test-next` entry from being pruned. See linkgit:gitrepository-layout[5] for details. +Multiple checkout support for submodules is incomplete. It is NOT +recommended to make multiple checkouts of a superproject. + EXAMPLES -- 2.2.0.84.ge9c7a8a -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] checkout: pass whole struct to parse_branchname_arg instead of individual flags
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/checkout.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/builtin/checkout.c b/builtin/checkout.c
index 953b763..d8717ef 100644
--- a/builtin/checkout.c
+++ b/builtin/checkout.c
@@ -1079,11 +1079,12 @@ static void check_linked_checkouts(struct branch_info
*new)
static int parse_branchname_arg(int argc, const char **argv,
int dwim_new_local_branch_ok,
struct branch_info *new,
- struct tree **source_tree,
- unsigned char rev[20],
- const char **new_branch,
- int force_detach)
+ struct checkout_opts *opts,
+ unsigned char rev[20])
{
+ struct tree **source_tree = &opts->source_tree;
+ const char **new_branch = &opts->new_branch;
+ int force_detach = opts->force_detach;
int argcount = 0;
unsigned char branch_rev[20];
const char *arg;
@@ -1420,9 +1421,7 @@ int cmd_checkout(int argc, const char **argv, const char
*prefix)
opts.track == BRANCH_TRACK_UNSPECIFIED &&
!opts.new_branch;
int n = parse_branchname_arg(argc, argv, dwim_ok,
-&new, &opts.source_tree,
-rev, &opts.new_branch,
-opts.force_detach);
+&new, &opts, rev);
argv += n;
argc -= n;
}
--
2.2.0.84.ge9c7a8a
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/3] nd/multiple-work-trees updates
These patches are on top of what's in 'pu'. They add --ignore-other-worktrees and make a note about current submodule support status. I don't think submodule support is ready yet even with Max Kirillov's series [1]. His 03/03 is already fixed in 'pu' though, so only 01/03 and 02/03 are new. [1] http://thread.gmane.org/gmane.comp.version-control.git/261107 Nguyễn Thái Ngọc Duy (3): checkout: pass whole struct to parse_branchname_arg instead of individual flags checkout: add --ignore-other-wortrees git-checkout.txt: a note about multiple checkout support for submodules Documentation/git-checkout.txt | 9 + builtin/checkout.c | 19 +++ t/t2025-checkout-to.sh | 7 +++ 3 files changed, 27 insertions(+), 8 deletions(-) -- 2.2.0.84.ge9c7a8a -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
