Re: [PATCH v2 2/5] config doc: unify the description of fsck.* and receive.fsck.*

On Fri, May 25, 2018 at 3:28 PM, Ævar Arnfjörð Bjarmason wrote: > The documentation for the fsck. and receive.fsck. > variables was mostly duplicated in two places, with fsck. > making no mention of the corresponding receive.fsck., and the > same for fsck.skipList. > [...] >

Re: [PATCH v2 1/5] config doc: don't describe *.fetchObjects twice

On Fri, May 25, 2018 at 3:28 PM, Ævar Arnfjörð Bjarmason wrote: > Let's not duplicate the description of what *.fsckObjects does twice. Nit: "duplicate" and "twice" smell redundant. > instead let's refer to transfer.fsckObjects from both fetch.* and > receive.*.

Re: [PATCH 2/4] config doc: unify the description of fsck.* and receive.fsck.*

On Thu, May 24, 2018 at 4:12 PM, Ævar Arnfjörð Bjarmason <ava...@gmail.com> wrote: > On Thu, May 24 2018, Eric Sunshine wrote: >> On Thu, May 24, 2018 at 3:35 PM, Ævar Arnfjörð Bjarmason >> <ava...@gmail.com> wrote: >>> fsck.skipList:: >>> + L

Re: [PATCH 3/4] config doc: elaborate on what transfer.fsckObjects does

On Thu, May 24, 2018 at 3:35 PM, Ævar Arnfjörð Bjarmason wrote: > The existing documentation led the user to believe that all we were > doing were basic readability sanity checks, but that hasn't been true > for a very long time. Update the description to match reality, and >

Re: [PATCH] Use proper syntax for replaceables in command docs

On Thu, May 24, 2018 at 3:54 PM, Robert P. J. Day wrote: > The standard for command documentation synopses appears to be: > > [...] means optional > <...> means replaceable > [<...>] means both optional and replaceable > > So fix a number of doc pages that use

Re: [PATCH 2/4] config doc: unify the description of fsck.* and receive.fsck.*

On Thu, May 24, 2018 at 3:35 PM, Ævar Arnfjörð Bjarmason wrote: > The documentation for the fsck. and receive.fsck. > variables was mostly duplicated in two places, with fsck. > making no mention of the corresponding receive.fsck., and the > same for fsck.skipList. > [...] >

Re: [PATCH v2 3/3] config: let `config_store_data_clear()` handle `key`

On Sun, May 20, 2018 at 6:42 AM, Martin Ågren wrote: > Instead of remembering to free `key` in each code path, let > `config_store_data_clear()` handle that. > > We still need to free it before replacing it, though. Move that freeing > closer to the replacing to be safe.

Re: [PATCH v2 0/3] config: free resources of `struct config_store_data`

On Sun, May 20, 2018 at 6:42 AM, Martin Ågren <martin.ag...@gmail.com> wrote: > On 14 May 2018 at 05:03, Eric Sunshine <sunsh...@sunshineco.com> wrote: >> On Sun, May 13, 2018 at 5:58 AM, Martin Ågren <martin.ag...@gmail.com> wrote: >>> How about the following t

Re: [PATCH] regex: do not call `regfree()` if compilation fails

On Mon, May 21, 2018 at 2:43 PM, Stefan Beller wrote: > On Sun, May 20, 2018 at 3:50 AM, Martin Ågren wrote: >> It is apparently undefined behavior to call `regfree()` on a regex where >> `regcomp()` failed. [...] >> >> diff --git a/diffcore-pickaxe.c

Re: [PATCH 2/2] t9902-completion: exercise __git_complete_index_file() directly

On Fri, May 18, 2018 at 10:17 AM, SZEDER Gábor wrote: > The tests added in 2f271cd9cf (t9902-completion: add tests > demonstrating issues with quoted pathnames, 2018-05-08) and in > 2ab6eab4fe (completion: improve handling quoted paths in 'git > ls-files's output,

Re: [PATCH] t7005-editor: get rid of the SPACES_IN_FILENAMES prereq

On Mon, May 14, 2018 at 6:28 AM, SZEDER Gábor wrote: > The last two tests 'editor with a space' and 'core.editor with a > space' in 't7005-editor.sh' need the SPACES_IN_FILENAMES prereq to > ensure that they are only run on filesystems that allow, well, spaces > in

Re: [PATCH/RFC] completion: complete all possible -no-

On Tue, May 8, 2018 at 11:24 AM, Duy Nguyen <pclo...@gmail.com> wrote: > On Mon, Apr 23, 2018 at 7:36 AM, Eric Sunshine <sunsh...@sunshineco.com> > wrote: >> I haven't looked at the implementation, so this may be an entirely >> stupid suggestion, but would it

Re: [PATCH 2/1] config: let `config_store_data_clear()` handle `value_regex`

On Sun, May 13, 2018 at 5:58 AM, Martin Ågren wrote: > Instead of carefully clearing up `value_regex` in each code path, let > `config_store_data_clear()` handle that. > > Signed-off-by: Martin Ågren > --- > I *think* that it should be ok to

Re: [PATCH] config: free resources of `struct config_store_data`

On Sun, May 13, 2018 at 5:58 AM, Martin Ågren <martin.ag...@gmail.com> wrote: > On 13 May 2018 at 10:59, Eric Sunshine <sunsh...@sunshineco.com> wrote: >> On Sun, May 13, 2018 at 4:23 AM Martin Ågren <martin.ag...@gmail.com> wrote: >>> Intro

Re: [PATCH] config: free resources of `struct config_store_data`

On Sun, May 13, 2018 at 4:23 AM Martin Ågren wrote: > Commit fee8572c6d (config: avoid using the global variable `store`, > 2018-04-09) dropped the staticness of a certain struct, instead letting > the users create an instance on the stack and pass around a pointer. > We

Re: [PATCH 7/9] completion: drop the hard coded list of config vars

On Thu, May 10, 2018 at 10:19 AM Nguyễn Thái Ngọc Duy wrote: > The new help option --config-for-completion is a machine friendlier > version of --config where all the placeholders and wildcards are > dropped, leaving only the good, completable prefixes for > git-completion.bash

Re: [PATCH 6/9] am: move advice.amWorkDir parsing back to advice.c

On Thu, May 10, 2018 at 10:19 AM Nguyễn Thái Ngọc Duy wrote: > The only benefit from this move (apart from cleaner code) is that > advice.amWorkDir should now show up in `git help --config`. There > should be no regression since advice config is always read by the >

Re: [PATCH 4/9] help: add --config to list all available config

On Thu, May 10, 2018 at 10:20 AM Nguyễn Thái Ngọc Duy wrote: > Sometimes it helps to list all available config vars so the user can > search for something they want. The config man page can also be used > but it's harder to search if you want to focus on the variable name, >

Re: [PATCH 3/9] fsck: factor out msg_id_info[] lazy initialization code

On Thu, May 10, 2018 at 10:19 AM Nguyễn Thái Ngọc Duy wrote: > This array will be used by some other function than parse_msg_id() in > the following commit. Factor out this prep code so it could be called > from that one. > Signed-off-by: Nguyễn Thái Ngọc Duy

Re: [PATCH] alloc: allow arbitrary repositories for alloc functions

On Fri, May 11, 2018 at 3:17 PM Stefan Beller wrote: > diff --git a/commit.c b/commit.c > @@ -296,6 +297,17 @@ void free_commit_buffer(struct commit *commit) > +void relase_commit_memory(struct commit *c) s/relase/release/

Re: [PATCH 00/28] Hash-independent tests (part 2)

On Sun, May 6, 2018 at 7:17 PM, brian m. carlson wrote: > This series introduces an SHA1 prerequisite which checks if the hash in > use is SHA-1, and can be used to skip the test if it is not. > Additionally, because NewHash will be 256-bit, I introduced aliases for

Re: [PATCH 16/28] t4008: abstract away SHA-1-specific constants

On Sun, May 6, 2018 at 7:17 PM, brian m. carlson wrote: > Adjust the test so that it computes variables for blobs instead of using > hard-coded hashes. > > Signed-off-by: brian m. carlson > --- > diff --git

Re: [PATCH 14/28] t3905: abstract away SHA-1-specific constants

On Sun, May 6, 2018 at 7:17 PM, brian m. carlson wrote: > Adjust the test so that it computes variables for blobs instead of using > hard-coded hashes. > > Signed-off-by: brian m. carlson > --- > diff --git

Re: [PATCH 04/28] t/test-lib: introduce FULL_HEX

On Sun, May 6, 2018 at 7:17 PM, brian m. carlson wrote: > Currently we have a variable, $_x40, which contains a regex that matches > a full 40-character hex constant. However, with NewHash, we'll have > object IDs that are longer than 40 characters. In such a case,

Re: [PATCH v2 02/18] Add a new builtin: branch-diff

On Sun, May 6, 2018 at 8:21 AM, Johannes Schindelin wrote: > On Sun, 6 May 2018, Junio C Hamano wrote: >> Johannes Schindelin writes: >> > On Sat, 5 May 2018, Jeff King wrote: >> >> One minor point about the name: will it become annoying as

Re: [PATCH 2/2] builtin/grep.c: teach '-o', '--only-matching' to 'git-grep'

On Sat, May 5, 2018 at 12:03 AM, Taylor Blau wrote: > Teach GNU grep(1)'s '-o' ('--only-matching') to 'git-grep'. This option > prints only the matching components of each line. It writes multiple > lines if more than one match exists on a given line. > > For example: > > $

Re: [PATCH 1/2] grep.c: extract show_line_header()

On Sat, May 5, 2018 at 12:03 AM, Taylor Blau wrote: > Teach 'git-grep(1)' how to print a line header multiple times from > show_line() in preparation for it learning '--only-matching'. > > show_line_header() comprises of the code in show_line() executed in s/of// > order to

Re: [PATCH v2] checkout & worktree: introduce checkout.implicitRemote

On Thu, May 3, 2018 at 9:18 AM, Ævar Arnfjörð Bjarmason wrote: > Introduce a checkout.implicitRemote setting which can be used to > designate a remote to prefer (via checkout.implicitRemote=origin) when > running e.g. "git checkout master" to mean origin/master, even though >

Re: [PATCH 02/18] Add a new builtin: branch-diff

On Fri, May 4, 2018 at 2:52 AM, Johannes Schindelin <johannes.schinde...@gmx.de> wrote: > On Thu, 3 May 2018, Eric Sunshine wrote: >> On Thu, May 3, 2018 at 11:30 AM, Johannes Schindelin >> <johannes.schinde...@gmx.de> wrote: >> > +static const ch

Re: [PATCH] checkout & worktree: introduce a core.DWIMRemote setting

On Fri, May 4, 2018 at 3:14 AM, Eric Sunshine <sunsh...@sunshineco.com> wrote: > The setting up of a remote-tracking branch is DWIM'd as of 4e85333197 > ("worktree: make add dwim", 2017-11-26); it doesn't > require an explicit option to enable it (though tracking can be

Re: [PATCH] checkout & worktree: introduce a core.DWIMRemote setting

On Wed, May 2, 2018 at 2:25 PM, Ævar Arnfjörð Bjarmason <ava...@gmail.com> wrote: > On Wed, May 02 2018, Eric Sunshine wrote: >> A few observations: >> >> 1. DWIM has broad meaning; while this certainly falls within DWIM, >> it's also just a _default_

Re: [PATCH 17/18] branch-diff: add a man page

On Thu, May 3, 2018 at 11:31 AM, Johannes Schindelin wrote: > This is a heavily butchered version of the README written by Thomas > Rast and Thomas Gummerer, lifted from https://github.com/trast/tbdiff. > > Signed-off-by: Johannes Schindelin

Re: [PATCH 05/18] branch-diff: also show the diff between patches

On Thu, May 3, 2018 at 10:51 PM, Eric Sunshine <sunsh...@sunshineco.com> wrote: > On Thu, May 3, 2018 at 11:30 AM, Johannes Schindelin > <johannes.schinde...@gmx.de> wrote: >> Note: while we now parse diff options such as --color, the effect is not >> yet the

Re: [PATCH 05/18] branch-diff: also show the diff between patches

On Thu, May 3, 2018 at 11:30 AM, Johannes Schindelin wrote: > Just like tbdiff, we now show the diff between matching patches. This is > a "diff of two diffs", so it can be a bit daunting to read for the > beginnger. s/beginnger/beginner/ > This brings branch-diff

Re: [PATCH 03/18] branch-diff: first rudimentary implementation

On Thu, May 3, 2018 at 11:30 AM, Johannes Schindelin wrote: > At this stage, `git branch-diff` can determine corresponding commits of > two related commit ranges. This makes use of the recently introduced > implementation of the Hungarian algorithm. > > The core of

Re: [PATCH 02/18] Add a new builtin: branch-diff

On Thu, May 3, 2018 at 11:30 AM, Johannes Schindelin wrote: > This builtin does not do a whole lot so far, apart from showing a usage > that is oddly similar to that of `git tbdiff`. And for a good reason: > the next commits will turn `branch-diff` into a full-blown

Re: [PATCH v2] git: add -P as a short option for --no-pager

On Thu, May 3, 2018 at 1:15 PM, Johannes Sixt wrote: > It is possible to configure 'less', the pager, to use an alternate > screen to show the content, for example, by setting LESS=RS in the > environment. When it is closed in this configuration, it switches > back to the original

Re: [PATCH] checkout & worktree: introduce a core.DWIMRemote setting

On Wed, May 2, 2018 at 11:21 AM, Duy Nguyen wrote: > On Wed, May 2, 2018 at 12:54 PM, Ævar Arnfjörð Bjarmason > wrote: >> Introduce a core.DWIMRemote setting which can be used to designate a >> remote to prefer (via core.DWIMRemote=origin) when running e.g.

Re: [PATCH 02/13] object: add repository argument to create_object

On Tue, May 1, 2018 at 5:33 PM, Stefan Beller wrote: > Add a repository argument to allow the callers of create_object > to be more specific about which repository to act on. This is a small > mechanical change; it doesn't change the implementation to handle > repositories

Re: [PATCH 2/2] submodule: Add --dissociate option to add/update commands

On Tue, May 1, 2018 at 2:09 PM, Casey Fitzpatrick wrote: > submodule: Add --dissociate option to add/update commands s/Add/add/ > Add --dissociate option to add and update commands, both clone helper commands > that already have the --reference option --dissociate pairs with.

Re: js/no-pager-shorthand [was: What's cooking in git.git (Apr 2018, #04; Mon, 30)]

On Tue, May 1, 2018 at 10:58 AM, Johannes Sixt wrote: > Am 01.05.2018 um 13:57 schrieb Johannes Schindelin: >> On Mon, 30 Apr 2018, Johannes Sixt wrote: >>> Am 30.04.2018 um 05:25 schrieb Junio C Hamano: * js/no-pager-shorthand (2018-04-25) 1 commit - git: add -N as a

Re: [PATCH] format-patch: make cover letters always text/plain

On Mon, Apr 30, 2018 at 8:02 PM, brian m. carlson wrote: > When formatting a series of patches using --attach and --cover-letter, > the cover letter lacks the closing MIME boundary, violating RFC 2046. > Certain clients, such as Thunderbird, discard the message body

Re: [PATCH 8/9] get_short_oid / peel_onion: ^{tree} should mean commit, not commitish

On Mon, Apr 30, 2018 at 6:07 PM, Ævar Arnfjörð Bjarmason wrote: > get_short_oid / peel_onion: ^{tree} should mean commit, not commitish s/tree/commit/ > Continue the untangling of peel disambiguation syntax. Before this > e8f2^{commit} would show the v2.17.0 tag, but now it'll

Re: [PATCH v1] test-drop-caches: simplify delay loading of NtSetSystemInformation

On Mon, Apr 30, 2018 at 10:26 AM, Ben Peart wrote: > Take advantage of the recent addition of support for lazy loading functions > on Windows to simplfy the loading of NtSetSystemInformation. s/simplfy/simplify/ > Signed-off-by: Ben Peart

Re: [PATCH 6/6] Convert remaining die*(BUG) messages

On Sun, Apr 29, 2018 at 6:19 PM, Johannes Schindelin wrote: > These were not caught by the previous commit, as they did not match the > regular expression. > > Signed-off-by: Johannes Schindelin > --- > diff --git a/submodule.c

Re: [PATCH v2 2/6] doc: align 'diff --no-index' in text with synopsis

On Fri, Apr 27, 2018 at 2:40 PM, Andreas Heiduk <ashei...@gmail.com> wrote: > Am 27.04.2018 um 19:33 schrieb Eric Sunshine: >> On Fri, Apr 27, 2018 at 1:04 PM, Andreas Heiduk <ashei...@gmail.com> wrote: >>> @@ -13,7 +13,7 @@ SYNOPSIS >>> -'git diff' [opti

Re: [PATCH v2 6/6] doc: add note about shell quoting to revision.txt

On Fri, Apr 27, 2018 at 1:04 PM, Andreas Heiduk wrote: > Signed-off-by: Andreas Heiduk > Reviewed-by: Junio C Hamano > --- > diff --git a/Documentation/revisions.txt b/Documentation/revisions.txt > @@ -186,6 +190,8 @@ existing tag

Re: [PATCH v2 2/6] doc: align 'diff --no-index' in text with synopsis

On Fri, Apr 27, 2018 at 1:04 PM, Andreas Heiduk wrote: > The two '' parameters are not optional but the option > '--no-index' is. Also move the `--options` part to the same > place where the other variants show them. > > All three items are already correct in the synopsis. > >

Re: What's cooking in git.git (Apr 2018, #03; Wed, 25)

On Wed, Apr 25, 2018 at 4:37 AM, Junio C Hamano wrote: > * tg/worktree-add-existing-branch (2018-04-25) 4 commits > - worktree: teach "add" to check out existing branches > - worktree: factor out dwim_branch function > - worktree: improve message when creating a new worktree

Re: [PATCH v9 0/4] worktree: teach "add" to check out existing branches

flag Thanks. I did another full review of all the patches and played around with the new functionality again for good measure. Everything looked good, and I think the patches are now ready to graduate. For what it's worth, the entire series is: Reviewed-by: Eric Sunshine <sunsh...@sunshineco.com>

Re: [PATCH v2 5/5] builtin/config: introduce `color` type specifier

On Thu, Apr 26, 2018 at 1:58 AM, Taylor Blau wrote: > [...] > For consistency, let's introduce `--type=color` and encourage its use > with `--default` together over `--get-color` alone. > > Signed-off-by: Taylor Blau > --- > diff --git

Re: [PATCH 2/5] builtin/config.c: support `--type=` as preferred alias for `--type`

On Thu, Apr 26, 2018 at 2:00 AM, Taylor Blau wrote: > On Thu, Apr 26, 2018 at 02:25:44PM +0900, Junio C Hamano wrote: >> Taylor Blau writes: >> >> > Subject: Re: [PATCH 2/5] builtin/config.c: support `--type=` as >> > preferred alias for `--type` >> >> I'd

Re: [PATCH v2 2/5] builtin/config.c: support `--type=` as preferred alias for `--`

On Thu, Apr 26, 2018 at 1:58 AM, Taylor Blau wrote: > `git config` has long allowed the ability for callers to provide a 'type > specifier', which instructs `git config` to (1) ensure that incoming > values can be interpreted as that type, and (2) that outgoing values are >

Re: [PATCH v4/wip 06/12] git: accept multiple --list-cmds options

On Wed, Apr 25, 2018 at 12:31 PM, Nguyễn Thái Ngọc Duy wrote: > Later on we may support non-overlapping command groups to > --list-cmds. Allow the user to execute just one "git" process and get > multiple groups. This may matter for git-completion.bash on Windows > because we

Re: [PATCH v4/wip 10/12] help: use command-list.txt for the source of guides

On Wed, Apr 25, 2018 at 12:31 PM, Nguyễn Thái Ngọc Duy wrote: > The help command currently hard codes the list of guides and their > summary in C. Let's move this list to command-list.txt. This lets us > extract summary lines from Documentation/git*.txt. This also > potentially

Re: [PATCH v4/wip 08/12] git: support --list-cmds=

On Wed, Apr 25, 2018 at 12:31 PM, Nguyễn Thái Ngọc Duy wrote: > This allows us to select any group of commands by a category defined > in command-list.txt. This is an internal/hidden option so we don't > have to be picky about the category name or worried about exposing too >

Re: [PATCH v4/wip 02/12] generate-cmds.sh: export all commands to command-list.h

On Wed, Apr 25, 2018 at 12:30 PM, Nguyễn Thái Ngọc Duy wrote: > The current generate-cmds.sh generates just enough to print "git help" > output. That is, it only extracts help text for common commands. > > The script is now updated to extract help text for all commands and >

Re: [PATCH v4/wip 01/12] generate-cmds.sh: factor out synopsis extract code

On Wed, Apr 25, 2018 at 12:30 PM, Nguyễn Thái Ngọc Duy wrote: > This makes it easier to reuse the same code in another place (very > soon). > > Signed-off-by: Nguyễn Thái Ngọc Duy > --- > diff --git a/generate-cmdlist.sh b/generate-cmdlist.sh > @@ -1,5 +1,17

Re: [PATCH v3 4/7] grep.c: display column number of first match

On Tue, Apr 24, 2018 at 1:07 AM, Taylor Blau wrote: > To prepare for 'git grep' learning '--column-number', teach grep.c's > show_line() how to show the column of the first match on non-context > line. > > Signed-off-by: Taylor Blau > --- > diff --git

Re: [PATCH v3 7/7] contrib/git-jump/git-jump: jump to match column in addition to line

On Tue, Apr 24, 2018 at 1:07 AM, Taylor Blau wrote: > Take advantage of 'git-grep(1)''s new option, '--column-number' in order > to teach Peff's 'git-jump' script how to jump to the correct column for > any given match. > > 'git-grep(1)''s output is in the correct format for

Re: [PATCH v8 4/4] worktree: teach "add" to check out existing branches

On Mon, Apr 23, 2018 at 3:38 PM, Thomas Gummerer wrote: > Currently 'git worktree add ' creates a new branch named after the > basename of the path by default. If a branch with that name already > exists, the command refuses to do anything, unless the '--force' option > is

Re: [PATCH v8 2/4] worktree: improve message when creating a new worktree

t the following output: > > Preparing worktree (detached HEAD 26da330922) > HEAD is now at 26da330922 > > - 'git worktree add ', which checks out the > branch prints the following output: s/prints/and prints/ > Preparing worktree (checking out '') >

Re: [PATCH v8 1/4] worktree: remove extra members from struct add_opts

On Mon, Apr 23, 2018 at 3:38 PM, Thomas Gummerer wrote: > There are two members of 'struct add_opts', which are only used inside > the 'add()' function, but being part of 'struct add_opts' they are > needlessly also passed to the 'add_worktree' function. > > Make them local

Re: Is support for 10.8 dropped?

On Mon, Apr 23, 2018 at 3:58 PM, Totsten Bögershausen <tbo...@web.de> wrote: > On 2018-04-23 18:53, Eric Sunshine wrote: >> On Mon, Apr 23, 2018 at 12:31 PM, Igor Korot <ikoro...@gmail.com> wrote: >>> 1. Is the file name "config.mak" or "config.make&q

Re: Is support for 10.8 dropped?

On Mon, Apr 23, 2018 at 12:31 PM, Igor Korot wrote: > 1. Is the file name "config.mak" or "config.make"? "config.mak" > 2. Do I have to do "make clean" or just remove the line and o "make"? "make clean" would not hurt.

Re: [PATCH v2 2/6] grep.c: take column number as argument to show_line()

On Mon, Apr 23, 2018 at 3:27 AM, Ævar Arnfjörð Bjarmason <ava...@gmail.com> wrote: > On Mon, Apr 23 2018, Eric Sunshine wrote: >> One important issue I noticed is that patch 3/7 neglects to update >> grep.c:init_grep_defaults() to initialize opt.color_columnno. > > I th

Re: [PATCH v3 6/6] help: use command-list.txt for the source of guides

On Sat, Apr 21, 2018 at 12:54 PM, Nguyễn Thái Ngọc Duy wrote: > The help command currently hard codes the list of guides and their > summary in C. Let's move this list to command-list.txt. This lets us > extract summary lines from Documentation/git*.txt. This also > potentially

Re: [PATCH/RFC] completion: complete all possible -no-

On Tue, Apr 17, 2018 at 2:13 PM, Nguyễn Thái Ngọc Duy wrote: > The problem with completing --no- form is that the number of > completable options now usually doubles, taking precious screen space > and also making it hard to find the option you want. > > So the other half of

Re: [PATCH v7 0/4] worktree: teach "add" to check out existing branches

On Sun, Apr 15, 2018 at 4:29 PM, Thomas Gummerer wrote: > The main change once again in this series is the user interface. It > feels like we went in a complete circle here now, as this iteration is > bringing the "Preparing ..." line back (although in a slightly >

Re: [PATCH v7 2/4] worktree: improve message when creating a new worktree

t ..." line is printed to stdout by 'git reset > --hard', which is used internally by 'git worktree add'. Fix this > inconsistency by printing the "Preparing ..." message to stdout as > well. As "Preparing ..." is not an error, stdout also seems like the > more appropriate output stream. > > Helped-by: Eric Sunshine <sunsh...@sunshineco.com> > Signed-off-by: Thomas Gummerer <t.gumme...@gmail.com>

Re: [PATCH v2 2/6] grep.c: take column number as argument to show_line()

On Sun, Apr 22, 2018 at 9:17 PM, Taylor Blau <m...@ttaylorr.com> wrote: > On Sun, Apr 22, 2018 at 08:16:12PM -0400, Eric Sunshine wrote: >> One way to achieve a more coherent patch series would be to build the >> machinery first and then expose it to the user in various ways

Re: [PATCH v2 5/6] builtin/grep.c: show column numbers via --column-number

On Sun, Apr 22, 2018 at 4:47 PM, Taylor Blau wrote: > This commit teaches 'git-grep(1)' a new option, '--column-number'. This > option builds upon previous commits to show the column number of the > first match on a non-context line. Imperative mood (and dropping unnecessary

Re: [PATCH v2 4/6] grep.c: display column number of first match

On Sun, Apr 22, 2018 at 4:47 PM, Taylor Blau wrote: > Building upon our work in the previous commit to add members 'columnnum' > and 'color_columno' to 'grep_opt', we teach show_line() how to respect > those options. > > When requested, show_line() will display the column

Re: [PATCH v2 3/6] grep.[ch]: teach columnnum, color_columnno to grep_opt

On Sun, Apr 22, 2018 at 7:24 PM, Taylor Blau wrote: > On Sun, Apr 22, 2018 at 11:42:48PM +0200, Ęvar Arnfjörš Bjarmason wrote: >> On Sun, Apr 22 2018, Taylor Blau wrote: >> > In preparation of adding --column-number to 'git-grep(1)', we extend >> > grep_opt to take in the

Re: [PATCH v2 2/6] grep.c: take column number as argument to show_line()

On Sun, Apr 22, 2018 at 4:47 PM, Taylor Blau wrote: > show_line() currently receives the line number within the > 'grep_opt->buf' in order to determine which line number to display. In > order to display information about the matching column number--if > requested--we must

Re: [PATCH v2 1/6] grep.c: take regmatch_t as argument in match_line()

On Sun, Apr 22, 2018 at 4:47 PM, Taylor Blau wrote: > In a subsequent patch, we teach show_line() to optionally include the > column number of the first match on each matched line. > > The regmatch_t involved in match_line() and match_one_pattern() both > contain this

Re: Is support for 10.8 dropped?

On Sun, Apr 22, 2018 at 1:15 AM, Igor Korot wrote: > MyMac:git-2.17.0 igorkorot$ cat config.mak > NO_GETTEXT=Yes > NO_OPENSSL=Yes > > MyMac:dbhandler igorkorot$ /Users/igorkorot/git-2.17.0/git pull > fatal: unable to access > 'https://github.com/oneeyeman1/dbhandler.git/':

Re: [PATCH v4 05/11] replace: introduce --convert-graft-file

On Sat, Apr 21, 2018 at 5:48 AM, Johannes Schindelin wrote: > This option is intended to help with the transition away from the > now-deprecated graft file. > > Signed-off-by: Johannes Schindelin > --- > diff --git a/builtin/replace.c

Re: [PATCH v3] fast-export: fix regression skipping some merge-commits

On Fri, Apr 20, 2018 at 6:12 PM, Martin Ågren wrote: > 7199203937 (object_array: add and use `object_array_pop()`, 2017-09-23) > noted that the pattern `object = array.objects[--array.nr].item` could > be abstracted as `object = object_array_pop()`. > > Unfortunately, one

Re: [PATCH 2/3] sequencer: leave a tell-tale when a fixup/squash failed

On Fri, Apr 20, 2018 at 8:18 AM, Johannes Schindelin wrote: > In the upcoming patch to clean up fixup/squash commit messages even when > skipping a final fixup/squash that failed with merge conflicts, we will > need to have some indicator what happened. > > As we need

Re: [PATCH 1/3] rebase -i: demonstrate bug with fixup!/squash! commit messages

On Fri, Apr 20, 2018 at 3:29 PM, Eric Sunshine <sunsh...@sunshineco.com> wrote: > On Fri, Apr 20, 2018 at 8:17 AM, Johannes Schindelin > <johannes.schinde...@gmx.de> wrote: >> + test_must_fail env FAKE_LINES="1 fixup 2 fixup 4" \ >&

Re: [PATCH 1/3] rebase -i: demonstrate bug with fixup!/squash! commit messages

On Fri, Apr 20, 2018 at 8:17 AM, Johannes Schindelin wrote: > When multiple fixup/squash commands are processed and the last one > causes merge conflicts and is skipped, we leave the "This is a > combination of ..." comments in the commit message. > > Signed-off-by:

Re: [PATCH v1] perf/aggregate: tighten option parsing

On Fri, Apr 20, 2018 at 8:10 AM, Christian Couder wrote: > When passing an option '--foo' that it does not recognize, the > aggregate.perl script should die with an helpful error message > like: > > unknown option '--foo' at ./aggregate.perl line 80. > > rather than:

Re: [PATCH 1/2] commit: fix --short and --porcelain

On Tue, Apr 17, 2018 at 11:06 PM, Samuel Lijin wrote: > Make invoking `git commit` with `--short` or `--porcelain` return status > code zero when there is something to commit. > > Mark the commitable flag in the wt_status object in the call to > `wt_status_collect()`, instead

Re: [PATCH v7 07/17] # This is a combination of 2 commits. # This is the 1st commit message:

On Thu, Apr 19, 2018 at 8:20 AM, Johannes Schindelin wrote: > # This is a combination of 2 commits. # This is the 1st commit message: Botched squash/fixup? > sequencer: introduce the `merge` command > > This patch is part of the effort to reimplement

Re: [PATCH] worktree: accept -f as short for --force for removal

On Tue, Apr 17, 2018 at 8:17 PM, Junio C Hamano <gits...@pobox.com> wrote: > Eric Sunshine <sunsh...@sunshineco.com> writes: >> Makes sense. A possible rewrite (of the entire commit message): >> >> worktree: remove: recognize -f as short for --force >>

Re: [PATCH 2/2] builtin/blame: highlight recently changed lines

On Tue, Apr 17, 2018 at 5:30 PM, Stefan Beller wrote: > Choose a different color for dates and imitate a 'temperature cool down' > depending upon age. > > Originally I had planned to have the temperature cooldown dependent on > the age of the project or file for example, as

Re: [PATCH] worktree: accept -f as short for --force for removal

rgets to recognize the short form, despite git-worktree.txt documenting -f as supported. Replace OPT_BOOL with OPT__FORCE, which provides -f for free, and makes 'remove' consistent with 'add' option parsing (which also specifies the PARSE_OPT_NOCOMPLETE flag). > Helped-by:

Re: What's cooking in git.git (Apr 2018, #02; Tue, 17)

On Tue, Apr 17, 2018 at 2:07 AM, Junio C Hamano wrote: > * so/grossary-ancestor (2018-04-17) 1 commit > - glossary: substitute "ancestor" for "direct ancestor" in 'push' > description. s/grossary/glossary/

Re: [PATCH] worktree: accept -f as short for --force for removal

On Mon, Apr 16, 2018 at 6:16 PM, Stefan Beller wrote: > The force flag is very common in many commands and is commonly > abbreviated with '-f', so add that to worktree removal, too > > Signed-off-by: Stefan Beller > --- > diff --git a/builtin/worktree.c

Re: [PATCH v8 08/14] commit-graph: implement git commit-graph read

On Sat, Apr 14, 2018 at 6:15 PM, Jakub Narebski wrote: > Derrick Stolee writes: >> + NUM_CHUNKS=$((3 + $(echo "$2" | wc -w))) > > I don't know if it is possible to do the above in a portable shell > without using external 'wc' command. Also, isn't

Re: [PATCH] Deprecate support for .git/info/grafts

On Fri, Apr 13, 2018 at 7:11 AM, Johannes Schindelin wrote: > The grafts feature was a convenient way to "stich together" ancient > history to the fresh start of linux.git. > [...] > The much younger feature implemented as `git replace` set out to remedy > those

Re: [PATCH v6 0/6] worktree: teach "add" to check out existing branches

On Wed, Apr 11, 2018 at 4:50 PM, Thomas Gummerer wrote: > And just as I'm re-reading my commit messages, I guess there was one > more motivation for printing the "HEAD is now at ..." line ourselves: > > If the '--no-checkout' flag is given, the output of 'git worktree

Re: [PATCH v6 0/6] worktree: teach "add" to check out existing branches

On Wed, Apr 11, 2018 at 4:09 PM, Thomas Gummerer <t.gumme...@gmail.com> wrote: > On 04/09, Eric Sunshine wrote: >> Another solution would be not to augment the "HEAD is now at..." >> message at all. I realize that that augmentation was one of the >> origi

Re: [PATCH resend] SubmittingPatches: mention the git contacts command

On Wed, Apr 11, 2018 at 4:20 PM, Thomas Gummerer wrote: > Instead of just mentioning 'git blame' and 'git shortlog', which make it > quite hard for new contributors to pick out the appropriate list of > people to cc on their patch series, mention the 'git contacts' utility,

Re: [PATCH v14 2/4] ref-filter: make ref_array_item allocation more consistent

On Wed, Apr 11, 2018 at 2:07 PM, Stefan Beller wrote: > On Wed, Apr 11, 2018 at 10:57 AM, Harald Nordgren > wrote: >> There have been no new comments for the last few days. I know Jeff >> King will be away for the next two weeks, but should we still

Re: [PATCH v2 04/10] commit-graph: compute generation numbers

On Wed, Apr 11, 2018 at 9:02 AM, Derrick Stolee wrote: > On 4/10/2018 10:51 PM, Junio C Hamano wrote: >> In case we want to do the "we know this is very large, but we do not >> know the exact value", we may actually want a mode where we can >> pretend that GENERATION_NUMBER_MAX

Re: [PATCH v6 15/15] rebase -i --rebase-merges: add a section to the man page

On Wed, Apr 11, 2018 at 11:35 AM, Phillip Wood wrote: > On 10/04/18 13:30, Johannes Schindelin wrote: >> +The `reset` command is essentially a `git reset --hard` to the specified >> +revision (typically a previously-labeled one). > > s/labeled/labelled/ American vs.

Re: Is support for 10.8 dropped?

On Wed, Apr 11, 2018 at 12:28 AM, Igor Korot wrote: >>> Is there a way to check for OpenSSL presence? >> >> Not sure what you're asking. Are you asking how to determine if you >> already have OpenSSL built on your machine? > > Yes, that's what I was asking... Easiest way to

Re: [PATCH v1] fsmonitor: fix incorrect buffer size when printing version number

On Tue, Apr 10, 2018 at 2:43 PM, Ben Peart wrote: > This is a trivial bug fix for passing the incorrect size to snprintf() when > outputing the version. It should be passing the size of the destination > buffer s/outputing/outputting/ > rather than the size of the

<    2   3   4   5   6   7   8   9   10   11   >