Re: [PATCH 8/8] gpg-interface: handle alternative signature types

On Mon, Apr 9, 2018 at 4:41 PM, Ben Toews wrote: > [...] > This patch introduces a set of configuration options for > defining a "signing tool", of which gpg may be just one. > With this patch you can: > > - define a new tool "foo" with signingtool.foo.program > > - map

Re: [PATCH v7 1/2] builtin/config.c: treat type specifiers singularly

On Mon, Apr 9, 2018 at 10:12 PM, Taylor Blau wrote: > On Tue, Apr 10, 2018 at 10:22:25AM +0900, Junio C Hamano wrote: >> I suspect that it may be OK to switch to last-one-wins, but then we >> should give a justification that is a bit stronger than "we want to >> avoid

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

On Mon, Apr 9, 2018 at 6:46 PM, Taylor Blau wrote: > Attached is the seventh re-roll of my series to support '--type=' > instead of '--' in 'git-config(1)'. > > Since v6, I have changed only the wording in > Documentation/git-config.txt, which Eric and I reached consensus upon

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

On Mon, Apr 9, 2018 at 3:30 PM, Thomas Gummerer <t.gumme...@gmail.com> wrote: > On 04/08, Eric Sunshine wrote: >> As with Junio, I'm fine with this hidden option (for now), however, I >> think you can take this a step further. Rather than having a (hidden) >> git-re

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

On Mon, Apr 9, 2018 at 3:44 PM, Thomas Gummerer <t.gumme...@gmail.com> wrote: > On 04/08, Eric Sunshine wrote: >> This is making me wonder if "Checking out branch" is perhaps the wrong >> terminology. What if it said something like this instead: >&

Re: [PATCH 6/8] gpg-interface: find the last gpg signature line

On Mon, Apr 9, 2018 at 4:41 PM, Ben Toews wrote: > From: Jeff King > > A signed tag has a detached signature like this: > > object ... > [...more header...] > > This is the tag body. > > -BEGIN PGP SIGNATURE- > [opaque gpg data] > -END

Re: [PATCH 1/8] gpg-interface: handle bool user.signingkey

On Mon, Apr 9, 2018 at 4:41 PM, Ben Toews wrote: > From: Jeff King > > The config handler for user.signingkey does not check for a > boolean value, and thus: > > git -c user.signingkey tag > > will segfault. We could fix this and even shorten the code > by

Re: Want to start contributing to git through this task: "Use dir-iterator to avoid explicit recursiv

On Mon, Apr 9, 2018 at 9:51 AM, vaibhav kurhe wrote: > https://git.github.io/SoC-2018-Microprojects/. > Out of the tasks listed down in above URL, I found this one interesting:- > "Use dir-iterator to avoid explicit recursive directory traversal" > I cloned the git repo

Re: [PATCH/RFC 5/5] help: add "-a --verbose" to list all commands with synopsis

On Mon, Apr 9, 2018 at 5:47 AM, Junio C Hamano <gits...@pobox.com> wrote: > Eric Sunshine <sunsh...@sunshineco.com> writes: >> On Mon, Mar 26, 2018 at 12:55 PM, Nguyễn Thái Ngọc Duy >> <pclo...@gmail.com> wrote: >>> + switch (category) { >>&

[PATCH] configure.ac: fix botched FREAD_READS_DIRECTORIES check

, the test program won't even compile, thus the check fails unconditionally. Fix these problems. Reported-by: Jonathan Primrose <jprim...@gmail.com> Signed-off-by: Eric Sunshine <sunsh...@sunshineco.com> --- Problem report and discussion: https://public-inbox.org/git/82c91eac-9d

[PATCH 1/2] git-worktree.txt: recommend 'git worktree remove' over manual deletion

When cc73385cf6 (worktree remove: new command, 2018-02-12) implemented and documented 'git worktree remove', it forgot to update existing instructions suggesting manual deletion. Fix this oversight by recommending 'git worktree remove' instead. Signed-off-by: Eric Sunshine <su

[PATCH 2/2] git-worktree.txt: unify command-line prompt in example blocks

The command-line prompt in the "EXAMPLES" section is "$", however, examples in the 'git worktree list' section (oddly) use "S" as a prompt. Fix this inconsistency by settling on "$" as prompt in all examples. Signed-off-by: Eric Sunshine <suns

Re: [PATCH/RFC 0/5] Keep all info in command-list.txt in git binary

On Mon, Mar 26, 2018 at 12:55 PM, Nguyễn Thái Ngọc Duy wrote: > This is pretty rough but I'd like to see how people feel about this > first. > > I notice we have two places for command classification. One in > command-list.txt, one in __git_list_porcelain_commands() in >

Re: [PATCH/RFC 3/5] generate-cmdlist.sh: keep all information in common-cmds.h

On Mon, Apr 9, 2018 at 12:59 AM, Eric Sunshine <sunsh...@sunshineco.com> wrote: > However, I'm concerned that this change may be going in the wrong > direction. A line in "### command list" section looks like this: > > command-name category [deprecated] [c

Re: [PATCH/RFC 5/5] help: add "-a --verbose" to list all commands with synopsis

On Mon, Mar 26, 2018 at 12:55 PM, Nguyễn Thái Ngọc Duy wrote: > Signed-off-by: Nguyễn Thái Ngọc Duy > --- > diff --git a/help.c b/help.c > @@ -282,6 +282,67 @@ void list_porcelain_cmds(void) > +static const char *get_category_name(unsigned int category) > +{

Re: [PATCH/RFC 3/5] generate-cmdlist.sh: keep all information in common-cmds.h

On Mon, Mar 26, 2018 at 12:55 PM, Nguyễn Thái Ngọc Duy wrote: > common-cmds.h is used to extract the list of common commands (by > group) and a one-line summary of each command. Some information is > dropped, for example command category or summary of other commands. > Update

Re: [PATCH/RFC 2/5] git.c: implement --list-cmds=all and use it in git-completion.bash

On Mon, Mar 26, 2018 at 12:55 PM, Nguyễn Thái Ngọc Duy wrote: > Signed-off-by: Nguyễn Thái Ngọc Duy > --- > diff --git a/help.c b/help.c > @@ -228,6 +228,21 @@ void list_common_cmds_help(void) > +void list_all_cmds(void) > +{ > + struct cmdnames

Re: [PATCH v12 4/4] ls-remote: create '--sort' option

On Sun, Apr 8, 2018 at 6:16 PM, Junio C Hamano wrote: > Harald Nordgren writes: >> +--sort=:: >> + Sort based on the key given. [...] > > This is a tangent but I suspect that the description of --sort in > git-for-each-ref documentation is wrong

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

On Sun, Apr 8, 2018 at 10:24 AM, Thomas Gummerer <t.gumme...@gmail.com> wrote: > On 04/08, Eric Sunshine wrote: >> On Sat, Mar 31, 2018 at 11:17 AM, Thomas Gummerer <t.gumme...@gmail.com> >> wrote: > Let me think through some of the cases here, of 'git worktre add &g

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

On Sun, Apr 1, 2018 at 9:11 AM, Thomas Gummerer wrote: > So while playing with it a bit more I found one case where the new UI > is not ideal and a bit confusing. Namely when the new check out dwim > kicks in, but there is already a file/directory at the path we're > giving

Re: Is support for 10.8 dropped?

On Sun, Apr 8, 2018 at 7:55 PM, Igor Korot <ikoro...@gmail.com> wrote: > On Sun, Apr 8, 2018, 6:23 PM Eric Sunshine <sunsh...@sunshineco.com> wrote: >> And, as noted earlier, before running "make", you may need to create >> config.mak to override some setti

Re: Is support for 10.8 dropped?

On Sun, Apr 8, 2018 at 6:37 PM, Igor Korot wrote: > MyMac:git-2.17.0 igorkorot$ make configure > GIT_VERSION = 2.17.0 > GEN configure > /bin/sh: autoconf: command not found > make: *** [configure] Error 127 > > Does this mean that something is a miss? That means that you

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

On Sat, Mar 31, 2018 at 11:18 AM, Thomas Gummerer wrote: > [...] > However we can do a little better than that, and check the branch out if > it is not checked out anywhere else. This will help users who just want > to check an existing branch out into a new worktree, and

Re: [PATCH v1 1/2] perf/run: add --subsection option

On Sun, Apr 8, 2018 at 5:35 AM, Christian Couder wrote: > This new option makes it possible to run perf tests as defined > in only one subsection of a config file. > > Signed-off-by: Christian Couder > --- > diff --git a/t/perf/run

Re: [PATCH v6 3/6] worktree: improve message when creating a new worktree

On Sat, Mar 31, 2018 at 11:18 AM, Thomas Gummerer wrote: > [...] > Fix these inconsistencies, and no longer show the identifier by making > the 'git reset --hard' call not print the "HEAD is now at ..." line > using the newly introduced flag from the previous commit, and

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

On Sat, Mar 31, 2018 at 11:17 AM, Thomas Gummerer wrote: > This round should fix all the UI issues Eric found in the last round. > The changes I made in a bit more detail: > > - added a new commit introducing a new hidden --show-new-head-line > flag in 'git reset'. This

Re: [PATCH v11 4/4] ls-remote: create '--sort' option

On Sat, Apr 7, 2018 at 12:42 PM, Harald Nordgren wrote: > Create a '--sort' option for ls-remote, based on the one from > for-each-ref. This e.g. allows ref names to be sorted by version > semantics, so that v1.2 is sorted before v1.10. > > Signed-off-by: Harald Nordgren

Re: [PATCH v11 1/4] ref-filter: use "struct object_id" consistently

On Sat, Apr 7, 2018 at 12:42 PM, Harald Nordgren wrote: > From: Jeff King > > Internally we store a "struct object_id", and all of our > callers have one to pass us. But we insist that they peel it > to its bare-sha1 hash, which we then hashcpy() into

Re: [RFC][PATCH] git-stash: convert git stash list to C builtin

On Sat, Apr 7, 2018 at 4:56 AM, Eric Sunshine <sunsh...@sunshineco.com> wrote: > The existing git-stash requires a working directory: > > % git stash list > fatal: not a git repository (or any of the parent directories): .git > % Correction on the error message: % git stash

Re: [RFC][PATCH] git-stash: convert git stash list to C builtin

On Tue, Apr 3, 2018 at 5:38 PM, Paul-Sebastian Ungureanu <ungureanupaulsebast...@gmail.com> wrote: > On 25.03.2018 10:08, Eric Sunshine wrote: >> On Sat, Mar 24, 2018 at 2:23 PM, Paul-Sebastian Ungureanu >> <ungureanupaulsebast...@gmail.com> wrote: >>> diff

Re: [PATCH v5 1/3] builtin/config: introduce `--default`

On Fri, Apr 6, 2018 at 8:58 PM, Taylor Blau <m...@ttaylorr.com> wrote: > On Fri, Apr 06, 2018 at 03:40:56AM -0400, Eric Sunshine wrote: >> On Fri, Apr 6, 2018 at 2:53 AM, Eric Sunshine <sunsh...@sunshineco.com> >> wrote: >> One other issue. If "git config

Re: [PATCH v5 1/3] builtin/config: introduce `--default`

On Fri, Apr 6, 2018 at 8:49 PM, Taylor Blau <m...@ttaylorr.com> wrote: > On Fri, Apr 06, 2018 at 02:53:45AM -0400, Eric Sunshine wrote: >> On Fri, Apr 6, 2018 at 2:30 AM, Taylor Blau <m...@ttaylorr.com> wrote: >> > +test_expect_success 'uses --default when missing e

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

On Fri, Apr 6, 2018 at 8:39 PM, Taylor Blau <m...@ttaylorr.com> wrote: > On Fri, Apr 06, 2018 at 03:04:53AM -0400, Eric Sunshine wrote: >> Sorry for being such a stickler, but this is still too mushy. The >> first two sentences are saying effectively the same thing. One o

Re: Is support for 10.8 dropped?

On Fri, Apr 6, 2018 at 10:20 PM, Igor Korot wrote: >>> dyld: lazy symbol binding failed: Symbol not found: ___strlcpy_chk >>> Referenced from: /usr/local/git/libexec/git-core/git >>> Expected in: /usr/lib/libSystem.B.dylib >> >> It's not clear what installer you used? Was

Re: [PATCH v2 4/4] Document the new color.* settings to colorize push errors/hints

On Fri, Apr 6, 2018 at 8:15 AM, Johannes Schindelin <johannes.schinde...@gmx.de> wrote: > On Fri, 6 Apr 2018, Eric Sunshine wrote: >> On Thu, Apr 5, 2018 at 6:48 PM, Johannes Schindelin >> <johannes.schinde...@gmx.de> wrote: >> > +color.advice.advice:: >>

Re: [PATCH 13/19] refs: store the main ref store inside the repository struct

On Fri, Apr 6, 2018 at 7:21 PM, Stefan Beller wrote: > diff --git a/repository.h b/repository.h > @@ -26,6 +26,11 @@ struct repository { > + /* > +* The store in which the refs are hold. > +*/ s/hold/held/ Also, this comment is short enough to fit on

Re: [PATCH 06/19] refs: add repository argument to get_main_ref_store

On Fri, Apr 6, 2018 at 7:21 PM, Stefan Beller wrote: > Add a repository argument to allow the get_main_ref_store caller > to be more specific about which repository to handle. This is a small > mechanical change; it doesn't change the implementation to handle > repositories

Re: [PATCH v2 4/4] Document the new color.* settings to colorize push errors/hints

On Thu, Apr 5, 2018 at 6:48 PM, Johannes Schindelin wrote: > Let's make it easier for users to find out how to customize these colors. > > Signed-off-by: Johannes Schindelin > --- > diff --git a/Documentation/config.txt

Re: [PATCH v2 3/4] Add a test to verify that push errors are colorful

On Thu, Apr 5, 2018 at 6:48 PM, Johannes Schindelin wrote: > This actually only tests whether the push errors/hints are colored if > the respective color.* config settings are `always`, but in the regular > case they default to `auto` (in which case we color the

Re: [PATCH v5 1/3] builtin/config: introduce `--default`

On Fri, Apr 6, 2018 at 2:53 AM, Eric Sunshine <sunsh...@sunshineco.com> wrote: > On Fri, Apr 6, 2018 at 2:30 AM, Taylor Blau <m...@ttaylorr.com> wrote: >> +test_expect_success 'uses entry when available' ' >> + echo bar >expect && >> + git

Re: [PATCH v5 3/3] builtin/config: introduce `color` type specifier

On Fri, Apr 6, 2018 at 2:30 AM, Taylor Blau wrote: > [...] > For consistency, let's introduce `--type=color` and encourage its use > with `--default` together over `--get-color` alone. A couple minor subjective comments below... neither worth a re-roll. > Signed-off-by:

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

On Fri, Apr 6, 2018 at 2:39 AM, Taylor Blau wrote: > [...] > In this patch, we support `--type=` in > addition to `--int`, `--bool`, and etc. This allows the aforementioned > upcoming patch to support querying a color value with a default via >

Re: [PATCH v5 1/3] builtin/config: introduce `--default`

On Fri, Apr 6, 2018 at 2:30 AM, Taylor Blau wrote: > [...] > This commit (and those following it in this series) aim to eventually > replace `--get-color` with a consistent alternative. By introducing > `--default`, we allow the `--get-color` action to be promoted to a >

Re: [PATCH v5 2/2] builtin/config.c: prefer `--type=bool` over `--bool`, etc.

On Fri, Apr 6, 2018 at 1:29 AM, Taylor Blau wrote: > builtin/config.c: prefer `--type=bool` over `--bool`, etc. This patch isn't just preferring --type; it's actually introducing the functionality. Perhaps: builtin/config.c: support --type= as preferred alias for -- (Not

Re: [PATCH v4 3/3] builtin/config: introduce `color` type specifier

On Thu, Apr 5, 2018 at 6:36 PM, Jeff King wrote: > On Wed, Apr 04, 2018 at 07:59:17PM -0700, Taylor Blau wrote: >> + if (type == TYPE_COLOR) { >> + char v[COLOR_MAXLEN]; >> + if (!git_config_color(v, key, value)) >> + /* >> +

Re: [PATCH v4 1/3] builtin/config: introduce `--default`

On Wed, Apr 4, 2018 at 10:59 PM, Taylor Blau wrote: > [...] > This commit (and those following it in this series) aim to eventually > replace `--get-color` with a consistent alternative. By introducing > `--default`, we allow the `--get-color` action to be promoted to a >

Re: [PATCH v4 2/2] builtin/config.c: prefer `--type=bool` over `--bool`, etc.

On Wed, Apr 4, 2018 at 10:00 PM, Taylor Blau wrote: > [...] > In this patch, we prefer `--type=[int|bool|bool-or-int|...]` over > `--int`, `--bool`, and etc. This allows the aforementioned upcoming > patch to support querying a color value with a default via `--type=color >

Re: Is support for 10.8 dropped?

On Thu, Apr 5, 2018 at 3:48 PM, Igor Korot wrote: > Is support for 10.8 dropped? Until about a year ago, I was still periodically building Git from source on MacOS 10.5, and there hasn't been any outright effort to drop support for older MacOS, so I expect that 10.8 is still

Re: Errors testing on macOS High Sierra version 10.13.4

On Wed, Apr 4, 2018 at 1:06 PM, Wink Saville wrote: > I built git on a mac osx laptop and got some errors when testing. > I ran ./ci/run-build-and-tests.sh and three of the tests had failures > that appear to be associated with character encoding: > ... > Of course on travis-ci

Re: [PATCH] specify encoding for sed command

On Thu, Apr 5, 2018 at 2:53 AM, Ævar Arnfjörð Bjarmason wrote: > On Thu, Apr 05 2018, Stephon Harris wrote: >> Fixes issue with seeing `sed: RE error: illegal byte sequence` when running >> git-completion.bash > > This is getting closer to the issue than your previous patch,

Re: [PATCH v3 2/2] t3200: verify "branch --list" sanity when rebasing from detached HEAD

On Tue, Apr 3, 2018 at 10:47 AM, Kaartic Sivaraam <kaartic.sivar...@gmail.com> wrote: > From: Eric Sunshine <sunsh...@sunshineco.com> > > "git branch --list" shows an in-progress rebase as: > > * (no branch, rebasing ) > master > ... > >

Re: [PATCH v3 1/2] builtin/config.c: treat type specifiers singularly

On Wed, Apr 4, 2018 at 2:07 AM, Taylor Blau wrote: > [...] > In fact, `git config` will not accept multiple type specifiers at a > time, as indicated by: > > $ git config --int --bool some.section > error: only one type at a time. > > This patch uses `OPT_SET_INT` to prefer

Re: [PATCH v3 2/2] builtin/config.c: prefer `--type=bool` over `--bool`, etc.

On Wed, Apr 4, 2018 at 2:07 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 are satisfiable under that type, and (2) that outgoing values are >

Re: A potential approach to making tests faster on Windows

On Tue, Apr 3, 2018 at 5:49 AM, Johannes Schindelin wrote: > My main evidence that shell scripts on macOS are slower than on Linux was > the difference of the improvement incurred by moving more things from > git-rebase--interactive.sh into sequencer.c: Linux saw an

[PATCH] t2028: tighten grep expression to make "move worktree" test more robust

such accidental matches. While at it, drop an unused variable ("toplevel") from the test and tighten a similarly too-loose expression in a related test. Reported-by: Jens Krüger <jens.krue...@frm2.tum.de> Signed-off-by: Eric Sunshine <sunsh...@sunshineco.com> --

Re: Test t2028 failes

On Tue, Apr 3, 2018 at 4:42 AM, Jens Krüger wrote: > Maybe, the attached patch may help. On my machine(s) it helped. > git worktree list --porcelain >out && > grep "^worktree.*/destination" out && > - ! grep "^worktree.*/source" out && > + ! grep

Re: Test t2028 failes

On Tue, Apr 3, 2018 at 4:38 AM, Jens Krüger <jens.krue...@frm2.tum.de> wrote: > Am 03.04.2018 um 10:16 schrieb Eric Sunshine: >> Using the "out" file you attached, can you show the output of these >> commands? >> grep "^worktree.*/destination&qu

Re: Test t2028 failes

On Tue, Apr 3, 2018 at 4:01 AM, Jens Krüger wrote: > The actual2 file does not exists, if I call the ./t2028-worktree-move.sh > with the '-v -i' options, only without any option or with '-v' option. The content of the various files looks correct, and absence of

Re: [PATCH v2 2/2] t3200: verify "branch --list" sanity when rebasing from detached HEAD

On Tue, Apr 3, 2018 at 12:31 AM, Kaartic Sivaraam <kaartic.sivar...@gmail.com> wrote: > From: Eric Sunshine <sunsh...@sunshineco.com> > > "git branch --list" shows an in-progress rebase as: > > * (no branch, rebasing ) > master > ... > >

Re: Test t2028 failes

On Tue, Apr 3, 2018 at 2:33 AM, Jens Krüger wrote: > *** t2028-worktree-move.sh *** > not ok 12 - move worktree > # > # toplevel="$(pwd)" && > # git worktree move source destination && > # test_path_is_missing source && > #

Re: [PATCH v5] ls-remote: create '--sort' option

On Mon, Apr 2, 2018 at 6:53 PM, Eric Sunshine <sunsh...@sunshineco.com> wrote: > On Mon, Apr 2, 2018 at 6:11 PM, Harald Nordgren > <haraldnordg...@gmail.com> wrote: >> Create a '--sort' option for ls-remote, based on the one from >> for-each-ref. This e.g. allows ref

Re: [PATCH v5] ls-remote: create '--sort' option

On Mon, Apr 2, 2018 at 6:11 PM, Harald Nordgren wrote: > Create a '--sort' option for ls-remote, based on the one from > for-each-ref. This e.g. allows ref names to be sorted by version > semantics, so that v1.2 is sorted before v1.10. > > Signed-off-by: Harald Nordgren

Re: [GSoC][PATCH v5] test: avoid pipes in git related commands for test

On Tue, Mar 27, 2018 at 1:31 PM, Pratik Karki wrote: > Avoid using pipes downstream of Git commands since the exit codes > of commands upstream of pipes get swallowed, thus potentially > hiding failure of those commands. Instead, capture Git command > output to a file and

Re: [PATCH v3 2/3] config.c: introduce 'git_config_color' to parse ANSI colors

On Wed, Mar 28, 2018 at 9:16 PM, Taylor Blau wrote: > In preparation for adding `--color` to the `git-config(1)` builtin, > let's introduce a color parsing utility, `git_config_color` in a similar > fashion to `git_config_`. Did you mean s/--color/--type=color/ ? >

Re: [PATCH v3 1/3] builtin/config: introduce `--default`

On Wed, Mar 28, 2018 at 9:16 PM, Taylor Blau wrote: > For some use cases, callers of the `git-config(1)` builtin would like to > fallback to default values when the slot asked for does not exist. In > addition, users would like to use existing type specifiers to ensure > that

Re: [PATCH v6 0/6] ref-filter: remove die() calls from formatting logic

On Thu, Mar 29, 2018 at 10:41 AM, Christian Couder wrote: > On Thu, Mar 29, 2018 at 2:52 PM, Оля Тележная > wrote: >> Move helper function from strbuf to ref-filter. >> Get rid of some memory leaks. > > The above seems to be the changes

Re: [PATCH v4 1/5] stash: improve option parsing test coverage

On Wed, Mar 28, 2018 at 6:21 PM, Joel Teichroeb wrote: > In preparation for converting the stash command incrementally to > a builtin command, this patch improves test coverage of the option > parsing. Both for having too many paramerters, or too few.

Re: [PATCH] submodule: check for NULL return of get_submodule_ref_store()

On Wed, Mar 28, 2018 at 4:08 PM, Stefan Beller <sbel...@google.com> wrote: > On Wed, Mar 28, 2018 at 11:57 AM, Eric Sunshine <sunsh...@sunshineco.com> > wrote: >>> +test_expect_success 'moving the submodule does not break the superproject' >>> ' >>&

Re: [PATCH] submodule: check for NULL return of get_submodule_ref_store()

On Wed, Mar 28, 2018 at 2:38 PM, Stefan Beller wrote: > diff --git a/t/t7400-submodule-basic.sh b/t/t7400-submodule-basic.sh > @@ -821,6 +821,18 @@ test_expect_success 'moving the superproject does not > break submodules' ' > +test_expect_success 'moving the submodule does

Re: [PATCH 2/4] add chdir-notify API

On Wed, Mar 28, 2018 at 1:40 PM, Jeff King wrote: > [...] > Let's provide an API to let code that stores relative paths > "subscribe" to updates to the current working directory. > This means that callers of chdir() don't need to know about > all subscribers ahead of time; they can

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

On Sun, Mar 25, 2018 at 9:49 AM, 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 v5 4/6] worktree: factor out dwim_branch function

On Sun, Mar 25, 2018 at 9:49 AM, Thomas Gummerer wrote: > Factor out a dwim_branch function, which takes care of the dwim'ery in > 'git worktree add '. It's not too much code currently, but we're > adding a new kind of dwim in a subsequent patch, at which point it makes >

Re: [PATCH v5 3/6] worktree: remove force_new_branch from struct add_opts

On Sun, Mar 25, 2018 at 9:49 AM, Thomas Gummerer wrote: > The 'force_new_branch' flag in 'struct add_opts' is only used inside the > add function, where we already have the same information stored in the > 'new_branch_force' variable. Avoid that unnecessary duplication.

Re: [PATCH v5 2/6] worktree: be clearer when "add" dwim-ery kicks in

On Sun, Mar 25, 2018 at 9:49 AM, Thomas Gummerer wrote: > Currently there is no indication in the "git worktree add" output that > a new branch was created. This would be especially useful information > in the case where the dwim of "git worktree add " kicks in, as the >

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

On Sun, Mar 25, 2018 at 9:49 AM, Thomas Gummerer wrote: > Thanks Eric for the review of the previous round and Duy and Junio for > additional comments. > This round should address all of Eric's comments from the previous round. Thanks, it appears to cover my review comments

Re: [PATCH 2/2] doc hash-function-transition: clarify what SHAttered means

On Mon, Mar 26, 2018 at 2:27 PM, Ævar Arnfjörð Bjarmason wrote: > Attempt to clarify what the SHAttered attack means in practice for > Git. The previous version of the text made no mention whatsoever of > Git already having a mitigation for this specific attack, which the >

Re: [PATCH v3 2/3] fast-import: introduce mem_pool type

On Mon, Mar 26, 2018 at 1:03 PM, Jameson Miller wrote: > Introduce the mem_pool type which encapsulates all the information > necessary to manage a pool of memory.This change moves the existing s/memory\.This/memory. This/ > variables in fast-import used to support the

Re: [PATCH] branch -l: print useful info whilst rebasing a non-local branch

creation > [2/5]: t: switch "branch -l" to "branch --create-reflog" > [3/5]: branch: deprecate "-l" option > [4/5]: branch: drop deprecated "-l" option > [5/5]: branch: make "-l" a synonym for "--list" The entire series looks good to me. FWIW, Reviewed-by: Eric Sunshine <sunsh...@sunshineco.com>

Re: [PATCH 00/10] Hash-independent tests (part 1)

On Sun, Mar 25, 2018 at 3:20 PM, brian m. carlson wrote: > This is a series to make our tests hash-independent. Many tests have > hard-coded SHA-1 values in them, and it would be valuable to express > these items in a hash-independent way for our hash transitions. >

Re: [PATCH 2/2] send-email: supply a --send-delay=1 by default

On Sun, Mar 25, 2018 at 2:28 PM, Ævar Arnfjörð Bjarmason wrote: > The earlier change to add this option described the problem this > option is trying to solve. > > This turns it on by default with a value of 1 second, which'll > hopefully solve it, and if not user reports as

Re: [GSoC][PATCH v4] test: avoid pipes in git related commands for test

On Fri, Mar 23, 2018 at 11:01 AM, Pratik Karki wrote: > I hope this follow-on patch[1] is ready for merge. This iteration appears to address review comments from the last few rounds, however, see below for a few new ones... > Avoid using pipes downstream of Git commands

Re: [RFC][PATCH] git-stash: convert git stash list to C builtin

On Sat, Mar 24, 2018 at 2:23 PM, Paul-Sebastian Ungureanu wrote: > Currently, because git stash is not fully converted to C, I > introduced a new helper that will hold the converted commands. > --- > diff --git a/builtin/stash--helper.c b/builtin/stash--helper.c

Re: [PATCH 4/4] stash: convert pop to builtin

On Sat, Mar 24, 2018 at 1:37 PM, Joel Teichroeb wrote: > diff --git a/builtin/stash--helper.c b/builtin/stash--helper.c > @@ -402,6 +408,36 @@ static int drop_stash(int argc, const char **argv, const > char *prefix) > +static int pop_stash(int argc, const char **argv, const

Re: [PATCH 3/4] stash: convert drop and clear to builtin

On Sat, Mar 24, 2018 at 1:37 PM, Joel Teichroeb wrote: > diff --git a/builtin/stash--helper.c b/builtin/stash--helper.c > @@ -313,6 +348,60 @@ static int apply_stash(int argc, const char **argv, > const char *prefix) > +static int drop_stash(int argc, const char **argv, const

Re: [PATCH 2/4] stash: convert branch to builtin

On Sat, Mar 24, 2018 at 1:37 PM, Joel Teichroeb wrote: > diff --git a/builtin/stash--helper.c b/builtin/stash--helper.c > @@ -307,6 +313,42 @@ static int apply_stash(int argc, const char **argv, > const char *prefix) > +static int branch_stash(int argc, const char **argv,

Re: [PATCH 1/4] stash: convert apply to builtin

On Sat, Mar 24, 2018 at 1:37 PM, Joel Teichroeb wrote: > diff --git a/builtin/stash--helper.c b/builtin/stash--helper.c > @@ -0,0 +1,339 @@ > +static int get_stash_info(struct stash_info *info, const char *commit) > +{ > + struct strbuf w_commit_rev = STRBUF_INIT; > +

Re: [PATCH] branch -l: print useful info whilst rebasing a non-local branch

On Sun, Mar 25, 2018 at 09:11:34AM +0530, Kaartic Sivaraam wrote: > On Sunday 25 March 2018 07:04 AM, Eric Sunshine wrote: > > Can we have a couple new tests: one checking "git branch --list" for > > the typical case (when rebasing off a named branch) and one checki

Re: [PATCH] branch -l: print useful info whilst rebasing a non-local branch

On Sun, Mar 25, 2018 at 12:10 AM, Jeff King wrote: > Alternatively, we could at least detect the situation that confused you: > > diff --git a/builtin/branch.c b/builtin/branch.c > @@ -676,6 +676,9 @@ int cmd_branch(int argc, const char **argv, const char > *prefix) > + if

Re: [PATCH] branch -l: print useful info whilst rebasing a non-local branch

On Sun, Mar 25, 2018 at 12:10 AM, Jeff King wrote: > So: > > git branch -l > > _looks_ like it works, but only because list mode is the default. If you > did: > > git branch -l foo > > you would find that it does list "foo" at all, but instead creates a new > branch "foo" with

Re: [PATCH] branch -l: print useful info whilst rebasing a non-local branch

On Sat, Mar 24, 2018 at 2:38 PM, Kaartic Sivaraam wrote: > When rebasing interacitvely (rebase -i), "git branch -l" prints a line The "git branch -l" threw me since "-l" is short for --create-reflog. I'm guessing you meant "git branch --list". > indicating the

Re: [PATCH v2 5/8] completion: add --option completion for most builtin commands

On Sat, Mar 24, 2018 at 4:35 PM, Nguyễn Thái Ngọc Duy wrote: > Many builtin commands use parseopt which supports expose the option s/expose/exposing/ maybe? > list via --git-completion-helper but do not have explicit support in > git-completion.bash. This patch detects those

Re: [PATCH v2] Makefile: detect compiler and enable more warnings in DEVELOPER=1

On Sat, Mar 24, 2018 at 8:53 AM, Nguyễn Thái Ngọc Duy wrote: > The set of extra warnings we enable when DEVELOPER has to be > conservative because we can't assume any compiler version the > developer may use. Detect the compiler version so we know when it's > safe to enable

Re: [RFC PATCH v5 4/8] Extract functions out of git_rebase__interactive

On Fri, Mar 23, 2018 at 5:25 PM, Wink Saville wrote: > The extracted functions are: > [...] > Signed-off-by: Wink Saville > --- > diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh > @@ -740,8 +740,20 @@ get_missing_commit_check_level () { >

Re: [PATCH 00/27] sb/object-store updates

On Fri, Mar 23, 2018 at 1:20 PM, Nguyễn Thái Ngọc Duy wrote: > Interdiff is big due to the "objects." to "objects->" conversion > (blame Brandon for his suggestion, don't blame me :D) > > diff --git a/packfile.c b/packfile.c > @@ -1938,7 +1939,7 @@ static int

Re: [RFC PATCH v4] rebase: Update invocation of rebase dot-sourced scripts

On Fri, Mar 23, 2018 at 5:01 PM, Junio C Hamano <gits...@pobox.com> wrote: > Eric Sunshine <sunsh...@sunshineco.com> writes: >> (despite the run-on sentence in the first paragraph and the apparent >> incorrect explanation of top-level "return" misbehavior --

Re: [RFC PATCH v4] rebase: Update invocation of rebase dot-sourced scripts

Thanks for splitting these changes into smaller, more manageable chunks. A couple non-code comments below apply to both patches in this 2-patch series even though I'm responding only to this patch. (The actual code changes in the other patch looked fine and the patch was easily digested.) On Fri,

Re: [PATCH v4 5/5] ref-filter: get_ref_atom_value() error handling

On Wed, Mar 21, 2018 at 3:30 PM, Junio C Hamano <gits...@pobox.com> wrote: > Eric Sunshine <sunsh...@sunshineco.com> writes: >> strbuf_error() was a possibility proposed in [1], and it does take a >> strbuf. Failure to pass in a strbuf here is just a typo. >

Re: [GSoC][PATCH v3] test: avoid pipes in git related commands for test

On Wed, Mar 21, 2018 at 2:11 PM, Junio C Hamano wrote: > Pratik Karki writes: >> Avoid using pipes downstream of Git commands since the exit >> codes of commands upstream of pipes get swallowed, thus potentially hiding >> failure of those commands.

Re: [GSoC][PATCH v3] test: avoid pipes in git related commands for test

On Wed, Mar 21, 2018 at 2:11 PM, Junio C Hamano wrote: > Pratik Karki writes: >> The changes in patch increased from v1 to v2 because I >> got excited to work in Git codebase and I tried to >> fix the exisiting problems as much as possible. >> Hence,

Re: [GSoC][PATCH] test: avoid pipes in git related commands for test suite

On Mon, Mar 19, 2018 at 1:32 PM, Pratik Karki <predatoram...@gmail.com> wrote: > Thank you Eric Sunshine, > I have done as you had instructed me. I look forward to more > understanding of the codebase and would love to fix > "git rev-parse" problems in my fo

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