* [PATCH 0/2] check-attr: add support to work with revisions @ 2022-12-06 10:37 Karthik Nayak 2022-12-06 10:37 ` [PATCH 1/2] t0003: move setup for `--all` into new block Karthik Nayak ` (3 more replies) 0 siblings, 4 replies; 17+ messages in thread From: Karthik Nayak @ 2022-12-06 10:37 UTC (permalink / raw) To: git; +Cc: toon, Karthik Nayak Given a pathname, git-check-attr(1) will list the attributes which apply to that pathname by reading all relevant gitattributes files. Currently there is no way to specify a revision to read the gitattributes from. This is specifically useful in bare repositories wherein the gitattributes are only present in the git working tree but not available directly on the filesystem. This series aims to add a new flag `-r|--revisions` to git-check-attr(1) which allows us to read gitattributes from the specified revision. Karthik Nayak (2): t0003: move setup for `--all` into new block attr: add flag `-r|--revisions` to work with revisions archive.c | 2 +- attr.c | 120 ++++++++++++++++++++++++++++------------- attr.h | 7 ++- builtin/check-attr.c | 25 ++++----- builtin/pack-objects.c | 2 +- convert.c | 2 +- ll-merge.c | 4 +- pathspec.c | 2 +- t/t0003-attributes.sh | 63 ++++++++++++++++++++-- userdiff.c | 2 +- ws.c | 2 +- 11 files changed, 170 insertions(+), 61 deletions(-) -- 2.38.1 ^ permalink raw reply [flat|nested] 17+ messages in thread
* [PATCH 1/2] t0003: move setup for `--all` into new block 2022-12-06 10:37 [PATCH 0/2] check-attr: add support to work with revisions Karthik Nayak @ 2022-12-06 10:37 ` Karthik Nayak 2022-12-06 10:37 ` [PATCH 2/2] attr: add flag `-r|--revisions` to work with revisions Karthik Nayak ` (2 subsequent siblings) 3 siblings, 0 replies; 17+ messages in thread From: Karthik Nayak @ 2022-12-06 10:37 UTC (permalink / raw) To: git; +Cc: toon, Karthik Nayak There is some setup code which is used by multiple tests being setup in `attribute test: --all option`. This means when we run "sh ./t0003-attributes.sh --run=setup,<num>" there is a chance of failing since we missed this setup block. So to ensure that setups are independent of test logic, move this to a new setup block. Signed-off-by: Karthik Nayak <karthik.188@gmail.com> Co-authored-by: toon@iotcl.com --- t/t0003-attributes.sh | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/t/t0003-attributes.sh b/t/t0003-attributes.sh index f7ee2f2ff0..b3aabb8aa3 100755 --- a/t/t0003-attributes.sh +++ b/t/t0003-attributes.sh @@ -203,9 +203,12 @@ test_expect_success 'attribute test: read paths from stdin' ' test_cmp expect actual ' -test_expect_success 'attribute test: --all option' ' +test_expect_success 'setup --all option' ' grep -v unspecified <expect-all | sort >specified-all && - sed -e "s/:.*//" <expect-all | uniq >stdin-all && + sed -e "s/:.*//" <expect-all | uniq >stdin-all +' + +test_expect_success 'attribute test: --all option' ' git check-attr --stdin --all <stdin-all >tmp && sort tmp >actual && test_cmp specified-all actual -- 2.38.1 ^ permalink raw reply related [flat|nested] 17+ messages in thread
* [PATCH 2/2] attr: add flag `-r|--revisions` to work with revisions 2022-12-06 10:37 [PATCH 0/2] check-attr: add support to work with revisions Karthik Nayak 2022-12-06 10:37 ` [PATCH 1/2] t0003: move setup for `--all` into new block Karthik Nayak @ 2022-12-06 10:37 ` Karthik Nayak 2022-12-06 11:27 ` Ævar Arnfjörð Bjarmason 2022-12-07 0:12 ` Junio C Hamano 2022-12-06 11:20 ` [PATCH 0/2] check-attr: add support " Philip Oakley 2022-12-07 1:09 ` Taylor Blau 3 siblings, 2 replies; 17+ messages in thread From: Karthik Nayak @ 2022-12-06 10:37 UTC (permalink / raw) To: git; +Cc: toon, Karthik Nayak Git check-attr currently doesn't check the git worktree, it either checks the index or the files directly. This means we cannot check the attributes for a file against a certain revision. Add a new flag `--revision`/`-r` which will allow it work with revisions. This command will now, instead of checking the files/index, try and receive the blob for the given attribute file against the provided revision. The flag overrides checking against the index and filesystem and also works with bare repositories. We cannot use the `<rev>:<path>` syntax like the one used in `git show` because any non-flag parameter before `--` is treated as an attribute and any parameter after `--` is treated as a pathname. This involves creating a new function `read_attr_from_blob`, which given the path reads the blob for the path against the provided revision and parses the attributes line by line. This function is plugged into `read_attr()` function wherein we go through the different attributes. Signed-off-by: Karthik Nayak <karthik.188@gmail.com> Co-authored-by: toon@iotcl.com --- archive.c | 2 +- attr.c | 120 ++++++++++++++++++++++++++++------------- attr.h | 7 ++- builtin/check-attr.c | 25 ++++----- builtin/pack-objects.c | 2 +- convert.c | 2 +- ll-merge.c | 4 +- pathspec.c | 2 +- t/t0003-attributes.sh | 56 ++++++++++++++++++- userdiff.c | 2 +- ws.c | 2 +- 11 files changed, 165 insertions(+), 59 deletions(-) diff --git a/archive.c b/archive.c index 941495f5d7..bf64dbdce1 100644 --- a/archive.c +++ b/archive.c @@ -120,7 +120,7 @@ static const struct attr_check *get_archive_attrs(struct index_state *istate, static struct attr_check *check; if (!check) check = attr_check_initl("export-ignore", "export-subst", NULL); - git_check_attr(istate, path, check); + git_check_attr(istate, path, check, NULL); return check; } diff --git a/attr.c b/attr.c index 42ad6de8c7..42b67a401f 100644 --- a/attr.c +++ b/attr.c @@ -11,8 +11,12 @@ #include "exec-cmd.h" #include "attr.h" #include "dir.h" +#include "git-compat-util.h" +#include "strbuf.h" #include "utf8.h" #include "quote.h" +#include "revision.h" +#include "object-store.h" #include "thread-utils.h" const char git_attr__true[] = "(builtin)true"; @@ -729,14 +733,67 @@ static struct attr_stack *read_attr_from_file(const char *path, unsigned flags) return res; } -static struct attr_stack *read_attr_from_index(struct index_state *istate, - const char *path, - unsigned flags) +static struct attr_stack *read_attr_from_buf(char *buf, const char *path, + unsigned flags) { struct attr_stack *res; - char *buf, *sp; + char *sp; int lineno = 0; + if (buf == NULL) + return NULL; + + CALLOC_ARRAY(res, 1); + for (sp = buf; *sp;) { + char *ep; + int more; + + ep = strchrnul(sp, '\n'); + more = (*ep == '\n'); + *ep = '\0'; + handle_attr_line(res, sp, path, ++lineno, flags); + sp = ep + more; + } + free(buf); + + return res; +} + +static struct attr_stack *read_attr_from_blob(const char *path, + const char *object_name, + unsigned flags) +{ + struct object_id oid; + unsigned long sz; + enum object_type type; + void *buf; + struct strbuf sb; + + if (object_name == NULL) + return NULL; + + strbuf_init(&sb, strlen(path) + 1 + strlen(object_name)); + strbuf_addstr(&sb, object_name); + strbuf_addstr(&sb, ":"); + strbuf_addstr(&sb, path); + + if (get_oid(sb.buf, &oid)) + return NULL; + + buf = read_object_file(&oid, &type, &sz); + if (!buf || type != OBJ_BLOB) { + free(buf); + return NULL; + } + + return read_attr_from_buf(buf, path, flags); +} + +static struct attr_stack *read_attr_from_index(struct index_state *istate, + const char *path, unsigned flags) +{ + char *buf; + if (!istate) return NULL; @@ -758,28 +815,19 @@ static struct attr_stack *read_attr_from_index(struct index_state *istate, if (!buf) return NULL; - CALLOC_ARRAY(res, 1); - for (sp = buf; *sp; ) { - char *ep; - int more; - - ep = strchrnul(sp, '\n'); - more = (*ep == '\n'); - *ep = '\0'; - handle_attr_line(res, sp, path, ++lineno, flags); - sp = ep + more; - } - free(buf); - return res; + return read_attr_from_buf(buf, path, flags); } static struct attr_stack *read_attr(struct index_state *istate, - const char *path, unsigned flags) + const char *path, const char *object_name, + unsigned flags) { struct attr_stack *res = NULL; if (direction == GIT_ATTR_INDEX) { res = read_attr_from_index(istate, path, flags); + } else if (object_name != NULL) { + res = read_attr_from_blob(path, object_name, flags); } else if (!is_bare_repository()) { if (direction == GIT_ATTR_CHECKOUT) { res = read_attr_from_index(istate, path, flags); @@ -839,7 +887,8 @@ static void push_stack(struct attr_stack **attr_stack_p, } static void bootstrap_attr_stack(struct index_state *istate, - struct attr_stack **stack) + struct attr_stack **stack, + const char *object_name) { struct attr_stack *e; unsigned flags = READ_ATTR_MACRO_OK; @@ -864,7 +913,7 @@ static void bootstrap_attr_stack(struct index_state *istate, } /* root directory */ - e = read_attr(istate, GITATTRIBUTES_FILE, flags | READ_ATTR_NOFOLLOW); + e = read_attr(istate, GITATTRIBUTES_FILE, object_name, flags | READ_ATTR_NOFOLLOW); push_stack(stack, e, xstrdup(""), 0); /* info frame */ @@ -877,9 +926,9 @@ static void bootstrap_attr_stack(struct index_state *istate, push_stack(stack, e, NULL, 0); } -static void prepare_attr_stack(struct index_state *istate, - const char *path, int dirlen, - struct attr_stack **stack) +static void prepare_attr_stack(struct index_state *istate, const char *path, + int dirlen, struct attr_stack **stack, + const char *object_name) { struct attr_stack *info; struct strbuf pathbuf = STRBUF_INIT; @@ -899,7 +948,7 @@ static void prepare_attr_stack(struct index_state *istate, * .gitattributes in deeper directories to shallower ones, * and finally use the built-in set as the default. */ - bootstrap_attr_stack(istate, stack); + bootstrap_attr_stack(istate, stack, object_name); /* * Pop the "info" one that is always at the top of the stack. @@ -954,7 +1003,7 @@ static void prepare_attr_stack(struct index_state *istate, strbuf_add(&pathbuf, path + pathbuf.len, (len - pathbuf.len)); strbuf_addf(&pathbuf, "/%s", GITATTRIBUTES_FILE); - next = read_attr(istate, pathbuf.buf, READ_ATTR_NOFOLLOW); + next = read_attr(istate, pathbuf.buf, object_name, READ_ATTR_NOFOLLOW); /* reset the pathbuf to not include "/.gitattributes" */ strbuf_setlen(&pathbuf, len); @@ -1073,9 +1122,9 @@ static void determine_macros(struct all_attrs_item *all_attrs, * If check->check_nr is non-zero, only attributes in check[] are collected. * Otherwise all attributes are collected. */ -static void collect_some_attrs(struct index_state *istate, - const char *path, - struct attr_check *check) +static void collect_some_attrs(struct index_state *istate, const char *path, + struct attr_check *check, + const char *object_name) { int pathlen, rem, dirlen; const char *cp, *last_slash = NULL; @@ -1094,7 +1143,7 @@ static void collect_some_attrs(struct index_state *istate, dirlen = 0; } - prepare_attr_stack(istate, path, dirlen, &check->stack); + prepare_attr_stack(istate, path, dirlen, &check->stack, object_name); all_attrs_init(&g_attr_hashmap, check); determine_macros(check->all_attrs, check->stack); @@ -1102,13 +1151,12 @@ static void collect_some_attrs(struct index_state *istate, fill(path, pathlen, basename_offset, check->stack, check->all_attrs, rem); } -void git_check_attr(struct index_state *istate, - const char *path, - struct attr_check *check) +void git_check_attr(struct index_state *istate, const char *path, + struct attr_check *check, const char *object_name) { int i; - collect_some_attrs(istate, path, check); + collect_some_attrs(istate, path, check, object_name); for (i = 0; i < check->nr; i++) { size_t n = check->items[i].attr->attr_nr; @@ -1119,13 +1167,13 @@ void git_check_attr(struct index_state *istate, } } -void git_all_attrs(struct index_state *istate, - const char *path, struct attr_check *check) +void git_all_attrs(struct index_state *istate, const char *path, + struct attr_check *check, const char *object_name) { int i; attr_check_reset(check); - collect_some_attrs(istate, path, check); + collect_some_attrs(istate, path, check, object_name); for (i = 0; i < check->all_attrs_nr; i++) { const char *name = check->all_attrs[i].attr->name; diff --git a/attr.h b/attr.h index 3fb40cced0..0708d6e046 100644 --- a/attr.h +++ b/attr.h @@ -169,6 +169,7 @@ struct attr_check { int all_attrs_nr; struct all_attrs_item *all_attrs; struct attr_stack *stack; + char *object_id; }; struct attr_check *attr_check_alloc(void); @@ -190,14 +191,16 @@ void attr_check_free(struct attr_check *check); const char *git_attr_name(const struct git_attr *); void git_check_attr(struct index_state *istate, - const char *path, struct attr_check *check); + const char *path, struct attr_check *check, + const char *object_name); /* * Retrieve all attributes that apply to the specified path. * check holds the attributes and their values. */ void git_all_attrs(struct index_state *istate, - const char *path, struct attr_check *check); + const char *path, struct attr_check *check, + const char *object_name); enum git_attr_direction { GIT_ATTR_CHECKIN, diff --git a/builtin/check-attr.c b/builtin/check-attr.c index 0fef10eb6b..3e032420ed 100644 --- a/builtin/check-attr.c +++ b/builtin/check-attr.c @@ -9,6 +9,7 @@ static int all_attrs; static int cached_attrs; static int stdin_paths; +static char *object_name; static const char * const check_attr_usage[] = { N_("git check-attr [-a | --all | <attr>...] [--] <pathname>..."), N_("git check-attr --stdin [-z] [-a | --all | <attr>...]"), @@ -23,6 +24,7 @@ static const struct option check_attr_options[] = { OPT_BOOL(0 , "stdin", &stdin_paths, N_("read file names from stdin")), OPT_BOOL('z', NULL, &nul_term_line, N_("terminate input and output records by a NUL character")), + OPT_STRING('r', "revision", &object_name, N_("revision"), N_("check attributes at this revision")), OPT_END() }; @@ -55,27 +57,26 @@ static void output_attr(struct attr_check *check, const char *file) } } -static void check_attr(const char *prefix, - struct attr_check *check, - int collect_all, - const char *file) +static void check_attr(const char *prefix, struct attr_check *check, + int collect_all, const char *file, + const char *object_name +) { char *full_path = prefix_path(prefix, prefix ? strlen(prefix) : 0, file); if (collect_all) { - git_all_attrs(&the_index, full_path, check); + git_all_attrs(&the_index, full_path, check, object_name); } else { - git_check_attr(&the_index, full_path, check); + git_check_attr(&the_index, full_path, check, object_name); } output_attr(check, file); free(full_path); } -static void check_attr_stdin_paths(const char *prefix, - struct attr_check *check, - int collect_all) +static void check_attr_stdin_paths(const char *prefix, struct attr_check *check, + int collect_all, const char *object_name) { struct strbuf buf = STRBUF_INIT; struct strbuf unquoted = STRBUF_INIT; @@ -89,7 +90,7 @@ static void check_attr_stdin_paths(const char *prefix, die("line is badly quoted"); strbuf_swap(&buf, &unquoted); } - check_attr(prefix, check, collect_all, buf.buf); + check_attr(prefix, check, collect_all, buf.buf, object_name); maybe_flush_or_die(stdout, "attribute to stdout"); } strbuf_release(&buf); @@ -177,10 +178,10 @@ int cmd_check_attr(int argc, const char **argv, const char *prefix) } if (stdin_paths) - check_attr_stdin_paths(prefix, check, all_attrs); + check_attr_stdin_paths(prefix, check, all_attrs, object_name); else { for (i = filei; i < argc; i++) - check_attr(prefix, check, all_attrs, argv[i]); + check_attr(prefix, check, all_attrs, argv[i], object_name); maybe_flush_or_die(stdout, "attribute to stdout"); } diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c index 573d0b20b7..f57a0188e6 100644 --- a/builtin/pack-objects.c +++ b/builtin/pack-objects.c @@ -1318,7 +1318,7 @@ static int no_try_delta(const char *path) if (!check) check = attr_check_initl("delta", NULL); - git_check_attr(the_repository->index, path, check); + git_check_attr(the_repository->index, path, check, NULL); if (ATTR_FALSE(check->items[0].value)) return 1; return 0; diff --git a/convert.c b/convert.c index 9b67649032..095729004f 100644 --- a/convert.c +++ b/convert.c @@ -1308,7 +1308,7 @@ void convert_attrs(struct index_state *istate, git_config(read_convert_config, NULL); } - git_check_attr(istate, path, check); + git_check_attr(istate, path, check, NULL); ccheck = check->items; ca->crlf_action = git_path_check_crlf(ccheck + 4); if (ca->crlf_action == CRLF_UNDEFINED) diff --git a/ll-merge.c b/ll-merge.c index 22a603e8af..45a534badf 100644 --- a/ll-merge.c +++ b/ll-merge.c @@ -391,7 +391,7 @@ enum ll_merge_result ll_merge(mmbuffer_t *result_buf, normalize_file(theirs, path, istate); } - git_check_attr(istate, path, check); + git_check_attr(istate, path, check, NULL); ll_driver_name = check->items[0].value; if (check->items[1].value) { marker_size = atoi(check->items[1].value); @@ -419,7 +419,7 @@ int ll_merge_marker_size(struct index_state *istate, const char *path) if (!check) check = attr_check_initl("conflict-marker-size", NULL); - git_check_attr(istate, path, check); + git_check_attr(istate, path, check, NULL); if (check->items[0].value) { marker_size = atoi(check->items[0].value); if (marker_size <= 0) diff --git a/pathspec.c b/pathspec.c index 46e77a85fe..b5217e4c36 100644 --- a/pathspec.c +++ b/pathspec.c @@ -732,7 +732,7 @@ int match_pathspec_attrs(struct index_state *istate, if (name[namelen]) name = to_free = xmemdupz(name, namelen); - git_check_attr(istate, name, item->attr_check); + git_check_attr(istate, name, item->attr_check, NULL); free(to_free); diff --git a/t/t0003-attributes.sh b/t/t0003-attributes.sh index b3aabb8aa3..90a3680a31 100755 --- a/t/t0003-attributes.sh +++ b/t/t0003-attributes.sh @@ -25,7 +25,14 @@ attr_check_quote () { git check-attr test -- "$path" >actual && echo "\"$quoted_path\": test: $expect" >expect && test_cmp expect actual +} + +attr_check_revision () { + path="$1" expect="$2" revision="$3" git_opts="$4" && + git $git_opts check-attr -r $revision test -- "$path" >actual 2>err && + echo "$path: test: $expect" >expect && + test_cmp expect actual } test_expect_success 'open-quoted pathname' ' @@ -33,7 +40,6 @@ test_expect_success 'open-quoted pathname' ' attr_check a unspecified ' - test_expect_success 'setup' ' mkdir -p a/b/d a/c b && ( @@ -80,6 +86,26 @@ test_expect_success 'setup' ' EOF ' +test_expect_success 'setup branches' ' + ( + echo "f test=f" && + echo "a/i test=n" + ) | git hash-object -w --stdin > id && + git update-index --add --cacheinfo 100644,$(cat id),foo/bar/.gitattributes && + git write-tree > id && + git commit-tree $(cat id) -m "random commit message" > id && + git update-ref refs/heads/branch1 $(cat id) && + + ( + echo "g test=g" && + echo "a/i test=m" + ) | git hash-object -w --stdin > id && + git update-index --add --cacheinfo 100644,$(cat id),foo/bar/.gitattributes && + git write-tree > id && + git commit-tree $(cat id) -m "random commit message" > id && + git update-ref refs/heads/branch2 $(cat id) +' + test_expect_success 'command line checks' ' test_must_fail git check-attr && test_must_fail git check-attr -- && @@ -287,6 +313,15 @@ test_expect_success 'using --git-dir and --work-tree' ' ) ' +test_expect_success 'using --revision' ' + attr_check_revision foo/bar/f f branch1 && + attr_check_revision foo/bar/a/i n branch1 && + attr_check_revision foo/bar/f unspecified branch2 && + attr_check_revision foo/bar/a/i m branch2 && + attr_check_revision foo/bar/g g branch2 && + attr_check_revision foo/bar/g unspecified branch1 +' + test_expect_success 'setup bare' ' git clone --template= --bare . bare.git ' @@ -306,6 +341,25 @@ test_expect_success 'bare repository: check that .gitattribute is ignored' ' ) ' +test_expect_success 'bare repository: with --revision' ' + ( + cd bare.git && + ( + echo "f test=f" && + echo "a/i test=a/i" + ) | git hash-object -w --stdin > id && + git update-index --add --cacheinfo 100644 $(cat id) .gitattributes && + git write-tree > id && + git commit-tree $(cat id) -m "random commit message" > id && + git update-ref refs/heads/master $(cat id) && + attr_check_revision f f HEAD && + attr_check_revision a/f f HEAD && + attr_check_revision a/c/f f HEAD && + attr_check_revision a/i a/i HEAD && + attr_check_revision subdir/a/i unspecified HEAD + ) +' + test_expect_success 'bare repository: check that --cached honors index' ' ( cd bare.git && diff --git a/userdiff.c b/userdiff.c index 151d9a5278..364f5a5ea2 100644 --- a/userdiff.c +++ b/userdiff.c @@ -412,7 +412,7 @@ struct userdiff_driver *userdiff_find_by_path(struct index_state *istate, check = attr_check_initl("diff", NULL); if (!path) return NULL; - git_check_attr(istate, path, check); + git_check_attr(istate, path, check, NULL); if (ATTR_TRUE(check->items[0].value)) return &driver_true; diff --git a/ws.c b/ws.c index 6e69877f25..8cc3e429c1 100644 --- a/ws.c +++ b/ws.c @@ -78,7 +78,7 @@ unsigned whitespace_rule(struct index_state *istate, const char *pathname) if (!attr_whitespace_rule) attr_whitespace_rule = attr_check_initl("whitespace", NULL); - git_check_attr(istate, pathname, attr_whitespace_rule); + git_check_attr(istate, pathname, attr_whitespace_rule, NULL); value = attr_whitespace_rule->items[0].value; if (ATTR_TRUE(value)) { /* true (whitespace) */ -- 2.38.1 ^ permalink raw reply related [flat|nested] 17+ messages in thread
* Re: [PATCH 2/2] attr: add flag `-r|--revisions` to work with revisions 2022-12-06 10:37 ` [PATCH 2/2] attr: add flag `-r|--revisions` to work with revisions Karthik Nayak @ 2022-12-06 11:27 ` Ævar Arnfjörð Bjarmason 2022-12-06 13:06 ` Karthik Nayak 2022-12-07 0:12 ` Junio C Hamano 1 sibling, 1 reply; 17+ messages in thread From: Ævar Arnfjörð Bjarmason @ 2022-12-06 11:27 UTC (permalink / raw) To: Karthik Nayak; +Cc: git, toon On Tue, Dec 06 2022, Karthik Nayak wrote: > Git check-attr currently doesn't check the git worktree, it either > checks the index or the files directly. This means we cannot check the > attributes for a file against a certain revision. > > Add a new flag `--revision`/`-r` which will allow it work with > revisions. This command will now, instead of checking the files/index, > try and receive the blob for the given attribute file against the > provided revision. The flag overrides checking against the index and > filesystem and also works with bare repositories. > > We cannot use the `<rev>:<path>` syntax like the one used in `git show` > because any non-flag parameter before `--` is treated as an attribute > and any parameter after `--` is treated as a pathname. > > This involves creating a new function `read_attr_from_blob`, which given > the path reads the blob for the path against the provided revision and > parses the attributes line by line. This function is plugged into > `read_attr()` function wherein we go through the different attributes. > > Signed-off-by: Karthik Nayak <karthik.188@gmail.com> > Co-authored-by: toon@iotcl.com > --- > archive.c | 2 +- > attr.c | 120 ++++++++++++++++++++++++++++------------- > attr.h | 7 ++- > builtin/check-attr.c | 25 ++++----- > builtin/pack-objects.c | 2 +- > convert.c | 2 +- > ll-merge.c | 4 +- > pathspec.c | 2 +- > t/t0003-attributes.sh | 56 ++++++++++++++++++- > userdiff.c | 2 +- > ws.c | 2 +- > 11 files changed, 165 insertions(+), 59 deletions(-) > > diff --git a/archive.c b/archive.c > index 941495f5d7..bf64dbdce1 100644 > --- a/archive.c > +++ b/archive.c > @@ -120,7 +120,7 @@ static const struct attr_check *get_archive_attrs(struct index_state *istate, > static struct attr_check *check; > if (!check) > check = attr_check_initl("export-ignore", "export-subst", NULL); > - git_check_attr(istate, path, check); > + git_check_attr(istate, path, check, NULL); > return check; > } > > diff --git a/attr.c b/attr.c > index 42ad6de8c7..42b67a401f 100644 > --- a/attr.c > +++ b/attr.c > @@ -11,8 +11,12 @@ > #include "exec-cmd.h" > #include "attr.h" > #include "dir.h" > +#include "git-compat-util.h" As a rule in this project we include either cache.h at the top, or git-compat-util.h, and the former includes the latter. This file already has cache.h at the top, so it won't need this. > + if (buf == NULL) if (!buf) > + more = (*ep == '\n'); Nit: parens not needed. > + struct object_id oid; > + unsigned long sz; > + enum object_type type; > + void *buf; > + struct strbuf sb; > + > + if (object_name == NULL) Ditto !object_name test. > + return NULL; > + > + strbuf_init(&sb, strlen(path) + 1 + strlen(object_name)); > + strbuf_addstr(&sb, object_name); > + strbuf_addstr(&sb, ":"); > + strbuf_addstr(&sb, path); Is this really performance sensitive so we need to pre-size this, or would a simpler: struct strbuf sb = STRBUF_INIT; strbuf_addf(&sb, "%s:%s", path, object_name); Do? > + } else if (object_name != NULL) { else if (object_name) > void git_check_attr(struct index_state *istate, > - const char *path, struct attr_check *check); > + const char *path, struct attr_check *check, > + const char *object_name); This (and possibly other places) seem funnily indented.. > if (collect_all) { > - git_all_attrs(&the_index, full_path, check); > + git_all_attrs(&the_index, full_path, check, object_name); > } else { > - git_check_attr(&the_index, full_path, check); > + git_check_attr(&the_index, full_path, check, object_name); > } Earlier you do a get_oid(), shouldn't that be a repo_get_oid(istate->repo, ...) to be future-proof? I.e. use the repo of the passed-in index. I think it'll always be "the_repository" for now, but for an API it makes sense to hardcode that assumption in fewer places. > +test_expect_success 'bare repository: with --revision' ' > + ( > + cd bare.git && > + ( > + echo "f test=f" && > + echo "a/i test=a/i" You don't need a subshell just to echo a string. You can use {}-braces, but in this case just: printf "%s\n", "f test=f" "a/i test=a/i" | git hash-object .... && > + ) | git hash-object -w --stdin > id && > + git update-index --add --cacheinfo 100644 $(cat id) .gitattributes && Split the "cat" into a varible, otherwise its failure will be hidden. > + git write-tree > id && We use ">id" style for redirection, not "> id". > + git commit-tree $(cat id) -m "random commit message" > id && Ditto.. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 2/2] attr: add flag `-r|--revisions` to work with revisions 2022-12-06 11:27 ` Ævar Arnfjörð Bjarmason @ 2022-12-06 13:06 ` Karthik Nayak 0 siblings, 0 replies; 17+ messages in thread From: Karthik Nayak @ 2022-12-06 13:06 UTC (permalink / raw) To: Ævar Arnfjörð Bjarmason; +Cc: git, toon Hello Ævar, > > > > diff --git a/attr.c b/attr.c > > index 42ad6de8c7..42b67a401f 100644 > > --- a/attr.c > > +++ b/attr.c > > @@ -11,8 +11,12 @@ > > #include "exec-cmd.h" > > #include "attr.h" > > #include "dir.h" > > +#include "git-compat-util.h" > > As a rule in this project we include either cache.h at the top, or > git-compat-util.h, and the former includes the latter. > > This file already has cache.h at the top, so it won't need this. > Right, will remove. > > + if (buf == NULL) > > if (!buf) Makes sense. > > > + more = (*ep == '\n'); > > Nit: parens not needed. > I rather let this be, since it's existing code that I just move. > > + struct object_id oid; > > + unsigned long sz; > > + enum object_type type; > > + void *buf; > > + struct strbuf sb; > > + > > + if (object_name == NULL) > > Ditto !object_name test. > Will change. > > + return NULL; > > + > > + strbuf_init(&sb, strlen(path) + 1 + strlen(object_name)); > > + strbuf_addstr(&sb, object_name); > > + strbuf_addstr(&sb, ":"); > > + strbuf_addstr(&sb, path); > > Is this really performance sensitive so we need to pre-size this, or > would a simpler: > > struct strbuf sb = STRBUF_INIT; > strbuf_addf(&sb, "%s:%s", path, object_name); > > Do? > This is much simpler and should do, will change. > > + } else if (object_name != NULL) { > > else if (object_name) Will change. > > > void git_check_attr(struct index_state *istate, > > - const char *path, struct attr_check *check); > > + const char *path, struct attr_check *check, > > + const char *object_name); > > This (and possibly other places) seem funnily indented.. > I think it's due to tab-indent being set to a default 4, I fixed it in the other files, forgot to check the header. Will fix it. > > if (collect_all) { > > - git_all_attrs(&the_index, full_path, check); > > + git_all_attrs(&the_index, full_path, check, object_name); > > } else { > > - git_check_attr(&the_index, full_path, check); > > + git_check_attr(&the_index, full_path, check, object_name); > > } > > Earlier you do a get_oid(), shouldn't that be a > repo_get_oid(istate->repo, ...) to be future-proof? I.e. use the repo of > the passed-in index. > > I think it'll always be "the_repository" for now, but for an API it > makes sense to hardcode that assumption in fewer places. > I will make this change, I didn't know about repo_get_oid() before. > > +test_expect_success 'bare repository: with --revision' ' > > + ( > > + cd bare.git && > > + ( > > + echo "f test=f" && > > + echo "a/i test=a/i" > > You don't need a subshell just to echo a string. You can use {}-braces, > but in this case just: > > printf "%s\n", "f test=f" "a/i test=a/i" | git hash-object .... && > > While I agree with what you're saying, the whole test file does it this way (echo in a subshell), wouldn't it be better to stay consistent? > > + ) | git hash-object -w --stdin > id && > > + git update-index --add --cacheinfo 100644 $(cat id) .gitattributes && > > Split the "cat" into a varible, otherwise its failure will be hidden. > Done. > > + git write-tree > id && > > We use ">id" style for redirection, not "> id". > > > + git commit-tree $(cat id) -m "random commit message" > id && > > Ditto.. Will make this change too. Thanks for the review. Will wait a day or two before sending in the next version. -- - Karthik ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 2/2] attr: add flag `-r|--revisions` to work with revisions 2022-12-06 10:37 ` [PATCH 2/2] attr: add flag `-r|--revisions` to work with revisions Karthik Nayak 2022-12-06 11:27 ` Ævar Arnfjörð Bjarmason @ 2022-12-07 0:12 ` Junio C Hamano 2022-12-07 1:10 ` Eric Sunshine ` (2 more replies) 1 sibling, 3 replies; 17+ messages in thread From: Junio C Hamano @ 2022-12-07 0:12 UTC (permalink / raw) To: Karthik Nayak; +Cc: git, toon Karthik Nayak <karthik.188@gmail.com> writes: > Add a new flag `--revision`/`-r` which will allow it work with > revisions. This command will now, instead of checking the files/index, > try and receive the blob for the given attribute file against the > provided revision. The flag overrides checking against the index and > filesystem and also works with bare repositories. As "check-attr" was not invented as a user-facing subcommand but was a hack for debugging, I would have minded this change, but these days people seem to treat it as if it is just one of the proper plumbing commands, the new command line convention bothers me a bit. No other command uses --<anything> to signal that what comes after it is a rev. But I do not think of a better alternative without making the command line ambiguous, so I'll stop at raising a concern, so that others who may be better at UI can come up with one. As to the C API, please do not append the new parameter at the end. When there are no logical ordering among the things listed, be it in the members of a struct or the parameters to a function, we encourage to append, but in this case void git_check_attr(struct index_state *istate, const char *path, struct attr_check *check) we are saying "pick <path>, referring to .gitattributes files from the index as needed, and apply the checks in check[]", and the new behaviour is "pick <path>, referring to .gitattributes files from the tree-ish as needed, and do the same", so istate and the tree-ish object should sit together. Also, at the C API level, I suspect that we strongly prefer to pass around either the "struct object_id *" or "struct tree *", not working with end-user supplied character strings without any sanity-checking or parsing. Another concern, among many existing callers of git_check_attr(), is there any that will conceivably benefit in the future if they could read the attributes from a tree-ish? If not, it may make a lot more sense if you did not butcher them, and instead introduce a new API function git_check_attr_from_tree() and use it in the only place you handle the "-r tree-ish" command line option in the updated part of the "git check-attr" command. Thanks. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 2/2] attr: add flag `-r|--revisions` to work with revisions 2022-12-07 0:12 ` Junio C Hamano @ 2022-12-07 1:10 ` Eric Sunshine 2022-12-07 11:05 ` Karthik Nayak 2022-12-07 11:38 ` Ævar Arnfjörð Bjarmason 2022-12-07 11:40 ` Karthik Nayak 2 siblings, 1 reply; 17+ messages in thread From: Eric Sunshine @ 2022-12-07 1:10 UTC (permalink / raw) To: Junio C Hamano; +Cc: Karthik Nayak, git, toon On Tue, Dec 6, 2022 at 7:15 PM Junio C Hamano <gitster@pobox.com> wrote: > Karthik Nayak <karthik.188@gmail.com> writes: > > Add a new flag `--revision`/`-r` which will allow it work with > > revisions. This command will now, instead of checking the files/index, > > try and receive the blob for the given attribute file against the > > provided revision. The flag overrides checking against the index and > > filesystem and also works with bare repositories. > > As "check-attr" was not invented as a user-facing subcommand but was > a hack for debugging, I would have minded this change, but these > days people seem to treat it as if it is just one of the proper > plumbing commands, the new command line convention bothers me a > bit. No other command uses --<anything> to signal that what comes > after it is a rev. > > But I do not think of a better alternative without making the > command line ambiguous, so I'll stop at raising a concern, so that > others who may be better at UI can come up with one. A few minor comments... We don't usually squat on short options, such as `-r`, right from the start but only add the short alias once shown that there is demand. Option `-r` has strong association with "recursive" elsewhere, so I'd worry about giving it such a completely different meaning here. Rather than calling the option `--revision`, perhaps pattern it after git-restore's `--source` option which allows specifying a particular commit, tree, tag, etc.? ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 2/2] attr: add flag `-r|--revisions` to work with revisions 2022-12-07 1:10 ` Eric Sunshine @ 2022-12-07 11:05 ` Karthik Nayak 0 siblings, 0 replies; 17+ messages in thread From: Karthik Nayak @ 2022-12-07 11:05 UTC (permalink / raw) To: Eric Sunshine; +Cc: Junio C Hamano, git, toon Hey Eric, On Wed, Dec 7, 2022 at 2:10 AM Eric Sunshine <sunshine@sunshineco.com> wrote: > > On Tue, Dec 6, 2022 at 7:15 PM Junio C Hamano <gitster@pobox.com> wrote: > > Karthik Nayak <karthik.188@gmail.com> writes: > > > Add a new flag `--revision`/`-r` which will allow it work with > > > revisions. This command will now, instead of checking the files/index, > > > try and receive the blob for the given attribute file against the > > > provided revision. The flag overrides checking against the index and > > > filesystem and also works with bare repositories. > > > > As "check-attr" was not invented as a user-facing subcommand but was > > a hack for debugging, I would have minded this change, but these > > days people seem to treat it as if it is just one of the proper > > plumbing commands, the new command line convention bothers me a > > bit. No other command uses --<anything> to signal that what comes > > after it is a rev. > > > > But I do not think of a better alternative without making the > > command line ambiguous, so I'll stop at raising a concern, so that > > others who may be better at UI can come up with one. > > A few minor comments... > > We don't usually squat on short options, such as `-r`, right from the > start but only add the short alias once shown that there is demand. > > Option `-r` has strong association with "recursive" elsewhere, so I'd > worry about giving it such a completely different meaning here. > > Rather than calling the option `--revision`, perhaps pattern it after > git-restore's `--source` option which allows specifying a particular > commit, tree, tag, etc.? I'm okay with removing the shortform `-r`. I decided to use `-r|--revision` because it is also used in `git svn`. I don't have strong feeling about the naming here, but I do feel that `-r|--revision` sounds better than `--source`, because source doesn't directly imply a revision and in the context of `git check-attr` is a bit ambiguous because it could imply the source regarding which `gitattributes` file to check against (although this feature doesn't exist). -- - Karthik ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 2/2] attr: add flag `-r|--revisions` to work with revisions 2022-12-07 0:12 ` Junio C Hamano 2022-12-07 1:10 ` Eric Sunshine @ 2022-12-07 11:38 ` Ævar Arnfjörð Bjarmason 2022-12-07 12:33 ` Karthik Nayak 2022-12-07 11:40 ` Karthik Nayak 2 siblings, 1 reply; 17+ messages in thread From: Ævar Arnfjörð Bjarmason @ 2022-12-07 11:38 UTC (permalink / raw) To: Junio C Hamano; +Cc: Karthik Nayak, git, toon On Wed, Dec 07 2022, Junio C Hamano wrote: > Karthik Nayak <karthik.188@gmail.com> writes: > >> Add a new flag `--revision`/`-r` which will allow it work with >> revisions. This command will now, instead of checking the files/index, >> try and receive the blob for the given attribute file against the >> provided revision. The flag overrides checking against the index and >> filesystem and also works with bare repositories. > > As "check-attr" was not invented as a user-facing subcommand but was > a hack for debugging, I would have minded this change, but these > days people seem to treat it as if it is just one of the proper > plumbing commands, the new command line convention bothers me a > bit. No other command uses --<anything> to signal that what comes > after it is a rev. > > But I do not think of a better alternative without making the > command line ambiguous, so I'll stop at raising a concern, so that > others who may be better at UI can come up with one. I don't really like it either, but maybe we've backed ourselves into a corner here. But let's look at that. So the command takes: git check-attr <attr>... -- <path>... Or: echo "<path>" | git check-attr --stdin <attr>... So we'd want to specify a <revision>, without making the <attr> or <path> ambiguous. Now, when we map the attributes we go through attr_name_valid(), which checks that the attribute names are valid. A commentthere says: * Attribute name cannot begin with '-' and must consist of * characters from [-A-Za-z0-9_.]. So can't we instead accept: git check-attr [<rev>:]<attr>... -- <path>... I.e.: git check-attr HEAD~:foo -- path And it wouldn't be ambiguous because attribute names can't contain ":"? This would be consistent with e.g. "git show" and "git cat-file", just with "<attr>" instead of the "<path>". This would also mean that we'd support: git check-attr HEAD:foo HEAD~:bar HEAD~2:baz etc., i.e. the ability to support multiple revision/attribute pairs. Skimming the currently proposed code there seems to be no good reason not to support that (we just need to look up other blobs), and it would allow querying those without spawning N processes. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 2/2] attr: add flag `-r|--revisions` to work with revisions 2022-12-07 11:38 ` Ævar Arnfjörð Bjarmason @ 2022-12-07 12:33 ` Karthik Nayak 0 siblings, 0 replies; 17+ messages in thread From: Karthik Nayak @ 2022-12-07 12:33 UTC (permalink / raw) To: Ævar Arnfjörð Bjarmason; +Cc: Junio C Hamano, git, toon On Wed, Dec 7, 2022 at 12:48 PM Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote: > > > On Wed, Dec 07 2022, Junio C Hamano wrote: > > > Karthik Nayak <karthik.188@gmail.com> writes: > > > >> Add a new flag `--revision`/`-r` which will allow it work with > >> revisions. This command will now, instead of checking the files/index, > >> try and receive the blob for the given attribute file against the > >> provided revision. The flag overrides checking against the index and > >> filesystem and also works with bare repositories. > > > > As "check-attr" was not invented as a user-facing subcommand but was > > a hack for debugging, I would have minded this change, but these > > days people seem to treat it as if it is just one of the proper > > plumbing commands, the new command line convention bothers me a > > bit. No other command uses --<anything> to signal that what comes > > after it is a rev. > > > > But I do not think of a better alternative without making the > > command line ambiguous, so I'll stop at raising a concern, so that > > others who may be better at UI can come up with one. > > I don't really like it either, but maybe we've backed ourselves into a > corner here. > > But let's look at that. So the command takes: > > git check-attr <attr>... -- <path>... > > Or: > > echo "<path>" | > git check-attr --stdin <attr>... > > So we'd want to specify a <revision>, without making the <attr> or > <path> ambiguous. > > Now, when we map the attributes we go through attr_name_valid(), which > checks that the attribute names are valid. A commentthere says: > > * Attribute name cannot begin with '-' and must consist of > * characters from [-A-Za-z0-9_.]. > > So can't we instead accept: > > git check-attr [<rev>:]<attr>... -- <path>... > > I.e.: > > git check-attr HEAD~:foo -- path > > And it wouldn't be ambiguous because attribute names can't contain ":"? > This would be consistent with e.g. "git show" and "git cat-file", just > with "<attr>" instead of the "<path>". > > This would also mean that we'd support: > > git check-attr HEAD:foo HEAD~:bar HEAD~2:baz > > etc., i.e. the ability to support multiple revision/attribute > pairs. Skimming the currently proposed code there seems to be no good > reason not to support that (we just need to look up other blobs), and it > would allow querying those without spawning N processes. Thanks for this walkthrough, quick question, this wouldn't work with the `-a` condition, right? Current patch series tends to work with/without `-a`. Also, my personal opinion is that when being consistent we need to be fully consistent, i.e. <revision>:<path>, tweaking this slightly to be <revision>:<attr> is worse than breaking consistency. -- - Karthik ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 2/2] attr: add flag `-r|--revisions` to work with revisions 2022-12-07 0:12 ` Junio C Hamano 2022-12-07 1:10 ` Eric Sunshine 2022-12-07 11:38 ` Ævar Arnfjörð Bjarmason @ 2022-12-07 11:40 ` Karthik Nayak 2022-12-07 11:53 ` Ævar Arnfjörð Bjarmason 2 siblings, 1 reply; 17+ messages in thread From: Karthik Nayak @ 2022-12-07 11:40 UTC (permalink / raw) To: Junio C Hamano; +Cc: git, toon On Wed, Dec 7, 2022 at 1:12 AM Junio C Hamano <gitster@pobox.com> wrote: > > Karthik Nayak <karthik.188@gmail.com> writes: > > > Add a new flag `--revision`/`-r` which will allow it work with > > revisions. This command will now, instead of checking the files/index, > > try and receive the blob for the given attribute file against the > > provided revision. The flag overrides checking against the index and > > filesystem and also works with bare repositories. > > As "check-attr" was not invented as a user-facing subcommand but was > a hack for debugging, I would have minded this change, but these > days people seem to treat it as if it is just one of the proper > plumbing commands, the new command line convention bothers me a > bit. No other command uses --<anything> to signal that what comes > after it is a rev. > > But I do not think of a better alternative without making the > command line ambiguous, so I'll stop at raising a concern, so that > others who may be better at UI can come up with one. > I understand this concern, but I do think it would be really useful. I see that Taylor and Brian have also mentioned how this would be useful. As such, I think it's a good indication to take this forward. > As to the C API, please do not append the new parameter at the end. > When there are no logical ordering among the things listed, be it in > the members of a struct or the parameters to a function, we encourage > to append, but in this case > > void git_check_attr(struct index_state *istate, > const char *path, > struct attr_check *check) > > we are saying "pick <path>, referring to .gitattributes files from > the index as needed, and apply the checks in check[]", and the new > behaviour is "pick <path>, referring to .gitattributes files from > the tree-ish as needed, and do the same", so istate and the tree-ish > object should sit together. > I will be more cognizant of this approach and make these changes. > Also, at the C API level, I suspect that we strongly prefer to pass > around either the "struct object_id *" or "struct tree *", not working > with end-user supplied character strings without any sanity-checking > or parsing. > I must admit, I did take the path of least resistance here. So we finally need to parse the `revision:<pathname>` where the `<pathname>` is generated dynamically as we move through the check-attr stack. My question is, if I generate an `object_id` at the start (in builtin/check-attr.c) with only the `revision`, is there a way to traverse to find the blob for each of the different <pathnames>? I haven't looked at Git code for a while now, and I'm not sure what the best way to do this. Maybe I've missed some API which would make this simple, any help is appreciated. > Another concern, among many existing callers of git_check_attr(), > is there any that will conceivably benefit in the future if they > could read the attributes from a tree-ish? If not, it may make a > lot more sense if you did not butcher them, and instead introduce a > new API function git_check_attr_from_tree() and use it in the only > place you handle the "-r tree-ish" command line option in the > updated part of the "git check-attr" command. > The concern then is that we'll also have to duplicate some of the code in `git_all_attrs` and `git_check_attr` and have some logic to work correctly for with and without the `-a` option. All in all, this was much easier. I don't have enough knowledge to say if the other callers will someday want to extend to providing a revision too, so I'll leave that to you! > Thanks. Thanks for the review. -- - Karthik ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 2/2] attr: add flag `-r|--revisions` to work with revisions 2022-12-07 11:40 ` Karthik Nayak @ 2022-12-07 11:53 ` Ævar Arnfjörð Bjarmason 2022-12-07 12:29 ` Karthik Nayak 0 siblings, 1 reply; 17+ messages in thread From: Ævar Arnfjörð Bjarmason @ 2022-12-07 11:53 UTC (permalink / raw) To: Karthik Nayak; +Cc: Junio C Hamano, git, toon On Wed, Dec 07 2022, Karthik Nayak wrote: > On Wed, Dec 7, 2022 at 1:12 AM Junio C Hamano <gitster@pobox.com> wrote: > [...] >> Also, at the C API level, I suspect that we strongly prefer to pass >> around either the "struct object_id *" or "struct tree *", not working >> with end-user supplied character strings without any sanity-checking >> or parsing. >> > > I must admit, I did take the path of least resistance here. So we finally need > to parse the `revision:<pathname>` where the `<pathname>` is generated > dynamically as we move through the check-attr stack. > > My question is, if I generate an `object_id` at the start (in > builtin/check-attr.c) > with only the `revision`, is there a way to traverse to find the blob > for each of > the different <pathnames>? I haven't looked at Git code for a while now, and > I'm not sure what the best way to do this. Maybe I've missed some API which > would make this simple, any help is appreciated. The get_oid() that you're doing now happens in a loop, and should be pulled out of it. I suggested making that a feature in https://lore.kernel.org/git/221207.86lenja0zi.gmgdl@evledraar.gmail.com/; but if you keep the interface you've got where you only support a single <rev> it would make the most sense to do that get_oid() in the builtin/ code at the start, and then pass the oid/path pair down. You'd still need to call read_object_file() or equivalent for each <rev>:<path> pair though. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 2/2] attr: add flag `-r|--revisions` to work with revisions 2022-12-07 11:53 ` Ævar Arnfjörð Bjarmason @ 2022-12-07 12:29 ` Karthik Nayak 0 siblings, 0 replies; 17+ messages in thread From: Karthik Nayak @ 2022-12-07 12:29 UTC (permalink / raw) To: Ævar Arnfjörð Bjarmason; +Cc: Junio C Hamano, git, toon On Wed, Dec 7, 2022 at 12:56 PM Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote: > > > On Wed, Dec 07 2022, Karthik Nayak wrote: > > > On Wed, Dec 7, 2022 at 1:12 AM Junio C Hamano <gitster@pobox.com> wrote: > > [...] > >> Also, at the C API level, I suspect that we strongly prefer to pass > >> around either the "struct object_id *" or "struct tree *", not working > >> with end-user supplied character strings without any sanity-checking > >> or parsing. > >> > > > > I must admit, I did take the path of least resistance here. So we finally need > > to parse the `revision:<pathname>` where the `<pathname>` is generated > > dynamically as we move through the check-attr stack. > > > > My question is, if I generate an `object_id` at the start (in > > builtin/check-attr.c) > > with only the `revision`, is there a way to traverse to find the blob > > for each of > > the different <pathnames>? I haven't looked at Git code for a while now, and > > I'm not sure what the best way to do this. Maybe I've missed some API which > > would make this simple, any help is appreciated. > > The get_oid() that you're doing now happens in a loop, and should be > pulled out of it. > > I suggested making that a feature in > https://lore.kernel.org/git/221207.86lenja0zi.gmgdl@evledraar.gmail.com/; > but if you keep the interface you've got where you only support a single > <rev> it would make the most sense to do that get_oid() in the builtin/ > code at the start, and then pass the oid/path pair down. > > You'd still need to call read_object_file() or equivalent for each > <rev>:<path> pair though. That's exactly my question, now we're calling `get_oid()` with the pathname. Which would directly give us the object_id for the blob. Whereas if we call `get_oid()` _without_ the pathname, we would still need to get the object_id for the blob. My specific question being, how do I, given: struct object_id oid_1; get_oid(revision, &oid) and pathname, get the equivalent of: struct object_id oid_2; strbuf_addf(&sb, "%s:%s", revision, path); get_oid(sb.buf, &oid) ? Basically, I fail to see how to transform oid_1 to oid_2, using pathname. I agree this would eventually be fed into `read_object_file`. -- - Karthik ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 0/2] check-attr: add support to work with revisions 2022-12-06 10:37 [PATCH 0/2] check-attr: add support to work with revisions Karthik Nayak 2022-12-06 10:37 ` [PATCH 1/2] t0003: move setup for `--all` into new block Karthik Nayak 2022-12-06 10:37 ` [PATCH 2/2] attr: add flag `-r|--revisions` to work with revisions Karthik Nayak @ 2022-12-06 11:20 ` Philip Oakley 2022-12-06 13:00 ` Karthik Nayak 2022-12-07 1:09 ` Taylor Blau 3 siblings, 1 reply; 17+ messages in thread From: Philip Oakley @ 2022-12-06 11:20 UTC (permalink / raw) To: Karthik Nayak, git; +Cc: toon Hi Karthik , On 06/12/2022 10:37, Karthik Nayak wrote: > Given a pathname, git-check-attr(1) will list the attributes which apply to that > pathname by reading all relevant gitattributes files. Currently there is no way > to specify a revision to read the gitattributes from. > > This is specifically useful in bare repositories wherein the gitattributes are > only present in the git working tree but not available directly on the > filesystem. > > This series aims to add a new flag `-r|--revisions` to git-check-attr(1) which > allows us to read gitattributes from the specified revision. Won't this also need a man page update? I don't see any changes to git/Documentation/git-check-attr.txt. Philip > > Karthik Nayak (2): > t0003: move setup for `--all` into new block > attr: add flag `-r|--revisions` to work with revisions > > archive.c | 2 +- > attr.c | 120 ++++++++++++++++++++++++++++------------- > attr.h | 7 ++- > builtin/check-attr.c | 25 ++++----- > builtin/pack-objects.c | 2 +- > convert.c | 2 +- > ll-merge.c | 4 +- > pathspec.c | 2 +- > t/t0003-attributes.sh | 63 ++++++++++++++++++++-- > userdiff.c | 2 +- > ws.c | 2 +- > 11 files changed, 170 insertions(+), 61 deletions(-) > ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 0/2] check-attr: add support to work with revisions 2022-12-06 11:20 ` [PATCH 0/2] check-attr: add support " Philip Oakley @ 2022-12-06 13:00 ` Karthik Nayak 0 siblings, 0 replies; 17+ messages in thread From: Karthik Nayak @ 2022-12-06 13:00 UTC (permalink / raw) To: philipoakley; +Cc: git, toon Hey Philip, On Tue, Dec 6, 2022 at 12:20 PM Philip Oakley <philipoakley@iee.email> wrote: > > Won't this also need a man page update? I don't see any changes to > git/Documentation/git-check-attr.txt. > You're right, I totally missed that, will add it to the v2 of the series. Thanks! - Karthik ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 0/2] check-attr: add support to work with revisions 2022-12-06 10:37 [PATCH 0/2] check-attr: add support to work with revisions Karthik Nayak ` (2 preceding siblings ...) 2022-12-06 11:20 ` [PATCH 0/2] check-attr: add support " Philip Oakley @ 2022-12-07 1:09 ` Taylor Blau 2022-12-07 2:11 ` brian m. carlson 3 siblings, 1 reply; 17+ messages in thread From: Taylor Blau @ 2022-12-07 1:09 UTC (permalink / raw) To: Karthik Nayak; +Cc: git, toon On Tue, Dec 06, 2022 at 11:37:34AM +0100, Karthik Nayak wrote: > This series aims to add a new flag `-r|--revisions` to git-check-attr(1) which > allows us to read gitattributes from the specified revision. I haven't looked at the patches below yet, so take my $.02 with a grain of salt, but I have definitely wished for something like this in the past. When scripting around to figure out which files at a given revision are affected by a given attribute, I will often have to resort to writing something like this when working in a bare repository: for repo in $LIST_OF_REPOS do export GIT_DIR="$repo" index="$(mktemp ...)" git read-tree --index-output="$index" HEAD 2>/dev/null || continue git ls-tree -rz --name-only HEAD | GIT_INDEX_FILE="$index" git check-attr --cached --stdin -z $attr | ruby -e ' print $stdin.readlines.join.split("\0"). each_slice(3). select { |path, _, val| val != "unspecified" && val != "unset" }. map(&:first).join("\0") ' done Which is just kind of gross. I had at one point when writing the above script wished for a '--blob' source option to check-attr. That might be sensible, but I think being able to read from an arbitrary revision (looking at all of the relevant .gitattributes file(s) recursively throughout the tree) is even more useful, since it allows you to accurately construct the attributes state in its entirety. Anyway, my point is that I think that this is a useful feature, and one that I (and I suspect other users, too) have wished for frequently in the past. Thanks, Taylor ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 0/2] check-attr: add support to work with revisions 2022-12-07 1:09 ` Taylor Blau @ 2022-12-07 2:11 ` brian m. carlson 0 siblings, 0 replies; 17+ messages in thread From: brian m. carlson @ 2022-12-07 2:11 UTC (permalink / raw) To: Taylor Blau; +Cc: Karthik Nayak, git, toon [-- Attachment #1: Type: text/plain, Size: 513 bytes --] On 2022-12-07 at 01:09:09, Taylor Blau wrote: > Anyway, my point is that I think that this is a useful feature, and one > that I (and I suspect other users, too) have wished for frequently in > the past. I fully agree. This would have come in useful for me many times, and I can tell you as one of the maintainers of Git LFS that this will be enormously useful to many users of that tool as well. I'm glad to see this series come by. -- brian m. carlson (he/him or they/them) Toronto, Ontario, CA [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 263 bytes --] ^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2022-12-07 12:34 UTC | newest] Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-12-06 10:37 [PATCH 0/2] check-attr: add support to work with revisions Karthik Nayak 2022-12-06 10:37 ` [PATCH 1/2] t0003: move setup for `--all` into new block Karthik Nayak 2022-12-06 10:37 ` [PATCH 2/2] attr: add flag `-r|--revisions` to work with revisions Karthik Nayak 2022-12-06 11:27 ` Ævar Arnfjörð Bjarmason 2022-12-06 13:06 ` Karthik Nayak 2022-12-07 0:12 ` Junio C Hamano 2022-12-07 1:10 ` Eric Sunshine 2022-12-07 11:05 ` Karthik Nayak 2022-12-07 11:38 ` Ævar Arnfjörð Bjarmason 2022-12-07 12:33 ` Karthik Nayak 2022-12-07 11:40 ` Karthik Nayak 2022-12-07 11:53 ` Ævar Arnfjörð Bjarmason 2022-12-07 12:29 ` Karthik Nayak 2022-12-06 11:20 ` [PATCH 0/2] check-attr: add support " Philip Oakley 2022-12-06 13:00 ` Karthik Nayak 2022-12-07 1:09 ` Taylor Blau 2022-12-07 2:11 ` brian m. carlson
Code repositories for project(s) associated with this public inbox https://80x24.org/mirrors/git.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).