* Fixing the warning about warning(""); was: Re: [PATCH] difftool.c: mark a file-local symbol with static
From: Johannes Schindelin @ 2017-01-25 10:36 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, David Aguilar, Ramsay Jones, GIT Mailing-list
In-Reply-To: <20170124230500.h3fasbvutjkkke5h@sigill.intra.peff.net>
Hi Peff,
On Tue, 24 Jan 2017, Jeff King wrote:
> On Tue, Jan 24, 2017 at 01:52:13PM -0800, Junio C Hamano wrote:
>
> > > I dunno. As ugly as the "%s" thing is in the source, at least it
> > > doesn't change the output. Not that an extra space is the end of the
> > > world, but it seems like it's letting the problem escape from the
> > > source code.
> > >
> > > Do people still care about resolving this? -Wno-format-zero-length
> > > is in the DEVELOPER options. It wasn't clear to me if that was
> > > sufficient, or if we're going to get a bunch of reports from people
> > > that need to be directed to the right compiler options.
> >
> > I view both as ugly, but probably "%s", "" is lessor of the two evils.
> >
> > Perhaps
> >
> > #define JUST_SHOW_EMPTY_LINE "%s", ""
> >
> > ...
> > warning(JUST_SHOW_EMPTY_LINE);
> > ...
> >
> > or something silly like that?
>
> Gross, but at least it's self documenting. :)
>
> I guess a less horrible version of that is:
>
> static inline warning_blank_line(void)
> {
> warning("%s", "");
> }
>
> We'd potentially need a matching one for error(), but at last it avoids
> macro trickery.
I fail to see how this function, or this definition, makes the code better
than simply calling `warning("%s", "");` and be done with it.
Ciao,
Johannes
^ permalink raw reply
* Re: [PATCH] connect: handle putty/plink also in GIT_SSH_COMMAND
From: Johannes Schindelin @ 2017-01-25 12:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Segev Finer
In-Reply-To: <xmqqmvf0wc2h.fsf@gitster.mtv.corp.google.com>
Hi Junio,
On Mon, 9 Jan 2017, Junio C Hamano wrote:
> IOW, "give an escape hatch to override auto-detected tortoiseplink and
> plink variables" suggestion should be taken as an "in addition to"
> suggestion (as opposed to an "instead of" suggestion). I was not clear
> in my very first message, and I thought in my second and my third
> message I clarified it as such, but probably I wasn't explicit enough.
While you may not have been explicit enough, I was not smart enough.
That escape-hatch exists *already*. And it is exactly the thing that you
mentioned earlier as a potential source of mis-identification.
Let's assume that you want to use a script for the GIT_SSH_COMMAND that
eventually uses PuTTY, and you call this script "junio-is-a-superstar.sh".
All plausible so far ;-)
Now, with the patch in question (without the follow-up, which I would like
to ask you to ignore, just like you did so far), Git would not figure out
that your script calls PuTTY eventually. The work-around? Easy:
DUMMY=/plink.exe /path/to/junio-is-a-superstar.sh
In other words: the thing that we thought may be a problem is actually a
feature.
Likewise, if your GIT_SSH_COMMAND looks like this:
THIS_IS_NOT_ACTUALLY_PUTTY=/my/window/needs/putty my-ssh.sh
... you can easily change Git's mind by prefixing
DUMMY=blubber
If you want to use a script that decides itself whether to call OpenSSH or
PuTTY, Git should "stay dumb" about it, as it will not be able to tell
beforehand whether a port argument should be passed via `-p` or `-P`
anyway.
Of course, given our discussion I think all of this should be documented
in the commit message as well as in the man page.
Do you agree this is a good direction to take?
Ciao,
Johannes
^ permalink raw reply
* [PATCH 1/5] rev-list-options.txt: delete an empty line
From: Nguyễn Thái Ngọc Duy @ 2017-01-25 12:50 UTC (permalink / raw)
To: git; +Cc: Jeff King, jacob.keller, Nguyễn Thái Ngọc Duy
In-Reply-To: <20170125125054.7422-1-pclouds@gmail.com>
The convention has been option name is followed immediately by its
description without a line break.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
Documentation/rev-list-options.txt | 1 -
1 file changed, 1 deletion(-)
diff --git a/Documentation/rev-list-options.txt b/Documentation/rev-list-options.txt
index 5da7cf5a8d..1f948cfb13 100644
--- a/Documentation/rev-list-options.txt
+++ b/Documentation/rev-list-options.txt
@@ -161,7 +161,6 @@ parents) and `--max-parents=-1` (negative numbers denote no upper limit).
or '[', '/{asterisk}' at the end is implied.
--exclude=<glob-pattern>::
-
Do not include refs matching '<glob-pattern>' that the next `--all`,
`--branches`, `--tags`, `--remotes`, or `--glob` would otherwise
consider. Repetitions of this option accumulate exclusion patterns
--
2.11.0.157.gd943d85
^ permalink raw reply related
* [PATCH 0/5] Prep steps for --decorate-reflog
From: Nguyễn Thái Ngọc Duy @ 2017-01-25 12:50 UTC (permalink / raw)
To: git; +Cc: Jeff King, jacob.keller, Nguyễn Thái Ngọc Duy
In-Reply-To: <20170121140806.tjs6wad3x4srdv3q@sigill.intra.peff.net>
I'm still half way through implementing --decorate-reflog that can
select what refs to decorate using --branches, --remotes, --tags...
But I want to make sure I'm heading the right direction first since
I'm not really sure if this is the right way (implementation wise).
This series does not really implement --decorate-reflog. It shuffles
revision.c code around a bit so thay the option can be implemented
later. The most controversal patch would be 4/5 where --exclude
behavior is changed slighly.
Good? Bad? Horror hooorrrible?
Nguyễn Thái Ngọc Duy (5):
rev-list-options.txt: delete an empty line
revision.c: group ref selection options together
revision.c: allow to change pseudo opt parsing function
revision.c: refactor ref selection handler after --exclude
revision.c: add --decorate-reflog
Documentation/rev-list-options.txt | 1 -
revision.c | 206 ++++++++++++++++++++++++++++++-------
revision.h | 4 +
3 files changed, 173 insertions(+), 38 deletions(-)
--
2.11.0.157.gd943d85
^ permalink raw reply
* [PATCH 2/5] revision.c: group ref selection options together
From: Nguyễn Thái Ngọc Duy @ 2017-01-25 12:50 UTC (permalink / raw)
To: git; +Cc: Jeff King, jacob.keller, Nguyễn Thái Ngọc Duy
In-Reply-To: <20170125125054.7422-1-pclouds@gmail.com>
These options have on thing in common: when specified right after
--exclude, they will de-select refs instead of selecting them by
default.
This change makes it possible to introduce new options that use these
options in the same way as --exclude. Such an option would just
implement something like handle_refs_pseudo_opt().
parse_ref_selector_option() is taken out of handle_refs_pseudo_opt() so
that similar functions like handle_refs_pseudo_opt() are forced to
handle all ref selector options, not skipping some by mistake, which may
revert the option back to default behavior (rev selection).
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
revision.c | 134 +++++++++++++++++++++++++++++++++++++++++++++----------------
1 file changed, 100 insertions(+), 34 deletions(-)
diff --git a/revision.c b/revision.c
index b37dbec378..6ebd38d1c8 100644
--- a/revision.c
+++ b/revision.c
@@ -2059,6 +2059,103 @@ static int for_each_good_bisect_ref(const char *submodule, each_ref_fn fn, void
return for_each_bisect_ref(submodule, fn, cb_data, term_good);
}
+enum ref_selector {
+ REF_SELECT_NONE,
+ REF_SELECT_ALL,
+ REF_SELECT_BRANCHES,
+ REF_SELECT_TAGS,
+ REF_SELECT_REMOTES,
+ REF_SELECT_BY_GLOB
+};
+
+static enum ref_selector parse_ref_selector_option(int argc, const char **argv,
+ const char **optarg,
+ int *argcount)
+{
+ const char *arg = argv[0];
+
+ *optarg = NULL;
+
+ if (!strcmp(arg, "--all"))
+ return REF_SELECT_ALL;
+ else if (!strcmp(arg, "--branches") ||
+ skip_prefix(arg, "--branches=", optarg))
+ return REF_SELECT_BRANCHES;
+ else if (!strcmp(arg, "--tags") ||
+ skip_prefix(arg, "--tags=", optarg))
+ return REF_SELECT_TAGS;
+ else if (!strcmp(arg, "--remotes") ||
+ skip_prefix(arg, "--remotes=", optarg))
+ return REF_SELECT_REMOTES;
+ else if ((*argcount = parse_long_opt("glob", argv, optarg)))
+ return REF_SELECT_BY_GLOB;
+
+ return REF_SELECT_NONE;
+}
+
+static int handle_refs_pseudo_opt(const char *submodule,
+ struct rev_info *revs,
+ int argc, const char **argv,
+ int *flags, int *ret)
+{
+ struct all_refs_cb cb;
+ const char *optarg = NULL;
+ int argcount;
+ enum ref_selector selector;
+
+ selector = parse_ref_selector_option(argc, argv, &optarg, &argcount);
+
+ if (optarg)
+ init_all_refs_cb(&cb, revs, *flags);
+ *ret = 1;
+
+ switch (selector) {
+ case REF_SELECT_ALL:
+ handle_refs(submodule, revs, *flags, for_each_ref_submodule);
+ handle_refs(submodule, revs, *flags, head_ref_submodule);
+ break;
+
+ case REF_SELECT_BRANCHES:
+ if (optarg)
+ for_each_glob_ref_in(handle_one_ref, optarg,
+ "refs/heads/", &cb);
+ else
+ handle_refs(submodule, revs, *flags,
+ for_each_branch_ref_submodule);
+ break;
+
+ case REF_SELECT_TAGS:
+ if (optarg)
+ for_each_glob_ref_in(handle_one_ref, optarg,
+ "refs/tags/", &cb);
+ else
+ handle_refs(submodule, revs, *flags,
+ for_each_tag_ref_submodule);
+ break;
+
+ case REF_SELECT_REMOTES:
+ if (optarg)
+ for_each_glob_ref_in(handle_one_ref, optarg,
+ "refs/remotes/", &cb);
+ else
+ handle_refs(submodule, revs, *flags,
+ for_each_remote_ref_submodule);
+ break;
+
+ case REF_SELECT_BY_GLOB:
+ init_all_refs_cb(&cb, revs, *flags);
+ for_each_glob_ref(handle_one_ref, optarg, &cb);
+ *ret = argcount;
+ break;
+
+ case REF_SELECT_NONE:
+ return 0;
+ }
+
+ clear_ref_exclusion(&revs->ref_excludes);
+ return 1;
+}
+
static int handle_revision_pseudo_opt(const char *submodule,
struct rev_info *revs,
int argc, const char **argv, int *flags)
@@ -2066,6 +2163,7 @@ static int handle_revision_pseudo_opt(const char *submodule,
const char *arg = argv[0];
const char *optarg;
int argcount;
+ int ret;
/*
* NOTE!
@@ -2077,48 +2175,16 @@ static int handle_revision_pseudo_opt(const char *submodule,
* When implementing your new pseudo-option, remember to
* register it in the list at the top of handle_revision_opt.
*/
- if (!strcmp(arg, "--all")) {
- handle_refs(submodule, revs, *flags, for_each_ref_submodule);
- handle_refs(submodule, revs, *flags, head_ref_submodule);
- clear_ref_exclusion(&revs->ref_excludes);
- } else if (!strcmp(arg, "--branches")) {
- handle_refs(submodule, revs, *flags, for_each_branch_ref_submodule);
- clear_ref_exclusion(&revs->ref_excludes);
+ if (handle_refs_pseudo_opt(submodule, revs, argc, argv, flags, &ret)) {
+ return ret;
} else if (!strcmp(arg, "--bisect")) {
read_bisect_terms(&term_bad, &term_good);
handle_refs(submodule, revs, *flags, for_each_bad_bisect_ref);
handle_refs(submodule, revs, *flags ^ (UNINTERESTING | BOTTOM), for_each_good_bisect_ref);
revs->bisect = 1;
- } else if (!strcmp(arg, "--tags")) {
- handle_refs(submodule, revs, *flags, for_each_tag_ref_submodule);
- clear_ref_exclusion(&revs->ref_excludes);
- } else if (!strcmp(arg, "--remotes")) {
- handle_refs(submodule, revs, *flags, for_each_remote_ref_submodule);
- clear_ref_exclusion(&revs->ref_excludes);
- } else if ((argcount = parse_long_opt("glob", argv, &optarg))) {
- struct all_refs_cb cb;
- init_all_refs_cb(&cb, revs, *flags);
- for_each_glob_ref(handle_one_ref, optarg, &cb);
- clear_ref_exclusion(&revs->ref_excludes);
- return argcount;
} else if ((argcount = parse_long_opt("exclude", argv, &optarg))) {
add_ref_exclusion(&revs->ref_excludes, optarg);
return argcount;
- } else if (starts_with(arg, "--branches=")) {
- struct all_refs_cb cb;
- init_all_refs_cb(&cb, revs, *flags);
- for_each_glob_ref_in(handle_one_ref, arg + 11, "refs/heads/", &cb);
- clear_ref_exclusion(&revs->ref_excludes);
- } else if (starts_with(arg, "--tags=")) {
- struct all_refs_cb cb;
- init_all_refs_cb(&cb, revs, *flags);
- for_each_glob_ref_in(handle_one_ref, arg + 7, "refs/tags/", &cb);
- clear_ref_exclusion(&revs->ref_excludes);
- } else if (starts_with(arg, "--remotes=")) {
- struct all_refs_cb cb;
- init_all_refs_cb(&cb, revs, *flags);
- for_each_glob_ref_in(handle_one_ref, arg + 10, "refs/remotes/", &cb);
- clear_ref_exclusion(&revs->ref_excludes);
} else if (!strcmp(arg, "--reflog")) {
add_reflogs_to_pending(revs, *flags);
} else if (!strcmp(arg, "--indexed-objects")) {
--
2.11.0.157.gd943d85
^ permalink raw reply related
* [PATCH 3/5] revision.c: allow to change pseudo opt parsing function
From: Nguyễn Thái Ngọc Duy @ 2017-01-25 12:50 UTC (permalink / raw)
To: git; +Cc: Jeff King, jacob.keller, Nguyễn Thái Ngọc Duy
In-Reply-To: <20170125125054.7422-1-pclouds@gmail.com>
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
revision.c | 11 ++++++++---
revision.h | 4 ++++
2 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/revision.c b/revision.c
index 6ebd38d1c8..cda2606c66 100644
--- a/revision.c
+++ b/revision.c
@@ -2273,10 +2273,15 @@ int setup_revisions(int argc, const char **argv, struct rev_info *revs, struct s
const char *arg = argv[i];
if (*arg == '-') {
int opts;
+ handle_pseudo_opt_cb handle_pseudo_opt =
+ handle_revision_pseudo_opt;
- opts = handle_revision_pseudo_opt(submodule,
- revs, argc - i, argv + i,
- &flags);
+ if (revs->handle_pseudo_opt)
+ handle_pseudo_opt = revs->handle_pseudo_opt;
+
+ opts = handle_pseudo_opt(submodule,
+ revs, argc - i, argv + i,
+ &flags);
if (opts > 0) {
i += opts - 1;
continue;
diff --git a/revision.h b/revision.h
index 9fac1a607d..9080eaf381 100644
--- a/revision.h
+++ b/revision.h
@@ -52,6 +52,8 @@ struct rev_cmdline_info {
#define REVISION_WALK_NO_WALK_SORTED 1
#define REVISION_WALK_NO_WALK_UNSORTED 2
+typedef int (*handle_pseudo_opt_cb)(const char *, struct rev_info *, int, const char **, int *);
+
struct rev_info {
/* Starting list */
struct commit_list *commits;
@@ -213,6 +215,8 @@ struct rev_info {
struct commit_list *previous_parents;
const char *break_bar;
+
+ handle_pseudo_opt_cb handle_pseudo_opt;
};
extern int ref_excluded(struct string_list *, const char *path);
--
2.11.0.157.gd943d85
^ permalink raw reply related
* [PATCH 5/5] revision.c: add --decorate-reflog
From: Nguyễn Thái Ngọc Duy @ 2017-01-25 12:50 UTC (permalink / raw)
To: git; +Cc: Jeff King, jacob.keller, Nguyễn Thái Ngọc Duy
In-Reply-To: <20170125125054.7422-1-pclouds@gmail.com>
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
revision.c | 46 ++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 46 insertions(+)
diff --git a/revision.c b/revision.c
index 45cffcab44..b77face513 100644
--- a/revision.c
+++ b/revision.c
@@ -2157,6 +2157,49 @@ static int handle_refs_pseudo_opt(const char *submodule,
static int handle_revision_pseudo_opt(const char *, struct rev_info *, int, const char **, int *);
+static int handle_revision_pseudo_opt_after_decorate_reflog(
+ const char *submodule, struct rev_info *revs,
+ int argc, const char **argv, int *flags)
+{
+ struct all_refs_cb cb;
+ const char *optarg = NULL;
+ int argcount;
+ enum ref_selector selector;
+
+ selector = parse_ref_selector_option(argc, argv, &optarg, &argcount);
+
+ if (optarg)
+ init_all_refs_cb(&cb, revs, *flags);
+
+ switch (selector) {
+ case REF_SELECT_ALL:
+ /* keep the info for load_ref_decorations() later */
+ return 1;
+
+ case REF_SELECT_BRANCHES:
+ /* keep the info for load_ref_decorations() later */
+ return 1;
+
+ case REF_SELECT_TAGS:
+ /* keep the info for load_ref_decorations() later */
+ return 1;
+
+ case REF_SELECT_REMOTES:
+ /* keep the info for load_ref_decorations() later */
+ return 1;
+
+ case REF_SELECT_BY_GLOB:
+ /* keep the info for load_ref_decorations() later */
+ return 1;
+
+ case REF_SELECT_NONE:
+ break;
+ }
+
+ revs->handle_pseudo_opt = NULL;
+ return handle_revision_pseudo_opt(submodule, revs, argc, argv, flags);
+}
+
static int handle_revision_pseudo_opt_after_exclude(const char *submodule,
struct rev_info *revs,
int argc, const char **argv,
@@ -2200,6 +2243,9 @@ static int handle_revision_pseudo_opt(const char *submodule,
add_ref_exclusion(&revs->ref_excludes, optarg);
revs->handle_pseudo_opt = handle_revision_pseudo_opt_after_exclude;
return argcount;
+ } else if ((argcount = parse_long_opt("decorate-reflog", argv, &optarg))) {
+ revs->handle_pseudo_opt = handle_revision_pseudo_opt_after_decorate_reflog;
+ return argcount;
} else if (!strcmp(arg, "--reflog")) {
add_reflogs_to_pending(revs, *flags);
} else if (!strcmp(arg, "--indexed-objects")) {
--
2.11.0.157.gd943d85
^ permalink raw reply related
* [PATCH 4/5] revision.c: refactor ref selection handler after --exclude
From: Nguyễn Thái Ngọc Duy @ 2017-01-25 12:50 UTC (permalink / raw)
To: git; +Cc: Jeff King, jacob.keller, Nguyễn Thái Ngọc Duy
In-Reply-To: <20170125125054.7422-1-pclouds@gmail.com>
Behavior change: "--exclude --blah --remotes" will not exclude remote
branches any more. Only "--exclude --remotes" does.
This is because --exclude is going to have a new friend --decorate-reflog
who haves the same way. When you allow a distant --remotes to complement
a previous option, things get complicated. In
--exclude .. --decorate-reflog ... --remotes
Does it mean decorate remote reflogs, or does it mean exclude remotes
from the selected revisions?
Granted, there may be valid use cases for such a combination (e.g.
"decorate all reflogs except remote ones") but I feel option order is
not a good fit to express them.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
revision.c | 17 ++++++++++++++++-
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/revision.c b/revision.c
index cda2606c66..45cffcab44 100644
--- a/revision.c
+++ b/revision.c
@@ -2152,10 +2152,24 @@ static int handle_refs_pseudo_opt(const char *submodule,
return 0;
}
- clear_ref_exclusion(&revs->ref_excludes);
return 1;
}
+static int handle_revision_pseudo_opt(const char *, struct rev_info *, int, const char **, int *);
+
+static int handle_revision_pseudo_opt_after_exclude(const char *submodule,
+ struct rev_info *revs,
+ int argc, const char **argv,
+ int *flags)
+{
+ int ret;
+
+ ret = handle_revision_pseudo_opt(submodule, revs, argc, argv, flags);
+ clear_ref_exclusion(&revs->ref_excludes);
+ revs->handle_pseudo_opt = NULL;
+ return ret;
+}
+
static int handle_revision_pseudo_opt(const char *submodule,
struct rev_info *revs,
int argc, const char **argv, int *flags)
@@ -2184,6 +2198,7 @@ static int handle_revision_pseudo_opt(const char *submodule,
revs->bisect = 1;
} else if ((argcount = parse_long_opt("exclude", argv, &optarg))) {
add_ref_exclusion(&revs->ref_excludes, optarg);
+ revs->handle_pseudo_opt = handle_revision_pseudo_opt_after_exclude;
return argcount;
} else if (!strcmp(arg, "--reflog")) {
add_reflogs_to_pending(revs, *flags);
--
2.11.0.157.gd943d85
^ permalink raw reply related
* Re: [PATCH 1/3] Documentation/stash: remove mention of git reset --hard
From: Jakub Narębski @ 2017-01-25 13:02 UTC (permalink / raw)
To: Jeff King, Thomas Gummerer
Cc: git, Stephan Beyer, Junio C Hamano, Marc Strapetz,
Johannes Schindelin
In-Reply-To: <20170124201415.zzyg4vt35vflwjnb@sigill.intra.peff.net>
W dniu 24.01.2017 o 21:14, Jeff King pisze:
> On Sat, Jan 21, 2017 at 08:08:02PM +0000, Thomas Gummerer wrote:
>
>> diff --git a/Documentation/git-stash.txt b/Documentation/git-stash.txt
>> index 2e9cef06e6..0ad5335a3e 100644
>> --- a/Documentation/git-stash.txt
>> +++ b/Documentation/git-stash.txt
>> @@ -47,8 +47,9 @@ OPTIONS
>>
>> save [-p|--patch] [-k|--[no-]keep-index] [-u|--include-untracked] [-a|--all] [-q|--quiet] [<message>]::
>>
>> - Save your local modifications to a new 'stash', and run `git reset
>> - --hard` to revert them. The <message> part is optional and gives
>> + Save your local modifications to a new 'stash', and revert the
>> + the changes in the working tree to match the index.
>> + The <message> part is optional and gives
>
> Hrm. "git reset --hard" doesn't just make the working tree match the
> index. It also resets the index to HEAD. So either the original or your
> new description is wrong.
>
> I think it's the latter. We really do reset the index unless
> --keep-index is specified.
I wonder if it is worth mentioning that "saving local modifications"
in 'git stash' means storing both the state of the worktree (of tracked
files in it) _and_ the state of the index, before both get set to
state of HEAD.
Best,
--
Jakub Narębski
^ permalink raw reply
* [PATCH] fixup! worktree move: new command
From: Johannes Schindelin @ 2017-01-25 13:04 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Nguyễn Thái Ngọc Duy
This is required for the test to pass on Windows, where $TRASH_DIRECTORY
is a POSIX path, while Git works with Windows paths instead. Using
`$(pwd)` is the common workaround: it reports a Windows path (while `$PWD`
would report the POSIX equivalent which, however, would only be understood
by shell and Perl scripts).
Duy, if you re-roll the `worktree-move` patch series, would you terribly
mind squashing this in?
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
Based-On: pu at https://github.com/dscho/git
Fetch-Base-Via: git fetch https://github.com/dscho/git pu
Published-As: https://github.com/dscho/git/releases/tag/nd/worktree-move-fixup-v1
Fetch-It-Via: git fetch https://github.com/dscho/git nd/worktree-move-fixup-v1
t/t2028-worktree-move.sh | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/t/t2028-worktree-move.sh b/t/t2028-worktree-move.sh
index 084acc6c6d..b3105eaaed 100755
--- a/t/t2028-worktree-move.sh
+++ b/t/t2028-worktree-move.sh
@@ -71,13 +71,14 @@ test_expect_success 'move locked worktree' '
'
test_expect_success 'move worktree' '
+ toplevel="$(pwd)" &&
git worktree move source destination &&
test_path_is_missing source &&
git worktree list --porcelain | grep "^worktree" >actual &&
cat <<-EOF >expected &&
- worktree $TRASH_DIRECTORY
- worktree $TRASH_DIRECTORY/destination
- worktree $TRASH_DIRECTORY/elsewhere
+ worktree $toplevel
+ worktree $toplevel/destination
+ worktree $toplevel/elsewhere
EOF
test_cmp expected actual &&
git -C destination log --format=%s >actual2 &&
base-commit: 8ef3497bf10296c74058e87d9c5b93372cad5137
--
2.11.0.windows.3.498.g86d49cc
^ permalink raw reply related
* Re: [PATCH v2 0/7] Macros for Asciidoctor support
From: Johannes Schindelin @ 2017-01-25 13:28 UTC (permalink / raw)
To: brian m. carlson; +Cc: git, Jeff King
In-Reply-To: <20170122024156.284180-1-sandals@crustytoothpaste.net>
Hi Brian,
On Sun, 22 Jan 2017, brian m. carlson wrote:
> There are two major processors of AsciiDoc: AsciiDoc itself, and
> Asciidoctor. Both have advantages and disadvantages, but traditionally
> the documentation has been built with AsciiDoc, leading to some
> surprising breakage when building with Asciidoctor. Partially, this is
> due to the need to specify a significant number of macros on the command
> line when building with Asciidoctor.
>
> This series cleans up some issues building the documentation with
> Asciidoctor and provides two knobs, USE_ASCIIDOCTOR, which controls
> building with Asciidoctor, and ASCIIDOCTOR_EXTENSIONS_LAB, which
> controls the location of the Asciidoctor Extensions Lab, which is
> necessary to expand the linkgit macro.
I like it.
I reviewed all the patches and think they are good (except the XSLT patch,
which made me just feel incompetent because I do not know enough to have
an opinion about it).
> The need for the extensions could be replaced with a small amount of
> Ruby code, if that's considered desirable. Previous opinions on doing
> so were negative, however.
Quite frankly, it is annoying to be forced to install the extensions. I
would much rather have the small amount of Ruby code in Git's repository.
Thanks,
Johannes
^ permalink raw reply
* Re: [PATCH v3 14/21] read-cache: touch shared index files when used
From: Christian Couder @ 2017-01-25 14:35 UTC (permalink / raw)
To: Junio C Hamano
Cc: Duy Nguyen, git, Ævar Arnfjörð Bjarmason,
Christian Couder
In-Reply-To: <xmqqefztsj4c.fsf@gitster.mtv.corp.google.com>
On Mon, Jan 23, 2017 at 7:53 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Christian Couder <christian.couder@gmail.com> writes:
>
>> Also in general the split-index mode is useful when you often write
>> new indexes, and in this case shared index files that are used will
>> often be freshened, so the risk of deleting interesting shared index
>> files should be low.
>> ...
>>> Not that I think freshening would actually fail in a repository
>>> where you can actually write into to update the index or its refs to
>>> make a difference (iow, even if we make it die() loudly when shared
>>> index cannot be "touched" because we are paranoid, no real life
>>> usage will trigger that die(), and if a repository does trigger the
>>> die(), I think you would really want to know about it).
>>
>> As I wrote above, I think if we can actually write the shared index
>> file but its freshening fails, it probably means that the shared index
>> file has been removed behind us, and this case is equivalent as when
>> loose files have been removed behind us.
>
> OK, so it is unlikely to happen, and when it happens it leads to a
> catastrophic failure---do we just ignore or do we report an error?
Well, when we cannot freshen a loose file (with
freshen_loose_object()), we don't warn or die, we just write the loose
file. But here we cannot write the shared index file.
And this doesn't lead to a catastrophic failure right away. There
could be a catastrophic failure if the shared index file is needed
again later, but we are not sure that it's going to be needed later.
In fact it may have just been removed because it won't be needed
later.
So I am not sure it's a good idea to anticipate a catastrophic failure
that may not happen. Perhaps we could just warn, but I am not sure it
will help the user. If the catastrophic failure doesn't happen because
the shared index file is not needed, I can't see how the warning could
help. And if there is a catastrophic failure, the following will be
displayed:
fatal: .git/sharedindex.cbfe41352a4623d4d3e9757861fed53f3094e0ac:
index file open failed: No such file or directory
and I don't see how the warning could help on top of that. It could at
most repeat the same thing.
^ permalink raw reply
* [PATCH] mingw: allow hooks to be .exe files
From: Johannes Schindelin @ 2017-01-25 16:58 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
This change is necessary to allow the files in .git/hooks/ to optionally
have the file extension `.exe` on Windows, as the file names are
hardcoded otherwise.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
Published-As: https://github.com/dscho/git/releases/tag/exe-as-hook-v1
Fetch-It-Via: git fetch https://github.com/dscho/git exe-as-hook-v1
run-command.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/run-command.c b/run-command.c
index 73bfba7ef9..45229ef052 100644
--- a/run-command.c
+++ b/run-command.c
@@ -871,8 +871,14 @@ const char *find_hook(const char *name)
strbuf_reset(&path);
strbuf_git_path(&path, "hooks/%s", name);
- if (access(path.buf, X_OK) < 0)
+ if (access(path.buf, X_OK) < 0) {
+#ifdef STRIP_EXTENSION
+ strbuf_addstr(&path, ".exe");
+ if (access(path.buf, X_OK) >= 0)
+ return path.buf;
+#endif
return NULL;
+ }
return path.buf;
}
base-commit: 4e59582ff70d299f5a88449891e78d15b4b3fabe
--
2.11.1.windows.prerelease.2.3.g7f3eb74
^ permalink raw reply related
* [PATCH] Retire the `relink` command
From: Johannes Schindelin @ 2017-01-25 16:58 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
Back in the olden days, when all objects were loose and rubber boots were
made out of wood, it made sense to try to share (immutable) objects
between repositories.
Ever since the arrival of pack files, it is but an anachronism.
Let's move the script to the contrib/examples/ directory and no longer
offer it.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
Published-As: https://github.com/dscho/git/releases/tag/retire-relink-v1
Fetch-It-Via: git fetch https://github.com/dscho/git retire-relink-v1
.gitignore | 1 -
Makefile | 1 -
command-list.txt | 1 -
git-relink.perl => contrib/examples/git-relink.perl | 0
{Documentation => contrib/examples}/git-relink.txt | 0
5 files changed, 3 deletions(-)
rename git-relink.perl => contrib/examples/git-relink.perl (100%)
rename {Documentation => contrib/examples}/git-relink.txt (100%)
diff --git a/.gitignore b/.gitignore
index 6722f78f9a..b1020b875f 100644
--- a/.gitignore
+++ b/.gitignore
@@ -118,7 +118,6 @@
/git-rebase--merge
/git-receive-pack
/git-reflog
-/git-relink
/git-remote
/git-remote-http
/git-remote-https
diff --git a/Makefile b/Makefile
index 27afd0f378..658ac19247 100644
--- a/Makefile
+++ b/Makefile
@@ -527,7 +527,6 @@ SCRIPT_PERL += git-archimport.perl
SCRIPT_PERL += git-cvsexportcommit.perl
SCRIPT_PERL += git-cvsimport.perl
SCRIPT_PERL += git-cvsserver.perl
-SCRIPT_PERL += git-relink.perl
SCRIPT_PERL += git-send-email.perl
SCRIPT_PERL += git-svn.perl
diff --git a/command-list.txt b/command-list.txt
index 2a94137bbb..a1fad28fd8 100644
--- a/command-list.txt
+++ b/command-list.txt
@@ -107,7 +107,6 @@ git-read-tree plumbingmanipulators
git-rebase mainporcelain history
git-receive-pack synchelpers
git-reflog ancillarymanipulators
-git-relink ancillarymanipulators
git-remote ancillarymanipulators
git-repack ancillarymanipulators
git-replace ancillarymanipulators
diff --git a/git-relink.perl b/contrib/examples/git-relink.perl
similarity index 100%
rename from git-relink.perl
rename to contrib/examples/git-relink.perl
diff --git a/Documentation/git-relink.txt b/contrib/examples/git-relink.txt
similarity index 100%
rename from Documentation/git-relink.txt
rename to contrib/examples/git-relink.txt
base-commit: 4e59582ff70d299f5a88449891e78d15b4b3fabe
--
2.11.1.windows.prerelease.2.3.g7f3eb74
^ permalink raw reply related
* git clone problem
From: Jordi Durban @ 2017-01-25 16:58 UTC (permalink / raw)
To: git
Hi all! Not sure if that will reach the goal, but let's it a try.
I have a problem with the git clone command: when I try to clone a
remote repository with the following:
git clone --recursive https://github.com/whatever.git
what I actually obtain is a copy of my own files in the current directory.
I mean:
In the current directory:
$ls
-rwxr-xr-x 1 1,6K oct 24 17:29 get_fasta.pl
-rwxr-xr-x 1 1,6K set 5 13:05 script_clus_miRNA_c95.pl
$git clone --recursive https://github.com/whatever.git WHATEVER
$ls
-rwxr-xr-x 1 1,6K oct 24 17:29 get_fasta.pl
-rwxr-xr-x 1 1,6K set 5 13:05 script_clus_miRNA_c95.pl
-rwxr-xr-x 1 1,6K set 5 13:05 WHATEVER
$ls WHATEVER
-rwxr-xr-x 1 1,6K oct 24 17:29 get_fasta.pl
-rwxr-xr-x 1 1,6K set 5 13:05 script_clus_miRNA_c95.pl
I am really confused with that.
Any help will be appreciated. Thank you
^ permalink raw reply
* Re: What's cooking in git.git (Jan 2017, #04; Mon, 23)
From: Johannes Schindelin @ 2017-01-25 17:01 UTC (permalink / raw)
To: Jeff King; +Cc: Lars Schneider, Junio C Hamano, git
In-Reply-To: <20170124132749.l3ezupyitvxe4t2l@sigill.intra.peff.net>
Hi Peff,
On Tue, 24 Jan 2017, Jeff King wrote:
> On Tue, Jan 24, 2017 at 11:04:21AM +0100, Lars Schneider wrote:
>
> > "fsck: prepare dummy objects for --connectivity-check" seems to
> > make t1450-fsck.sh fail on macOS with TravisCI:
> >
> > Initialized empty Git repository in /Users/travis/build/git/git/t/trash directory.t1450-fsck/connectivity-only/.git/
> > [master (root-commit) 86520b7] empty
> > Author: A U Thor <author@example.com>
> > 2 files changed, 1 insertion(+)
> > create mode 100644 empty
> > create mode 100644 empty.t
> > override r--r--r-- travis/staff for .git/objects/e6/9de29bb2d1d6434b8b29ae775ad8c2e48c5391? (y/n [n]) not overwritten
> > dangling blob c21c9352f7526e9576892a6631e0e8cf1fccd34d
>
> Looks like "mv" prompts and then fails to move the file (so we get the
> dangling blob for the source blob, and fsck doesn't report failure
> because we didn't actually corrupt the destination blob).
IIRC I had similar problems years ago, on a machine where the
administrator defined mandatory aliases, including mv="mv -i".
Ciao,
Johannes
^ permalink raw reply
* [ANNOUNCE] Git Rev News edition 23
From: Christian Couder @ 2017-01-25 17:20 UTC (permalink / raw)
To: git
Cc: Thomas Ferris Nicolaisen, Jakub Narebski, Markus Jansen,
Junio C Hamano, Johannes Schindelin, Jeff King, Stefan Beller,
Jacob Keller, Eric Wong, Eduardo Habkost, Pranit Bauva,
Andreas Schwab, Javantea, Aneesh Kumar K.V, Philip Oakley,
Lars Schneider
Hi everyone,
The 23rd edition of Git Rev News is now published:
https://git.github.io/rev_news/2017/01/25/edition-23/
Thanks a lot to all the contributors and helpers!
Enjoy,
Christian, Thomas, Jakub and Markus.
^ permalink raw reply
* Re: What's cooking in git.git (Jan 2017, #04; Mon, 23)
From: Jeff King @ 2017-01-25 17:39 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Lars Schneider, Junio C Hamano, git
In-Reply-To: <alpine.DEB.2.20.1701251800120.3469@virtualbox>
On Wed, Jan 25, 2017 at 06:01:11PM +0100, Johannes Schindelin wrote:
> > Looks like "mv" prompts and then fails to move the file (so we get the
> > dangling blob for the source blob, and fsck doesn't report failure
> > because we didn't actually corrupt the destination blob).
>
> IIRC I had similar problems years ago, on a machine where the
> administrator defined mandatory aliases, including mv="mv -i".
Yeah, that was my first thought, too. But this should be a
non-interactive shell, which would generally avoid loading rc files. I
think there are some exceptions, though (e.g., setting ENV or BASH_ENV).
Loading aliases like "mv -i" for non-interactive shells seems somewhat
insane to me. But whatever the cause, I think the workaround I posted is
easy enough to do.
-Peff
^ permalink raw reply
* Re: [PATCH 4/5] revision.c: refactor ref selection handler after --exclude
From: Jacob Keller @ 2017-01-25 17:41 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: Git mailing list, Jeff King
In-Reply-To: <20170125125054.7422-5-pclouds@gmail.com>
On Wed, Jan 25, 2017 at 4:50 AM, Nguyễn Thái Ngọc Duy <pclouds@gmail.com> wrote:
> Behavior change: "--exclude --blah --remotes" will not exclude remote
> branches any more. Only "--exclude --remotes" does.
>
> This is because --exclude is going to have a new friend --decorate-reflog
> who haves the same way. When you allow a distant --remotes to complement
> a previous option, things get complicated. In
>
> --exclude .. --decorate-reflog ... --remotes
>
> Does it mean decorate remote reflogs, or does it mean exclude remotes
> from the selected revisions?
>
> Granted, there may be valid use cases for such a combination (e.g.
> "decorate all reflogs except remote ones") but I feel option order is
> not a good fit to express them.
>
Limiting the scope of the exclude seems somewhat reasonable to me,
because it makes it much easier to explain and show the user. We do
need to make sure it's not going to break any scripts or other issues.
Is it possible for us to produce an error if the user does "--exclude"
without a necessary connecting option?
Thanks,
Jake
^ permalink raw reply
* Re: git clone problem
From: Santiago Torres @ 2017-01-25 17:58 UTC (permalink / raw)
To: Jordi Durban; +Cc: git
In-Reply-To: <ef188364-ccd2-e7f5-3c06-62afca79f8d3@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1375 bytes --]
Hello, Jordi.
Hmm, it should've cloned in the "whatever" directory.
Can you post your git version/configs and maybe the output verbatim of
the command when you run it?
If you can reproduce in an empty dictionary that'd be better
$ mkdir test && cd test
$ git clone --recursive https://github.com/...
$ ls
Thanks,
-Santiago
On Wed, Jan 25, 2017 at 05:58:58PM +0100, Jordi Durban wrote:
> Hi all! Not sure if that will reach the goal, but let's it a try.
>
> I have a problem with the git clone command: when I try to clone a remote
> repository with the following:
>
> git clone --recursive https://github.com/whatever.git
>
> what I actually obtain is a copy of my own files in the current directory.
>
> I mean:
>
> In the current directory:
>
> $ls
>
> -rwxr-xr-x 1 1,6K oct 24 17:29 get_fasta.pl
> -rwxr-xr-x 1 1,6K set 5 13:05 script_clus_miRNA_c95.pl
>
> $git clone --recursive https://github.com/whatever.git WHATEVER
>
> $ls
>
> -rwxr-xr-x 1 1,6K oct 24 17:29 get_fasta.pl
> -rwxr-xr-x 1 1,6K set 5 13:05 script_clus_miRNA_c95.pl
>
> -rwxr-xr-x 1 1,6K set 5 13:05 WHATEVER
>
> $ls WHATEVER
>
> -rwxr-xr-x 1 1,6K oct 24 17:29 get_fasta.pl
> -rwxr-xr-x 1 1,6K set 5 13:05 script_clus_miRNA_c95.pl
>
> I am really confused with that.
>
> Any help will be appreciated. Thank you
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH] tag: add tag.createReflog option
From: Jeff King @ 2017-01-25 18:00 UTC (permalink / raw)
To: cornelius.weig; +Cc: git, novalis, pclouds
In-Reply-To: <20170125001906.13916-1-cornelius.weig@tngtech.com>
On Wed, Jan 25, 2017 at 01:19:06AM +0100, cornelius.weig@tngtech.com wrote:
> From: Cornelius Weig <cornelius.weig@tngtech.com>
>
> Git does not create a history for tags, in contrast to common
> expectation to simply version everything. This can be changed by using
> the `--create-reflog` flag when creating the tag. However, a config
> option to enable this behavior by default is missing.
Hmm, I didn't even know we had "tag --create-reflog". Looks like it was
added by 144c76fa39 (update-ref and tag: add --create-reflog arg,
2015-07-21).
IMHO it is a mistake. The "update-ref --create-reflog" variant makes
sense to me as a plumbing operation. But are there end users who want to
create a reflog for just _one_ tag?
As your patch shows, the more likely variant is "I want reflogs for all
tags". But that raises two questions with your patch:
- yours isn't "reflogs for all tags". It's "reflogs for tags I created
with git-tag". What about other operations that create tags, like
fetching (or even just a script that uses update-ref under the
hood).
IOW, instead of tag.createReflog, should this be tweaing
core.logallrefupdates to have a mode that includes tags?
- Is that the end of it, or is the desire really "I want reflogs for
_everything_"? That seems like a sane thing to want.
If so, then the update to core.logallrefupdates should turn it into
a tri-state:
- false; no reflogs
- true; reflogs for branches, remotes, notes, as now
- always; reflogs for all refs under "refs/"
I made a lot of suppositions about your desires there, so maybe you
really do want just tag.createReflog. But "core.logallrefupdates =
always" sounds a lot more useful to me.
-Peff
^ permalink raw reply
* Re: [PATCH] tag: add tag.createReflog option
From: Junio C Hamano @ 2017-01-25 18:10 UTC (permalink / raw)
To: Jeff King; +Cc: cornelius.weig, git, novalis, pclouds
In-Reply-To: <20170125180054.7mioop2o6uvqloyt@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> I made a lot of suppositions about your desires there, so maybe you
> really do want just tag.createReflog. But "core.logallrefupdates =
> always" sounds a lot more useful to me.
Thanks for saving me from typing exactly the same thing ;-)
^ permalink raw reply
* Re: What's cooking in git.git (Jan 2017, #04; Mon, 23)
From: Junio C Hamano @ 2017-01-25 18:16 UTC (permalink / raw)
To: Jeff King; +Cc: Johannes Schindelin, Lars Schneider, git
In-Reply-To: <20170125173958.pg546a6w33dirp5k@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Wed, Jan 25, 2017 at 06:01:11PM +0100, Johannes Schindelin wrote:
>
>> > Looks like "mv" prompts and then fails to move the file (so we get the
>> > dangling blob for the source blob, and fsck doesn't report failure
>> > because we didn't actually corrupt the destination blob).
>>
>> IIRC I had similar problems years ago, on a machine where the
>> administrator defined mandatory aliases, including mv="mv -i".
>
> Yeah, that was my first thought, too. But this should be a
> non-interactive shell, which would generally avoid loading rc files. I
> think there are some exceptions, though (e.g., setting ENV or BASH_ENV).
> Loading aliases like "mv -i" for non-interactive shells seems somewhat
> insane to me.
It does to me, too.
> But whatever the cause, I think the workaround I posted is
> easy enough to do.
Or spelling it explicitly as "/bin/mv" (forgetting systems that does
not have it in /bin but as /usr/bin/mv) would also defeat alias if
that were the cause.
One downside of working it around like your patch does, or spelling
it out as "/bin/mv", is that we'd need to worry about all the uses
of "mv" in our scripts. If this were _only_ happening in the Travis
environment, I'd prefer to see why it happens only there and fix that
instead.
^ permalink raw reply
* Re: [PATCH 01/12] for_each_alternate_ref: handle failure from real_pathdup()
From: Junio C Hamano @ 2017-01-25 18:26 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20170124003827.l2rimgitsyxsvtly@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> In older versions of git, if real_path() failed to resolve
> the alternate object store path, we would die() with an
> error. However, since 4ac9006f8 (real_path: have callers use
> real_pathdup and strbuf_realpath, 2016-12-12) we use the
> real_pathdup() function, which may return NULL. Since we
> don't check the return value, we can segfault.
>
> This is hard to trigger in practice, since we check that the
> path is accessible before creating the alternate_object_database
> struct. But it could be removed racily, or we could see a
> transient filesystem error.
>
> We could restore the original behavior by switching back to
> xstrdup(real_path()). However, dying is probably not the
> best option here. This whole function is best-effort
> already; there might not even be a repository around the
> shared objects at all. And if the alternate store has gone
> away, there are no objects to show.
>
> So let's just quietly return, as we would if we failed to
> open "refs/", or if upload-pack failed to start, etc.
That's sensible, methinks.
>
> Signed-off-by: Jeff King <peff@peff.net>
> ---
> transport.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/transport.c b/transport.c
> index c86ba2eb8..74d0e45bd 100644
> --- a/transport.c
> +++ b/transport.c
> @@ -1215,6 +1215,8 @@ static int refs_from_alternate_cb(struct alternate_object_database *e,
> struct alternate_refs_data *cb = data;
>
> other = real_pathdup(e->path);
> + if (!other)
> + return 0;
> len = strlen(other);
>
> while (other[len-1] == '/')
^ permalink raw reply
* Re: [PATCH 03/12] for_each_alternate_ref: use strbuf for path allocation
From: Junio C Hamano @ 2017-01-25 18:29 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20170124004038.njjevfku4v7kmnh4@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> We have a string with ".../objects" pointing to the
> alternate object store, and overwrite bits of it to look at
> other paths in the (potential) git repository holding it.
> This works because the only path we care about is "refs",
> which is shorter than "objects".
Yup, this was probably copied from a lazy original I wrote ;-)
Thanks for cleaning up.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox