Re: [PATCH v2 3/6] generate-cmdlist.sh: keep all information in common-cmds.h
Junio C Hamano writes: > Nguyễn Thái Ngọc Duy writes: > > > +category_list () { > > + command_list "$1" | awk '{print $2;}' | sort | uniq > > +} > > Piping output of awk to sort/uniq, instead of processing all inside > awk within the END block of the script, means that we are wasting > two processes---I do not think we care too much about it, but some > people might. > Can be written as: command_list "$1" | awk '!seen[$2]++ {print $2}' This doesn't actually sort it, though, which I'm not sure whether is a good thing or a bad thing in this case. But it is less work, and being fast is nice for completion scripts. Øsse
Re: [PATCH] rev-parse: rev-parse: add --is-shallow-repository
> Hm, can you say more about the context? From a certain point of view, > it might make sense for that command to succeed instead: if the repo > is already unshallow, then why should't "fetch --unshallow" complain > instead of declaring victory? A fellow in #git on Freenode was writing a script for automation and encountered this error, and asked how to find out whether a repo was shallow. My *first instinct* was to check if rev-parse had a flag for it; I wouldn't have been surprised if it did. I agree that treating it as a fatal error is a bit much in the first place, but I also think having a way to check can be useful. I also wonder if a lot of the stuff rev-parse is used for now should be moved to some sort of `git misc` command, but that's a different can of worms, so into rev-parse a new flag went. > What does git-path mean here? I wonder if it's a copy/paste error. > ... > Reviewed-by: Jonathan Nieder Yeah, the titles were copy-pasted without adjusting, thanks for fixing, Jonathan! ;) > I agree with the fixes to the test titles suggested, so I'll queue the > patch with the fixes squashed in. Hearing "yeah, the titles were > copy-pasted without adjusting, thanks for fixing, Jonathan!" sent by > =C3=98ystein would be super nice. Sounds good. Thanks for queueing my patch. My fourth! �sse
[PATCH] rev-parse: rev-parse: add --is-shallow-repository
Running `git fetch --unshallow` on a repo that is not in fact shallow produces a fatal error message. Add a helper to rev-parse that scripters can use to determine whether a repo is shallow or not. Signed-off-by: Øystein Walle --- Documentation/git-rev-parse.txt | 3 +++ builtin/rev-parse.c | 5 + t/t1500-rev-parse.sh| 15 +++ 3 files changed, 23 insertions(+) diff --git a/Documentation/git-rev-parse.txt b/Documentation/git-rev-parse.txt index b1293f24b..0917b8207 100644 --- a/Documentation/git-rev-parse.txt +++ b/Documentation/git-rev-parse.txt @@ -235,6 +235,9 @@ print a message to stderr and exit with nonzero status. --is-bare-repository:: When the repository is bare print "true", otherwise "false". +--is-shallow-repository:: + When the repository is shallow print "true", otherwise "false". + --resolve-git-dir :: Check if is a valid repository or a gitfile that points at a valid repository, and print the location of the diff --git a/builtin/rev-parse.c b/builtin/rev-parse.c index 2bd28d3c0..c923207f2 100644 --- a/builtin/rev-parse.c +++ b/builtin/rev-parse.c @@ -868,6 +868,11 @@ int cmd_rev_parse(int argc, const char **argv, const char *prefix) : "false"); continue; } + if (!strcmp(arg, "--is-shallow-repository")) { + printf("%s\n", is_repository_shallow() ? "true" + : "false"); + continue; + } if (!strcmp(arg, "--shared-index-path")) { if (read_cache() < 0) die(_("Could not read the index")); diff --git a/t/t1500-rev-parse.sh b/t/t1500-rev-parse.sh index 03d3c7f6d..9d3433a30 100755 --- a/t/t1500-rev-parse.sh +++ b/t/t1500-rev-parse.sh @@ -116,6 +116,21 @@ test_expect_success 'git-path inside sub-dir' ' test_cmp expect actual ' +test_expect_success 'git-path shallow repository' ' + test_commit test_commit && + echo true >expect && + git clone --depth 1 --no-local . shallow && + test_when_finished "rm -rf shallow" && + git -C shallow rev-parse --is-shallow-repository >actual && + test_cmp expect actual +' + +test_expect_success 'git-path notshallow repository' ' + echo false >expect && + git rev-parse --is-shallow-repository >actual && + test_cmp expect actual +' + test_expect_success 'showing the superproject correctly' ' git rev-parse --show-superproject-working-tree >out && test_must_be_empty out && -- 2.11.0.485.g4e59582
Re: [PATCH] stash: allow ref of a stash by index
Pasting text into Gmail's web interface is not conducive to sending tabs through the intertubes. But you get the idea.. Øsse
Re: [PATCH] stash: allow ref of a stash by index
Hi, guys I like this idea. It makes stash easier and quicker to use, and it "hides" the fact that it uses the reflog for keeping track of the made stashes. *Not* to say I discourage interested people from peeking under the hood. I just think it's nice to sometimes think of the stash as a separate concept instead of being built on top of strange merge commits constructed in temporary indexes :) The bash-specific code is a no-go, so here's a way to do it in a way that I think is in line with Git's code style for shell scripts. I took the liberty of removing the '|| exit 1' since the rev is verified later on anyway, as can be seen in the last piece of context. That way the argument munging can be done at a later stage where we don't have to loop over multiple ones. The first rev-parse's purpose is just to apply --sq. (Besides, the only way to do it at the top like in the original patch was for arg in bleh "$@" where bleh is a marker to indicate that the positional arguments should be cleared in a separate case branch so that they can be rebuilt with multiple invocations of set later. Not pretty, in my opinion.) Regards, Øsse diff --git a/git-stash.sh b/git-stash.sh index 826af18..b026288 100755 --- a/git-stash.sh +++ b/git-stash.sh @@ -384,7 +384,7 @@ parse_flags_and_rev() i_tree= u_tree= -REV=$(git rev-parse --no-flags --symbolic --sq "$@") || exit 1 +REV=$(git rev-parse --no-flags --symbolic --sq "$@" 2>/dev/null) FLAGS= for opt @@ -422,6 +422,15 @@ parse_flags_and_rev() ;; esac +case "$1" in +*[!0-9]*) +: +;; +*) +set -- "${ref_stash}@{$1}" +;; +esac + REV=$(git rev-parse --symbolic --verify --quiet "$1") || { reference="$1" die "$(eval_gettext "\$reference is not a valid reference")"
Re: [PATCH v2] for-each-ref: add %(upstream:gone) to mark missing refs
On 25 August 2016 at 07:56, Karthik Nayak wrote: > > I'm thinking more on the lines of `%(upstream)` being an atom and the > `:track` being an option under that atom. I like sub-atom though ;) > On second thought maybe "quark" is better :P > On Thu, Aug 25, 2016 at 12:03 AM, Jeff King wrote: >> >> Ah, right. I was feeling like this was all vaguely familiar. I think >> it would be better to push forward kn/ref-filter-branch-list. >> According to the last "what's cooking", I think that topic is waiting >> on more review. If you're willing and able to do so, that would be a >> big help. >> > > It's been waiting for review for a _long_ time now. > To be perfectly honest my C skills and familiarity with the git source code is not much to speak of. I very much want to take a close look but I cannot promise anything worth your time... But if I do find something I'd like to point out should I just reply directly to the e-mails containing the patches as one usually does even though they're months old at this point? Øsse -- 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] for-each-ref: add %(upstream:gone) to mark missing refs
Hi, Peff On 24 August 2016 at 20:07, Jeff King wrote > > Whoops, your v2 spurred me to review, but I accidentally read and > responded to v1. > Thanks for the review! I was worried this patch had been buried :-) In the mean time, however, I have discovered that this conflicts with kn/ref-filter-branch-list in pu. In that topic this specific feature is implemented as well. They incorporate it into %(upstream:track) instead of having a separate "sub-atom" (what's the correct nomenclature, by the way?) more in line with with branch -vv and your idea. I recall seeing discussions about this work earlier, but I based my patch on master and forgot to check pu. (It was a spur-of-the-moment thing fueled by a question in #git about how to parse branch -vv to delete all local branch who had their remote counter-parts removed after a fetch --prune.) Unless that topic gets rejected, or is known to not be merged for a _long_ while, my patch doesn't add much value. Regards, Øsse -- 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 v2] for-each-ref: add %(upstream:gone) to mark missing refs
git branch -vv will show "gone" next to a remote tracking branch if it does not exist. for-each-ref is suitable for parsing but had no way of showing this information. This introduces "%(upstream:gone)" to display "gone" in the formatted output if the ref does not exist or an empty string otherwise, analogous to git branch -vv. Signed-off-by: Øystein Walle --- I took the liberty of sending in a v2 on my own. Removed the last argument to stat_tracking_info() and used test_config instead of test_when_finished. Documentation/git-for-each-ref.txt | 5 +++-- ref-filter.c | 9 - t/t6300-for-each-ref.sh| 11 +++ 3 files changed, 22 insertions(+), 3 deletions(-) diff --git a/Documentation/git-for-each-ref.txt b/Documentation/git-for-each-ref.txt index f57e69b..039a86b 100644 --- a/Documentation/git-for-each-ref.txt +++ b/Documentation/git-for-each-ref.txt @@ -114,8 +114,9 @@ upstream:: `refname` above. Additionally respects `:track` to show "[ahead N, behind M]" and `:trackshort` to show the terse version: ">" (ahead), "<" (behind), "<>" (ahead and behind), - or "=" (in sync). Has no effect if the ref does not have - tracking information associated with it. + or "=" (in sync) and `:gone` to show "gone" if the remote ref + does not exist, or an empty string if it does. Has no effect if + the ref does not have tracking information associated with it. push:: The name of a local ref which represents the `@{push}` location diff --git a/ref-filter.c b/ref-filter.c index bc551a7..757f473 100644 --- a/ref-filter.c +++ b/ref-filter.c @@ -37,7 +37,7 @@ static struct used_atom { union { char color[COLOR_MAXLEN]; struct align align; - enum { RR_NORMAL, RR_SHORTEN, RR_TRACK, RR_TRACKSHORT } + enum { RR_NORMAL, RR_SHORTEN, RR_TRACK, RR_TRACKSHORT, RR_GONE } remote_ref; struct { enum { C_BARE, C_BODY, C_BODY_DEP, C_LINES, C_SIG, C_SUB } option; @@ -67,6 +67,8 @@ static void remote_ref_atom_parser(struct used_atom *atom, const char *arg) atom->u.remote_ref = RR_TRACK; else if (!strcmp(arg, "trackshort")) atom->u.remote_ref = RR_TRACKSHORT; + else if (!strcmp(arg, "gone")) + atom->u.remote_ref = RR_GONE; else die(_("unrecognized format: %%(%s)"), atom->name); } @@ -923,6 +925,11 @@ static void fill_remote_ref_details(struct used_atom *atom, const char *refname, *s = ">"; else *s = "<>"; + } else if (atom->u.remote_ref == RR_GONE) { + if (stat_tracking_info(branch, &num_ours, &num_theirs, NULL) < 0) + *s = "gone"; + else + *s = ""; } else /* RR_NORMAL */ *s = refname; } diff --git a/t/t6300-for-each-ref.sh b/t/t6300-for-each-ref.sh index 19a2823..f99bfd0 100755 --- a/t/t6300-for-each-ref.sh +++ b/t/t6300-for-each-ref.sh @@ -383,6 +383,17 @@ test_expect_success 'Check that :track[short] works when upstream is invalid' ' test_cmp expected actual ' +test_expect_success 'Check that :gone produces expected results' ' + cat >expected <<-\EOF && +gone + EOF + test_config branch.master.merge refs/heads/does-not-exist && + git for-each-ref \ + --format="%(upstream:gone)" \ + refs/heads >actual && + test_cmp expected actual +' + test_expect_success 'Check for invalid refname format' ' test_must_fail git for-each-ref --format="%(refname:INVALID)" ' -- 2.9.2 -- 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] for-each-ref: add %(upstream:gone) to mark missing refs
git branch -vv will show "gone" next to a remote tracking branch if it does not exist. for-each-ref is suitable for parsing but had no way of showing this information. This introduces "%(upstream:gone)" to display "gone" in the formatted output if the ref does not exist or an empty string otherwise, analogous to git branch -vv. Signed-off-by: Øystein Walle --- Documentation/git-for-each-ref.txt | 5 +++-- ref-filter.c | 10 +- t/t6300-for-each-ref.sh| 12 3 files changed, 24 insertions(+), 3 deletions(-) diff --git a/Documentation/git-for-each-ref.txt b/Documentation/git-for-each-ref.txt index f57e69b..039a86b 100644 --- a/Documentation/git-for-each-ref.txt +++ b/Documentation/git-for-each-ref.txt @@ -114,8 +114,9 @@ upstream:: `refname` above. Additionally respects `:track` to show "[ahead N, behind M]" and `:trackshort` to show the terse version: ">" (ahead), "<" (behind), "<>" (ahead and behind), - or "=" (in sync). Has no effect if the ref does not have - tracking information associated with it. + or "=" (in sync) and `:gone` to show "gone" if the remote ref + does not exist, or an empty string if it does. Has no effect if + the ref does not have tracking information associated with it. push:: The name of a local ref which represents the `@{push}` location diff --git a/ref-filter.c b/ref-filter.c index bc551a7..5402052 100644 --- a/ref-filter.c +++ b/ref-filter.c @@ -37,7 +37,7 @@ static struct used_atom { union { char color[COLOR_MAXLEN]; struct align align; - enum { RR_NORMAL, RR_SHORTEN, RR_TRACK, RR_TRACKSHORT } + enum { RR_NORMAL, RR_SHORTEN, RR_TRACK, RR_TRACKSHORT, RR_GONE } remote_ref; struct { enum { C_BARE, C_BODY, C_BODY_DEP, C_LINES, C_SIG, C_SUB } option; @@ -67,6 +67,8 @@ static void remote_ref_atom_parser(struct used_atom *atom, const char *arg) atom->u.remote_ref = RR_TRACK; else if (!strcmp(arg, "trackshort")) atom->u.remote_ref = RR_TRACKSHORT; + else if (!strcmp(arg, "gone")) + atom->u.remote_ref = RR_GONE; else die(_("unrecognized format: %%(%s)"), atom->name); } @@ -923,6 +925,12 @@ static void fill_remote_ref_details(struct used_atom *atom, const char *refname, *s = ">"; else *s = "<>"; + } else if (atom->u.remote_ref == RR_GONE) { + const char *upstream; + if (stat_tracking_info(branch, &num_ours, &num_theirs, &upstream) < 0) + *s = "gone"; + else + *s = ""; } else /* RR_NORMAL */ *s = refname; } diff --git a/t/t6300-for-each-ref.sh b/t/t6300-for-each-ref.sh index 19a2823..1fc5d1d 100755 --- a/t/t6300-for-each-ref.sh +++ b/t/t6300-for-each-ref.sh @@ -383,6 +383,18 @@ test_expect_success 'Check that :track[short] works when upstream is invalid' ' test_cmp expected actual ' +test_expect_success 'Check that :gone produces expected results' ' + cat >expected <<-\EOF && +gone + EOF + 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:gone)" \ + refs/heads >actual && + test_cmp expected actual +' + test_expect_success 'Check for invalid refname format' ' test_must_fail git for-each-ref --format="%(refname:INVALID)" ' -- 2.9.2 -- 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] Pass amend to pre-commit hook
Jeff King peff.net> writes: > > On Mon, Sep 14, 2015 at 01:14:20PM +0100, Alan Clucas wrote: > > > Pass a single parameter 'amend' to the pre-commit hook when performing a > > commit amend. > > I think this is a sensible thing to want, and it has come up a few > times. I'm not sure why the last round didn't get merged, though. Looks > like it just slipped through the cracks. > > Here are the relevant threads: > > http://thread.gmane.org/gmane.comp.version-control.git/260122 > > http://thread.gmane.org/gmane.comp.version-control.git/260245 > > Looks like there was some question of what to pass in the normal, > non-amend case. I've added interested parties from the original thread > to the cc here. > > -Peff > There were so many different ways of solving them that we weren't able to decide between them: Assuming we give the string "amend" as the hook's argv[1], what to do when --amend is not used? We can pass nothing, or the empty string, or the string "noamend". Then there was the suggestion of exporting GIT_AMEND=1 or something like that. In any case, what to do when we want to pass more arguments? Should we let the hook check argv[1] to decide whether --amend was used, argv[2] to check whether {some scenario here} is the case? Or make the hook author effectively implement options parsing? And then it died out... In my totally unprofessional opinion anything more complex than maybe passing "amend" in argv[1] is unwarranted. Since I posted my first patch almost a year ago there has been no discussion regarding passing other information along to pre-commit. Furthermore --amend is the only thing I know of that a pre-commit hook cannot discover on its own. On the other hand the desire for this has popped up at least twice on #git in the same time span. Alan Clucas' solution looks fine to me. It is essentially the same as mine. But mine had tests and whatnot ;-) Øsse
[PATCH v2] fetch: add configuration for making --all default
Fetching from all remotes by default is useful if you're working on a repo with few and/or fast remotes. It also lets you fetch from origin even if the current branch's upstream is elsewhere without specifying it explicitly. Signed-off-by: Øystein Walle --- Thanks for the quick feedback, Remi. There's a fixed version. Documentation/config.txt| 5 + Documentation/fetch-options.txt | 4 +++- Documentation/git-fetch.txt | 3 ++- builtin/fetch.c | 21 - t/t5514-fetch-multiple.sh | 23 +++ 5 files changed, 49 insertions(+), 7 deletions(-) diff --git a/Documentation/config.txt b/Documentation/config.txt index 3e37b93..997a8d9 100644 --- a/Documentation/config.txt +++ b/Documentation/config.txt @@ -1170,6 +1170,11 @@ fetch.prune:: If true, fetch will automatically behave as if the `--prune` option was given on the command line. See also `remote..prune`. +fetch.all:: + If true, fetch will automatically behave as if the `--all` + option was given on the command line unless a remote was given. The + default is false. + format.attach:: Enable multipart/mixed attachments as the default for 'format-patch'. The value can also be a double quoted string diff --git a/Documentation/fetch-options.txt b/Documentation/fetch-options.txt index 45583d8..aa95a30 100644 --- a/Documentation/fetch-options.txt +++ b/Documentation/fetch-options.txt @@ -1,5 +1,7 @@ --all:: - Fetch all remotes. + Fetch all remotes. This can be configured to be the default behaviour + when no remotes are given explicitly. See the `fetch.all` configuration + variable in linkgit:git-config[1]. -a:: --append:: diff --git a/Documentation/git-fetch.txt b/Documentation/git-fetch.txt index e62d9a0..584f3fb 100644 --- a/Documentation/git-fetch.txt +++ b/Documentation/git-fetch.txt @@ -36,7 +36,8 @@ there is a remotes. entry in the configuration file. (See linkgit:git-config[1]). When no remote is specified, by default the `origin` remote will be used, -unless there's an upstream branch configured for the current branch. +unless there's an upstream branch configured for the current branch, or the +`fetch.all` configuration variable is set to true. The names of refs that are fetched, together with the object names they point at, are written to `.git/FETCH_HEAD`. This information diff --git a/builtin/fetch.c b/builtin/fetch.c index 8d5b2db..715ea82 100644 --- a/builtin/fetch.c +++ b/builtin/fetch.c @@ -30,10 +30,12 @@ enum { }; static int fetch_prune_config = -1; /* unspecified */ +static int fetch_all_config = -1; /* unspecified */ static int prune = -1; /* unspecified */ +static int all = -1; /* unspecified */ #define PRUNE_BY_DEFAULT 0 /* do we prune by default? */ -static int all, append, dry_run, force, keep, multiple, update_head_ok, verbosity; +static int append, dry_run, force, keep, multiple, update_head_ok, verbosity; static int progress = -1, recurse_submodules = RECURSE_SUBMODULES_DEFAULT; static int tags = TAGS_DEFAULT, unshallow, update_shallow; static const char *depth; @@ -67,6 +69,10 @@ static int git_fetch_config(const char *k, const char *v, void *cb) fetch_prune_config = git_config_bool(k, v); return 0; } + if (!strcmp(k, "fetch.all")) { + fetch_all_config = git_config_bool(k, v); + return 0; + } return git_default_config(k, v, cb); } @@ -1168,7 +1174,7 @@ int cmd_fetch(int argc, const char **argv, const char *prefix) git_config(submodule_config, NULL); } - if (all) { + if (all == 1) { if (argc == 1) die(_("fetch --all does not take a repository argument")); else if (argc > 1) @@ -1176,9 +1182,14 @@ int cmd_fetch(int argc, const char **argv, const char *prefix) (void) for_each_remote(get_one_remote_for_fetch, &list); result = fetch_multiple(&list); } else if (argc == 0) { - /* No arguments -- use default remote */ - remote = remote_get(NULL); - result = fetch_one(remote, argc, argv); + if (fetch_all_config && all != 0) { + (void) for_each_remote(get_one_remote_for_fetch, &list); + result = fetch_multiple(&list); + } else { + /* No arguments and no --all -- use default remote */ + remote = remote_get(NULL); + result = fetch_one(remote, argc, argv); + } } else if (multiple) { /* All arguments are assumed to be remotes or groups */ for (i = 0; i < argc; i++) diff --git a/t/t5514-fetch-multiple.sh b/t/t5514-fetch-multiple
[PATCH] fetch: add configuration for making --all default
Fetching from all remotes by default is useful if you're working on a repo with few and/or fast remotes. It also lets you fetch from origin even if the current branch's upstream is elsewhere without specifying it explicitly. Signed-off-by: Øystein Walle --- This is scratching a itch I have. Most of the time I just want to fetch everything, wherever it may be, and fetch's behavour of using the current upstream's remote sometimes doesn't read my mind as well as I'd like it to. It's not particularly useful. But more "destructive" behaviours (--prune) can be made default, so think this could be as well. Documentation/config.txt| 5 + Documentation/fetch-options.txt | 4 +++- Documentation/git-fetch.txt | 3 ++- builtin/fetch.c | 21 - t/t5514-fetch-multiple.sh | 23 +++ 5 files changed, 49 insertions(+), 7 deletions(-) diff --git a/Documentation/config.txt b/Documentation/config.txt index 3e37b93..c40654f 100644 --- a/Documentation/config.txt +++ b/Documentation/config.txt @@ -1170,6 +1170,11 @@ fetch.prune:: If true, fetch will automatically behave as if the `--prune` option was given on the command line. See also `remote..prune`. +fetch.all:: + If true, fetch will automatically behave as if the `--all` + option was given on the command line uness a remote was given. The + default is false. + format.attach:: Enable multipart/mixed attachments as the default for 'format-patch'. The value can also be a double quoted string diff --git a/Documentation/fetch-options.txt b/Documentation/fetch-options.txt index 45583d8..aa95a30 100644 --- a/Documentation/fetch-options.txt +++ b/Documentation/fetch-options.txt @@ -1,5 +1,7 @@ --all:: - Fetch all remotes. + Fetch all remotes. This can be configured to be the default behaviour + when no remotes are given explicitly. See the `fetch.all` configuration + variable in linkgit:git-config[1]. -a:: --append:: diff --git a/Documentation/git-fetch.txt b/Documentation/git-fetch.txt index e62d9a0..584f3fb 100644 --- a/Documentation/git-fetch.txt +++ b/Documentation/git-fetch.txt @@ -36,7 +36,8 @@ there is a remotes. entry in the configuration file. (See linkgit:git-config[1]). When no remote is specified, by default the `origin` remote will be used, -unless there's an upstream branch configured for the current branch. +unless there's an upstream branch configured for the current branch, or the +`fetch.all` configuration variable is set to true. The names of refs that are fetched, together with the object names they point at, are written to `.git/FETCH_HEAD`. This information diff --git a/builtin/fetch.c b/builtin/fetch.c index 8d5b2db..715ea82 100644 --- a/builtin/fetch.c +++ b/builtin/fetch.c @@ -30,10 +30,12 @@ enum { }; static int fetch_prune_config = -1; /* unspecified */ +static int fetch_all_config = -1; /* unspecified */ static int prune = -1; /* unspecified */ +static int all = -1; /* unspecified */ #define PRUNE_BY_DEFAULT 0 /* do we prune by default? */ -static int all, append, dry_run, force, keep, multiple, update_head_ok, verbosity; +static int append, dry_run, force, keep, multiple, update_head_ok, verbosity; static int progress = -1, recurse_submodules = RECURSE_SUBMODULES_DEFAULT; static int tags = TAGS_DEFAULT, unshallow, update_shallow; static const char *depth; @@ -67,6 +69,10 @@ static int git_fetch_config(const char *k, const char *v, void *cb) fetch_prune_config = git_config_bool(k, v); return 0; } + if (!strcmp(k, "fetch.all")) { + fetch_all_config = git_config_bool(k, v); + return 0; + } return git_default_config(k, v, cb); } @@ -1168,7 +1174,7 @@ int cmd_fetch(int argc, const char **argv, const char *prefix) git_config(submodule_config, NULL); } - if (all) { + if (all == 1) { if (argc == 1) die(_("fetch --all does not take a repository argument")); else if (argc > 1) @@ -1176,9 +1182,14 @@ int cmd_fetch(int argc, const char **argv, const char *prefix) (void) for_each_remote(get_one_remote_for_fetch, &list); result = fetch_multiple(&list); } else if (argc == 0) { - /* No arguments -- use default remote */ - remote = remote_get(NULL); - result = fetch_one(remote, argc, argv); + if (fetch_all_config && all != 0) { + (void) for_each_remote(get_one_remote_for_fetch, &list); + result = fetch_multiple(&list); + } else { + /* No arguments and no --all -- use default remote */
Re: Question on for-each-ref and --contains
St. Blind gmail.com> writes: > > The > git-branch --contains and --merged are not very handy too, > because the> output is not really flexible, and the --merged works > on HEAD only. > `git branch --merged foo` will list branches that are merged in the history of 'foo'. And the equivalent is true for `--contains`. Not sure if that will solve everything, though. Øsse -- 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
[BUG] git rebase -X fails with merge-recursive error
Hi, I discovered this while rebasing a branch after having converted files to use LF line endings. I got around the problem by using --ignore-whitespace but the error still seems strange to me so I'm reporting it. The following script is equivalent: it creates a repo with a CRLF file, creates a "feature" branch, converts the file and then tries to rebase the feature branch with git rebase -X ignore-whitespace-at-eol: git init echo "That's some catch, that Catch-1984" >file.txt unix2dos file.txt git add file.txt git commit -m 'Initial commit' git checkout -b feature ex -sc 's/1984/22/|x' file.txt git commit -m "Fix literary confusion" file.txt git checkout master echo '* text=auto' > .gitattributes dos2unix file.txt git add . git commit -m 'CRLF to LF' git checkout feature gti config merge.renormalize true git rebase -X ignore-space-at-eol master While rebasing the following error appears: error: addinfo_cache failed for path 'file.txt' It comes from the git-merge-recursive invocation git-rebase performs[1] and is printed because make_cache_entry() fails[2]. I also get this error when using the other 'ignore-*' strategy options, as well as 'theirs'. At this point file.txt still has its CRLF terminator, but simply: git add file.txt git rebase --continue has the desired effect (as it did in my real life situation). I've tested this on Git 2.2.0, 2.1.3 and 1.9.0. I don't know whether this is actually related to git-rebase. It's a way to reproduce it if nothing else. I haven't tried any experiments with git-merge-recursive directly, I get the impression I'm not supposed to since it doesn't have a manpage ;) Interestingly, removing the creation of .gitattributes makes the problem go away. Additionally, git-merge-recursive exits with status 0. This confuses git-rebase which will continue and then complain about the state of the index. (Interestingly, at this point my prompt thingy complains that .git/rebase-merge/done isn't there). Regards, Øsse [1]: https://github.com/git/git/blob/master/git-rebase--merge.sh#L70 [2]: https://github.com/git/git/blob/master/merge-recursive.c#L209 -- 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/2] commit: inform pre-commit that --amend was used
When a commit is amended a pre-commit hook that verifies the commit's contents might not find what it's looking for if it looks at the differences against HEAD when HEAD~1 might be more appropriate. Inform the commit hook that --amend is being used so that hook authors can do e.g. if test "$1" = amend; then ... else ... fi to handle these situations. Signed-off-by: Øystein Walle --- Documentation/githooks.txt | 3 ++- builtin/commit.c | 3 ++- t/t7503-pre-commit-hook.sh | 11 +++ 3 files changed, 15 insertions(+), 2 deletions(-) diff --git a/Documentation/githooks.txt b/Documentation/githooks.txt index 9ef2469..fb3e71e 100644 --- a/Documentation/githooks.txt +++ b/Documentation/githooks.txt @@ -73,7 +73,8 @@ pre-commit ~~ This hook is invoked by 'git commit', and can be bypassed -with `--no-verify` option. It takes no parameter, and is +with `--no-verify` option. It takes one parameter which is "amend" if +`--amend` was used when committing and "noamend" if not. It is invoked before obtaining the proposed commit log message and making a commit. Exiting with non-zero status from this script causes the 'git commit' to abort. diff --git a/builtin/commit.c b/builtin/commit.c index e108c53..f9e5d27 100644 --- a/builtin/commit.c +++ b/builtin/commit.c @@ -694,7 +694,8 @@ static int prepare_to_commit(const char *index_file, const char *prefix, /* This checks and barfs if author is badly specified */ determine_author_info(author_ident); - if (!no_verify && run_commit_hook(use_editor, index_file, "pre-commit", NULL)) + if (!no_verify && run_commit_hook(use_editor, index_file, "pre-commit", + amend ? "amend" : "noamend", NULL)) return 0; if (squash_message) { diff --git a/t/t7503-pre-commit-hook.sh b/t/t7503-pre-commit-hook.sh index 99ed967..b400afe 100755 --- a/t/t7503-pre-commit-hook.sh +++ b/t/t7503-pre-commit-hook.sh @@ -133,4 +133,15 @@ test_expect_success 'check the author in hook' ' git show -s ' +# a hook that checks if "amend" is passed as an argument +write_script "$HOOK" <http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] t7503: use write_script to generate hook scripts
Signed-off-by: Øystein Walle --- t/t7503-pre-commit-hook.sh | 9 +++-- 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/t/t7503-pre-commit-hook.sh b/t/t7503-pre-commit-hook.sh index 984889b..99ed967 100755 --- a/t/t7503-pre-commit-hook.sh +++ b/t/t7503-pre-commit-hook.sh @@ -24,8 +24,7 @@ test_expect_success '--no-verify with no hook' ' HOOKDIR="$(git rev-parse --git-dir)/hooks" HOOK="$HOOKDIR/pre-commit" mkdir -p "$HOOKDIR" -cat > "$HOOK" < "$HOOK" < "$HOOK" <http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] pre-commit hook updates
The first patch changes t/t7503-pre-commit-hook.sh to use write_script everywhere, as was suggested by Jeff King in the discussion of the previous patch. The second patch is v2 of the patch I sent earlier. I've incorporated Eric Sunshine's suggestions. I didn't do enough digging; I found test_expect_failure and assumed this was test_expect_success's twin brother, but it marked stuff as known breakages so I went with the '!'. I also found it a bit strange that test_must_fail has a different signature (to the extent a shell function has one at all). Is my use of test_must_fail correct? I agree with Junio Hamano that it's better to provide no argument at all rather than an empty one. I also agree with Jeff King that "noamend" is better than an empty argument. I went with the second one since Jeff seemed to get the last word :) I'm not sure I like the ternary inside the function call like that, but I went with it because it gave the smallest footprint (which is probably not a good argument). I suppose I could have done: if (amend) hook_arg1 = "amend" else hook_arg1 = "noamend" ... ... run_commit_hook(use_editor, index_file, "pre-commit", hook_arg1, NULL); or create a hook_amend variable. I'm happy to send a v3. Øystein Walle (2): t7503: use write_script to generate hook scripts commit: inform pre-commit that --amend was used Documentation/githooks.txt | 3 ++- builtin/commit.c | 3 ++- t/t7503-pre-commit-hook.sh | 20 ++-- 3 files changed, 18 insertions(+), 8 deletions(-) -- 2.2.0.rc2.23.gca0107e -- 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] commit: inform pre-commit if --amend is used
When a commit is amended a pre-commit hook that verifies the commit's contents might not find what it's looking for if for example it looks at the differences against HEAD when HEAD~1 might be more appropriate. Inform the commit hook that --amend is being used so that hook authors can do e.g. if test "$1" = amend then ... else ... fi to handle these situations. Signed-off-by: Øystein Walle --- Documentation/githooks.txt | 3 ++- builtin/commit.c | 3 ++- t/t7503-pre-commit-hook.sh | 14 ++ 3 files changed, 18 insertions(+), 2 deletions(-) diff --git a/Documentation/githooks.txt b/Documentation/githooks.txt index 9ef2469..e113027 100644 --- a/Documentation/githooks.txt +++ b/Documentation/githooks.txt @@ -73,7 +73,8 @@ pre-commit ~~ This hook is invoked by 'git commit', and can be bypassed -with `--no-verify` option. It takes no parameter, and is +with `--no-verify` option. It takes one parameter which is "amend" if +`--amend` was used when committing and empty otherwise. It is invoked before obtaining the proposed commit log message and making a commit. Exiting with non-zero status from this script causes the 'git commit' to abort. diff --git a/builtin/commit.c b/builtin/commit.c index e108c53..e38dd4a 100644 --- a/builtin/commit.c +++ b/builtin/commit.c @@ -694,7 +694,8 @@ static int prepare_to_commit(const char *index_file, const char *prefix, /* This checks and barfs if author is badly specified */ determine_author_info(author_ident); - if (!no_verify && run_commit_hook(use_editor, index_file, "pre-commit", NULL)) + if (!no_verify && run_commit_hook(use_editor, index_file, + "pre-commit", amend ? "amend" : "", NULL)) return 0; if (squash_message) { diff --git a/t/t7503-pre-commit-hook.sh b/t/t7503-pre-commit-hook.sh index 984889b..be97676 100755 --- a/t/t7503-pre-commit-hook.sh +++ b/t/t7503-pre-commit-hook.sh @@ -136,4 +136,18 @@ test_expect_success 'check the author in hook' ' git show -s ' +# a hook that checks if "amend" is passed as an argument +cat > "$HOOK" <http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4] completion: ignore chpwd_functions when cding on zsh
Brandon Turner brandonturner.net> writes: > > On Thu, Oct 9, 2014 at 5:11 PM, Junio C Hamano pobox.com> wrote: > > Actually the patch was slightly wrong. It did not quite matter as > > "cd ''" is a no-op, but "git -C '' cmd" is not that lenient (which > > may be something we may want to fix) and breaks t9902 by exposing > > an existing breakage in the callchain. > > > > Here is a replacement. > > I did some more testing on this iteration as well - looks good. > Sorry, for the late reply, guys... I've tested it too and it seems to work just fine. As for my comments about using $=2 instead of $2: When zsh runs through this code it does so while emulating ksh. Thus the reliance on splitting unquoted expansions is not a problem. I was unaware of this until ten minutes ago. Øsse -- 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 v4] completion: ignore chpwd_functions when cding on zsh
Brandon Turner brandonturner.net> writes: > +__git_ls_files_helper () > +{ > + ( > + test -n "${CDPATH+set}" && unset CDPATH > + cd -q "$1" > + if [ "$2" == "--committable" ]; then > + git diff-index --name-only --relative HEAD > + else > + # NOTE: $2 is not quoted in order to support multiple > options > + git ls-files --exclude-standard $2 > + fi > + ) 2>/dev/null > +} > + (Sorry about this; I should've caught it the first time around). Zsh does not split string expansions into several words by default. For example: $ str1='hello world' $ str2='goodbye moon' $ printf '%s\n' $str1 $str2 hello world goodbye moon This can be enabled on a "per-expansion basis" by using = while expanding: $ str1='hello world' $ str2='goodbye moon' $ printf '%s\n' $=str1 $str2 hello world goodbye moon So the $2 in your patch should be $=2. BUT: Over a year ago Git learned the -C argument. Couldn't we use that here? That way we would not have to unset CDPATH and can get rid of the subshell and cd -q. If we allow the other functions to use several arguments to pass options with we can get rid of the whole seperation between bash and zsh altogether. Øsse -- 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] completion: ignore chpwd_functions when cding on zsh
Junio C Hamano pobox.com> writes: > > Øystein Walle gmail.com> writes: > > > Brandon Turner brandonturner.net> writes: > > > >> > >> Software, such as RVM (ruby version manager), may set chpwd functions > >> that result in an endless loop when cding. chpwd functions should be > >> ignored. > > > > Now that it has moved to the zsh-specific script you can achieve this more > > simply by using cd -q. > > > > Is the way we defeat CDPATH for POSIX shells sufficient, or does it > also need to be customized for zsh? > That is fine (to the best of my knowledge). If the current directory is not part of CDPATH at all then Zsh will try the current directory first, so if anything Zsh should fail more seldom here than others (but not *never*, so the hack is still needed). Øsse -- 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] completion: ignore chpwd_functions when cding on zsh
Brandon Turner brandonturner.net> writes: > > Software, such as RVM (ruby version manager), may set chpwd functions > that result in an endless loop when cding. chpwd functions should be > ignored. Now that it has moved to the zsh-specific script you can achieve this more simply by using cd -q. Øsse -- 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: [BUG (maybe)] git rev-parse --verify --quiet isn't quiet
Junio C Hamano pobox.com> writes: > > Junio C Hamano pobox.com> writes: > > > I would suspect that this may be fine. > > > > "rev-parse --verify" makes sure the named object exists, but in this > > case {u} does not even name any object, does it? > > Hmph, but "rev-parse --verify no-such-branch" does *not* name any > object, we would want to see it barf, and we probably would want to > be able to squelch the message. So it is unclear if {u} barfing is > a good idea. > That was my counter-argument :) The "vibe" I get from rev-parse --verify --quiet is that it should handle anything. > > What is the reason why it is inpractical to pass 'quiet' down the > callchain? > Maybe I'm missing something obvious, but wouldn't that mean changing the signature of 9 different functions, and consequently all of their calls throughout Git? That's perhaps not a good argument. Who cares whether a diff is small or large if it fixes a bug properly? But most (or all) of those functions do not concern themselves with printing stuff so maybe an additional "quiet?" argument would look foreign in most places and make the code harder to read. Øsse -- 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
[BUG (maybe)] git rev-parse --verify --quiet isn't quiet
Hi, I noticed this while writing a small script for myself: $ git rev-parse --verify --quiet '@{u}' fatal: No upstream configured for branch 'local' The functions that get run when rev-parse does its thing all return a pointer to a strbuf, return the length of the modified buf or something to that effect. However get_upstream_branch() calls die() which writes to stderr unconditionally. Call hierarchy in the above case: die() get_upstream_branch() interpret_upstream_mark() interpret_branch_name() substitute_branch_name() dwim_ref() get_sha1_basic() get_sha1_1() get_sha1_with_context_1() get_sha1_with_context() get_sha1() cmd_rev_parse() Passing quiet = 1 all the way down I assume isn't feasible. Changing get_upstream_branch() to not die but rather signify an error could work. But interpret_branch_name() has four different callers belonging to different parts of Git. I marked this as "maybe" because I guess it's fair to say that rev-parse '@{u}' is not the correct way to check whether a branch as a configured upstream. Furthermore even if it writes to stderr the exit status is still non-zero so the only way to get bitten by this is if you doing something like: foo=$(git rev-parse --verify --quiet $bar 2>&1) # pointless redirection *and* you check whether the exit code is equal to 1, not unequal to zero. On the other hand, it does break the expectations that the documentation and the other uses of git rev-parse one encounters give. At least for me. It should be able to verify that $foo is valid, and it should do so quietly. On a related note: $ git branch origin/master $ git rev-parse --verify --quiet origin/master warning: refname 'origin/master' is ambiguous. 7c07808349fd0fc2c61a169833eeb55163cf3df4 Best regards, Øsse -- 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: stash-p broken?
brian m. carlson crustytoothpaste.net> writes: > > On Mon, Jul 28, 2014 at 05:56:28PM -0700, Michael Migdol wrote: > > Sorry for error -- I meant: git stash list -p, not git stash -p. > > > > On Mon, Jul 28, 2014 at 5:38 PM, Michael Migdol migdol.net> wrote: > > > I recently upgraded from Ubuntu 13.10 to Ubuntu 14.04. After doing so, > > > "git stash -p" stopped working. (It apparently is ignoring the -p > > > parameter). I'm not sure what version I was using previously, but after > > > some experimentation, I see that: > > > > > > version 1.7.12.2 : stash -p DOES work > > > version 1.9.3 : doesn't work > > > version 2.0.3 : doesn't work > > Under the hood, we do: > > git log --format="%gd: %gs" -g "$ " refs/stash -- > > But it looks like git log ignores -p if -g is provided. > Unfortunately I don't have much to add... I have a weird issue where `git stash list -p` does not show a diff, but `~/usr/bin/git stash list -p` does, for the exact same version of Git. However, the underlying command does not show a diff in either case, even though I can tell that is the one being executed (with set -x inserted into .../libexec/git-stash). This is so weird that I think it's my system's fault. I have to do some more digging. Øsse -- 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: Git autocorrect bug
David Turner twopensource.com> writes: > > (I am extremely unlikely to fix this bug myself, since it only arises in > very rare circumstances). > I see now that `git init foo` and `git git foo` (with git corrected to init) behave differently. Is this the bug you're referring to? -- 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: Git autocorrect bug
David Turner twopensource.com> writes: > > $ cd [some existing git repo] > $ git git foo > WARNING: You called a Git command named 'git', which does not exist. > Continuing under the assumption that you meant 'init' > in 0.1 seconds automatically... > fatal: internal error: work tree has already been set > Current worktree: /home/dturner/git > New worktree: /home/dturner/git/foo > > (I am extremely unlikely to fix this bug myself, since it only arises in > very rare circumstances). > > You have help.autocorrect enabled. Then this is expected behaviour (it doesn't seem out of place to me at least) Running `git config --unset help.autocorrect` should disable it. It may be that you enabled it for only one repo by accident. Øsse -- 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] config: respect '~' and '~user' in mailmap.file
Jeff King peff.net> writes: > > Makes sense. Curious if there was a reason we did not use it in the > first place, I looked at the history. The reason is that mailmap.file > was added in d551a48 (2009-02-08) and git_config_pathname came months > later in 395de25 (2009-11-17). Retro-fitting it now should not cause a > problem for any sane paths. So: > > Reviewed-by: Jeff King peff.net> > > -Peff > Thanks for the review. I saw it was added back in 2009 but didn't give it much thought other than "Oh, that bug has been there for a long time!" :) (Not that this is a serious bug as such, more than a slight inconsistency in how the path is handled compared to other config values expected to be paths) Øsse -- 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] config: respect '~' and '~user' in mailmap.file
git_config_string() does not handle '~' and '~user' as part of the value. Using git_config_pathname() fixes this. Signed-off-by: Øystein Walle --- config.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/config.c b/config.c index 314d8ee..ec7af5f 100644 --- a/config.c +++ b/config.c @@ -963,7 +963,7 @@ static int git_default_push_config(const char *var, const char *value) static int git_default_mailmap_config(const char *var, const char *value) { if (!strcmp(var, "mailmap.file")) - return git_config_string(&git_mailmap_file, var, value); + return git_config_pathname(&git_mailmap_file, var, value); if (!strcmp(var, "mailmap.blob")) return git_config_string(&git_mailmap_blob, var, value); -- 2.0.0.rc4 -- 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 v7 00/11] Add interpret-trailers builtin
Junio C Hamano pobox.com> writes: > > ... > > is easier to read and maintain if written like so (with using HT > properly---our MUAs may damage it and turn the indentation into > spaces): > > ... && > sed -e "s/ Z$/ /" >>expect <<-\EOF && > Fixes: Z > Acked-by= Z > Reviewed-by: Z > Signed-off-by: Z > EOF > ... > How about: printf '%s: \n' Fixes Acked-by Reviewed-by Signed-off-by >> expect This solution scores high marks in both readability and maintainability in my mind. -- 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] for-each-ref: add option to omit newlines
Junio C Hamano pobox.com> writes: > > I very well understand that. All other commands that support "-z" > to give you NUL terminated output do not consider that a downside. > Why should for-each-ref be special? > After I discovered log also has this there is nothing special about for-each-ref any longer, so my patch as-is would only make things less consistent. What is "special" is that they give you the option of supplying a format string. ls-files, diff and others print a specific list of items (paths, shas, ...) and there's no question about how they are presented other than the delimiter between each item, to which a selection of either a newline or a null byte is plenty. With log, for-each-ref and rev-list (any others?) that sort of breaks down. With the format string you're given the power to make the command print basically anything you like, however you like; no longer only a question of mere delimiters. It only makes sense then (to me, at least) that the command does not meddle with the format the user has chosen. Maybe it's all subjective... I'm okay with just leaving things as they are. There are ways around it. -- 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] for-each-ref: add option to omit newlines
Junio C Hamano pobox.com> writes: > > I would rather see us go in the direction to add "-z" output option, > which is what everybody else that produces NUL terminated entries in > our suite of subcommands does. > I agree that -z would help in this case and I very much appreciate that option when using diff --name-only, ls-files, etc. However, when specifying a format string it's just a matter of ending the format string in '%00' and you're good to go. But then you get the null byte *and* a newline. And with your proposal there would be no way of saying you want neither. I expected the output to be formatted according to a (repetition of) the format string, not some variation of it that I couldn't opt out of. But I see that git-log also shows this behavior and already has a -z option, so I guess that's fairly ingrained. Maybe it's just me? In that case I've no problem with throwing in the towel. Øsse -- 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] for-each-ref: add option to omit newlines
Øystein Walle gmail.com> writes: > > splitting the output on newlines, for example. > Ugh, I mean on null bytes, naturally. Øsse. -- 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] for-each-ref: add option to omit newlines
Even when having specified a format string for-each-ref still prints a newline after printing each ref according to the format. This breaks splitting the output on newlines, for example. Signed-off-by: Øystein Walle --- I was somewhat surprised by this behaviour; I expected to be in full control of the output but I could not get rid of the newlines. As far as I'm *personally* concerned the line "putchar('\n');" could just as well be removed completely and an '\n' appended to the default format string. But since this command (and this behaviour) as been around since 2006 I assume that it's in Git's best interest to not change the default behaviour. Hence the introduction of this option. Although I was taken aback by this behaviour, is it patch-worthy? The fix isn't very pretty. On to the patch itself: I contemplated putting '\n' in the default format and removing it if -n was given, which would get rid of the need to pass an exta argument to show_ref(). But that means we would need to *insert it* when a format is given and -n is not... I've changed how the default format is assigned so that we can check if it's NULL after option parsing to spit out an error. Alternatively we could just allow it. Documentation/git-for-each-ref.txt | 3 +++ builtin/for-each-ref.c | 20 +++- 2 files changed, 18 insertions(+), 5 deletions(-) diff --git a/Documentation/git-for-each-ref.txt b/Documentation/git-for-each-ref.txt index 4240875..805914a 100644 --- a/Documentation/git-for-each-ref.txt +++ b/Documentation/git-for-each-ref.txt @@ -62,6 +62,9 @@ OPTIONS the specified host language. This is meant to produce a scriptlet that can directly be `eval`ed. +-n:: +--no-newlines:: + Do not print a newline after printing each formatted ref. FIELD NAMES --- diff --git a/builtin/for-each-ref.c b/builtin/for-each-ref.c index 51798b4..32d6b12 100644 --- a/builtin/for-each-ref.c +++ b/builtin/for-each-ref.c @@ -998,7 +998,8 @@ static void emit(const char *cp, const char *ep) } } -static void show_ref(struct refinfo *info, const char *format, int quote_style) +static void show_ref(struct refinfo *info, const char *format, int quote_style, +int no_newlines) { const char *cp, *sp, *ep; @@ -1023,7 +1024,8 @@ static void show_ref(struct refinfo *info, const char *format, int quote_style) resetv.s = color; print_value(&resetv, quote_style); } - putchar('\n'); + if (!no_newlines) + putchar('\n'); } static struct ref_sort *default_sort(void) @@ -1067,9 +1069,9 @@ static char const * const for_each_ref_usage[] = { int cmd_for_each_ref(int argc, const char **argv, const char *prefix) { int i, num_refs; - const char *format = "%(objectname) %(objecttype)\t%(refname)"; + const char *format = NULL; struct ref_sort *sort = NULL, **sort_tail = &sort; - int maxcount = 0, quote_style = 0; + int maxcount = 0, quote_style = 0, no_newlines = 0; struct refinfo **refs; struct grab_ref_cbdata cbdata; @@ -1082,6 +1084,8 @@ int cmd_for_each_ref(int argc, const char **argv, const char *prefix) N_("quote placeholders suitably for python"), QUOTE_PYTHON), OPT_BIT(0 , "tcl", "e_style, N_("quote placeholders suitably for tcl"), QUOTE_TCL), + OPT_BOOL('n' , "no-newlines", &no_newlines, + N_("do not output a newline after each ref")), OPT_GROUP(""), OPT_INTEGER( 0 , "count", &maxcount, N_("show only matched refs")), @@ -1100,6 +1104,12 @@ int cmd_for_each_ref(int argc, const char **argv, const char *prefix) error("more than one quoting style?"); usage_with_options(for_each_ref_usage, opts); } + if (no_newlines && !format) { + error("--no-newlines without --format does not make sense"); + usage_with_options(for_each_ref_usage, opts); + } + if (!format) + format = "%(objectname) %(objecttype)\t%(refname)"; if (verify_format(format)) usage_with_options(for_each_ref_usage, opts); @@ -1120,6 +1130,6 @@ int cmd_for_each_ref(int argc, const char **argv, const char *prefix) if (!maxcount || num_refs < maxcount) maxcount = num_refs; for (i = 0; i < maxcount; i++) - show_ref(refs[i], format, quote_style); + show_ref(refs[i], format, quote_style, no_newlines); return 0; } -- 1.8.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
Re: git best strategy for two version development
Carlos Pereira ist.utl.pt> writes: > > Hello, > > I am a git and CVS newbie, I bought and red most of the excellent Pro > Git book by Scott Chacon, but I still have a doubt. I have a package > that I distribute in two versions differing only in one library: > version_A uses this library, version_B uses my own code to replace it. > For strategic reasons I want to keep it this way for the time being. > Both versions have the same documentation, the same data files, and 99% > of the source code is the same (a few makefile changes, two additional > files in version_B and some minor changes: a diff -r has only 170 > lines). The question is what is the best strategy to manage a situation > like this with git? > > Shall I maintain two different repositories? I don't think so... > If the changes are as small as you say, is it an option to use just one branch but have two possible build configurations? That seems like the easiest way to do it, in my opinion. E.g.: $ make LIB=versionA $ make LIB=versionB Consider the above as pseudo-code, though. I don't know what build system you use or even if your package is even something that is "built". But you get the idea. Øsse -- 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] Documentation: fix typos in man pages
Signed-off-by: Øystein Walle --- In July I sent in some typo fixes but it halted in a discussion on UK vs. US English and so forth ($gmane/231331). There were some actual typo fixes in there though (in addition to the "opinionated typo fixes"). Powering up my old laptop for the first time in months I noticed that I had them idling in a branch, and that incidentally none of them has been fixed. Hopefully I've managed to seperate the genuine typo fixes from the rest. Documentation/git-clone.txt | 2 +- Documentation/git-diff.txt| 2 +- Documentation/gitcli.txt | 2 +- Documentation/githooks.txt| 2 +- Documentation/gitweb.conf.txt | 4 ++-- Documentation/user-manual.txt | 2 +- 6 files changed, 7 insertions(+), 7 deletions(-) diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt index 4987857..bf3dac0 100644 --- a/Documentation/git-clone.txt +++ b/Documentation/git-clone.txt @@ -208,7 +208,7 @@ objects from the source repository into a pack in the cloned repository. --separate-git-dir=:: Instead of placing the cloned repository where it is supposed to be, place the cloned repository at the specified directory, - then make a filesytem-agnostic Git symbolic link to there. + then make a filesystem-agnostic Git symbolic link to there. The result is Git repository can be separated from working tree. diff --git a/Documentation/git-diff.txt b/Documentation/git-diff.txt index 33fbd8c..56fb7e5 100644 --- a/Documentation/git-diff.txt +++ b/Documentation/git-diff.txt @@ -44,7 +44,7 @@ two blob objects, or changes between two files on disk. commit relative to the named . Typically you would want comparison with the latest commit, so if you do not give , it defaults to HEAD. - If HEAD does not exist (e.g. unborned branches) and + If HEAD does not exist (e.g. unborn branches) and is not given, it shows all staged changes. --staged is a synonym of --cached. diff --git a/Documentation/gitcli.txt b/Documentation/gitcli.txt index 3f33ca5..1c3e109 100644 --- a/Documentation/gitcli.txt +++ b/Documentation/gitcli.txt @@ -28,7 +28,7 @@ arguments. Here are the rules: they can be disambiguated by placing `--` between them. E.g. `git diff -- HEAD` is, "I have a file called HEAD in my work tree. Please show changes between the version I staged in the index - and what I have in the work tree for that file". not "show difference + and what I have in the work tree for that file", not "show difference between the HEAD commit and the work tree as a whole". You can say `git diff HEAD --` to ask for the latter. diff --git a/Documentation/githooks.txt b/Documentation/githooks.txt index d48bf4d..d954bf6 100644 --- a/Documentation/githooks.txt +++ b/Documentation/githooks.txt @@ -251,7 +251,7 @@ three parameters: - the name of the ref being updated, - the old object name stored in the ref, - - and the new objectname to be stored in the ref. + - and the new object name to be stored in the ref. A zero exit from the update hook allows the ref to be updated. Exiting with a non-zero status prevents 'git-receive-pack' diff --git a/Documentation/gitweb.conf.txt b/Documentation/gitweb.conf.txt index db4154f..952f503 100644 --- a/Documentation/gitweb.conf.txt +++ b/Documentation/gitweb.conf.txt @@ -630,13 +630,13 @@ need to set this element to empty list i.e. `[]`. override:: If this field has a true value then the given feature is - overriddable, which means that it can be configured + overridable, which means that it can be configured (or enabled/disabled) on a per-repository basis. + Usually given "" is configurable via the `gitweb.` config variable in the per-repository Git configuration file. + -*Note* that no feature is overriddable by default. +*Note* that no feature is overridable by default. sub:: Internal detail of implementation. What is important is that diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt index 248dcab..d4f9804 100644 --- a/Documentation/user-manual.txt +++ b/Documentation/user-manual.txt @@ -3795,7 +3795,7 @@ like so: $ git update-index filename - -but to avoid common mistakes with filename globbing etc, the command +but to avoid common mistakes with filename globbing etc., the command will not normally add totally new entries or remove old entries, i.e. it will normally just update existing cache entries. -- 1.8.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
Re: [PATCH v3] stash: handle specifying stashes with spaces
Junio C Hamano pobox.com> writes: > > Thomas Rast thomasrast.ch> writes: > > > Junio C Hamano pobox.com> writes: > > > >> > >> This is brittle. If new tests are added before this, the test_tick > >> will give you different timestamp and this test will start failing. > >> > >> Perhaps grab the timestamp out of the stash that was created [...] > > > > Hmm, now that I stare at this, why not simply use something like > > > > git stash apply "stash { 0 }" > > > > It seems to refer to the same as stash {0} as one would expect, while > > still triggering the bug with unpatched git-stash. > > Yeah, that is fine as well. For the record, here is what I > tentatively queued. > I completely agree that it's brittle. I mentioned it when I submitted v1 but at the time it didn't occur to me that new tests might be added before it. And of course I agree with your proposed changes to the test. I must say I like Thomas' solution because of its simplicity and the whole test could be made much shorter: just create stash and try to pop it. But it's seems the spaces trigger some other way of interpreting the selector. In my git.git, git rev-parse HEAD{0} gives me the same result as HEAD@{ 0 } but HEAD@{1} and HEAD@{ 1 } are different. Is this intentional? If not, can this impact the reliability of the test if we use HEAD@{ 0 } ? Thanks for queuing! Regards, Øsse -- 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 v3] stash: handle specifying stashes with spaces
When trying to pop/apply a stash specified with an argument containing spaces git-stash will throw an error: $ git stash pop 'stash@{two hours ago}' Too many revisions specified: stash@{two hours ago} This happens because word splitting is used to count non-option arguments. Make use of rev-parse's --sq option to quote the arguments for us to ensure a correct count. Add quotes where necessary. Also add a test that verifies correct behaviour. Helped-by: Thomas Rast Signed-off-by: Øystein Walle --- v3 uses the same eval/--sq technique as v2, suggested by Thomas Rast. This is basically a resend except that I added a missing '&&' in the test that Eric Sunshine noticed when reading v1. git-stash.sh | 14 +++--- t/t3903-stash.sh | 11 +++ 2 files changed, 18 insertions(+), 7 deletions(-) diff --git a/git-stash.sh b/git-stash.sh index 1e541a2..f0a94ab 100755 --- a/git-stash.sh +++ b/git-stash.sh @@ -358,7 +358,7 @@ parse_flags_and_rev() i_tree= u_tree= - REV=$(git rev-parse --no-flags --symbolic "$@") || exit 1 + REV=$(git rev-parse --no-flags --symbolic --sq "$@") || exit 1 FLAGS= for opt @@ -376,7 +376,7 @@ parse_flags_and_rev() esac done - set -- $REV + eval set -- $REV case $# in 0) @@ -391,13 +391,13 @@ parse_flags_and_rev() ;; esac - REV=$(git rev-parse --quiet --symbolic --verify $1 2>/dev/null) || { + REV=$(git rev-parse --quiet --symbolic --verify "$1" 2>/dev/null) || { reference="$1" die "$(eval_gettext "\$reference is not valid reference")" } - i_commit=$(git rev-parse --quiet --verify $REV^2 2>/dev/null) && - set -- $(git rev-parse $REV $REV^1 $REV: $REV^1: $REV^2: 2>/dev/null) && + i_commit=$(git rev-parse --quiet --verify "$REV^2" 2>/dev/null) && + set -- $(git rev-parse "$REV" "$REV^1" "$REV:" "$REV^1:" "$REV^2:" 2>/dev/null) && s=$1 && w_commit=$1 && b_commit=$2 && @@ -408,8 +408,8 @@ parse_flags_and_rev() test "$ref_stash" = "$(git rev-parse --symbolic-full-name "${REV%@*}")" && IS_STASH_REF=t - u_commit=$(git rev-parse --quiet --verify $REV^3 2>/dev/null) && - u_tree=$(git rev-parse $REV^3: 2>/dev/null) + u_commit=$(git rev-parse --quiet --verify "$REV^3" 2>/dev/null) && + u_tree=$(git rev-parse "$REV^3:" 2>/dev/null) } is_stash_like() diff --git a/t/t3903-stash.sh b/t/t3903-stash.sh index debda7a..7eb011c 100755 --- a/t/t3903-stash.sh +++ b/t/t3903-stash.sh @@ -673,4 +673,15 @@ test_expect_success 'store updates stash ref and reflog' ' grep quux bazzy ' +test_expect_success 'handle stash specification with spaces' ' + git stash clear && + echo pig > file && + git stash && + test_tick && + echo cow > file && + git stash && + git stash apply "stash@{Thu Apr 7 15:17:13 2005 -0700}" && + grep pig file +' + test_done -- 1.8.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
Re: [PATCH] Improve user-manual html and pdf formatting
Andreas Schwab linux-m68k.org> writes: > > That's a Unicode Byte Order Mark. > > No, its an ampersand, a hash, a number and a semicolon. Definitely not > a BOM. > > Andreas. > You're right, of course :) I was a bit hasty. #65279; is a HTML entity (or at least something like looks like one) for the character U+FEFF, which also serves as the Byte Order Mark. I assume the entity was added to the file by mistake. Øsse -- 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] Improve user-manual html and pdf formatting
Jonathan Nieder gmail.com> writes: > > Hi, > > Thomas Ackermann wrote: > > > --- a/Documentation/user-manual.txt > > +++ b/Documentation/user-manual.txt > > -1,5 +1,5 > > -Git User Manual > > +Git User Manual > > Why? > > Puzzled, > Jonathan > That's a Unicode Byte Order Mark. In UTF-8 it serves no purpose except to indicate that a file is in fact UTF-8. A job which most editors don't need help with. See http://en.wikipedia.org/wiki/Byte_order_mark Øsse -- 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: git stash doesn't honor --work-tree or GIT_WORK_TREE
Duy Nguyen gmail.com> writes: > It should. At the beginning of cmd_rev_parse(), setup_git_directory() > is called, which will check and follow all GIT_* or their command line > equivalent. I'll look into this some time later. I think I was wrong and rev-parse --is-inside-work-tree *does* honor them. It prints 'false'. If it hadn't honored them it would have printed "fatal: Not a git repository (...)". Øsse -- 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: git stash doesn't honor --work-tree or GIT_WORK_TREE
Aaron Brooks brooks1.net> writes: > > Unlike other commands, git stash doesn't work outside of the worktree, > even when --work-tree is specified: > > (...) > > It looks like the "require_work_tree" function should check the > environment variables in addition to the status of the PWD (via > git-rev-parse). > > Having looked through several of the other git-*.sh scripts, I think > other shell based git commands will have similar problems. > > Thanks, > > Aaron > The environment variables are properly exported. I verified this by adding 'echo $GIT_WORK_TREE; echo $GIT_DIR' at the top of git-stash.sh. So these should propagate to "child gits" just fine, and so it shouldn't be necessary to test them explicitly. The problem seems to be that git rev-parse --is-inside-work-tree does not honor these. In fact it doesn't even honor --git-dir or --work-tree. Judging by the name this may be intentional. In the mean time, if you are able to use Git 1.8.5, `git -C test-repo stash` will work just fine. Øsse -- 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] stash: handle specifying stashes with spaces
Thomas Rast thomasrast.ch> writes: > I wonder what we would lose by dropping the --symbolic in the line I > quoted above (which is the second parsing pass), so that it resolves > to a SHA1. We would gain some robustness, as I'm not sure "$REV:" > works correctly in the face of weird revision expressions like > ":/foo". If I drop --symbolic then all hell breaks loose. Removing it very naively led to 29 failed tests. I managed to get that down quite a bit though. After the function ends $REV is supposed to expand to a symbolic reference, and the test for whether the given argument is a valid stash reference is to see if running `git rev-parse --symbolic-full-name "${REV%@*}"` expands to 'refs/stash' or not. So we have to do both with and without --symbolic and keep both around. For example `git stash drop` had problems because git-reflog doesn't let you remove entries in the log by SHA1: $ git reflog delete --updateref --rewrite $(git rev-parse stash@{0}) error: Not a reflog: 418af27beea220ad8a2fd3b8286959b1ec9c8852 I think a not entirely accurate but succinct way of putting it is that if foo is a valid ref or valid entry in the reflog then git rev-parse --symbolic $(git rev-parse foo) does *not* output 'foo' but the SHA1 of 'foo'. So we cannot simply convert everything to hashes and proceed from there. Øsse -- 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 v2] stash: handle specifying stashes with spaces
When trying to pop/apply a stash specified with an argument containing spaces git-stash will throw an error: $ git stash pop 'stash@{two hours ago}' Too many revisions specified: stash@{two hours ago} This happens because word splitting is used to count non-option arguments. Make use of rev-parse's --sq option to quote the arguments for us to ensure a correct count. Add quotes where necessary. Also add a test that verifies correct behaviour. Helped-by: Thomas Rast Signed-off-by: Øystein Walle --- Many thanks to Thomas Rast for helping me with this approach. git-stash.sh | 14 +++--- t/t3903-stash.sh | 11 +++ 2 files changed, 18 insertions(+), 7 deletions(-) diff --git a/git-stash.sh b/git-stash.sh index 1e541a2..f0a94ab 100755 --- a/git-stash.sh +++ b/git-stash.sh @@ -358,7 +358,7 @@ parse_flags_and_rev() i_tree= u_tree= - REV=$(git rev-parse --no-flags --symbolic "$@") || exit 1 + REV=$(git rev-parse --no-flags --symbolic --sq "$@") || exit 1 FLAGS= for opt @@ -376,7 +376,7 @@ parse_flags_and_rev() esac done - set -- $REV + eval set -- $REV case $# in 0) @@ -391,13 +391,13 @@ parse_flags_and_rev() ;; esac - REV=$(git rev-parse --quiet --symbolic --verify $1 2>/dev/null) || { + REV=$(git rev-parse --quiet --symbolic --verify "$1" 2>/dev/null) || { reference="$1" die "$(eval_gettext "\$reference is not valid reference")" } - i_commit=$(git rev-parse --quiet --verify $REV^2 2>/dev/null) && - set -- $(git rev-parse $REV $REV^1 $REV: $REV^1: $REV^2: 2>/dev/null) && + i_commit=$(git rev-parse --quiet --verify "$REV^2" 2>/dev/null) && + set -- $(git rev-parse "$REV" "$REV^1" "$REV:" "$REV^1:" "$REV^2:" 2>/dev/null) && s=$1 && w_commit=$1 && b_commit=$2 && @@ -408,8 +408,8 @@ parse_flags_and_rev() test "$ref_stash" = "$(git rev-parse --symbolic-full-name "${REV%@*}")" && IS_STASH_REF=t - u_commit=$(git rev-parse --quiet --verify $REV^3 2>/dev/null) && - u_tree=$(git rev-parse $REV^3: 2>/dev/null) + u_commit=$(git rev-parse --quiet --verify "$REV^3" 2>/dev/null) && + u_tree=$(git rev-parse "$REV^3:" 2>/dev/null) } is_stash_like() diff --git a/t/t3903-stash.sh b/t/t3903-stash.sh index debda7a..0568ec5 100755 --- a/t/t3903-stash.sh +++ b/t/t3903-stash.sh @@ -673,4 +673,15 @@ test_expect_success 'store updates stash ref and reflog' ' grep quux bazzy ' +test_expect_success 'handle stash specification with spaces' ' + git stash clear + echo mook > file && + git stash && + test_tick && + echo kleb > file && + git stash && + git stash apply "stash@{Thu Apr 7 15:17:13 2005 -0700}" && + grep mook file +' + test_done -- 1.8.5.rc0.23.gaa27064.dirty -- 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] stash: handle specifying stashes with spaces
When trying to pop/apply a stash specified with an argument containing spaces the user will see an error: $ git stash pop 'stash@{two hours ago}' Too many revisions specified: stash@{two hours ago} This happens because word splitting is used to count non-option arguments. Instead shift the positional arguments as the options are processed; the number of arguments left is then the number we're after. Add quotes where necessary. Also add a test that verifies correct behaviour. Signed-off-by: Øystein Walle --- This is perhaps an esoteric use case but it's still worth fixing in my opinion. It also saves a fork/exec so I see it as a win-win :) Comments welcome, of course. Especially on the test. I couldn't use a relative date spec since the commits and stashes are made with bogus timestamps and the spec is compared to the local time. It looks a bit icky the way it's written now. git-stash.sh | 20 ++-- t/t3903-stash.sh | 11 +++ 2 files changed, 21 insertions(+), 10 deletions(-) diff --git a/git-stash.sh b/git-stash.sh index 1e541a2..0a48d42 100755 --- a/git-stash.sh +++ b/git-stash.sh @@ -358,26 +358,25 @@ parse_flags_and_rev() i_tree= u_tree= - REV=$(git rev-parse --no-flags --symbolic "$@") || exit 1 - FLAGS= for opt do case "$opt" in -q|--quiet) GIT_QUIET=-t + shift ;; --index) INDEX_OPTION=--index + shift ;; -*) FLAGS="${FLAGS}${FLAGS:+ }$opt" + shift ;; esac done - set -- $REV - case $# in 0) have_stash || die "$(gettext "No stash found.")" @@ -387,17 +386,18 @@ parse_flags_and_rev() : ;; *) - die "$(eval_gettext "Too many revisions specified: \$REV")" + refs="$*" + die "$(eval_gettext "Too many revisions specified: \$refs")" ;; esac - REV=$(git rev-parse --quiet --symbolic --verify $1 2>/dev/null) || { + REV=$(git rev-parse --quiet --symbolic --verify "$1" 2>/dev/null) || { reference="$1" die "$(eval_gettext "\$reference is not valid reference")" } - i_commit=$(git rev-parse --quiet --verify $REV^2 2>/dev/null) && - set -- $(git rev-parse $REV $REV^1 $REV: $REV^1: $REV^2: 2>/dev/null) && + i_commit=$(git rev-parse --quiet --verify "$REV^2" 2>/dev/null) && + set -- $(git rev-parse "$REV" "$REV^1" "$REV:" "$REV^1:" "$REV^2:" 2>/dev/null) && s=$1 && w_commit=$1 && b_commit=$2 && @@ -408,8 +408,8 @@ parse_flags_and_rev() test "$ref_stash" = "$(git rev-parse --symbolic-full-name "${REV%@*}")" && IS_STASH_REF=t - u_commit=$(git rev-parse --quiet --verify $REV^3 2>/dev/null) && - u_tree=$(git rev-parse $REV^3: 2>/dev/null) + u_commit=$(git rev-parse --quiet --verify "$REV^3" 2>/dev/null) && + u_tree=$(git rev-parse "$REV^3:" 2>/dev/null) } is_stash_like() diff --git a/t/t3903-stash.sh b/t/t3903-stash.sh index debda7a..0568ec5 100755 --- a/t/t3903-stash.sh +++ b/t/t3903-stash.sh @@ -673,4 +673,15 @@ test_expect_success 'store updates stash ref and reflog' ' grep quux bazzy ' +test_expect_success 'handle stash specification with spaces' ' + git stash clear + echo pig > file && + git stash && + test_tick && + echo cow > file && + git stash && + git stash apply "stash@{Thu Apr 7 15:17:13 2005 -0700}" && + grep pig file +' + test_done -- 1.8.5.1.g359345f -- 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: Git 1.8.4.2: 'git-rev-parse --is-inside-git-dir' wrong output!
Ville Walveranta gmail.com> writes: > > "git-rev-parse --is-inside-git-dir" outputs "fatal: Not a git > repository (or any of the parent directories): .git", instead of > "false" when outside of a git directory. "--is-inside-work-tree" > behaves the same way. Both commands work correctly (i.e. output > "true") when inside a git directory, or inside a work tree, > respectively. > > To test, I installed git 1.8.4.2 initially from > https://launchpad.net/~git-core/+archive/ppa for Ubuntu 12.04.3, and > then also compiled it from source, but both seem to behave the same > way. The problem is not yet present in version 1.7.9.5. > > Thanks, > > Ville Walveranta > Hi, I thought I'd try to bisect this but I ended up discovering that I get the exact same behaviour with both 1.7.9.5 and 1.8.4.2. 1.7.9.5 will also output 'fatal: ...' like 1.8.4.2 does. Both version will however behave as expected if you provide --git-dir and --work-tree: $ pwd /home/osse $ git --version git version 1.8.4.2 $ git --git-dir=/home/osse/git/.git \ --work-tree=/home/osse/git\ rev-parse --is-inside-work-tree false Ditto for --is-inside-git-dir. Incidentally I discovered that the new -C option does *not* behave this way: $ git --version git version 1.8.5.rc0.23.gaa27064 $ git -C /home/osse/git rev-parse --is-inside-work-tree true But given that the purpose of the -C option is to make Git behave as if you were in that directory this is perhaps expected behaviour. Regards, Øsse -- 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] Documentation: fix typos in man pages
Signed-off-by: Øystein Walle --- I thought I'd take part in the typo fixing frenzy :) I have some other potential typos lines up. Right now the docs refer to both 'filesystem' and 'file system', as well as both 'testsuite' and 'test suite'. I think words like these are generally split in English but I'm not sure. There are also some words that I think look better with with a dash, e.g. 'trade-off'. Should I just send these as a patch too instead of jabbering on about it? Documentation/git-check-ignore.txt | 2 +- Documentation/git-clone.txt| 2 +- Documentation/git-daemon.txt | 2 +- Documentation/git-diff.txt | 2 +- Documentation/gitcli.txt | 2 +- Documentation/githooks.txt | 2 +- Documentation/gitweb.conf.txt | 4 ++-- Documentation/user-manual.txt | 2 +- 8 files changed, 9 insertions(+), 9 deletions(-) diff --git a/Documentation/git-check-ignore.txt b/Documentation/git-check-ignore.txt index d2df487..5354301 100644 --- a/Documentation/git-check-ignore.txt +++ b/Documentation/git-check-ignore.txt @@ -35,7 +35,7 @@ OPTIONS Read file names from stdin instead of from the command-line. -z:: - The output format is modified to be machine-parseable (see + The output format is modified to be machine-parsable (see below). If `--stdin` is also given, input paths are separated with a NUL character instead of a linefeed character. diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt index 450f158..3865658 100644 --- a/Documentation/git-clone.txt +++ b/Documentation/git-clone.txt @@ -213,7 +213,7 @@ objects from the source repository into a pack in the cloned repository. --separate-git-dir=:: Instead of placing the cloned repository where it is supposed to be, place the cloned repository at the specified directory, - then make a filesytem-agnostic Git symbolic link to there. + then make a filesystem-agnostic Git symbolic link to there. The result is Git repository can be separated from working tree. diff --git a/Documentation/git-daemon.txt b/Documentation/git-daemon.txt index 223f731..a3283e1 100644 --- a/Documentation/git-daemon.txt +++ b/Documentation/git-daemon.txt @@ -189,7 +189,7 @@ Git configuration files in that directory are readable by ``. service by exiting with a non-zero status (or to allow it by exiting with a zero status). It can also look at the $REMOTE_ADDR and $REMOTE_PORT environment variables to learn about the - requestor when making this decision. + requester when making this decision. + The external command can optionally write a single line to its standard output to be sent to the requestor as an error message when diff --git a/Documentation/git-diff.txt b/Documentation/git-diff.txt index 78d6d50..fe42bf6 100644 --- a/Documentation/git-diff.txt +++ b/Documentation/git-diff.txt @@ -39,7 +39,7 @@ directories. This behavior can be forced by --no-index. commit relative to the named . Typically you would want comparison with the latest commit, so if you do not give , it defaults to HEAD. - If HEAD does not exist (e.g. unborned branches) and + If HEAD does not exist (e.g. unborn branches) and is not given, it shows all staged changes. --staged is a synonym of --cached. diff --git a/Documentation/gitcli.txt b/Documentation/gitcli.txt index 9ac5088..670c285 100644 --- a/Documentation/gitcli.txt +++ b/Documentation/gitcli.txt @@ -28,7 +28,7 @@ arguments. Here are the rules: they can be disambiguated by placing `--` between them. E.g. `git diff -- HEAD` is, "I have a file called HEAD in my work tree. Please show changes between the version I staged in the index - and what I have in the work tree for that file". not "show difference + and what I have in the work tree for that file", not "show difference between the HEAD commit and the work tree as a whole". You can say `git diff HEAD --` to ask for the latter. diff --git a/Documentation/githooks.txt b/Documentation/githooks.txt index d48bf4d..d954bf6 100644 --- a/Documentation/githooks.txt +++ b/Documentation/githooks.txt @@ -251,7 +251,7 @@ three parameters: - the name of the ref being updated, - the old object name stored in the ref, - - and the new objectname to be stored in the ref. + - and the new object name to be stored in the ref. A zero exit from the update hook allows the ref to be updated. Exiting with a non-zero status prevents 'git-receive-pack' diff --git a/Documentation/gitweb.conf.txt b/Documentation/gitweb.conf.txt index 305db63..5945d7a 100644 --- a/Documentation/gitweb.conf.txt +++ b/Documentation/gitweb.conf.txt @@ -630,13 +630,13 @@ need to set this element to empty list i.e. `[]`. override:: If this field ha
Re: [PATCH 2/4] git-prompt.sh: refactor colored prompt code
Eduardo R. D'Avila gmail.com> writes: > + local c_red='\[\e[31m\]' > + local c_green='\[\e[32m\]' > + local c_lblue='\[\e[1;34m\]' > + local c_clear='\[\e[0m\]' > fi > - local c_red='\e[31m' > - local c_green='\e[32m' > - local c_lblue='\e[1;34m' > - local c_clear='\e[0m' I've gotten the impression it's better to use tput to generate the escape sequences instead of hardcoding them. So something like: local c_red='\['"$(tput setaf 1)"'\]' local c_green='\['"$(tput setaf 2)"'\]' local c_green='\['"$(tput setaf 4)"'\]' local c_clear='\['"$(tput sgr0)"'\]' which is technically cleaner, if not visually. The problem with that approach is that tput will be run several times for each prompt, so it would be best if the color variables were global. Another thing is that you rely on tput being available. Øsse -- 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 v2] show-branch: use pager
This is for consistency with other porcelain commands such as 'log'. Signed-off-by: Øystein Walle --- Hi, Jeff Thanks for the (fast!) feedback and good to hear it won't cause any trouble. I hadn't actually noticed this mechanism of setting up the pager before now but I fully agree. Here's an updated version. Øsse git.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/git.c b/git.c index 4359086..6d1f6ca 100644 --- a/git.c +++ b/git.c @@ -406,7 +406,7 @@ static void handle_internal_command(int argc, const char **argv) { "send-pack", cmd_send_pack, RUN_SETUP }, { "shortlog", cmd_shortlog, RUN_SETUP_GENTLY | USE_PAGER }, { "show", cmd_show, RUN_SETUP }, - { "show-branch", cmd_show_branch, RUN_SETUP }, + { "show-branch", cmd_show_branch, RUN_SETUP | USE_PAGER }, { "show-ref", cmd_show_ref, RUN_SETUP }, { "stage", cmd_add, RUN_SETUP | NEED_WORK_TREE }, { "status", cmd_status, RUN_SETUP | NEED_WORK_TREE }, -- 1.8.2.2 -- 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 RFC] show-branch: use pager
This is for consistency with other porcelain commands such as 'log'. Signed-off-by: Øystein Walle --- The rationale for this patch I hope is consicely explained in the commit message. I was rather surprised it didn't use a pager as I've gotten used to it for most commands. I marked this as an RFC because of Jeff King's comments in daa0c3d97 where I got the impression this this might not be a good idea. However I haven't found any bugs and all the tests pass. It is more a huble suggestion than anything but I thought I might as well send it as a patch. setup_pager() is already pulled in via cache.h so there was no need to add any #include directive. I suppose this is as close to a one-liner as it gets :) Best regards, Øsse builtin/show-branch.c | 1 + 1 file changed, 1 insertion(+) diff --git a/builtin/show-branch.c b/builtin/show-branch.c index 90fc6b1..bd3e10c 100644 --- a/builtin/show-branch.c +++ b/builtin/show-branch.c @@ -683,6 +683,7 @@ int cmd_show_branch(int ac, const char **av, const char *prefix) }; git_config(git_show_branch_config, NULL); + setup_pager(); /* If nothing is specified, try the default first */ if (ac == 1 && default_num) { -- 1.8.2.2 -- 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: What's cooking in git.git (May 2013, #09; Wed, 29)
Junio C Hamano pobox.com> writes: > * kb/status-ignored-optim-2 (2013-05-29) 1 commit > - dir.c: fix ignore processing within not-ignored directories > > Fix 1.8.3 regressions in the .gitignore path exclusion logic. Hi, I see that the Tested-by line in kb/status-ignored-optim-2 (3973cbd) doesn't contain my e-mail address. I personally have no particular preference whether it's there or not, but I noticed that it usually is on Tested-by lines, so I'm wondering if I have slipped on some standard practice. Would be useful to know in case I get the chance to help out more :) Thanks, Øsse -- 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: 1.8.3 - gitignore not being parsed correctly on OS X; regex support is broken?
Karsten Blees gmail.com> writes: > Øystein: in the meantime, could you check if this fixes the problem for you? > > --- 8< --- > diff --git a/dir.c b/dir.c > index a5926fb..13858fe 100644 > --- a/dir.c > +++ b/dir.c > -821,6 +821,9 static void prep_exclude(struct dir_struct *dir, const char *base, int baselen) > dir->basebuf, stk->baselen - 1, > dir->basebuf + current, &dt); > dir->basebuf[stk->baselen - 1] = '/'; > + if (dir->exclude && > + dir->exclude->flags & EXC_FLAG_NEGATIVE) > + dir->exclude = NULL; > if (dir->exclude) { > dir->basebuf[stk->baselen] = 0; > dir->exclude_stack = stk; Hi, Karsten I applied your fix on v1.8.3 on both systems I mentioned earlier and from my tests the issue I reported is fixed. Thank you very much! :) Regards Øsse -- 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: 1.8.3 - gitignore not being parsed correctly on OS X; regex support is broken?
Misty De Meo brew.sh> writes: > > Hi, > > Gitignore parsing no longer seems to work properly in git 1.8.3. > > One of my repositories has the following gitignore: > > /* > !/.gitignore > !/Library/ > !/CONTRIBUTING.md > !/README.md > !/SUPPORTERS.md > !/bin > /bin/* > !/bin/brew > !/share/man/man1/brew.1 > .DS_Store > /Library/LinkedKegs > /Library/PinnedKegs > /Library/Taps > /Library/Formula/.gitignore > > In 1.8.2.3 and earlier, this works as expected. However, in 1.8.3 I'm > seeing every file in /bin/ being marked as an untracked file. > > I asked about this in #git, and was told that the culprit was the > regex support; apparently recompiling without regex support fixes the > specific gitignore issue. However, this doesn't seem to have been > reported anywhere on the mailing list that I can see. I was also told > that the issue is OS X-specific, and doesn't happen on other > platforms. > > Thanks, > Misty De Meo > I see a similar problem using e.g. the following .gitignore to exclude everything except C source files and header files: * !*/ !*.c !*.h In Git 1.8.3 'git status' will show other files as untracked while in Git 1.8.2.3 I don't have that problem. I bisected to find that the offending commit is v1.8.2.1-402-g95c6f27. I am not on OSX, however, but on Linux (Ubuntu 12.04 and RHEL 5.8) so this may be a separate issue. I've also gotten the impression that this is intentional. In any case I cannot create a .gitignore that achieves the same for both older and newer versions of Git. Best regards, Øystein Walle -- 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