Re: [PATCH 0/4] pre-merge hook

Michael J Gruber writes: > Now that f8b863598c ("builtin/merge: honor commit-msg hook for merges", > 2017-09-07) has landed, merge is getting closer to behaving like commit, > which is important because both are used to complete merges (automatic > vs. non-automatic). Just a

[PATCH] ref-filter.c: pass empty-string as NULL to atom parsers

Peff points out that different atom parsers handle the empty "sub-argument" list differently. An example of this is the format "%(refname:)". Since callers often use `string_list_split` (which splits the empty string with any delimiter as a 1-ary string_list containing the empty string), this

Re: [PATCH 07/11] apply: remove `newfd` from `struct apply_state`

On Sun, Oct 01, 2017 at 04:56:08PM +0200, Martin Ågren wrote: > Similar to a previous patch, we do not need to use `newfd` to signal > that we have a lockfile to clean up. We can just unconditionally call > `rollback_lock_file`. If we do not hold the lock, it will be a no-op. > > Where we check

[PATCH 0/1] ref-filter.c: pass empty-string as NULL to atom parsers

Hi, Attached is a one-long patch series to un-distinguish between atoms without sub-arguments ("%(refname)") and atoms with empty sub-argument lists ("%(refname:)"). This addresses a user-experience issue that Peff points out: > Doh, that string_list behavior is what I was missing in my earlier

Re: [PATCH 06/11] apply: move lockfile into `apply_state`

On Sun, Oct 01, 2017 at 04:56:07PM +0200, Martin Ågren wrote: > We have two users of `struct apply_state` and the related functionality > in apply.c. Each user sets up its `apply_state` by handing over a > pointer to its static `lock_file`. (Before 076aa2cbd (tempfile: > auto-allocate tempfiles

Re: [PATCH 05/11] cache-tree: simplify locking logic

On Sun, Oct 01, 2017 at 04:56:06PM +0200, Martin Ågren wrote: > After we have taken the lock using `LOCK_DIE_ON_ERROR`, we know that > `newfd` is non-negative. So when we check for exactly that property > before calling `write_locked_index()`, the outcome is guaranteed. > > If we write and

Re: [PATCH 04/11] tempfile: fix documentation on `delete_tempfile()`

On Sun, Oct 01, 2017 at 04:56:05PM +0200, Martin Ågren wrote: > The function has always been documented as returning 0 or -1. It is in > fact `void`. Correct that. As part of the rearrangements we lose the > mention that `delete_tempfile()` might set `errno`. Because there is > no return value,

Re: [PATCH 03/11] lockfile: fix documentation on `close_lock_file_gently()`

On Sun, Oct 01, 2017 at 04:56:04PM +0200, Martin Ågren wrote: > Commit 83a3069a3 (lockfile: do not rollback lock on failed close, > 2017-09-05) forgot to update the documentation by the function definition > to reflect that the lock is not rolled back in case closing fails. Oops, thanks for

Re: [PATCH 02/11] treewide: prefer lockfiles on the stack

On Sun, Oct 01, 2017 at 04:56:03PM +0200, Martin Ågren wrote: > There is no longer any need to allocate and leak a `struct lock_file`. > The previous patch addressed an instance where we needed a minor tweak > alongside the trivial changes. > > Deal with the remaining instances where we allocate

Re: [PATCH 01/11] sha1_file: do not leak `lock_file`

On Sun, Oct 01, 2017 at 04:56:02PM +0200, Martin Ågren wrote: > There is no longer any need to allocate and leak a `struct lock_file`. > Initialize it on the stack instead. > > Instead of setting `lock = NULL` to signal that we have already rolled > back, and that we should not do any more work,

[PATCH v6 6/7] ref-filter.c: use trailer_opts to format trailers

Fill trailer_opts with "unfold" and "only" to match the sub-arguments given to the "%(trailers)" atom. Then, let's use the filled trailer_opts instance with 'format_trailers_from_commit' in order to format trailers in the desired manner. Signed-off-by: Taylor Blau ---

[PATCH v6 5/7] t6300: refactor %(trailers) tests

We currently have one test for %(trailers) in `git-for-each-ref(1)`, through "%(contents:trailers)". In preparation for more, let's add a few things: - Move the commit creation step to its own test so that it can be re-used. - Add a non-trailer to the commit's trailers to test that

[PATCH v6 7/7] ref-filter.c: parse trailers arguments with %(contents) atom

The %(contents) atom takes a contents "field" as its argument. Since "trailers" is one of those fields, extend contents_atom_parser to parse "trailers"'s arguments when used through "%(contents)", like: %(contents:trailers:unfold,only) A caveat: trailers_atom_parser expects NULL when no

[PATCH v6 4/7] doc: use modern "`"-style code quoting

"'"- (single-quote) styled code quoting is no longer considered modern within the "Documentation/" subtree. In preparation for adding additional information to this section of git-for-each-ref(1)'s documentation, update old-style code quoting to use "`"-style quoting instead. Signed-off-by:

[PATCH v6 1/7] pretty.c: delimit "%(trailers)" arguments with ","

In preparation for adding consistent "%(trailers)" atom options to `git-for-each-ref(1)`'s "--format" argument, change "%(trailers)" in pretty.c to separate sub-arguments with a ",", instead of a ":". Multiple sub-arguments are given either as "%(trailers:unfold,only)" or

[PATCH v6 3/7] doc: 'trailers' is the preferred way to format trailers

The documentation makes reference to 'contents:trailers' as an example to dig the trailers out of a commit. 'trailers' is an unmentioned alternative, which is treated as an alias of 'contents:trailers'. Since 'trailers' is easier to type, prefer that as the designated way to dig out trailers

[PATCH v6 2/7] t4205: unfold across multiple lines

Tests in t4205 test the following: git log --format='%(trailers:unfold)' ... By ensuring the multi-line trailers are unfolded back onto the same line. t4205 only includes tests for 2-line trailers, but `unfold()` will fail for folded trailers on 3 or more lines. In preparation for adding

Re: [PATCH v6 0/7] Support %(trailers) arguments in for-each-ref(1)

Hi, Attached is the sixth revision of my patch-set "Support %(trailers) arguments in for-each-ref(1)". In includes the following changes since v5: * Added an additional patch to change t4205 to harden `unfold()` against multi-line trailer folding. * Added a missing parameter call in

Re: [PATCH 2/2] commit: use strbuf_add() to add a buffer to a strbuf

On Sun, Oct 01, 2017 at 04:54:14PM +0200, René Scharfe wrote: > This is shorter, easier and makes the intent clearer. > > Patch generated with Coccinelle and contrib/coccinelle/strbuf.cocci. Technically this behaves differently if there is a NUL embedded in the string. I'd expect that to be

Re: [PATCH v5 6/6] ref-filter.c: parse trailers arguments with %(contents) atom

On Sun, Oct 01, 2017 at 10:12:16PM -0700, Taylor Blau wrote: > > Doh, that string_list behavior is what I was missing in my earlier > > comments. I agree this is probably the best way of doing it. I'm tempted > > to say that parse_ref_filter_atom() should do a similar thing. Right now > > we've

Re: [PATCH v5 6/6] ref-filter.c: parse trailers arguments with %(contents) atom

On Mon, Oct 02, 2017 at 01:51:11PM +0900, Junio C Hamano wrote: > Taylor Blau writes: > > > @@ -212,9 +212,10 @@ static void contents_atom_parser(const struct > > ref_format *format, struct used_at > > atom->u.contents.option = C_SIG; > > else if (!strcmp(arg,

Re: [PATCH v5 6/6] ref-filter.c: parse trailers arguments with %(contents) atom

On Mon, Oct 02, 2017 at 01:03:51AM -0400, Jeff King wrote: > On Sun, Oct 01, 2017 at 05:33:04PM -0700, Taylor Blau wrote: > > > The %(contents) atom takes a contents "field" as its argument. Since > > "trailers" is one of those fields, extend contents_atom_parser to parse > > "trailers"'s

Re: [PATCH] graph: use strbuf_addchars() to add spaces

On Sun, Oct 01, 2017 at 04:45:45PM +0200, René Scharfe wrote: > strbuf_addf() can be used to add a specific number of space characters > by using the format "%*s" with an empty string and specifying the > desired width. Use strbuf_addchars() instead as it's shorter, makes the > intent clearer

Re: [PATCH 4/5] ref-filter.c: use trailer_opts to format trailers

On Mon, Oct 02, 2017 at 01:05:07AM -0400, Jeff King wrote: > On Sun, Oct 01, 2017 at 06:00:25PM +0900, Junio C Hamano wrote: > > > Taylor Blau writes: > > > > > diff --git a/t/t6300-for-each-ref.sh b/t/t6300-for-each-ref.sh > > > index 2a9fcf713..2bd0c5da7 100755 > > > ---

Re: [PATCH] tag: avoid NULL pointer arithmetic

On Sun, Oct 01, 2017 at 04:45:13PM +0200, René Scharfe wrote: > lookup_blob() etc. can return NULL if the referenced object isn't of the > expected type. In theory it's wrong to reference the object member in > that case. In practice it's OK because it's located at offset 0 for all > types, so

Re: [PATCH 4/5] ref-filter.c: use trailer_opts to format trailers

On Sun, Oct 01, 2017 at 06:00:25PM +0900, Junio C Hamano wrote: > Taylor Blau writes: > > > diff --git a/t/t6300-for-each-ref.sh b/t/t6300-for-each-ref.sh > > index 2a9fcf713..2bd0c5da7 100755 > > --- a/t/t6300-for-each-ref.sh > > +++ b/t/t6300-for-each-ref.sh > > @@ -597,6

Re: [PATCH v5 6/6] ref-filter.c: parse trailers arguments with %(contents) atom

On Sun, Oct 01, 2017 at 05:33:04PM -0700, Taylor Blau wrote: > The %(contents) atom takes a contents "field" as its argument. Since > "trailers" is one of those fields, extend contents_atom_parser to parse > "trailers"'s arguments when used through "%(contents)", like: > >

Re: [PATCH v4 1/6] pretty.c: delimit "%(trailers)" arguments with ","

On Mon, Oct 02, 2017 at 09:11:50AM +0900, Junio C Hamano wrote: > > diff --git a/pretty.c b/pretty.c > > index 94eab5c89..eec128bc1 100644 > > --- a/pretty.c > > +++ b/pretty.c > > @@ -1056,6 +1056,25 @@ static size_t parse_padding_placeholder(struct > > strbuf *sb, > > return 0; > > } > >

Re: [PATCH v4 4/6] doc: use modern "`"-style code fencing

On Mon, Oct 02, 2017 at 10:35:45AM +0900, Junio C Hamano wrote: > Taylor Blau writes: > > >> Is this just me who wants to do s/fenc/quot/g? Unless somebody > >> objects, I'd do so while queuing. > > > > I don't object, I think that fencing is less appropriate than quoting. >

Re: [PATCH v5 6/6] ref-filter.c: parse trailers arguments with %(contents) atom

Taylor Blau writes: > @@ -212,9 +212,10 @@ static void contents_atom_parser(const struct ref_format > *format, struct used_at > atom->u.contents.option = C_SIG; > else if (!strcmp(arg, "subject")) > atom->u.contents.option = C_SUB; > -

Re: [PATCH v5 6/6] ref-filter.c: parse trailers arguments with %(contents) atom

Taylor Blau writes: > A caveat: trailers_atom_parser expects NULL when no arguments are given > (see: `parse_ref_filter_atom`). This is because string_list_split (given > a maxsplit of -1) returns a 1-ary string_list* containing the given > string if the delimiter could not be

Re: [PATCH 00/18] Partial clone (from clone to lazy fetch in 18 patches)

Jonathan Tan writes: > Jeff Hostetler has sent out some object-filtering patches [1] that is a > superset of the object-filtering functionality that I have (in the > pack-objects patches). I have gone for the minimal approach here, but if > his patches are merged, I'll

Re: [PATCH 09/11] read-cache: require flags for `write_locked_index()`

On 2 October 2017 at 05:49, Junio C Hamano wrote: > Martin Ågren writes: > >> ... Instead, require that one of the >> flags is set. Adjust documentation and the assert we already have for >> checking that we don't have too many flags. Add a macro

Re: [PATCH] tag: avoid NULL pointer arithmetic

René Scharfe writes: > lookup_blob() etc. can return NULL if the referenced object isn't of the > expected type. In theory it's wrong to reference the object member in > that case. In practice it's OK because it's located at offset 0 for all > types, so the pointer arithmetic

Re: [PATCH 02/11] treewide: prefer lockfiles on the stack

On 2 October 2017 at 05:37, Junio C Hamano wrote: > Martin Ågren writes: > > This is not a show-stopper for this patch series, but just something > I noticed, something that used to be unavoidable in the old world > order that requires us to leak

Re: [PATCH] builtin/: add UNLEAKs

Martin Ågren writes: > ... While addressing `msg` in builtin/tag.c, convert the existing > `strbuf_release()` calls as well. That part of this patch made me raise eyebrows a bit but only slightly. We are about to leave the function to exit anyway, and all the other that

Re: [PATCH 11/11] read-cache: roll back lock on error with `COMMIT_LOCK`

Martin Ågren writes: > Teach `write_locked_index(..., COMMIT_LOCK)` to roll back the lock > before returning. If we have already succeeded and committed, it will be > a noop. Simplify the existing callers where we now have a superfluous > call to `rollback_lockfile()`.

Re: [PATCH 09/11] read-cache: require flags for `write_locked_index()`

Martin Ågren writes: > ... Instead, require that one of the > flags is set. Adjust documentation and the assert we already have for > checking that we don't have too many flags. Add a macro `HAS_SINGLE_BIT` > (inspired by `HAS_MULTI_BITS`) to simplify this check and

Re: [PATCH 05/11] cache-tree: simplify locking logic

Martin Ågren writes: > After we have taken the lock using `LOCK_DIE_ON_ERROR`, we know that > `newfd` is non-negative. So when we check for exactly that property > before calling `write_locked_index()`, the outcome is guaranteed. > > If we write and commit successfully,

Re: [PATCH 02/11] treewide: prefer lockfiles on the stack

Martin Ågren writes: > diff --git a/builtin/diff.c b/builtin/diff.c > index 7e3ebcea3..91995965d 100644 > --- a/builtin/diff.c > +++ b/builtin/diff.c > @@ -203,17 +203,16 @@ static int builtin_diff_combined(struct rev_info *revs, > > static void

Re: [PATCH 00/11] various lockfile-leaks and -fixes

Martin Ågren writes: > Martin Ågren (11): > sha1_file: do not leak `lock_file` > treewide: prefer lockfiles on the stack > lockfile: fix documentation on `close_lock_file_gently()` > tempfile: fix documentation on `delete_tempfile()` > cache-tree: simplify

Re: [PATCH v4 4/6] doc: use modern "`"-style code fencing

Taylor Blau writes: >> Is this just me who wants to do s/fenc/quot/g? Unless somebody >> objects, I'd do so while queuing. > > I don't object, I think that fencing is less appropriate than quoting. > I couldn't find the term myself when writing this commit :-). > > I am happy

Re: [PATCH v6 3/3] submodule: port submodule subcommand 'status' from shell to C

Prathamesh Chavan writes: > > #define CB_OPT_QUIET (1<<0) > +#define CB_OPT_CACHED(1<<1) > +#define CB_OPT_RECURSIVE (1<<2) Same comments on both naming and formatting. > @@ -245,6 +250,53 @@ static char *get_submodule_displaypath(const char

Re: [PATCH v6 2/3] submodule--helper: introduce for_each_listed_submodule()

Prathamesh Chavan writes: > Introduce function for_each_listed_submodule() and replace a loop > in module_init() with a call to it. > > The new function will also be used in other parts of the > system in later patches. > > Mentored-by: Christian Couder

Re: [PATCH v6 1/3] submodule--helper: introduce get_submodule_displaypath()

This step looks good to me. Thanks.

Re: [PATCH v6 0/3] Incremental rewrite of git-submodules

Prathamesh Chavan writes: > * The function get_submodule_displaypath() was modified for the case > when get_super_prefix() returns a non-null value. The condition to check > if the super-prefix ends with a '/' is removed. To accomodate this change > appropriate value of

[PATCH v5 4/6] doc: use modern "`"-style code quoting

"'"- (single-quote) styled code quoting is no longer considered modern within the "Documentation/" subtree. In preparation for adding additional information to this section of git-for-each-ref(1)'s documentation, update old-style code quoting to use "`"-style quoting instead. Signed-off-by:

[PATCH v5 6/6] ref-filter.c: parse trailers arguments with %(contents) atom

The %(contents) atom takes a contents "field" as its argument. Since "trailers" is one of those fields, extend contents_atom_parser to parse "trailers"'s arguments when used through "%(contents)", like: %(contents:trailers:unfold,only) A caveat: trailers_atom_parser expects NULL when no

[PATCH v5 5/6] ref-filter.c: use trailer_opts to format trailers

Fill trailer_opts with "unfold" and "only" to match the sub-arguments given to the "%(trailers)" atom. Then, let's use the filled trailer_opts instance with 'format_trailers_from_commit' in order to format trailers in the desired manner. Signed-off-by: Taylor Blau ---

[PATCH v5 2/6] t6300: refactor %(trailers) tests

We currently have one test for %(trailers) in `git-for-each-ref(1)`, through "%(contents:trailers)". In preparation for more, let's add a few things: - Move the commit creation step to its own test so that it can be re-used. - Add a non-trailer to the commit's trailers to test that

[PATCH v5 1/6] pretty.c: delimit "%(trailers)" arguments with ","

In preparation for adding consistent "%(trailers)" atom options to `git-for-each-ref(1)`'s "--format" argument, change "%(trailers)" in pretty.c to separate sub-arguments with a ",", instead of a ":". Multiple sub-arguments are given either as "%(trailers:unfold,only)" or

[PATCH v5 3/6] doc: 'trailers' is the preferred way to format trailers

The documentation makes reference to 'contents:trailers' as an example to dig the trailers out of a commit. 'trailers' is an unmentioned alternative, which is treated as an alias of 'contents:trailers'. Since 'trailers' is easier to type, prefer that as the designated way to dig out trailers

Re: [PATCH v5 0/6] Support %(trailers) arguments in for-each-ref(1)

Hi, Attached is the fifth revision of my patch-set "Support %(trailers) arguments in for-each-ref(1)". It includes the following changes since v4: * Clarified "ref-filter.c: parse trailers arguments with %(contents) atom" to include reasoning for passing NULL as "" empty string in

Re: "man git-checkout", man page is inconsistent between SYNOPSIS and details

"Robert P. J. Day" writes: > ok, i'm going to have to digest all that; pretty sure someone else > will need to change the man page to clarify the apparent inconsistency > i was referring to: > > SYNOPSIS >git checkout [-p|--patch] [] [--] [...] > DESCRIPTION >

Re: [PATCH v4 6/6] ref-filter.c: parse trailers arguments with %(contents) atom

Taylor Blau writes: > The %(contents) atom takes a contents "field" as its argument. Since > "trailers" is one of those fields, extend contents_atom_parser to parse > "trailers"'s arguments when used through "%(contents)", like: > > %(contents:trailers:unfold,only) > > A

Re: [PATCH v4 5/6] ref-filter.c: use trailer_opts to format trailers

Taylor Blau writes: > +test_expect_success '%(trailers) rejects unknown trailers arguments' ' > + cat >expect <<-EOF && > + fatal: unknown %(trailers) argument: unsupported > + EOF > + test_must_fail git for-each-ref --format="%(trailers:unsupported)" > 2>actual

Re: [PATCH v4 2/6] t6300: refactor %(trailers) tests

Looks good to me, thanks.

Re: [PATCH v4 1/6] pretty.c: delimit "%(trailers)" arguments with ","

Taylor Blau writes: > In preparation for adding consistent "%(trailers)" atom options to > `git-for-each-ref(1)`'s "--format" argument, change "%(trailers)" in > pretty.c to separate sub-arguments with a ",", instead of a ":". > > Multiple sub-arguments are given either as

Re: [PATCH v4 4/6] doc: use modern "`"-style code fencing

On Mon, Oct 02, 2017 at 08:55:53AM +0900, Junio C Hamano wrote: > Taylor Blau writes: > > > "'"- (single-quote) styled code fencing is no longer considered modern > > within the "Documentation/" subtree. > > > > In preparation for adding additional information to this section

Re: [PATCH v4 4/6] doc: use modern "`"-style code fencing

Taylor Blau writes: > "'"- (single-quote) styled code fencing is no longer considered modern > within the "Documentation/" subtree. > > In preparation for adding additional information to this section of > git-for-each-ref(1)'s documentation, update old-style code fencing to >

[PATCH v3] clang-format: add a comment about the meaning/status of the

From: Stephan Beyer Having a .clang-format file in a project can be understood in a way that code has to be in the style defined by the .clang-format file, i.e., you just have to run clang-format over all code and you are set. This unfortunately is not yet the case in the Git

Re: "man git-stash" explanation of "--include-untracked" and "--all" seems ambiguous

Thomas Gummerer writes: > This is fine when --include-untracked is specified first, as --all > implies --include-untracked, but I guess the behaviour could be a bit > surprising if --all is specified first and --include-untracked later > on the command line. > > Changing

Re: What's cooking in git.git (Sep 2017, #06; Fri, 29)

Derrick Stolee writes: > On 9/29/2017 12:34 AM, Junio C Hamano wrote: >> * ds/find-unique-abbrev-optim (2017-09-19) 4 commits >> - SQUASH??? >> - sha1_name: parse less while finding common prefix >> - sha1_name: unroll len loop in find_unique_abbrev_r() >> - sha1_name:

[PATCH 18/24] Convert remaining callers of resolve_gitlink_ref to object_id

Signed-off-by: brian m. carlson --- diff-lib.c | 4 ++-- dir.c | 8 read-cache.c | 6 +++--- unpack-trees.c | 8 4 files changed, 13 insertions(+), 13 deletions(-) diff --git a/diff-lib.c b/diff-lib.c index 4e0980caa8..af4f1b7865

[PATCH 04/24] refs: convert update_ref and refs_update_ref to use struct object_id

Convert update_ref, refs_update_ref, and write_pseudoref to use struct object_id. Update the existing callers as well. Remove update_ref_oid, as it is no longer needed. Signed-off-by: brian m. carlson --- bisect.c | 6 -- builtin/am.c

[PATCH 13/24] builtin/pack-objects: convert to struct object_id

This is one of the last unconverted callers to peel_ref. While we're fixing that, convert the rest of the file, since it will need to be converted at some point anyway. Signed-off-by: brian m. carlson --- builtin/pack-objects.c | 131

[PATCH 20/24] worktree: convert struct worktree to object_id

Convert the head_sha1 member to be head_oid instead. This is required to convert resolve_ref_unsafe. Signed-off-by: brian m. carlson --- builtin/worktree.c | 6 +++--- worktree.c | 2 +- worktree.h | 2 +- 3 files changed, 5 insertions(+), 5

[PATCH 09/24] refs: convert dwim_ref and expand_ref to struct object_id

All of the callers of these functions just pass the hash member of a struct object_id, so convert them to use a pointer to struct object_id directly. Signed-off-by: brian m. carlson --- archive.c | 2 +- branch.c | 2 +-

[PATCH 12/24] pack-bitmap: convert traverse_bitmap_commit_list to object_id

Convert traverse_bitmap_commit_list and the callbacks it takes to use a pointer to struct object_id. Signed-off-by: brian m. carlson --- builtin/pack-objects.c | 8 builtin/rev-list.c | 4 ++-- pack-bitmap.c | 8 pack-bitmap.h

[PATCH 14/24] refs: convert peel_ref to struct object_id

Convert peel_ref (and its corresponding backend) to struct object_id. This transformation was done with an update to the declaration, definition, and test helper and the following semantic patch: @@ expression E1, E2; @@ - peel_ref(E1, E2.hash) + peel_ref(E1, ) @@ expression E1, E2; @@ -

[PATCH 10/24] builtin/reflog: convert remaining unsigned char uses to object_id

Convert the remaining uses of unsigned char [20] to struct object_id. This conversion is needed for dwim_log. Signed-off-by: brian m. carlson --- builtin/reflog.c | 18 +- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git

[PATCH 19/24] refs: convert resolve_gitlink_ref to struct object_id

Convert the declaration and definition of resolve_gitlink_ref to use struct object_id and apply the following semantic patch: @@ expression E1, E2, E3; @@ - resolve_gitlink_ref(E1, E2, E3.hash) + resolve_gitlink_ref(E1, E2, ) @@ expression E1, E2, E3; @@ - resolve_gitlink_ref(E1, E2, E3->hash) +

[PATCH 21/24] refs: convert resolve_ref_unsafe to struct object_id

Convert resolve_ref_unsafe to take a pointer to struct object_id by converting one remaining caller to use struct object_id, converting the declaration and definition, and applying the following semantic patch: @@ expression E1, E2, E3, E4; @@ - resolve_ref_unsafe(E1, E2, E3.hash, E4) +

[PATCH 16/24] refs: convert reflog_expire parameter to struct object_id

reflog_expire already used struct object_id internally, but it did not take it as a parameter. Adjust the parameter (and the callers) to pass a pointer to struct object_id instead of a pointer to unsigned char. Remove the temporary inserted earlier as it is no longer required. Signed-off-by:

[PATCH 22/24] refs: convert peel_object to struct object_id

Signed-off-by: brian m. carlson --- refs.c| 8 refs/files-backend.c | 2 +- refs/packed-backend.c | 4 ++-- refs/ref-cache.c | 2 +- refs/refs-internal.h | 4 ++-- 5 files changed, 10 insertions(+), 10 deletions(-) diff --git

[PATCH 23/24] refs: convert read_raw_ref backends to struct object_id

Convert the unsigned char * parameter to struct object_id * for files_read_raw_ref and packed_read_raw-ref. Update the documentation. Switch from using get_sha1_hex and a hard-coded 40 to using parse_oid_hex. Signed-off-by: brian m. carlson --- refs.c

[PATCH 15/24] refs: convert read_ref_at to struct object_id

Convert the callers and internals, including struct read_ref_at_cb, of read_ref_at to use struct object_id. Signed-off-by: brian m. carlson --- builtin/show-branch.c | 5 ++--- refs.c| 34 +- refs.h|

[PATCH 07/24] refs: convert resolve_refdup and refs_resolve_refdup to struct object_id

All of the callers already pass the hash member of struct object_id, so update them to pass a pointer to the struct directly, This transformation was done with an update to declaration and definition and the following semantic patch: @@ expression E1, E2, E3, E4; @@ - resolve_refdup(E1, E2,

[PATCH 24/24] refs/files-backend: convert static functions to object_id

Convert several static functions to take pointers to struct object_id. Change the relevant parameters to write_packed_entry to be const, as we don't modify them. Rename lock_ref_sha1_basic to lock_ref_oid_basic to reflect its new argument. Signed-off-by: brian m. carlson

[PATCH 08/24] refs: convert read_ref and read_ref_full to object_id

All but two of the call sites already had parameters using the hash parameter of struct object_id, so convert them to take a pointer to the struct directly. Also convert refs_read_refs_full, the underlying implementation. Signed-off-by: brian m. carlson ---

[PATCH 11/24] refs: convert dwim_log to struct object_id

Signed-off-by: brian m. carlson --- builtin/reflog.c | 4 ++-- reflog-walk.c| 2 +- refs.c | 8 refs.h | 2 +- sha1_name.c | 2 +- 5 files changed, 9 insertions(+), 9 deletions(-) diff --git a/builtin/reflog.c

[PATCH 17/24] sha1_file: convert index_path and index_fd to struct object_id

Convert these two functions and the functions that underlie them to take pointers to struct object_id. This is a prerequisite to convert resolve_gitlink_ref. Fix a stray tab in the middle of the index_mem call in index_pipe by converting it to a space. Signed-off-by: brian m. carlson

[PATCH 03/24] refs: convert delete_ref and refs_delete_ref to struct object_id

Convert delete_ref and refs_delete_ref to take a pointer to struct object_id. Update the documentation accordingly, including referring to null_oid in lowercase, as it is not a #define constant. Signed-off-by: brian m. carlson --- builtin/branch.c | 2 +-

[PATCH 06/24] Convert check_connected to use struct object_id

Convert check_connected and the callbacks it takes to use struct object_id. Signed-off-by: brian m. carlson --- builtin/clone.c| 4 ++-- builtin/fetch.c| 4 ++-- builtin/receive-pack.c | 10 +- connected.c| 18

[PATCH 01/24] walker: convert to struct object_id

Signed-off-by: brian m. carlson --- walker.c | 24 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/walker.c b/walker.c index 274f1a4935..2d83254bc0 100644 --- a/walker.c +++ b/walker.c @@ -7,7 +7,7 @@ #include "blob.h"

[PATCH 05/24] refs: update ref transactions to use struct object_id

Update the ref transaction code to use struct object_id. Remove one NULL pointer check which was previously inserted around a dereference; since we now pass a pointer to struct object_id directly through, the code we're calling handles this for us. Signed-off-by: brian m. carlson

[PATCH 00/24] object_id part 10

This is the tenth in a series of patches to convert from unsigned char [20] to struct object_id. This series mostly involves changes to the refs code. After these changes, there are almost no references to unsigned char in the main refs code. I've tried to update the code comments as I've

[PATCH 02/24] refs/files-backend: convert struct ref_to_prune to object_id

Change the member of this struct to be a struct object_id. Signed-off-by: brian m. carlson --- refs/files-backend.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/refs/files-backend.c b/refs/files-backend.c index fec77744b4..e3968d4f7c

Re: what is git's position on "classic" mac -only end of lines?

On Sun, 1 Oct 2017, Johannes Sixt wrote: > Am 01.10.2017 um 21:29 schrieb Bryan Turner: > > On Sun, Oct 1, 2017 at 10:52 AM, Robert P. J. Day > > wrote: > > > > > >sorry for more pedantic nitpickery, but i'm trying to write a > > > section on how to properly process

Re: [PATCH v2] Add a comment to .clang-format about the meaning of the file

On 10/01/2017 10:30 PM, Junio C Hamano wrote: > I think we do want the endgame to be that .clang-format defines how > the code should look like. It's that we are not there yet, and I > think that is what we should say in this comment. > > Note that this style definition does not yet quite

Re: what is git's position on "classic" mac -only end of lines?

Am 01.10.2017 um 21:29 schrieb Bryan Turner: On Sun, Oct 1, 2017 at 10:52 AM, Robert P. J. Day wrote: sorry for more pedantic nitpickery, but i'm trying to write a section on how to properly process mixtures of EOLs in git, and when i read "man git-config",

Re: "man git-stash" explanation of "--include-untracked" and "--all" seems ambiguous

On Sun, 1 Oct 2017, Thomas Gummerer wrote: > On 09/29, Robert P. J. Day wrote: > > > > from the man page: > > > > "If the --include-untracked option is used, all untracked files > > are also stashed and then cleaned up with git clean, leaving the > > working directory in a very clean state. If

Re: [PATCH v2] Add a comment to .clang-format about the meaning of the file

Stephan Beyer writes: > Having a .clang-format file in a project can be understood in a way that code > has to be in the style defined by the .clang-format file, i.e., you just have > to run clang-format over all code and you are set. This is not the case in the > Git project,

Re: "man git-stash" explanation of "--include-untracked" and "--all" seems ambiguous

On 09/29, Robert P. J. Day wrote: > > from the man page: > > "If the --include-untracked option is used, all untracked files are > also stashed and then cleaned up with git clean, leaving the working > directory in a very clean state. If the --all option is used instead >

Re: what is git's position on "classic" mac -only end of lines?

On Sun, Oct 1, 2017 at 10:52 AM, Robert P. J. Day wrote: > > sorry for more pedantic nitpickery, but i'm trying to write a > section on how to properly process mixtures of EOLs in git, and when i > read "man git-config", everything seems to refer to Mac OS X and macOS >

what is git's position on "classic" mac -only end of lines?

sorry for more pedantic nitpickery, but i'm trying to write a section on how to properly process mixtures of EOLs in git, and when i read "man git-config", everything seems to refer to Mac OS X and macOS (and linux, of course) using for EOL, with very little mention of what one does if faced

[PATCH] builtin/: add UNLEAKs

Add some UNLEAKs where we are about to return from `cmd_*`. UNLEAK the variables in the same order as we've declared them. While addressing `msg` in builtin/tag.c, convert the existing `strbuf_release()` calls as well. Signed-off-by: Martin Ågren --- builtin/checkout.c

Donation for you!!

GREETINGS, My name is Carlos Slim Helu, A philanthropist the CEO and Chairman of the Carlos Slim Helu Foundation Charitable Foundation, one of the largest private foundations in the world. I believe strongly in‘giving while living’ I had one idea that never changed in my mind — that you

[PATCH v4 1/6] pretty.c: delimit "%(trailers)" arguments with ","

In preparation for adding consistent "%(trailers)" atom options to `git-for-each-ref(1)`'s "--format" argument, change "%(trailers)" in pretty.c to separate sub-arguments with a ",", instead of a ":". Multiple sub-arguments are given either as "%(trailers:unfold,only)" or

[PATCH v4 3/6] doc: 'trailers' is the preferred way to format trailers

The documentation makes reference to 'contents:trailers' as an example to dig the trailers out of a commit. 'trailers' is an unmentioned alternative, which is treated as an alias of 'contents:trailers'. Since 'trailers' is easier to type, prefer that as the designated way to dig out trailers

  1   2   >