* [PATCH v4 3/3] branch: Add an extra verbose output displaying worktree path for refs checked out in a linked worktree
From: nbelakovski @ 2018-12-24 8:47 UTC (permalink / raw)
To: git; +Cc: peff, rafa.almas, gitster, avarab, Nickolai Belakovski
In-Reply-To: <20181224084756.49952-1-nbelakovski@gmail.com>
From: Nickolai Belakovski <nbelakovski@gmail.com>
---
builtin/branch.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/builtin/branch.c b/builtin/branch.c
index 2a24153b78..56589a3684 100644
--- a/builtin/branch.c
+++ b/builtin/branch.c
@@ -366,6 +366,10 @@ static char *build_format(struct ref_filter *filter, int maxwidth, const char *r
strbuf_addstr(&local, branch_get_color(BRANCH_COLOR_RESET));
strbuf_addf(&local, " %s ", obname.buf);
+ if (filter->verbose > 2)
+ strbuf_addf(&local, "%s%%(if:notequals=*)%%(HEAD)%%(then)%%(if)%%(worktreepath)%%(then)%%(worktreepath) %%(end)%%(end)%s",
+ branch_get_color(BRANCH_COLOR_WORKTREE), branch_get_color(BRANCH_COLOR_RESET));
+
if (filter->verbose > 1)
strbuf_addf(&local, "%%(if)%%(upstream)%%(then)[%s%%(upstream:short)%s%%(if)%%(upstream:track)"
"%%(then): %%(upstream:track,nobracket)%%(end)] %%(end)%%(contents:subject)",
--
2.14.2
^ permalink raw reply related
* [PATCH v4 2/3] branch: Mark and color a branch differently if it is checked out in a linked worktree
From: nbelakovski @ 2018-12-24 8:47 UTC (permalink / raw)
To: git; +Cc: peff, rafa.almas, gitster, avarab, Nickolai Belakovski
In-Reply-To: <20181224084756.49952-1-nbelakovski@gmail.com>
From: Nickolai Belakovski <nbelakovski@gmail.com>
In order to more clearly display which branches are active, the output
of git branch is modified to mark branches checkout out in a linked
worktree with a "+" and color them in cyan (in contrast to the current
branch, which will still be denoted with a "*" and colored in green)
This is meant to simplify workflows related to worktree, particularly
due to the limitations of not being able to check out the same branch in
two worktrees and the inability to delete a branch checked out in a
worktree. When performing branch operations like checkout and delete, it
would be useful to know more readily if the branches in which the user
is interested are already checked out in a worktree.
The git worktree list command contains the relevant information, however
this is a much less frquently used command than git branch.
---
builtin/branch.c | 12 ++++++++----
t/t3200-branch.sh | 8 ++++----
t/t3203-branch-output.sh | 21 +++++++++++++++++++++
3 files changed, 33 insertions(+), 8 deletions(-)
diff --git a/builtin/branch.c b/builtin/branch.c
index 0c55f7f065..2a24153b78 100644
--- a/builtin/branch.c
+++ b/builtin/branch.c
@@ -47,6 +47,7 @@ static char branch_colors[][COLOR_MAXLEN] = {
GIT_COLOR_NORMAL, /* LOCAL */
GIT_COLOR_GREEN, /* CURRENT */
GIT_COLOR_BLUE, /* UPSTREAM */
+ GIT_COLOR_CYAN, /* WORKTREE */
};
enum color_branch {
BRANCH_COLOR_RESET = 0,
@@ -54,7 +55,8 @@ enum color_branch {
BRANCH_COLOR_REMOTE = 2,
BRANCH_COLOR_LOCAL = 3,
BRANCH_COLOR_CURRENT = 4,
- BRANCH_COLOR_UPSTREAM = 5
+ BRANCH_COLOR_UPSTREAM = 5,
+ BRANCH_COLOR_WORKTREE = 6
};
static const char *color_branch_slots[] = {
@@ -64,6 +66,7 @@ static const char *color_branch_slots[] = {
[BRANCH_COLOR_LOCAL] = "local",
[BRANCH_COLOR_CURRENT] = "current",
[BRANCH_COLOR_UPSTREAM] = "upstream",
+ [BRANCH_COLOR_WORKTREE] = "worktree",
};
static struct string_list output = STRING_LIST_INIT_DUP;
@@ -342,9 +345,10 @@ static char *build_format(struct ref_filter *filter, int maxwidth, const char *r
struct strbuf local = STRBUF_INIT;
struct strbuf remote = STRBUF_INIT;
- strbuf_addf(&local, "%%(if)%%(HEAD)%%(then)* %s%%(else) %s%%(end)",
- branch_get_color(BRANCH_COLOR_CURRENT),
- branch_get_color(BRANCH_COLOR_LOCAL));
+ strbuf_addf(&local, "%%(if)%%(HEAD)%%(then)* %s%%(else)%%(if)%%(worktreepath)%%(then)+ %s%%(else) %s%%(end)%%(end)",
+ branch_get_color(BRANCH_COLOR_CURRENT),
+ branch_get_color(BRANCH_COLOR_WORKTREE),
+ branch_get_color(BRANCH_COLOR_LOCAL));
strbuf_addf(&remote, " %s",
branch_get_color(BRANCH_COLOR_REMOTE));
diff --git a/t/t3200-branch.sh b/t/t3200-branch.sh
index 478b82cf9b..e404f6e23c 100755
--- a/t/t3200-branch.sh
+++ b/t/t3200-branch.sh
@@ -292,7 +292,7 @@ test_expect_success 'git branch --list -v with --abbrev' '
test_expect_success 'git branch --column' '
COLUMNS=81 git branch --column=column >actual &&
cat >expected <<\EOF &&
- a/b/c bam foo l * master n o/p r
+ a/b/c + bam foo l * master n o/p r
abc bar j/k m/m master2 o/o q
EOF
test_cmp expected actual
@@ -307,7 +307,7 @@ test_expect_success 'git branch --column with an extremely long branch name' '
cat >expected <<EOF &&
a/b/c
abc
- bam
++ bam
bar
foo
j/k
@@ -332,7 +332,7 @@ test_expect_success 'git branch with column.*' '
git config --unset column.branch &&
git config --unset column.ui &&
cat >expected <<\EOF &&
- a/b/c bam foo l * master n o/p r
+ a/b/c + bam foo l * master n o/p r
abc bar j/k m/m master2 o/o q
EOF
test_cmp expected actual
@@ -349,7 +349,7 @@ test_expect_success 'git branch -v with column.ui ignored' '
cat >expected <<\EOF &&
a/b/c
abc
- bam
++ bam
bar
foo
j/k
diff --git a/t/t3203-branch-output.sh b/t/t3203-branch-output.sh
index ee6787614c..94ab05ad59 100755
--- a/t/t3203-branch-output.sh
+++ b/t/t3203-branch-output.sh
@@ -240,6 +240,27 @@ test_expect_success 'git branch --format option' '
test_i18ncmp expect actual
'
+test_expect_success '"add" a worktree' '
+ mkdir worktree_dir &&
+ git worktree add -b master_worktree worktree_dir master
+'
+
+cat >expect <<'EOF'
+* <GREEN>(HEAD detached from fromtag)<RESET>
+ ambiguous<RESET>
+ branch-one<RESET>
+ branch-two<RESET>
+ master<RESET>
++ <CYAN>master_worktree<RESET>
+ ref-to-branch<RESET> -> branch-one
+ ref-to-remote<RESET> -> origin/branch-one
+EOF
+test_expect_success TTY 'worktree colors correct' '
+ test_terminal git branch >actual.raw &&
+ test_decode_color <actual.raw >actual &&
+ test_cmp expect actual
+'
+
test_expect_success "set up color tests" '
echo "<RED>master<RESET>" >expect.color &&
echo "master" >expect.bare &&
--
2.14.2
^ permalink raw reply related
* [PATCH v4 1/3] ref-filter: add worktreepath atom
From: nbelakovski @ 2018-12-24 8:47 UTC (permalink / raw)
To: git; +Cc: peff, rafa.almas, gitster, avarab, Nickolai Belakovski
In-Reply-To: <20181224084756.49952-1-nbelakovski@gmail.com>
From: Nickolai Belakovski <nbelakovski@gmail.com>
Add an atom providing the path of the linked worktree where this ref is
checked out, if it is checked out in any linked worktrees, and empty
string otherwise.
---
Documentation/git-for-each-ref.txt | 5 +++
ref-filter.c | 72 +++++++++++++++++++++++++++++++++++++-
t/t6302-for-each-ref-filter.sh | 15 ++++++++
3 files changed, 91 insertions(+), 1 deletion(-)
diff --git a/Documentation/git-for-each-ref.txt b/Documentation/git-for-each-ref.txt
index 901faef1bf..caba1c23b8 100644
--- a/Documentation/git-for-each-ref.txt
+++ b/Documentation/git-for-each-ref.txt
@@ -209,6 +209,11 @@ symref::
`:lstrip` and `:rstrip` options in the same way as `refname`
above.
+worktreepath::
+ The absolute path to the worktree in which the ref is checked
+ out, if it is checked out in any linked worktree. Empty string
+ otherwise.
+
In addition to the above, for commit and tag objects, the header
field names (`tree`, `parent`, `object`, `type`, and `tag`) can
be used to specify the value in the header field.
diff --git a/ref-filter.c b/ref-filter.c
index 5de616befe..240e7b80f8 100644
--- a/ref-filter.c
+++ b/ref-filter.c
@@ -20,6 +20,8 @@
#include "commit-slab.h"
#include "commit-graph.h"
#include "commit-reach.h"
+#include "worktree.h"
+#include "hashmap.h"
static struct ref_msg {
const char *gone;
@@ -34,6 +36,8 @@ static struct ref_msg {
"ahead %d, behind %d"
};
+static struct worktree **worktrees;
+
void setup_ref_filter_porcelain_msg(void)
{
msgs.gone = _("gone");
@@ -75,6 +79,11 @@ static struct expand_data {
struct object_info info;
} oi, oi_deref;
+struct ref_to_worktree_entry {
+ struct hashmap_entry ent; /* must be the first member! */
+ struct worktree *wt; /* key is wt->head_ref */
+};
+
/*
* An atom is a valid field atom listed below, possibly prefixed with
* a "*" to denote deref_tag().
@@ -116,7 +125,8 @@ static struct used_atom {
char *head;
} u;
} *used_atom;
-static int used_atom_cnt, need_tagged, need_symref;
+static int used_atom_cnt, need_tagged, need_symref, has_worktree;
+static struct hashmap ref_to_worktree_map;
/*
* Expand string, append it to strbuf *sb, then return error code ret.
@@ -420,6 +430,42 @@ static int head_atom_parser(const struct ref_format *format, struct used_atom *a
return 0;
}
+static int worktree_hashmap_cmpfnc(const void *unused_lookupdata, const void *existing_hashmap_entry_to_test,
+ const void *unused_key, const void *keydata_aka_refname)
+{
+ const struct ref_to_worktree_entry *e = existing_hashmap_entry_to_test;
+ return strcmp(e->wt->head_ref, keydata_aka_refname);
+}
+
+static int worktree_atom_parser(const struct ref_format *format,
+ struct used_atom *atom,
+ const char *arg,
+ struct strbuf *unused_err)
+{
+ int i;
+ if (has_worktree)
+ return 0;
+
+ worktrees = get_worktrees(0);
+
+ hashmap_init(&ref_to_worktree_map, worktree_hashmap_cmpfnc, NULL, 0);
+
+ for (i = 0; worktrees[i]; i++) {
+ if (worktrees[i]->head_ref) {
+ struct ref_to_worktree_entry *entry;
+ entry = xmalloc(sizeof(*entry));
+ entry->wt = worktrees[i];
+ hashmap_entry_init(entry, strhash(worktrees[i]->head_ref));
+
+ hashmap_add(&ref_to_worktree_map, entry);
+ }
+ }
+
+ has_worktree = 1;
+
+ return 0;
+}
+
static struct {
const char *name;
info_source source;
@@ -461,6 +507,7 @@ static struct {
{ "flag", SOURCE_NONE },
{ "HEAD", SOURCE_NONE, FIELD_STR, head_atom_parser },
{ "color", SOURCE_NONE, FIELD_STR, color_atom_parser },
+ { "worktreepath", SOURCE_NONE, FIELD_STR, worktree_atom_parser },
{ "align", SOURCE_NONE, FIELD_STR, align_atom_parser },
{ "end", SOURCE_NONE },
{ "if", SOURCE_NONE, FIELD_STR, if_atom_parser },
@@ -1500,6 +1547,20 @@ static int get_object(struct ref_array_item *ref, int deref, struct object **obj
return 0;
}
+static const char *get_worktree_path(const struct used_atom *atom, const struct ref_array_item *ref)
+{
+ struct strbuf val = STRBUF_INIT;
+ struct hashmap_entry entry;
+ struct ref_to_worktree_entry *lookup_result;
+
+ hashmap_entry_init(&entry, strhash(ref->refname));
+ lookup_result = hashmap_get(&ref_to_worktree_map, &entry, ref->refname);
+
+ strbuf_addstr(&val, lookup_result ? lookup_result->wt->path : "");
+
+ return strbuf_detach(&val, NULL);
+}
+
/*
* Parse the object referred by ref, and grab needed value.
*/
@@ -1537,6 +1598,10 @@ static int populate_value(struct ref_array_item *ref, struct strbuf *err)
if (starts_with(name, "refname"))
refname = get_refname(atom, ref);
+ else if (starts_with(name, "worktreepath")) {
+ v->s = get_worktree_path(atom, ref);
+ continue;
+ }
else if (starts_with(name, "symref"))
refname = get_symref(atom, ref);
else if (starts_with(name, "upstream")) {
@@ -2020,6 +2085,11 @@ void ref_array_clear(struct ref_array *array)
free_array_item(array->items[i]);
FREE_AND_NULL(array->items);
array->nr = array->alloc = 0;
+ if (has_worktree)
+ {
+ hashmap_free(&ref_to_worktree_map, 1);
+ free_worktrees(worktrees);
+ }
}
static void do_merge_filter(struct ref_filter_cbdata *ref_cbdata)
diff --git a/t/t6302-for-each-ref-filter.sh b/t/t6302-for-each-ref-filter.sh
index fc067ed672..d70517a6ae 100755
--- a/t/t6302-for-each-ref-filter.sh
+++ b/t/t6302-for-each-ref-filter.sh
@@ -441,4 +441,19 @@ test_expect_success '--merged is incompatible with --no-merged' '
test_must_fail git for-each-ref --merged HEAD --no-merged HEAD
'
+test_expect_success '"add" a worktree' '
+ mkdir worktree_dir &&
+ git worktree add -b master_worktree worktree_dir master
+'
+
+test_expect_success 'validate worktree atom' '
+ {
+ echo master: $PWD &&
+ echo master_worktree: $PWD/worktree_dir &&
+ echo side: not checked out
+ } > expect &&
+ git for-each-ref --format="%(refname:short): %(if)%(worktreepath)%(then)%(worktreepath)%(else)not checked out%(end)" refs/heads/ >actual &&
+ test_cmp expect actual
+'
+
test_done
--
2.14.2
^ permalink raw reply related
* [PATCH v4 0/3]
From: nbelakovski @ 2018-12-24 8:47 UTC (permalink / raw)
To: git; +Cc: peff, rafa.almas, gitster, avarab, Nickolai Belakovski
In-Reply-To: <20181220145931.GB27361@sigill.intra.peff.net>
From: Nickolai Belakovski <nbelakovski@gmail.com>
> I don't think that works. The default function is always_equal(), which
> will treat two entries equal if they have the same hash value. I.e., any
> collisions would be considered a match.
You're absolutely right. I've added a compare function, but I left out the
functionality for it to work with an entry passed in as a key. Doing so would
mean the user would have to allocate a worktree struct, which just seems silly
when the ref is all that's needed (and also defeats the purpose of avoiding
extra allocations).
And while most of the hashmap API seems OK, yea, this is definitely awful. It
feels like it should just be able to take a key and return either an entry or
NULL, and do away with entry_or_key and equals_function_data.
Travis-CI results: https://travis-ci.org/nbelakovski/git/builds/471787317
Nickolai Belakovski (3):
ref-filter: add worktreepath atom
branch: Mark and color a branch differently if it is checked out in a
linked worktree
branch: Add an extra verbose output displaying worktree path for refs
checked out in a linked worktree
Documentation/git-for-each-ref.txt | 5 +++
builtin/branch.c | 16 ++++++---
ref-filter.c | 72 +++++++++++++++++++++++++++++++++++++-
t/t3200-branch.sh | 8 ++---
t/t3203-branch-output.sh | 21 +++++++++++
t/t6302-for-each-ref-filter.sh | 15 ++++++++
6 files changed, 128 insertions(+), 9 deletions(-)
--
2.14.2
^ permalink raw reply
* Re: [PATCH v2] sha1-name.c: Fix handling of revisions that contain paths with brackets
From: Duy Nguyen @ 2018-12-24 8:06 UTC (permalink / raw)
To: Stan Hu; +Cc: git
In-Reply-To: <20181223234058.5834-1-stanhu@gmail.com>
On Sun, Dec 23, 2018 at 11:40:59PM +0000, Stan Hu wrote:
> Previously, calling ls-tree with a revision such as
> `master^{tree}:foo/{{path}}` would show the root tree instead of the
> correct tree pointed by foo/{{path}}. If a colon is present in the revision
> name, peel_onion() should assume that the presence of a bracket
> at the end of the string belongs to the filename.
>
> Signed-off-by: Stan Hu <stanhu@gmail.com>
> ---
> sha1-name.c | 14 +++++++++++++-
> t/t3104-ls-tree-braces.sh | 30 ++++++++++++++++++++++++++++++
> 2 files changed, 43 insertions(+), 1 deletion(-)
> create mode 100755 t/t3104-ls-tree-braces.sh
>
> diff --git a/sha1-name.c b/sha1-name.c
> index faa60f69e3..588b7a53cc 100644
> --- a/sha1-name.c
> +++ b/sha1-name.c
> @@ -1001,9 +1001,21 @@ static int peel_onion(const char *name, int len, struct object_id *oid,
> * "ref^{commit}". "commit^{tree}" could be used to find the
> * top-level tree of the given commit.
> */
> - if (len < 4 || name[len-1] != '}')
> + if (len < 4)
> return -1;
>
> + /* Check for names in ref:path format in case the path includes
> + * brackets (e.g. ref^{type}:foo/{{bar}}).
> + */
> + for (sp = name; sp < name + len; sp++) {
> + if (*sp == ':')
> + return -1;
> + }
> +
> + if (name[len-1] != '}') {
> + return -1;
> + }
Instead of replacing one loose check (find '}' at the end) with
another one, how about tighten the parsing? peel_onion() is supposed
to consume all "len" characters or none so checking something like
this may be better.
Note that it also shows another corner case we need to be careful
about: master^{/regex} syntax _can_ contain colons in regex. I suppose
doing strchr to find the closing '}' here is better than what I did
below.
--8<--
diff --git a/sha1-name.c b/sha1-name.c
index faa60f69e3..c9e26206ce 100644
--- a/sha1-name.c
+++ b/sha1-name.c
@@ -989,7 +989,7 @@ static int peel_onion(const char *name, int len, struct object_id *oid,
unsigned lookup_flags)
{
struct object_id outer;
- const char *sp;
+ const char *sp, *end;
unsigned int expected_type = 0;
struct object *o;
@@ -1013,21 +1013,26 @@ static int peel_onion(const char *name, int len, struct object_id *oid,
return -1;
sp++; /* beginning of type name, or closing brace for empty */
- if (starts_with(sp, "commit}"))
+ if (skip_prefix(sp, "commit}", &end))
expected_type = OBJ_COMMIT;
- else if (starts_with(sp, "tag}"))
+ else if (skip_prefix(sp, "tag}", &end))
expected_type = OBJ_TAG;
- else if (starts_with(sp, "tree}"))
+ else if (skip_prefix(sp, "tree}", &end))
expected_type = OBJ_TREE;
- else if (starts_with(sp, "blob}"))
+ else if (skip_prefix(sp, "blob}", &end))
expected_type = OBJ_BLOB;
- else if (starts_with(sp, "object}"))
+ else if (skip_prefix(sp, "object}", &end))
expected_type = OBJ_ANY;
- else if (sp[0] == '}')
+ else if (sp[0] == '}') {
expected_type = OBJ_NONE;
- else if (sp[0] == '/')
+ end = sp + 1;
+ } else if (sp[0] == '/') {
expected_type = OBJ_COMMIT;
- else
+ end = name + len;
+ } else
+ return -1;
+
+ if (end != name + len)
return -1;
lookup_flags &= ~GET_OID_DISAMBIGUATORS;
--8<--
--
Duy
^ permalink raw reply related
* Re: Can git choose perl at runtime?
From: brian m. carlson @ 2018-12-24 2:20 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason; +Cc: John Passaro, git
In-Reply-To: <87wonzes23.fsf@evledraar.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1057 bytes --]
On Mon, Dec 24, 2018 at 12:34:12AM +0100, Ævar Arnfjörð Bjarmason wrote:
> Yeah, but my reading (which may be wrong) of John Passaro's E-Mail
> upthread
> (<CAJdN7Kioa22xrDP2ssZXmBbu7KDkcr2MQCUDW=Tzm5ydzeChBQ@mail.gmail.com>)
> is that for some users this is the path of least resistance to getting
> git-send-email et al working for whatever reason.
I think we should just ask Homebrew to ship a functional, complete Git.
If they need to use the Homebrew Perl to install modules instead of the
system Perl, then they should do that. It sounds like we're engineering
a feature that lets users shoot themselves in the foot to work around an
easily fixable distributor issue.
I'm sympathetic to the difficult job of distributors, but Git is not an
unreasonable upstream, and I don't think it's unfair to ask Homebrew to
solve this problem in their distribution.
I've commented on the issue on their GitHub repository, asking them to
address this problem.
--
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 868 bytes --]
^ permalink raw reply
* Re: Referring to commits in commit messages
From: Jacob Keller @ 2018-12-24 0:01 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Duy Nguyen, Ævar Arnfjörð Bjarmason,
Git Mailing List, Han-Wen Nienhuys, Johannes Schindelin
In-Reply-To: <20181219221401.GC228469@google.com>
On Wed, Dec 19, 2018 at 2:36 PM Jonathan Nieder <jrnieder@gmail.com> wrote:
> In Linux kernel land, Documentation/process/submitting-patches.rst
> contains the following:
>
> -- >8 --
> If your patch fixes a bug in a specific commit, e.g. you found an issue using
> ``git bisect``, please use the 'Fixes:' tag with the first 12 characters of
> the SHA-1 ID, and the one line summary. For example::
>
> Fixes: e21d2170f366 ("video: remove unnecessary platform_set_drvdata()")
>
> The following ``git config`` settings can be used to add a pretty format for
> outputting the above style in the ``git log`` or ``git show`` commands::
>
> [core]
> abbrev = 12
> [pretty]
> fixes = Fixes: %h (\"%s\")
> -- 8< --
>
> I like it because (1) the semantics are clear, (2) it's very concrete
> (e.g. "first 12 characters", (3) it goes in a trailer, where other
> bits intended for machine consumption already go.
>
For what it's worth, Linux's checkpatch.pl script also checks for and
enforces that commit references have this format.
I personally like having the date information, and have attempted to
get checkpatch.pl to stop complaining about the date when it's
included. (see https://patchwork.ozlabs.org/patch/821543/ for the
patch that I've had up, we've been trying to get the maintainer of
checkpatch.pl to notice and pull it in, but not very much success as
of yet).
I'd prefer to keep the format as seen on this list fairly often which
is the something like
show --pretty=%h (\"%s\", %ad) --date=short
or
show --pretty=%h (\"%s\", %cd) --date=short
I like the date since it gives a quick approximation of how long ago
the commit was made, and helps in the rare case of disambiguation.
Personally I also like the quotes since it makes it more obvious where
the subject begins and ends. They aren't strictly necessary but aid
readability to me.
Thanks,
Jake
^ permalink raw reply
* [PATCH v2] sha1-name.c: Fix handling of revisions that contain paths with brackets
From: Stan Hu @ 2018-12-23 23:40 UTC (permalink / raw)
To: git, stanhu
In-Reply-To: <20181223233736.10306-1-stanhu@gmail.com>
Previously, calling ls-tree with a revision such as
`master^{tree}:foo/{{path}}` would show the root tree instead of the
correct tree pointed by foo/{{path}}. If a colon is present in the revision
name, peel_onion() should assume that the presence of a bracket
at the end of the string belongs to the filename.
Signed-off-by: Stan Hu <stanhu@gmail.com>
---
sha1-name.c | 14 +++++++++++++-
t/t3104-ls-tree-braces.sh | 30 ++++++++++++++++++++++++++++++
2 files changed, 43 insertions(+), 1 deletion(-)
create mode 100755 t/t3104-ls-tree-braces.sh
diff --git a/sha1-name.c b/sha1-name.c
index faa60f69e3..588b7a53cc 100644
--- a/sha1-name.c
+++ b/sha1-name.c
@@ -1001,9 +1001,21 @@ static int peel_onion(const char *name, int len, struct object_id *oid,
* "ref^{commit}". "commit^{tree}" could be used to find the
* top-level tree of the given commit.
*/
- if (len < 4 || name[len-1] != '}')
+ if (len < 4)
return -1;
+ /* Check for names in ref:path format in case the path includes
+ * brackets (e.g. ref^{type}:foo/{{bar}}).
+ */
+ for (sp = name; sp < name + len; sp++) {
+ if (*sp == ':')
+ return -1;
+ }
+
+ if (name[len-1] != '}') {
+ return -1;
+ }
+
for (sp = name + len - 1; name <= sp; sp--) {
int ch = *sp;
if (ch == '{' && name < sp && sp[-1] == '^')
diff --git a/t/t3104-ls-tree-braces.sh b/t/t3104-ls-tree-braces.sh
new file mode 100755
index 0000000000..3ead86c4fe
--- /dev/null
+++ b/t/t3104-ls-tree-braces.sh
@@ -0,0 +1,30 @@
+#!/bin/sh
+
+test_description='ls-tree with a folder with braces'
+
+. ./test-lib.sh
+
+test_expect_success 'setup' '
+ mkdir -p "newdir/{{curly}}" &&
+ touch "newdir/{{curly}}/one" &&
+ git add "newdir/{{curly}}/one" &&
+ git commit -m test
+'
+
+test_expect_success 'ls-tree with curly brace folder' '
+ cat >expect <<-EOF &&
+ 100644 blob $EMPTY_BLOB one
+ EOF
+ git ls-tree -r "HEAD:newdir/{{curly}}" >actual &&
+ test_cmp expect actual
+'
+
+test_expect_success 'ls-tree with type restriction and curly brace folder' '
+ cat >expect <<-EOF &&
+ 100644 blob $EMPTY_BLOB one
+ EOF
+ git ls-tree "HEAD^{tree}:newdir/{{curly}}" >actual &&
+ test_cmp expect actual
+'
+
+test_done
--
2.19.0
^ permalink raw reply related
* [PATCH] sha1-name.c: Fix handling of revisions that contain paths with brackets
From: Stan Hu @ 2018-12-23 23:37 UTC (permalink / raw)
To: git, stanhu
In-Reply-To: <20181223232716.6339-1-stanhu@gmail.com>
Previously, calling ls-tree with a revision such as
`master^{tree}:foo/{{path}}` would show the root tree instead of the
correct tree pointed by foo/{{path}}. If a colon is present in the revision
name, peel_onion() should assume that the presence of a bracket
at the end of the string belongs to the filename.
Signed-off-by: Stan Hu <stanhu@gmail.com>
---
sha1-name.c | 14 +++++++++++++-
t/t3104-ls-tree-braces.sh | 30 ++++++++++++++++++++++++++++++
2 files changed, 43 insertions(+), 1 deletion(-)
create mode 100644 t/t3104-ls-tree-braces.sh
diff --git a/sha1-name.c b/sha1-name.c
index faa60f69e3..69ecf0a26c 100644
--- a/sha1-name.c
+++ b/sha1-name.c
@@ -1001,9 +1001,21 @@ static int peel_onion(const char *name, int len, struct object_id *oid,
* "ref^{commit}". "commit^{tree}" could be used to find the
* top-level tree of the given commit.
*/
- if (len < 4 || name[len-1] != '}')
+ if (len < 4)
return -1;
+ /* Check for names in ref:path format in case the path includes
+ * brackets (e.g. ref^{type}:foo/{{bar}}).
+ */
+ for (sp = name; sp < name + len; sp++) {
+ if (*sp == ':')
+ return -1;
+ }
+
+ if (sp == name && name[len-1] != '}') {
+ return -1;
+ }
+
for (sp = name + len - 1; name <= sp; sp--) {
int ch = *sp;
if (ch == '{' && name < sp && sp[-1] == '^')
diff --git a/t/t3104-ls-tree-braces.sh b/t/t3104-ls-tree-braces.sh
new file mode 100644
index 0000000000..3ead86c4fe
--- /dev/null
+++ b/t/t3104-ls-tree-braces.sh
@@ -0,0 +1,30 @@
+#!/bin/sh
+
+test_description='ls-tree with a folder with braces'
+
+. ./test-lib.sh
+
+test_expect_success 'setup' '
+ mkdir -p "newdir/{{curly}}" &&
+ touch "newdir/{{curly}}/one" &&
+ git add "newdir/{{curly}}/one" &&
+ git commit -m test
+'
+
+test_expect_success 'ls-tree with curly brace folder' '
+ cat >expect <<-EOF &&
+ 100644 blob $EMPTY_BLOB one
+ EOF
+ git ls-tree -r "HEAD:newdir/{{curly}}" >actual &&
+ test_cmp expect actual
+'
+
+test_expect_success 'ls-tree with type restriction and curly brace folder' '
+ cat >expect <<-EOF &&
+ 100644 blob $EMPTY_BLOB one
+ EOF
+ git ls-tree "HEAD^{tree}:newdir/{{curly}}" >actual &&
+ test_cmp expect actual
+'
+
+test_done
--
2.19.0
^ permalink raw reply related
* Re: Can git choose perl at runtime?
From: Ævar Arnfjörð Bjarmason @ 2018-12-23 23:34 UTC (permalink / raw)
To: brian m. carlson; +Cc: John Passaro, git
In-Reply-To: <20181223231834.GD26554@genre.crustytoothpaste.net>
On Sun, Dec 23 2018, brian m. carlson wrote:
> On Sun, Dec 23, 2018 at 11:05:46PM +0100, Ævar Arnfjörð Bjarmason wrote:
>>
>> On Fri, Dec 21 2018, brian m. carlson wrote:
>> > How do git send-email and git svn work in such a case? They depend on
>> > the Git and Git::SVN modules being in place, so if you use a Perl other
>> > than the one you built Git with, they won't be present (or they'll be
>> > present, but potentially with the wrong version).
>>
>> Yeah this is one of the things I was alluding to in
>> <87a7l1fx8x.fsf@evledraar.gmail.com>.
>>
>> We don't ship any C bindings, so our libs end up in
>> e.g. /usr/share/perl5, some custom-built perls will have that in their
>> @INC still, no idea if any of this OSX stuff does.
>>
>> But otherwise we'd either need to give the user a way to override
>> PERL5LIB (or they can do it themselves...), or better yet continue what
>> I started in 20d2a30f8f ("Makefile: replace perl/Makefile.PL with simple
>> make rules", 2017-12-10) and make our perl stuff entirely decoupled from
>> the system install.
>>
>> E.g. Linux distros would probably still override that and install our
>> *.pm stuff in their usual Perl places, but by default we could just have
>> a libexec/perl directory with all this stuff, and find our libraries
>> there, then it won't matter if we chainload to a new Perl interpreter,
>> we'll still find the libs in the same place.
>
> This wouldn't fix the fact that we still need modules like Net::SMTP,
> Authen::SASL, and IO::Socket::SSL (because these days every provider
> forces TLS on the submission port). Since those are going to come from
> the distributor, letting people override the Perl path to some arbitrary
> path will mean that those modules may not be installed.
Yeah, but my reading (which may be wrong) of John Passaro's E-Mail
upthread
(<CAJdN7Kioa22xrDP2ssZXmBbu7KDkcr2MQCUDW=Tzm5ydzeChBQ@mail.gmail.com>)
is that for some users this is the path of least resistance to getting
git-send-email et al working for whatever reason.
I.e. they'd like to install a git version that's compiled against
/usr/bin/perl, and then after the fact ask git to point to some other
better working perl installation with all of the above compiled.
> I also think that the situation you want with relocatable modules is
> only going to be useful for people who custom-install their own Git,
> which is not most people. Nobody shipping a packaged version of Git is
> going to install modules in a custom Git-specific path (since they can't
> be loaded by other software), so everyone who want to use a custom Perl
> will already be compiling a custom Git and can just specify the Perl
> they want to use.
I mean that we could just make RUNTIME_PREFIX our default behavior, it
would simplify things by only carrying one "how do we find stuff" mode,
and in this case nicely solve this whole problem of your custom perl not
having git's perl modules in its @INC (but having everything else,
e.g. Authen::SASL available).
> My concern is, more generally, that this situation is going to lead to
> hard-to-troubleshoot user support issues. I routinely answer questions
> on Stack Overflow and I see all sorts of cases where users who may be
> great programmers but are mostly unfamiliar with Git end up in bad
> situations.
>
> For example, at a previous job, we shipped a newer Git and Perl, which
> were installed in a custom path (so definitely not using relocatable
> modules). If this option were enabled and user used the newer Git, which
> was installed in a custom path, but the system Perl, things would
> definitely be broken, since the system Perl would almost certainly have
> none of the right modules (or, if it did, they'd be grossly out of
> date). A lot of the users who would run into this issue are less
> technical, and so wouldn't know how to fix it.
No comment on this other than: "whoever's itch this actually is and who
picks up my POC patch will need to address this to brian's satisfaction"
:)
> We've traditionally shied away from specifying things like
> "#!/usr/bin/env perl" specifically for this reason: because people will
> often have custom-compiled versions of interpreters that don't meet our
> needs. I'm not seeing how this is significantly different.
Because "#!/usr/bin/env perl" would break git if you were just playing
around with a custom perl for some other reason, e.g. perl web
development. I agree that this wouldn't be acceptable (as see in my
https://public-inbox.org/git/878t55qga6.fsf@evledraar.gmail.com/ that
John linked to).
Whereas what's being proposed here is some way to specifically tell git
via configuration that it should use a runtime configured perl instead
of the compile-time one.
^ permalink raw reply
* [PATCH] sha1-name.c: Fix handling of revisions that contain paths with brackets
From: Stan Hu @ 2018-12-23 23:27 UTC (permalink / raw)
To: git, stanhu
Previously, calling ls-tree with a revision such as
`master^{tree}:foo/{{path}}` would show the root tree instead of the
correct tree pointed by foo/{{path}}. If a colon is present in the revision
name, peel_onion() should assume that the presence of a bracket
at the end of the string belongs to the filename.
Signed-off-by: Stan Hu <stanhu@gmail.com>
---
sha1-name.c | 14 +++++++++++++-
t/t3104-ls-tree-braces.sh | 30 ++++++++++++++++++++++++++++++
2 files changed, 43 insertions(+), 1 deletion(-)
create mode 100644 t/t3104-ls-tree-braces.sh
diff --git a/sha1-name.c b/sha1-name.c
index faa60f69e3..69ecf0a26c 100644
--- a/sha1-name.c
+++ b/sha1-name.c
@@ -1001,9 +1001,21 @@ static int peel_onion(const char *name, int len, struct object_id *oid,
* "ref^{commit}". "commit^{tree}" could be used to find the
* top-level tree of the given commit.
*/
- if (len < 4 || name[len-1] != '}')
+ if (len < 4)
return -1;
+ /* Check for names in ref:path format in case the path includes
+ * brackets (e.g. ref^{type}:foo/{{bar}}).
+ */
+ for (sp = name; sp < name + len; sp++) {
+ if (*sp == ':')
+ return -1;
+ }
+
+ if (sp == name && name[len-1] != '}') {
+ return -1;
+ }
+
for (sp = name + len - 1; name <= sp; sp--) {
int ch = *sp;
if (ch == '{' && name < sp && sp[-1] == '^')
diff --git a/t/t3104-ls-tree-braces.sh b/t/t3104-ls-tree-braces.sh
new file mode 100644
index 0000000000..3ead86c4fe
--- /dev/null
+++ b/t/t3104-ls-tree-braces.sh
@@ -0,0 +1,30 @@
+#!/bin/sh
+
+test_description='ls-tree with a folder with braces'
+
+. ./test-lib.sh
+
+test_expect_success 'setup' '
+ mkdir -p "newdir/{{curly}}" &&
+ touch "newdir/{{curly}}/one" &&
+ git add "newdir/{{curly}}/one" &&
+ git commit -m test
+'
+
+test_expect_success 'ls-tree with curly brace folder' '
+ cat >expect <<-EOF &&
+ 100644 blob $EMPTY_BLOB one
+ EOF
+ git ls-tree -r "HEAD:newdir/{{curly}}" >actual &&
+ test_cmp expect actual
+'
+
+test_expect_success 'ls-tree with type restriction and curly brace folder' '
+ cat >expect <<-EOF &&
+ 100644 blob $EMPTY_BLOB one
+ EOF
+ git ls-tree "HEAD^{tree}:newdir/{{curly}}" >actual &&
+ test_cmp expect actual
+'
+
+test_done
--
2.19.1
^ permalink raw reply related
* Re: Can git choose perl at runtime?
From: brian m. carlson @ 2018-12-23 23:18 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason; +Cc: John Passaro, git
In-Reply-To: <87y38few5h.fsf@evledraar.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3349 bytes --]
On Sun, Dec 23, 2018 at 11:05:46PM +0100, Ævar Arnfjörð Bjarmason wrote:
>
> On Fri, Dec 21 2018, brian m. carlson wrote:
> > How do git send-email and git svn work in such a case? They depend on
> > the Git and Git::SVN modules being in place, so if you use a Perl other
> > than the one you built Git with, they won't be present (or they'll be
> > present, but potentially with the wrong version).
>
> Yeah this is one of the things I was alluding to in
> <87a7l1fx8x.fsf@evledraar.gmail.com>.
>
> We don't ship any C bindings, so our libs end up in
> e.g. /usr/share/perl5, some custom-built perls will have that in their
> @INC still, no idea if any of this OSX stuff does.
>
> But otherwise we'd either need to give the user a way to override
> PERL5LIB (or they can do it themselves...), or better yet continue what
> I started in 20d2a30f8f ("Makefile: replace perl/Makefile.PL with simple
> make rules", 2017-12-10) and make our perl stuff entirely decoupled from
> the system install.
>
> E.g. Linux distros would probably still override that and install our
> *.pm stuff in their usual Perl places, but by default we could just have
> a libexec/perl directory with all this stuff, and find our libraries
> there, then it won't matter if we chainload to a new Perl interpreter,
> we'll still find the libs in the same place.
This wouldn't fix the fact that we still need modules like Net::SMTP,
Authen::SASL, and IO::Socket::SSL (because these days every provider
forces TLS on the submission port). Since those are going to come from
the distributor, letting people override the Perl path to some arbitrary
path will mean that those modules may not be installed.
I also think that the situation you want with relocatable modules is
only going to be useful for people who custom-install their own Git,
which is not most people. Nobody shipping a packaged version of Git is
going to install modules in a custom Git-specific path (since they can't
be loaded by other software), so everyone who want to use a custom Perl
will already be compiling a custom Git and can just specify the Perl
they want to use.
My concern is, more generally, that this situation is going to lead to
hard-to-troubleshoot user support issues. I routinely answer questions
on Stack Overflow and I see all sorts of cases where users who may be
great programmers but are mostly unfamiliar with Git end up in bad
situations.
For example, at a previous job, we shipped a newer Git and Perl, which
were installed in a custom path (so definitely not using relocatable
modules). If this option were enabled and user used the newer Git, which
was installed in a custom path, but the system Perl, things would
definitely be broken, since the system Perl would almost certainly have
none of the right modules (or, if it did, they'd be grossly out of
date). A lot of the users who would run into this issue are less
technical, and so wouldn't know how to fix it.
We've traditionally shied away from specifying things like
"#!/usr/bin/env perl" specifically for this reason: because people will
often have custom-compiled versions of interpreters that don't meet our
needs. I'm not seeing how this is significantly different.
--
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 868 bytes --]
^ permalink raw reply
* Parsing trailers
From: William Chargin @ 2018-12-23 22:41 UTC (permalink / raw)
To: Git Mailing List
I'm interested in parsing the output of `git-interpret-trailers` in a
script. I had hoped that the `--parse` option would make this easy, but
it seems that the `trailer.separators` configuration option is used to
specify both the input format (which separators may indicate a trailer)
and the output format of `git interpret-trailers --parse`. Given that
`trailer.separators` may contain any (non-NUL) characters, including
whitespace, parsing the output is not straightforward.
Here's what I've come up with. The output format is "<tok><sep> <val>",
where "<tok>" and "<val>" have been trimmed and so have no leading or
trailing whitespace, but "<val>" may have internal whitespace while
"<tok>" may not. Thus, the first space character in the output may
correspond to either "<sep>" or the fixed space, but we should be able
to determine which is the case: the first space is immediately followed
by a second space if and only if the first space corresponds to "<sep>".
Assuming that the above analysis is correct, the following procedure
should suffice to safely parse the output:
- Let `i` be the index of the first space in `s`.
- If `s[i+1]` is a space, let `sep_pos` be `i`. Otherwise, let
`sep_pos` be `i - 1`.
- The substring `s[:sep_pos]` is the token.
- The character at index `sep_pos` is the separator.
- The character at index `sep_pos + 1` is the fixed space.
- The substring `s[sep_pos+2:nl]` is the value, where `nl` is the
index of the first newline in `s` after `sep_pos`.
(It seems unfortunately complicated when all we want to do is parse the
output of `--parse`, but I don't see a better approach!)
My questions:
- Is this accurate?
- Is this algorithm guaranteed to remain correct in future versions of
Git?
- Is there a simpler way to extract the token-value pairs from a
commit message string?
Would appreciate any advice.
Thanks!
WC
^ permalink raw reply
* Re: Can git choose perl at runtime?
From: Ævar Arnfjörð Bjarmason @ 2018-12-23 22:05 UTC (permalink / raw)
To: brian m. carlson; +Cc: John Passaro, git
In-Reply-To: <20181221234231.GB10611@genre.crustytoothpaste.net>
On Fri, Dec 21 2018, brian m. carlson wrote:
> On Tue, Dec 18, 2018 at 10:09:14PM -0500, John Passaro wrote:
>> I recently submitted my first patch using OSX and found the experience
>> frustrating, for reasons that have come up on the list before,
>> concerning git-send-email and perl dependencies that you need to be
>> root to update.
>>
>> Last seen here:
>> https://public-inbox.org/git/878t55qga6.fsf@evledraar.gmail.com/
>>
>> The struggle is that Mac's package manager Homebrew has opted,
>> apparently with some finality, to no longer support linking to a user
>> perl at build time. PERL_PATH is hard-coded to link to the system
>> perl, which means the user needs sudo to install the SSL libraries
>> required for send-email. So for send-email to work, you need to either
>> sudo cpan or build git yourself. The obvious solution here would be to
>> do /usr/bin/env perl, but in the above message Aevar pointed out
>> pitfalls with that.
>>
>> It seems that choosing perl at compile time necessarily comes with
>> tradeoffs. So I wonder if there is a way we can support choosing a
>> perl at runtime without breaking the existing mechanism of linking to
>> perl at compile time.
>>
>> I'm picturing adding an executable "git-perl" to libexec that checks
>> config core.perlPath and envvar GIT_PERL_PATH, in some order. Having
>> chosen one of these or the build-time PERL_PATH as a last resort, it
>> exec's the correct perl executable.
>>
>> Then relevant scripts (e.g. git-add--interactive, git-send-email)
>> invoke git-perl instead of /usr/bin/perl, and the makefile no longer
>> replaces that with PERL_PATH -- instead that will be used at runtime
>> via git-perl when we can be sure the user does not explicitly prefer
>> something different.
>
> How do git send-email and git svn work in such a case? They depend on
> the Git and Git::SVN modules being in place, so if you use a Perl other
> than the one you built Git with, they won't be present (or they'll be
> present, but potentially with the wrong version).
Yeah this is one of the things I was alluding to in
<87a7l1fx8x.fsf@evledraar.gmail.com>.
We don't ship any C bindings, so our libs end up in
e.g. /usr/share/perl5, some custom-built perls will have that in their
@INC still, no idea if any of this OSX stuff does.
But otherwise we'd either need to give the user a way to override
PERL5LIB (or they can do it themselves...), or better yet continue what
I started in 20d2a30f8f ("Makefile: replace perl/Makefile.PL with simple
make rules", 2017-12-10) and make our perl stuff entirely decoupled from
the system install.
E.g. Linux distros would probably still override that and install our
*.pm stuff in their usual Perl places, but by default we could just have
a libexec/perl directory with all this stuff, and find our libraries
there, then it won't matter if we chainload to a new Perl interpreter,
we'll still find the libs in the same place.
We could also turn RUNTIME_PREFIX on by default, it already fixes this
by proxy.
^ permalink raw reply
* [PATCH] doc/config: do a better job of introducing 'worktree.guessRemote'
From: Eric Sunshine @ 2018-12-23 19:24 UTC (permalink / raw)
To: git
Cc: Олег Самойлов,
Thomas Gummerer, Eric Sunshine
The documentation for this option jumps right in with "With `add`",
without explaining that `add` is a sub-command of "git worktree".
Together with rather odd grammatical structure of the remainder of the
sentence, the description can be difficult for newcomers to understand.
Clarify by improving the grammar and mentioning "git worktree add"
explicitly.
Reported-by: Олег Самойлов <splarv@ya.ru>
Signed-off-by: Eric Sunshine <sunshine@sunshineco.com>
---
Reference: https://public-inbox.org/git/0E640233-B2CB-465D-9713-BBECE331CA80@ya.ru/
Documentation/config/worktree.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/config/worktree.txt b/Documentation/config/worktree.txt
index b853798fc2..048e349482 100644
--- a/Documentation/config/worktree.txt
+++ b/Documentation/config/worktree.txt
@@ -1,6 +1,6 @@
worktree.guessRemote::
- With `add`, if no branch argument, and neither of `-b` nor
- `-B` nor `--detach` are given, the command defaults to
+ If no branch is specified and neither `-b` nor `-B` nor
+ `--detach` is used, then `git worktree add` defaults to
creating a new branch from HEAD. If `worktree.guessRemote` is
set to true, `worktree add` tries to find a remote-tracking
branch whose name uniquely matches the new branch name. If
--
2.20.1.415.g653613c723
^ permalink raw reply related
* RE: git-rebase is ignoring working-tree-encoding
From: Alexandre Grigoriev @ 2018-12-23 14:46 UTC (permalink / raw)
To: 'Torsten Bögershausen',
'Adrián Gimeno Balaguer'
Cc: git
In-Reply-To: <20181104170729.GA21372@tor.lan>
>On Fri, Nov 02, 2018 at 03:30:17AM +0100, Adrián Gimeno Balaguer wrote:
>> I’m attempting to perform fixups via git-rebase of UTF-16 LE files
>> (the project I’m working on requires that exact encoding on certain
>> files). When the rebase is complete, Git changes that file’s encoding
>> to UTF-16 BE. I have been using the newer working-tree-encoding
>> attribute in .gitattributes. I’m using Git for Windows.
>>
>> $ git version
>> git version 2.19.1.windows.1
>>
>Thanks for the report.
>I have tried to follow the problem from your verbal descriptions
>(and the PR) but I need to admit that I don't fully understand the
>problem (yet).
>Could you try to create some instructions how to reproduce it?
>A numer of shell istructions would be great,
>in best case some kind of "test case", like the tests in
>the t/ directory in Git.
>It would be nice to be able to re-produce it.
>And if there is a bug, to get it fixed.
This is not as much Git issue (and not rebase issue at all), as libiconv issue.
Iconv program exhibits the same behavior. If you ask it to convert to UTF-16,
It will produce UTF-16BE with BOM.
That said, it appears that Centos (tested on 7.4) devs have seen the wrong in it and patched libiconv to produce UTF-16LE with BOM.
Git on Centos does check out files as UTF-16LE, and iconv produces these files, as well.
Just need to find out what patch they applied to libiconv.
^ permalink raw reply
* Re: [PATCH v2 7/8] checkout: introduce --{,no-}overlay option
From: Eric Sunshine @ 2018-12-23 9:44 UTC (permalink / raw)
To: Duy Nguyen
Cc: Thomas Gummerer, Git Mailing List, Junio C Hamano, Elijah Newren
In-Reply-To: <CACsJy8B-jB6o2XYG_6UdTrhrGbos-+5rs98qqQQuJYYV+6W+SQ@mail.gmail.com>
On Sun, Dec 23, 2018 at 3:05 AM Duy Nguyen <pclouds@gmail.com> wrote:
> On Thu, Dec 20, 2018 at 2:48 PM Thomas Gummerer <t.gummerer@gmail.com> wrote:
> > +--[no-]overlay::
> > + In the default overlay mode files `git checkout` never
>
> -ECANTPARSE. Maybe "files" should be removed from this line?
Also, add a comma after "mode".
^ permalink raw reply
* Re: [PATCH v2 7/8] checkout: introduce --{,no-}overlay option
From: Duy Nguyen @ 2018-12-23 8:05 UTC (permalink / raw)
To: Thomas Gummerer; +Cc: Git Mailing List, Junio C Hamano, Elijah Newren
In-Reply-To: <20181220134820.21810-8-t.gummerer@gmail.com>
On Thu, Dec 20, 2018 at 2:48 PM Thomas Gummerer <t.gummerer@gmail.com> wrote:
> diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt
> index 801de2f764..4ac8c55865 100644
> --- a/Documentation/git-checkout.txt
> +++ b/Documentation/git-checkout.txt
> @@ -260,6 +260,9 @@ the conflicted merge in the specified paths.
> This means that you can use `git checkout -p` to selectively discard
> edits from your current working tree. See the ``Interactive Mode''
> section of linkgit:git-add[1] to learn how to operate the `--patch` mode.
> ++
> +Note that this option uses the no overlay mode by default (see also
> +-`--[no-]overlay`), and currently doesn't support overlay mode.
>
> --ignore-other-worktrees::
> `git checkout` refuses when the wanted ref is already checked
> @@ -276,6 +279,13 @@ section of linkgit:git-add[1] to learn how to operate the `--patch` mode.
> Just like linkgit:git-submodule[1], this will detach the
> submodules HEAD.
>
> +--[no-]overlay::
> + In the default overlay mode files `git checkout` never
-ECANTPARSE. Maybe "files" should be removed from this line?
> + removes files from the index or the working tree. When
> + specifying --no-overlay, files that appear in the index and
> + working tree, but not in <tree-ish> are removed, to make them
> + match <tree-ish> exactly.
> +
> <branch>::
> Branch to checkout; if it refers to a branch (i.e., a name that,
> when prepended with "refs/heads/", is a valid ref), then that
--
Duy
^ permalink raw reply
* Re: Does "git push" open a pack for read before closing it?
From: brian m. carlson @ 2018-12-22 23:12 UTC (permalink / raw)
To: git-mailinglist; +Cc: git
In-Reply-To: <5878633d-cdbd-ce05-30de-3417386c720e@happybeing.com>
[-- Attachment #1: Type: text/plain, Size: 2681 bytes --]
On Fri, Dec 21, 2018 at 12:46:35PM +0000, git-mailinglist@happybeing.com wrote:
> Here's the output from the last command above:
>
> Enumerating objects: 373, done.
> Counting objects: 100% (373/373), done.
> Delta compression using up to 8 threads
> Compressing objects: 100% (371/371), done.
> Writing objects: 100% (373/373), 187.96 KiB | 33.00 KiB/s, done.
> Total 373 (delta 254), reused 0 (delta 0)
> remote: fatal: unable to open
> /home/mrh/SAFE/_public/tests/data1/blah/./objects/incoming-73lbb6/pack/tmp_pack_pL28kQ:
> Remote I/O error
> error: remote unpack failed: index-pack abnormal exit
> To /home/mrh/SAFE/_public/tests/data1/blah
> ! [remote rejected] master -> master (unpacker error)
> error: failed to push some refs to '/home/mrh/SAFE/_public/tests/data1/blah'
>
> Inspecting the logs from my FUSE implementation I see that there's a
> problem related to this file on the mounted storage:
>
> /_public/tests/data1/blah/objects/incoming-73lbb6/pack/tmp_pack_pL28kQ
>
> Prior to the error the file is written to multiple times by git - all
> good (about 200kB in all). Then, before the file is closed I see an
> attempt to open it for read, which fails. The failure is because I don't
> support read on a file that is open for write yet, and I'm not sure if
> that is sensible or what git might be expecting to do given the file has
> not even been flushed to disk at this point.
What I expect is happening is that Git receives the objects and writes
them to a temporary file (which you see in "objects/incoming") and then
they're passed to either git unpack-objects or git index-pack, which
then attempts to read it.
> So I'd like to know if this is expected behaviour by git (or where to
> look to find out), and if it is expected, then what might git expect to
> do if the file were opened successfully?
This behavior is expected. POSIX says that a read that can be proved to
have occurred after a write must contain the new data, so it's possible
that a separate process may choose to read the file and index it,
knowing that the index process was started after all the writes.
This is definitely an important invariant to preserve if your FUSE
file system is going to be used on a Unix system. In other words,
consistency (in the CAP sense) is required.
> N.B. After the failure, the file is closed and then deleted!
Right, if this had succeeded, we would have renamed it into place (or
unpacked it and deleted it), but since it failed, we clean up after
ourselves so as not to leave large temporary files around.
--
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 868 bytes --]
^ permalink raw reply
* Re: [PATCH] log: add %S option (like --source) to log --format
From: Jeff King @ 2018-12-22 22:22 UTC (permalink / raw)
To: Issac Trotts; +Cc: git, Noemi Mercado, Issac Trotts
In-Reply-To: <CANdyxMyz3u+ajH0X7BPJBPBT0iepWhunA_VA+HEGFrurYghSWQ@mail.gmail.com>
On Thu, Dec 20, 2018 at 09:24:10PM -0800, Issac Trotts wrote:
> Hi all, friendly ping. Is there still interest in merging this patch?
Yes, but I think people are largely absent for holidays at this point.
If there hasn't been any movement on it, I'll try to review after Jan
5th (it also wouldn't hurt to re-post around then).
-Peff
^ permalink raw reply
* Re: [PATCH 1/1] abspath_part_inside_repo: respect core.fileMode
From: Carlo Arenas @ 2018-12-22 18:11 UTC (permalink / raw)
To: Johannes Schindelin via GitGitGadget
Cc: git, Junio C Hamano, Johannes Schindelin
In-Reply-To: <4fb5de504e9b48a35075cb87f4158149055f1a13.1545391939.git.gitgitgadget@gmail.com>
On Fri, Dec 21, 2018 at 8:34 AM Johannes Schindelin via GitGitGadget
<gitgitgadget@gmail.com> wrote:
> +test_expect_success MINGW 'path is case-insensitive' '
CASE_INSENSITIVE_FS might be a better prereq
Carlo
^ permalink raw reply
* Re: Show-branch without commits
From: David @ 2018-12-22 2:20 UTC (permalink / raw)
To: Brian Johnson; +Cc: git list
In-Reply-To: <CAArbzTBWk2WhEeuqCzUuXC1FAnF1i3ZyM_RsJRDP0Pm0+mHa3A@mail.gmail.com>
On Sat, 22 Dec 2018 at 10:04, Brian Johnson <brian.johnson@takehiko.net> wrote:
>
> Is it possible (or could a flag be added) to have show-branch only
> show the branch hierarchy at the top and not print out the commit
> list?
Does
git show-branch --list
do what you want?
^ permalink raw reply
* Re: Can git choose perl at runtime?
From: brian m. carlson @ 2018-12-21 23:42 UTC (permalink / raw)
To: John Passaro; +Cc: git
In-Reply-To: <CAJdN7Kioa22xrDP2ssZXmBbu7KDkcr2MQCUDW=Tzm5ydzeChBQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2066 bytes --]
On Tue, Dec 18, 2018 at 10:09:14PM -0500, John Passaro wrote:
> I recently submitted my first patch using OSX and found the experience
> frustrating, for reasons that have come up on the list before,
> concerning git-send-email and perl dependencies that you need to be
> root to update.
>
> Last seen here:
> https://public-inbox.org/git/878t55qga6.fsf@evledraar.gmail.com/
>
> The struggle is that Mac's package manager Homebrew has opted,
> apparently with some finality, to no longer support linking to a user
> perl at build time. PERL_PATH is hard-coded to link to the system
> perl, which means the user needs sudo to install the SSL libraries
> required for send-email. So for send-email to work, you need to either
> sudo cpan or build git yourself. The obvious solution here would be to
> do /usr/bin/env perl, but in the above message Aevar pointed out
> pitfalls with that.
>
> It seems that choosing perl at compile time necessarily comes with
> tradeoffs. So I wonder if there is a way we can support choosing a
> perl at runtime without breaking the existing mechanism of linking to
> perl at compile time.
>
> I'm picturing adding an executable "git-perl" to libexec that checks
> config core.perlPath and envvar GIT_PERL_PATH, in some order. Having
> chosen one of these or the build-time PERL_PATH as a last resort, it
> exec's the correct perl executable.
>
> Then relevant scripts (e.g. git-add--interactive, git-send-email)
> invoke git-perl instead of /usr/bin/perl, and the makefile no longer
> replaces that with PERL_PATH -- instead that will be used at runtime
> via git-perl when we can be sure the user does not explicitly prefer
> something different.
How do git send-email and git svn work in such a case? They depend on
the Git and Git::SVN modules being in place, so if you use a Perl other
than the one you built Git with, they won't be present (or they'll be
present, but potentially with the wrong version).
--
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 868 bytes --]
^ permalink raw reply
* Re: [PATCH] diff: add support for reading files literally with --no-index
From: brian m. carlson @ 2018-12-21 23:20 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Jeff King, Duy Nguyen
In-Reply-To: <nycvar.QRO.7.76.6.1812211246050.41@tvgsbejvaqbjf.bet>
[-- Attachment #1: Type: text/plain, Size: 983 bytes --]
On Fri, Dec 21, 2018 at 12:52:04PM +0100, Johannes Schindelin wrote:
> ... and in Git for Windows' Bash, it would result in something like:
>
> $ git -P diff --no-index <(printf "a\nb\n") <(printf "a\nc\n")
> error: Could not access '/proc/24012/fd/63'
>
> ... because the Bash is "MSYS2-aware" and knows about `/proc/` while
> `git.exe` is a pure Win32 executable that has no idea what Bash is talking
> about.
>
> Sadly, your patch does not change the situation one bit (because it does
> not change the fact that the MSYS2 Bash passes a path to `git.exe` that is
> not a valid Windows path, and neither could it, but that's not the problem
> of your patch).
That tells me that I need to exclude Windows (excepting Cygwin) if I add
a PROCESS_SUBSTITUTION test like Ævar suggested, and that indeed is
helpful information. I'm sorry my patch won't be useful on Windows,
though.
--
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 868 bytes --]
^ permalink raw reply
* Re: Unable to install latest git version. Claims git process pid running
From: David Brown @ 2018-12-21 20:19 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <nycvar.QRO.7.76.6.1812211652150.41@tvgsbejvaqbjf.bet>
Howdy Johannes, thanks for the speedy reply.
Unfortunately I have hit refresh many times in previous attempts.
Notwithstanding, the dialog maintains the error condition claiming pid
10128 must be closed prior to install.
I'm a big fan of Git but not a Windows fan in the least.
I have downloaded the latest Windows git and killing as many apps and
pids possible after Windows restart the installation goes south
nonetheless.
Please advise.
On 2018-12-21 09:55, Johannes Schindelin wrote:
> Hi,
>
> On Thu, 20 Dec 2018, David Brown wrote:
>
>> - [ ] I was not able to find an
>> [open](https://github.com/git-for-windows/git/issues?q=is%3Aopen) or
>> [closed](https://github.com/git-for-windows/git/issues?q=is%3Aclosed)
>> issue
>> matching what I'm seeing
>
> That's a new one. I saw many bug reporters simply deleting the issue
> reporting template at https://github.com/git-for-windows/git/issues/new
> (and usually then filing only very little information, definitely not
> enough to make sense of the bug report), but I never saw this bug
> reporting template being used to report a Git for Windows bug to the
> Git
> mailing list yet ;-)
>
>> ### Setup
>>
>> - Which version of Git for Windows are you using? Is it 32-bit or
>> 64-bit?
>>
>> $ git --version --build-options
>>
>> git version 2.20.0.windows.1 cpu: x86_64 built from commit:
>> 95155834166f64fe9666f2c0a4909f076080893a
>> sizeof-long: 4
>> sizeof-size_t: 8 **
>>
>> - Which version of Windows are you running? Vista, 7, 8, 10? Is it
>> 32-bit or
>> 64-bit?
>>
>> $ cmd.exe /c ver
>>
>> ** Microsoft Windows [Version 6.1.7601] **
>>
>> - What options did you set as part of the installation? Or did you
>> choose the
>> defaults?
>>
>> # One of the following:
>>
>> $ cat /etc/install-options.txt Editor Option: VIM Custom Editor Path:
>> Path Option: BashOnly
>> SSH Option: OpenSSH
>> CURL Option: WinSSL
>> CRLF Option: CRLFAlways
>> Bash Terminal Option: MinTTY
>> Performance Tweaks
>> FSCache: Enabled
>> Use Credential Manager: Enabled
>> Enable Symlinks: Disabled
>>
>> - Any other interesting things about your environment that might be
>> related
>> to the issue you're seeing?
>>
>> ** A so-called VDI running on a Dell WYSE **
>>
>> ### Details
>>
>> - Which terminal/shell are you running Git from? e.g
>> Bash/CMD/PowerShell/other
>>
>> ** Bash **
>>
>> - What commands did you run to trigger this issue? If you can provide
>> a
>> [Minimal, Complete, and Verifiable
>> example](http://stackoverflow.com/help/mcve)
>> this will help us understand the issue.
>>
>> ** Windows git upgrade dialog **
>>
>> - What did you expect to occur after running these commands?
>>
>> ** latest version of git installed **
>>
>> - What actually happened instead?
>>
>> ** No such pid 10128 to close therefore cancel install **
>
> This typically means that that process existed *at the time the
> installer
> checked*. If it was a short-lived process, you can check again by
> clicking
> that "Refresh" button on the lower left.
>
> Ciao,
> Johannes
>
>>
>> - If the probleminsert URL herey, can you provide the
>> URL to that repository to help us with testing?
>>
>> ** Internal company url. Windows git install dialog is issue **
>>
^ 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