[PATCHv2 1/2] builtin/commit.c: drop use snprintf via dynamic allocation

In general snprintf is bad because it may silently truncate results if we're wrong. In this patch where we use PATH_MAX, we'd want to handle larger paths anyway, so we switch to dynamic allocation. Helped-by: Jeff King Signed-off-by: Elia Pinto --- This

[PATCHv2 2/2] builtin/commit.c: drop use snprintf via dynamic allocation

In general snprintf is bad because it may silently truncate results if we're wrong. In this patch, instead of using xnprintf, which asserts that we don't truncate, we are switching to dynamic allocation, so we can avoid dealing with magic numbers in the code. Helped-by: Jeff King

Re: [PATCH 2/2] diff: document the pattern format for diff.orderFile

Richard Hansen writes: > I was looking at the code to see how the two file formats differed and > noticed that match_order() doesn't set the WM_PATHNAME flag when it > calls wildmatch(). That's unintentional (a bug), right? It has been that way from day one IIRC even before

[PATCH v2 0/2] diff orderfile documentation improvements

Changes from v1: * Don't reference gitignore for the file format because they're not quite the same. Richard Hansen (2): diff: document behavior of relative diff.orderFile diff: document the format of the -O (diff.orderFile) file Documentation/diff-config.txt | 7 +++---

[PATCH v2 2/2] diff: document the format of the -O (diff.orderFile) file

Signed-off-by: Richard Hansen --- Documentation/diff-config.txt | 5 ++-- Documentation/diff-options.txt | 54 -- 2 files changed, 54 insertions(+), 5 deletions(-) diff --git a/Documentation/diff-config.txt

[PATCH v2 1/2] diff: document behavior of relative diff.orderFile

Document that a relative pathname for diff.orderFile is interpreted as relative to the top-level work directory. Signed-off-by: Richard Hansen --- Documentation/diff-config.txt | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/diff-config.txt

Re: [PATCH 2/2] diff: document the pattern format for diff.orderFile

On 2017-01-10 15:14, Junio C Hamano wrote: Richard Hansen writes: Document the format of the patterns used for the diff.orderFile setting and diff's '-O' option by referring the reader to the gitignore[5] page. Signed-off-by: Richard Hansen ---

Re: What's cooking in git.git (Jan 2017, #01; Tue, 10)

On Tue, Jan 10, 2017 at 3:48 PM, Junio C Hamano wrote: > Here are the topics that have been cooking. These two are not included: A bug fix (regression from rewriting submodule stuff in C) http://public-inbox.org/git/20170107001953.3196-1-sbel...@google.com/ And another

Re: git cat-file on a submodule

On Tue, Jan 10, 2017 at 4:11 PM, David Turner wrote: > Why does git cat-file -t $sha:foo, where foo is a submodule, not work? > > git rev-parse $sha:foo works. > > By "why", I mean "would anyone complain if I fixed it?" $ git log -- builtin/cat-file.c |grep -i -e gitlink -e

git cat-file on a submodule

Why does git cat-file -t $sha:foo, where foo is a submodule, not work? git rev-parse $sha:foo works. By "why", I mean "would anyone complain if I fixed it?" FWIW, I think -p should just return the submodule's sha.

What's cooking in git.git (Jan 2017, #01; Tue, 10)

Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. The ones marked with '.' do not appear in any of the integration branches, but I am still holding onto them. You can find the changes

Re: [PATCH v1] convert: add "status=delayed" to filter process protocol

On Tue, Jan 10, 2017 at 11:11:01PM +0100, Jakub Narębski wrote: > W dniu 09.01.2017 o 00:42, Junio C Hamano pisze: > > larsxschnei...@gmail.com writes: > >> From: Lars Schneider > >> > >> Some `clean` / `smudge` filters might require a significant amount of > >> time to

Re: [PATCH 1/2] asciidoctor: fix user-manual to be built by `asciidoctor`

Jeff King writes: > On Sat, Jan 07, 2017 at 02:03:30PM -0800, Junio C Hamano wrote: > >> Is that a longer way to say that the claim "... is designed as a >> book" is false? >> >> > So I dunno. I really do think "article" is conceptually the most >> > appropriate style, but I

Re: [PATCH 1/2] asciidoctor: fix user-manual to be built by `asciidoctor`

"brian m. carlson" writes: >> [1] I think we've also traditionally considered asciidoc to be the >> definitive toolchain, and people using asciidoctor are free to >> submit patches to make things work correctly in both places. I'm not >> opposed to

Re: [PATCH 1/2] diff: document behavior of relative diff.orderFile

Richard Hansen writes: >> A related tangent. >> >> I wonder if anything that uses git_config_pathname() should be >> relative to GIT_DIR when it is not absolute. > > I think so. (For bare repositories anyway; non-bare should be > relative to GIT_WORK_TREE.) Perhaps

Re: [PATCH v1] convert: add "status=delayed" to filter process protocol

W dniu 09.01.2017 o 00:42, Junio C Hamano pisze: > larsxschnei...@gmail.com writes: >> From: Lars Schneider >> >> Some `clean` / `smudge` filters might require a significant amount of >> time to process a single blob. During this process the Git checkout >> operation is

Re: [PATCH 1/2] diff: document behavior of relative diff.orderFile

On 2017-01-10 15:23, Junio C Hamano wrote: Junio C Hamano writes: Richard Hansen writes: On 2017-01-10 01:58, Jeff King wrote: ... What happens in a bare repository? I'm guessing it's relative to the top-level of the repository, I just tried it

Re: [PATCH 2/4] t1000: modernize style

Stefan Beller writes: > On Tue, Jan 10, 2017 at 12:37 PM, Junio C Hamano wrote: >> Stefan Beller writes: >> >>> The preferred style in tests seems to be >> >> s/seems to be/is/; > > If this is the only nit, mind to fix up the commit

Re: [PATCHv2 4/5] unpack-trees: factor file removal out of check_updates

Stefan Beller writes: > As far as I understand the operations now, a working tree operation > is done like this: > > * First compute the new index, how the world would look like > (don't touch a thing in the working tree, it is like a complete > dry run, that just checks

Re: [PATCH v10 00/20] port branch.c to use ref-filter's printing options

Karthik Nayak writes: > index 81db67d74..08be8462c 100644 > --- a/Documentation/git-for-each-ref.txt > +++ b/Documentation/git-for-each-ref.txt > @@ -95,13 +95,17 @@ refname:: > The name of the ref (the part after $GIT_DIR/). > For a non-ambiguous short name of

Re: [PATCHv2 4/5] unpack-trees: factor file removal out of check_updates

On Tue, Jan 10, 2017 at 12:05 PM, Junio C Hamano wrote: > Stefan Beller writes: > >> This makes check_updates shorter and easier to understand. >> >> Signed-off-by: Stefan Beller >> --- > > I agree that 3/5 made it easier to understand

Re: [PATCH v10 03/20] ref-filter: implement %(if:equals=) and %(if:notequals=)

Karthik Nayak writes: > + if_then_else->condition_satisfied = 1; > + } else if (if_then_else->cmp_status == COMPARE_UNEQUAL) { Please, no space before tabs (locally fixed--no need to resend).

[PATCH v5 06/14] t7610: don't rely on state from previous test

If the repository must be in a particular state (beyond what is already done by the 'setup' test case) before the test can run, make the necessary repository changes in the test script even if it means duplicating some lines of code from the previous test case. This is a step toward making the

[PATCH v5 03/14] t7610: update branch names to match test number

Rename the testNN branches so that NN matches the test number. This should make it easier to troubleshoot test issues. Use $test_count to keep this future-proof. Signed-off-by: Richard Hansen --- t/t7610-mergetool.sh | 82

[PATCH v5 04/14] t7610: Move setup code to the 'setup' test case.

Multiple test cases depend on these hunks, so move them to the 'setup' test case. This is a step toward making the tests more independent so that if one test fails it doesn't cause subsequent tests to fail. Signed-off-by: Richard Hansen --- t/t7610-mergetool.sh | 65

Re: [PATCH 2/4] t1000: modernize style

On Tue, Jan 10, 2017 at 12:37 PM, Junio C Hamano wrote: > Stefan Beller writes: > >> The preferred style in tests seems to be > > s/seems to be/is/; If this is the only nit, mind to fix up the commit message locally? (I was even unsure if we want to have

[PATCH v5 02/14] rev-parse doc: pass "--" to rev-parse in the --prefix example

The "--" argument avoids "ambiguous argument: unknown revision or path not in the working tree" errors when a pathname argument refers to a non-existent file. The "--" passed explicitly to set was removed because rev-parse outputs the "--" argument that it is given. Signed-off-by: Richard Hansen

[PATCH v5 05/14] t7610: use test_when_finished for cleanup tasks

This is a step toward making the tests more independent so that if one test fails it doesn't cause subsequent tests to fail. Signed-off-by: Richard Hansen --- t/t7610-mergetool.sh | 71 +++- 1 file changed, 37 insertions(+), 34

[PATCH v5 10/14] t7610: don't assume the checked-out commit

Always check out the required commit at the beginning of the test so that a failure in a previous test does not cause the test to work off of the wrong commit. This is a step toward making the tests more independent so that if one test fails it doesn't cause subsequent tests to fail.

[PATCH v5 08/14] t7610: delete some now-unnecessary 'git reset --hard' lines

Tests now always run 'git reset --hard' at the end (even if they fail), so it's no longer necessary to run 'git reset --hard' at the beginning of a test. Signed-off-by: Richard Hansen --- t/t7610-mergetool.sh | 2 -- 1 file changed, 2 deletions(-) diff --git

[PATCH v5 13/14] mergetool: take the "-O" out of $orderfile

This will make it easier for a future commit to convert a relative orderfile pathname to either absolute or relative to the top-level directory. It also improves code readability. Signed-off-by: Richard Hansen --- git-mergetool.sh | 4 ++-- 1 file changed, 2 insertions(+),

[PATCH v5 11/14] t7610: spell 'git reset --hard' consistently

Signed-off-by: Richard Hansen --- t/t7610-mergetool.sh | 37 +++-- 1 file changed, 19 insertions(+), 18 deletions(-) diff --git a/t/t7610-mergetool.sh b/t/t7610-mergetool.sh index 54164a320..c031ecd9e 100755 --- a/t/t7610-mergetool.sh +++

[PATCH v5 07/14] t7610: run 'git reset --hard' after each test to clean up

Use test_when_finished to run 'git reset --hard' after each test so that the repository is left in a saner state for the next test. This is a step toward making the tests more independent so that if one test fails it doesn't cause subsequent tests to fail. Signed-off-by: Richard Hansen

[PATCH v5 14/14] mergetool: fix running in subdir when rerere enabled

The pathnames output by the 'git rerere remaining' command are relative to the top-level directory but the 'git diff --name-only' command expects its pathname arguments to be relative to the current working directory. Run cd_to_toplevel before running 'git diff --name-only' and adjust any

[PATCH v5 12/14] t7610: add test case for rerere+mergetool+subdir bug

If rerere is enabled and mergetool is run from a subdirectory, mergetool always prints "No files need merging". Add an expected failure test case for this situation. Signed-off-by: Richard Hansen --- t/t7610-mergetool.sh | 21 - 1 file changed, 20

[PATCH v5 00/14] fix mergetool+rerere+subdir regression

If rerere is enabled, no pathnames are given, and mergetool is run from a subdirectory, mergetool always prints "No files need merging". Fix the bug. This regression was introduced in 57937f70a09c12ef484c290865dac4066d207c9c (v2.11.0). Changes since v4: * Revert to Junio's original proposal

[PATCH v5 01/14] .mailmap: Use my personal email address as my canonical

When I changed employers my work address changed from rhan...@bbn.com to hans...@google.com. Rather than map my old work address to my new, map them both to my permanent personal email address. (I will still use my work address in commits I submit so that my employer gets some credit.)

[PATCH v5 09/14] t7610: always work on a test-specific branch

Create and use a test-specific branch when the test might create a commit. This is not always necessary for correctness, but it improves debuggability by ensuring a commit created by test #N shows up on the testN branch, not the branch for test #N-1. Signed-off-by: Richard Hansen

Re: [PATCH 1/4] read-tree: use OPT_BOOL instead of OPT_SET_INT

Stefan Beller writes: > All occurrences of OPT_SET_INT were setting the value to 1; > internally OPT_BOOL is just that. > > Signed-off-by: Stefan Beller > --- > builtin/read-tree.c | 36 ++-- > 1 file changed, 18

Re: [PATCH 2/4] t1000: modernize style

Stefan Beller writes: > The preferred style in tests seems to be s/seems to be/is/; > > test_expect_success 'short description, ended by 2 single quotes' ' > here comes the test && > and chains over many lines && > ended by a quote > ' Thanks. This is

Re: [PATCH v4 14/14] mergetool: fix running in subdir when rerere enabled

Am 10.01.2017 um 20:25 schrieb Junio C Hamano: Johannes Sixt writes: BTW, the --sq and eval business is not required here. At this point, $IFS = $'\n', so set -- $(git rev-parse --sq --prefix "$prefix" -- "$@") will do. (Except that it would not detect errors.)

Re: git-mergetool to be used for rebases as well?

Stefan Beller writes: > $ git status > rebase in progress; onto ... > You are currently rebasing branch '...' on '...'. > > Changes to be committed: > modified: ... > > Unmerged paths: > both modified:

Re: [PATCH 1/2] diff: document behavior of relative diff.orderFile

Junio C Hamano writes: > Richard Hansen writes: > >> On 2017-01-10 01:58, Jeff King wrote: >> ... >>> What happens in a bare repository? >>> >>> I'm guessing it's relative to the top-level of the repository, >> >> I just tried it out and it's relative to

Re: [PATCH 1/2] diff: document behavior of relative diff.orderFile

Richard Hansen writes: > On 2017-01-10 01:58, Jeff King wrote: > ... >> What happens in a bare repository? >> >> I'm guessing it's relative to the top-level of the repository, > > I just tried it out and it's relative to $PWD. That is understandable. When the user says

Re: [PATCH 2/2] diff: document the pattern format for diff.orderFile

Richard Hansen writes: > Document the format of the patterns used for the diff.orderFile > setting and diff's '-O' option by referring the reader to the > gitignore[5] page. > > Signed-off-by: Richard Hansen > --- > Documentation/diff-config.txt | 3 ++-

[PATCH] index: improve constness for reading blob data

Improve constness of the index_state parameter to the 'read_blob_data_from_index' function. Signed-off-by: Brandon Williams --- cache.h | 2 +- read-cache.c | 3 ++- 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/cache.h b/cache.h index

Re: [PATCHv2 4/5] unpack-trees: factor file removal out of check_updates

Stefan Beller writes: > This makes check_updates shorter and easier to understand. > > Signed-off-by: Stefan Beller > --- I agree that 3/5 made it easier to understand by ejecting a block that is not essential to the functionality of the function out of

Re: [PATCHv2 2/5] unpack-trees: remove unneeded continue

Stefan Beller writes: > The continue is the last statement in the loop, so not needed. > This situation arose in 700e66d66 (2010-07-30, unpack-trees: let > read-tree -u remove index entries outside sparse area) when statements > after the continue were removed. > >

Re: [PATCH v4 14/14] mergetool: fix running in subdir when rerere enabled

Johannes Sixt writes: >> +prefix=$(git rev-parse --show-prefix) || exit 1 >> +cd_to_toplevel >> + >> +if test -n "$orderfile" >> +then >> +orderfile=$(git rev-parse --prefix "$prefix" -- "$orderfile") >> || exit 1 >> +orderfile=$(printf

git-mergetool to be used for rebases as well?

An internal user report running on origin/next: $ git pull From . * branch... -> FETCH_HEAD First, rewinding head to replay your work on top of it... Applying: ... Applying: ... Using index info to reconstruct a base tree...

Re: [RFC PATCH 0/5] Localise error headers

On Tue, Jan 10, 2017 at 1:04 AM, Jeff King wrote: > On Mon, Jan 09, 2017 at 01:43:15PM +0100, Michael J Gruber wrote: > >> > I can't say I'm excited about having matching "_" variants for each >> > function. Are we sure that they are necessary? I.e., would it be >> > acceptable to

Re: [PATCHv8] pathspec: give better message for submodule related pathspec error

Stefan Beller writes: > This comes as a single patch again, replacing sb/pathspec-errors. > It goes directly on top of bw/pathspec-cleanup. > > v8: > cleaned white spaces in commit message > removed TEST_CREATE_SUBMODULE=yes > : > instead of touch. > > v7: >

Re: [PATCH 1/2] diff: document behavior of relative diff.orderFile

On 2017-01-10 01:58, Jeff King wrote: On Mon, Jan 09, 2017 at 07:40:30PM -0500, Richard Hansen wrote: Document that a relative pathname for diff.orderFile is interpreted as relative to the top-level work directory. Signed-off-by: Richard Hansen ---

Re: [PATCH v4 14/14] mergetool: fix running in subdir when rerere enabled

On 2017-01-10 01:17, Johannes Sixt wrote: Am 10.01.2017 um 00:29 schrieb Richard Hansen: The pathnames output by the 'git rerere remaining' command are relative to the top-level directory but the 'git diff --name-only' command expects its pathname arguments to be relative to the current working

Re: [PATCH v5 0/4] Per-worktree config file support

On Tue, Jan 10, 2017 at 3:25 AM, Nguyễn Thái Ngọc Duy wrote: > Let's get this rolling again. To refresh your memory because it's half > a year since v4 [1], this is about letting each worktree in multi > worktree setup has their own config settings. The most prominent ones >

Re: [PATCH v5 2/4] config: --worktree for manipulating per-worktree config file

> + if (repository_format_worktree_config) > + given_config_source.file = > git_pathdup("config.worktree"); > + else if (worktrees[0] && worktrees[1]) { > + die("BUG: migration is not supported yet"); > + } else

Re: Refreshing index timestamps without reading content

On Mon, Jan 09, 2017 at 04:55:37PM +0100, Quentin Casasnovas wrote: > On Mon, Jan 09, 2017 at 07:01:36AM -0800, Junio C Hamano wrote: > > Duy Nguyen writes: > > > > > On Thu, Jan 5, 2017 at 6:23 PM, Quentin Casasnovas > > > wrote: > > >> Is there

Re: [musl] Re: Test failures when Git is built with libpcre and grep is built without it

* A. Wilcox [2017-01-10 04:36:50 -0600]: > On 09/01/17 15:33, Jeff King wrote: > > The problem is that we are expecting the regex "\x{2b}" to complain > > in regcomp() (as an ERE), but it doesn't. And that probably _is_ > > related to musl, which is providing the libc

Re: [PATCH v5 0/4] Per-worktree config file support

On Tue, Jan 10, 2017 at 6:25 PM, Nguyễn Thái Ngọc Duy wrote: > Not much has changed from v4, except that the migration to new config > layout is done automatically _update_ a config variable with "git > config --worktree". I accidentally two words that may make it hard to

[PATCH/RFC 5/4] Redefine core.bare in multiple working tree setting

When core.bare was added, time was simpler, we only had one worktree associated to one repository. The situation gets a bit complicated when multiple worktrees are added. If core.bare is set in the per-repo config file, should all worktrees see this variable? Since core.bare affects

[PATCH v5 4/4] t2029: add tests for per-worktree config

Signed-off-by: Nguyễn Thái Ngọc Duy --- t/t2029-worktree-config.sh (new +x) | 82 + 1 file changed, 82 insertions(+) create mode 100755 t/t2029-worktree-config.sh diff --git a/t/t2029-worktree-config.sh b/t/t2029-worktree-config.sh new

[PATCH v5 0/4] Per-worktree config file support

Let's get this rolling again. To refresh your memory because it's half a year since v4 [1], this is about letting each worktree in multi worktree setup has their own config settings. The most prominent ones are core.worktree, used by submodules, and core.sparseCheckout. This time I'm not touching

[PATCH v5 2/4] config: --worktree for manipulating per-worktree config file

As noted in the previous commit, "git config" without options will read both per-worktree and per-repo by default. --worktree is needed to read just per-worktree config. Writing goes to per-repo by default though, unless --worktree is given. Signed-off-by: Nguyễn Thái Ngọc Duy

[PATCH v5 3/4] config: automatically migrate to new config layout when --worktree is used

It's not fun to ask the user to set extensions.worktreeConfig manually. It's error-prone too. So we do it automatically whenever anybody sets a per-worktree config with "git config" (support for builtin commands is coming later). Signed-off-by: Nguyễn Thái Ngọc Duy ---

[PATCH v5 1/4] config: read per-worktree config files

A new repo extension is added, worktreeConfig. When it is present: - Repository config reading by default includes $GIT_DIR/config _and_ $GIT_DIR/config.worktree. "config" file remains shared in multiple worktree setup. - The special treatment for core.bare and core.worktree, to stay

Re: git branch -D doesn't work with deleted worktree

On Tue, Jan 10, 2017 at 12:08 PM, Jacob Keller wrote: > On Mon, Jan 9, 2017 at 2:07 AM, Duy Nguyen wrote: >> On Mon, Jan 9, 2017 at 10:44 AM, Jacob Keller wrote: >>> Why not just update the documentation to be "when you are done

Re: Test failures when Git is built with libpcre and grep is built without it

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 (Hi, musl developers! Read on for some information regarding what began as a test failure during packaging of Git 2.7.3 that appears to be related to musl's regexp library.) On 09/01/17 05:27, Jeff King wrote: > Are you trying with a version of

Microsoft Outlook säkerhetsgruppen

Din e-rutan konto behöver vara verifiera nu för oegentligheter finns i din e-box-konto eller kommer att blockera. KLICKA här för att verifiera din e-postbrevlåda och fylla i ditt fullständiga användarnamn och lösenord omedelbart Microsoft

Re: [ANNOUNCE] git-test: run automated tests against a range of Git commits

On Sun, Jan 08, 2017 at 10:52:25AM +0100, Michael Haggerty wrote: > > I see the symmetry and simplicity in allowing the user to specify a full > > range. But it also seems like it's easy to make a mistake that's going > > to want to test a lot of commits. I wonder if it should complain when > >

Re: Preserve/Prune Old Pack Files

On Mon, Jan 09, 2017 at 09:17:56AM -0700, Martin Fick wrote: > > I suspect the name-change will break a few tools that you > > might want to use to look at a preserved pack (like > > verify-pack). I know that's not your primary use case, > > but it seems plausible that somebody may one day want

Re: [RFC PATCH 0/5] Localise error headers

On Mon, Jan 09, 2017 at 01:43:15PM +0100, Michael J Gruber wrote: > > I can't say I'm excited about having matching "_" variants for each > > function. Are we sure that they are necessary? I.e., would it be > > acceptable to just translate them always? > > We would still need to mark the

[PATCH v10 12/20] ref-filter: make remote_ref_atom_parser() use refname_atom_parser_internal()

From: Karthik Nayak Use the recently introduced refname_atom_parser_internal() within remote_ref_atom_parser(), this provides a common base for all the ref printing atoms, allowing %(upstream) and %(push) to also use the ':strip' option. The atoms '%(push)' and

[PATCH v10 13/20] ref-filter: rename the 'strip' option to 'lstrip'

In preparation for the upcoming patch, where we introduce the 'rstrip' option. Rename the 'strip' option to 'lstrip' to remove ambiguity. Signed-off-by: Karthik Nayak --- Documentation/git-for-each-ref.txt | 10 +- builtin/tag.c | 4 ++--

[PATCH v10 14/20] ref-filter: Do not abruptly die when using the 'lstrip=' option

Currently when we use the 'lstrip=' option, if 'N' is greater than the number of components available in the refname, we abruptly end program execution by calling die(). This behavior is undesired since a single refname with few components could end program execution. To avoid this, return an

[PATCH v10 08/20] ref-filter: add support for %(upstream:track,nobracket)

From: Karthik Nayak Add support for %(upstream:track,nobracket) which will print the tracking information without the brackets (i.e. "ahead N, behind M"). This is needed when we port branch.c to use ref-filter's printing APIs. Add test and documentation for the same.

[PATCH v10 19/20] branch: use ref-filter printing APIs

From: Karthik Nayak Port branch.c to use ref-filter APIs for printing. This clears out most of the code used in branch.c for printing and replaces them with calls made to the ref-filter library. Introduce build_format() which gets the format required for printing of refs.

[PATCH v10 01/20] ref-filter: implement %(if), %(then), and %(else) atoms

From: Karthik Nayak Implement %(if), %(then) and %(else) atoms. Used as %(if)...%(then)...%(end) or %(if)...%(then)...%(else)...%(end). If the format string between %(if) and %(then) expands to an empty string, or to only whitespaces, then the whole %(if)...%(end) expands

[PATCH v10 18/20] branch, tag: use porcelain output

From: Karthik Nayak Call ref-filter's setup_ref_filter_porcelain_msg() to enable translated messages for the %(upstream:tack) atom. Although branch.c doesn't currently use ref-filter's printing API's, this will ensure that when it does in the future patches, we do not need

[PATCH v10 03/20] ref-filter: implement %(if:equals=) and %(if:notequals=)

From: Karthik Nayak Implement %(if:equals=) wherein the if condition is only satisfied if the value obtained between the %(if:...) and %(then) atom is the same as the given ''. Similarly, implement (if:notequals=) wherein the if condition is only satisfied if the value

[PATCH v10 16/20] ref-filter: add an 'rstrip=' option to atoms which deal with refnames

Complimenting the existing 'lstrip=' option, add an 'rstrip=' option which strips `` slash-separated path components from the end of the refname (e.g., `%(refname:rstrip=2)` turns `refs/tags/foo` into `refs`). Signed-off-by: Karthik Nayak ---

[PATCH v10 11/20] ref-filter: introduce refname_atom_parser()

From: Karthik Nayak Using refname_atom_parser_internal(), introduce refname_atom_parser() which will parse the %(symref) and %(refname) atoms. Store the parsed information into the 'used_atom' structure based on the modifiers used along with the atoms. Now the '%(symref)'

[PATCH v10 20/20] branch: implement '--format' option

From: Karthik Nayak Implement the '--format' option provided by 'ref-filter'. This lets the user list branches as per desired format similar to the implementation in 'git for-each-ref'. Add tests and documentation for the same. Mentored-by: Christian Couder

[PATCH v10 09/20] ref-filter: make "%(symref)" atom work with the ':short' modifier

From: Karthik Nayak The "%(symref)" atom doesn't work when used with the ':short' modifier because we strictly match only 'symref' for setting the 'need_symref' indicator. Fix this by comparing with the valid_atom rather than the used_atom. Add tests for %(symref) and

[PATCH v10 17/20] ref-filter: allow porcelain to translate messages in the output

From: Karthik Nayak Introduce setup_ref_filter_porcelain_msg() so that the messages used in the atom %(upstream:track) can be translated if needed. By default, keep the messages untranslated, which is the right behavior for plumbing commands. This is needed as we port

[PATCH v10 07/20] ref-filter: make %(upstream:track) prints "[gone]" for invalid upstreams

From: Karthik Nayak Borrowing from branch.c's implementation print "[gone]" whenever an unknown upstream ref is encountered instead of just ignoring it. This makes sure that when branch.c is ported over to using ref-filter APIs for printing, this feature is not lost.

[PATCH v10 15/20] ref-filter: modify the 'lstrip=' option to work with negative ''

Currently the 'lstrip=' option only takes a positive value '' and strips '' slash-separated path components from the left. Modify the 'lstrip' option to also take a negative number '' which would strip from the left as necessary and _leave_ behind only 'N' slash-separated path components from the

[PATCH v10 02/20] ref-filter: include reference to 'used_atom' within 'atom_value'

From: Karthik Nayak Ensure that each 'atom_value' has a reference to its corresponding 'used_atom'. This lets us use values within 'used_atom' in the 'handler' function. Hence we can get the %(align) atom's parameters directly from the 'used_atom' therefore removing the

[PATCH v10 10/20] ref-filter: introduce refname_atom_parser_internal()

From: Karthik Nayak Since there are multiple atoms which print refs ('%(refname)', '%(symref)', '%(push)', '%(upstream)'), it makes sense to have a common ground for parsing them. This would allow us to share implementations of the atom modifiers between these atoms.

[PATCH v10 05/20] ref-filter: move get_head_description() from branch.c

From: Karthik Nayak Move the implementation of get_head_description() from branch.c to ref-filter. This gives a description of the HEAD ref if called. This is used as the refname for the HEAD ref whenever the FILTER_REFS_DETACHED_HEAD option is used. Make it public

[PATCH v10 04/20] ref-filter: modify "%(objectname:short)" to take length

From: Karthik Nayak Add support for %(objectname:short=) which would print the abbreviated unique objectname of given length. When no length is specified, the length is 'DEFAULT_ABBREV'. The minimum length is 'MINIMUM_ABBREV'. The length may be exceeded to ensure that the

[PATCH v10 00/20] port branch.c to use ref-filter's printing options

This is part of unification of the commands 'git tag -l, git branch -l and git for-each-ref'. This ports over branch.c to use ref-filter's printing options. Initially posted here: $(gmane/279226). It was decided that this series would follow up after refactoring ref-filter parsing mechanism,

[PATCH v10 06/20] ref-filter: introduce format_ref_array_item()

From: Karthik Nayak To allow column display, we will need to first render the output in a string list to allow print_columns() to compute the proper size of each column before starting the actual output. Introduce the function format_ref_array_item() that does the