Re: [PATCH v2 13/18] color: provide inverted colors, too

On Sun, May 06, 2018 at 09:20:46PM -0400, Johannes Schindelin wrote: > > Heh, of course you knew that already, as I just noticed your patch is > > using the reverse attribute internally (I had thought at first glance > > you were just specifying the background independently). > > > > So really,

main url for linking to git source?

The git-scm.com site currently links to https://github.com/git/git for the (non-tarball) source code. Somebody raised the question[1] of whether it should point to kernel.org instead. Do people find one interface more or less pleasing than the other? Do we want to prefer kernel.org as more

Offre de prêts

Bonjour Vous aviez besoin de prêts d'argent entre particuliers pour faire face aux difficultés financières pour enfin sortir de l'impasse que provoquent les banques, par le rejet de vos dossiers de demande de crédits ? Je suis un un citoyen français à la retraite en mesure de vous faire un prêt

Re: [PATCH] refs: handle null-oid for pseudorefs

On 05/06/2018 03:35 PM, Martin Ågren wrote: > According to the documentation on `git update-ref`, it is possible to > "specify 40 '0' or an empty string as to make sure that the > ref you are creating does not exist." But in the code for pseudorefs, we > do not implement this. If we fail to read

Re: [PATCH v2 13/18] color: provide inverted colors, too

On Mon, May 07, 2018 at 10:35:53AM +0900, Junio C Hamano wrote: > > So really, I guess all I am arguing for is having GIT_COLOR_INV (or > > REVERSE) as a constant, and then teaching the code to combine it with > > the existing "new" color. It's perfectly OK to have: > > > > \x1b[7m\x1b[36m > >

Re: [PATCH v2 2/4] run-command: use BUG() to report bugs, not die()

On Wed, May 02, 2018 at 11:38:31AM +0200, Johannes Schindelin wrote: > The slightly misleading name die_bug() of the function intended to > report a bug is actually called always, and only reports a bug if the > passed-in parameter `err` is non-zero. > > It uses die_errno() to report the bug, to

Re: [PATCH 3/8] push tests: add more testing for forced tag pushing

Hi, On Monday 30 April 2018 01:50 AM, Ævar Arnfjörð Bjarmason wrote: > diff --git a/t/t5516-fetch-push.sh b/t/t5516-fetch-push.sh > index 15c8d5a734..c9a2011915 100755 > --- a/t/t5516-fetch-push.sh > +++ b/t/t5516-fetch-push.sh > @@ -981,7 +981,17 @@ test_expect_success 'push requires --force to

Re: [PATCH v3 1/1] completion: load completion file for external subcommand

On Sun, Apr 29, 2018 at 6:42 PM, Florian Gamböck wrote: > This way we can leverage bash-completion's dynamic loading for git > subcommands and make it easier for developers to distribute custom > completion scripts. The patch and the updated commit message both look good to me.

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

On Sat, May 05, 2018 at 11:57:26PM +0200, Johannes Schindelin wrote: > > It feels really petty complaining about the name, but I just want to > > raise the point, since it will never be easier to change than right now. > > I do hear you. Especially since I hate `git cherry` every single time

Re: [PATCH v2 0/4] Finish the conversion from die("BUG: ...") to BUG()

On Wed, May 02, 2018 at 11:38:13AM +0200, Johannes Schindelin wrote: > The BUG() macro was introduced in this patch series: > https://public-inbox.org/git/20170513032414.mfrwabt4hovuj...@sigill.intra.peff.net > > The second patch in that series converted one caller from die("BUG: ") > to use the

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

On Tue, Apr 17, 2018 at 12:12:12AM +, brian m. carlson wrote: > > That argues more strongly that we would regret unless we make the > > end-user configuration to at least the whole string (which later can > > be promoted to "a pattern that matches the whole string"), not just > > the part

Re: [PATCH 01/28] t/test-lib: add an SHA1 prerequisite

On 7 May 2018 at 01:17, brian m. carlson wrote: > Add an SHA1 prerequisite to annotate both of these types of tests and > disable them when we're using a different hash. In the future, we can > create versions of these tests which handle both SHA-1 and NewHash.

Re: [PATCH 10/28] t: skip pack tests if not using SHA-1

On 7 May 2018 at 01:17, brian m. carlson wrote: > These tests rely on creating packs with specially named objects which > are necessarily dependent on the hash used. Skip these tests if we're > not using SHA-1. > > Signed-off-by: brian m. carlson

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

On Sun, May 06, 2018 at 10:04:31PM -0400, Johannes Schindelin wrote: > > Let's, please, not fall into the trap of polluting git-branch with > > utterly unrelated functionality, as has happened a few times with > > other Git commands. Let's especially not do so merely for the sake of > >

Re: [PATCH] refs: handle null-oid for pseudorefs

On 7 May 2018 at 09:39, Michael Haggerty wrote: > Thanks for the patch. This looks good to me. But it it seems that the > test coverage related to pseudorefs is still not great. Ideally, all of > the following combinations should be tested: > > Pre-update value |

Re: [PATCH 06/28] t0000: annotate with SHA1 prerequisite

On 7 May 2018 at 01:17, brian m. carlson wrote: > Since this is a core test that tests basic functionality, annotate the > assertions that have dependencies on SHA-1 with the appropriate > prerequisite. > > Signed-off-by: brian m. carlson

Re: main url for linking to git source?

Hi Peff, On Mon, 7 May 2018, Jeff King wrote: > The git-scm.com site currently links to https://github.com/git/git for > the (non-tarball) source code. Somebody raised the question[1] of > whether it should point to kernel.org instead. > > Do people find one interface more or less pleasing than

Re: [PATCH] tests: introduce test_unset_prereq, for debugging

> While working on the --convert-graft-file test, I missed that I was > relying on the GPG prereq, by using output of test cases that were only > run under that prereq. That GPG vs --convert-graft-file thing really does have a bit of a fallout, doesn't it? I'm at five patches and possibly

Re: main url for linking to git source?

Jeff King writes: > The git-scm.com site currently links to https://github.com/git/git for > the (non-tarball) source code. Somebody raised the question[1] of > whether it should point to kernel.org instead. Do people find one > interface more or less pleasing than the other? Do

Re: [PATCH 00/13] object store: alloc

Stefan Beller writes: > This applies on top of sb/oid-object-info and is the logical continuum of > the series that it builds on; this brings the object store into more of > Gits code, removing global state, such that reasoning about the state of > the in-memory

[PATCH] t6050-replace: don't disable stdin for the whole test script

The test script 't6050-replace.sh' starts off with redirecting the whole test script's stdin from /dev/null. This redirection has been there since the test script was introduced in a3e8267225 (replace_object: add a test case, 2009-01-23), but the commit message doesn't explain why it was deemed

Re: [PATCH v4 5/7] builtin/grep.c: add '--column' option to 'git-grep(1)'

Taylor Blau writes: > diff --git a/Documentation/git-grep.txt b/Documentation/git-grep.txt > index 18b494731f..5409a24399 100644 > --- a/Documentation/git-grep.txt > +++ b/Documentation/git-grep.txt > @@ -13,7 +13,7 @@ SYNOPSIS > [-v | --invert-match] [-h|-H]

Re: [PATCH] tests: introduce test_unset_prereq, for debugging

SZEDER Gábor writes: >> For convenience, the following two methods are now supported ways to >> pretend that a prereq is not met: >> >> test_set_prereq !GPG >> >> and >> >> test_unset_prereq GPG > > I'm not sure this is the right way to do this. > > I wanted to

Re: git merge banch w/ different submodule revision

Hi, Am Freitag, den 04.05.2018, 07:43 -0700 schrieb Elijah Newren: > On Fri, May 4, 2018 at 3:18 AM, Heiko Voigt wrote: > > Hi, > > > > On Fri, May 04, 2018 at 08:29:32AM +, Middelschulte, Leif wrote: > > > Am Donnerstag, den 03.05.2018, 18:42 +0200 schrieb Heiko Voigt: >

[PATCH] fixup! merge-recursive: add get_directory_renames()

--- merge-recursive.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/merge-recursive.c b/merge-recursive.c index 5f42c677d5..9b9a4b8213 100644 --- a/merge-recursive.c +++ b/merge-recursive.c @@ -1851,7 +1851,7 @@ static struct hashmap *get_directory_renames(struct

Re: [PATCH v2] completion: reduce overhead of clearing cached --options

I haven't seen any discussion about this recently. What are the chances of getting it merged? I'd like to see this included in 2.18. >> To get the names of all '$__git_builtin_*' variables caching --options >> of builtin commands in order to unset them, 8b0eaa41f2 (completion: >> clear cached

Re: main url for linking to git source?

On 05/07/18 07:38, Johannes Schindelin wrote: >> The git-scm.com site currently links to https://github.com/git/git for >> the (non-tarball) source code. Somebody raised the question[1] of >> whether it should point to kernel.org instead. >> >> Do people find one interface more or less pleasing

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

Jeff King writes: > On Tue, Apr 17, 2018 at 12:12:12AM +, brian m. carlson wrote: > >> > That argues more strongly that we would regret unless we make the >> > end-user configuration to at least the whole string (which later can >> > be promoted to "a pattern that matches the

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

On Mon, May 7, 2018 at 9:50 AM, Jeff King wrote: > On Sat, May 05, 2018 at 11:57:26PM +0200, Johannes Schindelin wrote: > >> > It feels really petty complaining about the name, but I just want to >> > raise the point, since it will never be easier to change than right now. >> >> I

Re: [RFC] Other chunks for commit-graph, part 1 - Bloom filters, topo order, etc.

On 5/4/2018 3:40 PM, Jakub Narebski wrote: Hello, With early parts of commit-graph feature (ds/commit-graph and ds/lazy-load-trees) close to being merged into "master", see https://public-inbox.org/git/xmqq4ljtz87g@gitster-ct.c.googlers.com/ I think it would be good idea to think what other

What's cooking in git.git (May 2018, #01; Mon, 7)

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 v2 02/18] Add a new builtin: branch-diff

Johannes Schindelin writes: > It would be easy to introduce, but I am wary about its usefulness. > Unless you re-generate the branch from patches (which I guess you do a > lot, but I don't), you are likely to compare incomplete patch series: say, > when you call `git

Re: Is support for 10.8 dropped?

Hi guys, I am going to try and build the OpenSSL and Git locally. Search brought me here: https://wiki.openssl.org/index.php/Compilation_and_Installation#OS_X. Which options do I absolutely have to have for configuring OpenSSL? Should I exclude "no--ssl2"? "no-ssl3"? Thank you. On Mon, Apr 23,

Re: What's cooking in git.git (May 2018, #01; Mon, 7)

On 5/7/2018 10:58 AM, Junio C Hamano wrote: * ds/generation-numbers (2018-05-02) 11 commits - commit-graph.txt: update design document - merge: check config before loading commits - commit: use generation number in remove_redundant() - commit: add short-circuit to paint_down_to_common()

Re: [PATCH 4/5] lock_file: make function-local locks non-static

On Sun, May 6, 2018 at 9:32 PM, Martin Ågren wrote: > On 6 May 2018 at 19:42, Duy Nguyen wrote: >> On Sun, May 6, 2018 at 7:26 PM, Duy Nguyen wrote: >>> On Sun, May 6, 2018 at 4:10 PM, Martin Ågren wrote:

Re: [PATCH] mailmap: update brian m. carlson's email address

On Sun, May 6, 2018 at 8:37 PM, Junio C Hamano wrote: > "brian m. carlson" writes: > >> The order of addresses in the mailmap file was reversed, leading to git >> preferring the crustytoothpaste.ath.cx address, which is obsolete, over >> the

Re: [PATCH 06/28] t0000: annotate with SHA1 prerequisite

On Mon, May 07, 2018 at 12:24:13PM +0200, Martin Ågren wrote: > This could be more centralized at the top of the file, more likely to be > noticed during a `make test` and easier to adapt in the future. Maybe > something like this at the top of the file: > > if hash for storage is SHA-1 then >

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

On Mon, May 7, 2018 at 8:28 AM, Duy Nguyen wrote: >>> I do hear you. Especially since I hate `git cherry` every single time that >>> I try to tab-complete `git cherry-pick`. >> >> Me too. :) > > Just so you know I'm also not happy with that "git cherry". Since I'm > updating

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

On Sun, May 06, 2018 at 08:03:01PM +0200, Ævar Arnfjörð Bjarmason wrote: > > On Sun, May 06 2018, Martin Ågren wrote: > > > On 5 May 2018 at 04:43, Taylor Blau wrote: > >> Take advantage of 'git-grep(1)''s new option, '--column' in order to > >> teach Peff's 'git-jump' script

Re: [PATCH v4 5/7] builtin/grep.c: add '--column' option to 'git-grep(1)'

On Sat, May 05, 2018 at 08:15:03AM +0200, Duy Nguyen wrote: > On Sat, May 5, 2018 at 4:43 AM, Taylor Blau wrote: > > Teach 'git-grep(1)' a new option, '--column', to show the column > > number of the first match on a non-context line. > > Why? Or put it another way, what is

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

Hi Dscho, On 07/05/2018 03:34, Johannes Schindelin wrote: > > > > I think Todd's idea to shift it from a full-blown builtin to a cmdmode > > > of `branch` makes tons of sense. > > > > I don`t know, I still find it a bit strange that in order to "diff > > something", you go to "something" and

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

Hi Stefan, On 08/05/2018 00:24, Stefan Beller wrote: > > > List, rename, delete -- all these seem more as basic CRUD operations, > > where comparison is a more complex one. And not to get me wrong - I > > could see "branch diff" being part of "branch", but not really when > > "diff" already

Re: [PATCH v4 5/7] builtin/grep.c: add '--column' option to 'git-grep(1)'

On Sun, May 06, 2018 at 07:56:42PM +0200, Ævar Arnfjörð Bjarmason wrote: > > On Sat, May 05 2018, Taylor Blau wrote: > > > > + test_expect_success "grep -w $L (with --{line,column}-number)" ' > > It's now --column in v4 but this still refers to v3 --column-number. Thanks, I certainly missed

Re: [PATCH 01/28] t/test-lib: add an SHA1 prerequisite

On Mon, May 07, 2018 at 12:10:39PM +0200, Martin Ågren wrote: > On 7 May 2018 at 01:17, brian m. carlson wrote: > > Add an SHA1 prerequisite to annotate both of these types of tests and > > disable them when we're using a different hash. In the future, we can > >

Re: [PATCH 4/5] lock_file: make function-local locks non-static

On 7 May 2018 at 17:24, Duy Nguyen wrote: > On Sun, May 6, 2018 at 9:32 PM, Martin Ågren wrote: >> On 6 May 2018 at 19:42, Duy Nguyen wrote: >> Thank you Duy for your comments. How about I write the commit message >> like so: > >

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

On 07/05/2018 09:48, Jeff King wrote: > > > > Let's, please, not fall into the trap of polluting git-branch with > > > utterly unrelated functionality, as has happened a few times with > > > other Git commands. Let's especially not do so merely for the sake of > > > tab-completion. git-branch is

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

On Mon, May 07, 2018 at 05:45:00AM -0400, Jeff King wrote: > Isn't that basically what this patch is, though? Or at least a step in > that direction? For generic signing support, you need: > > 1. A way to tell Git to recognize that a signature exists, and what > type it is. > > 2. A way

Dearest

Dearest, I am Sister Renee Shine, I contacted you regards to the total sum of(3 million USD) which I signed and donated in your custody as the beneficiary,I was diagnosed with the cancer of the esophagus it has defied all forms of medical treatment and at this point i have few weeks to live

Re: [PATCH 00/13] object store: alloc

Hi Junio, On Mon, May 7, 2018 at 7:05 AM, Junio C Hamano wrote: > Stefan Beller writes: > >> This applies on top of sb/oid-object-info and is the logical continuum of >> the series that it builds on; this brings the object store into more of >> Gits code,

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

On Mon, May 7, 2018 at 3:05 PM, Igor Djordjevic wrote: > List, rename, delete -- all these seem more as basic CRUD operations, > where comparison is a more complex one. And not to get me wrong - I > could see "branch diff" being part of "branch", but not really when

[PATCH v2 01/13] repository: introduce parsed objects field

Convert the existing global cache for parsed objects (obj_hash) into repository-specific parsed object caches. Existing code that uses obj_hash are modified to use the parsed object cache of the_repository; future patches will use the parsed object caches of other repositories. Another future use

[PATCH v2 09/13] alloc: add repository argument to alloc_report

This is a small mechanical change; it doesn't change the implementation to handle repositories other than the_repository yet. Use a macro to catch callers passing a repository other than the_repository at compile time. Signed-off-by: Stefan Beller --- alloc.c | 2 +- cache.h

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

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 other than the_repository yet. Signed-off-by: Jonathan Nieder

[PATCH v2 00/13] object store: alloc

v2: * I decided to stick with alloc.c and not migrate it to the mem-pool for now. The reasoning for that is that mem-pool.h would introduce some alignment waste, which I really did not want to. * renamed to struct parsed_object_pool; * free'd the additional memory of trees and commits. * do

[PATCH v2 11/13] object: allow grow_object_hash to handle arbitrary repositories

Reviewed-by: Jonathan Tan Signed-off-by: Jonathan Nieder Signed-off-by: Stefan Beller --- object.c | 16 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/object.c b/object.c index

[PATCH v2 06/13] alloc: add repository argument to alloc_commit_node

This is a small mechanical change; it doesn't change the implementation to handle repositories other than the_repository yet. Use a macro to catch callers passing a repository other than the_repository at compile time. Signed-off-by: Stefan Beller --- alloc.c | 2

[PATCH v2 05/13] alloc: add repository argument to alloc_tree_node

This is a small mechanical change; it doesn't change the implementation to handle repositories other than the_repository yet. Use a macro to catch callers passing a repository other than the_repository at compile time. Signed-off-by: Stefan Beller --- alloc.c | 2 +- cache.h

[PATCH v2 13/13] alloc: allow arbitrary repositories for alloc functions

We have to convert all of the alloc functions at once, because alloc_report uses a funky macro for reporting. It is better for the sake of mechanical conversion to convert multiple functions at once rather than changing the structure of the reporting function. We record all memory allocation in

[PATCH v2 04/13] alloc: add repository argument to alloc_blob_node

This is a small mechanical change; it doesn't change the implementation to handle repositories other than the_repository yet. Use a macro to catch callers passing a repository other than the_repository at compile time. Signed-off-by: Stefan Beller --- alloc.c | 2 +- blob.c

[PATCH v2 12/13] object: allow create_object to handle arbitrary repositories

Reviewed-by: Jonathan Tan Signed-off-by: Jonathan Nieder Signed-off-by: Stefan Beller --- object.c | 12 ++-- object.h | 3 +-- 2 files changed, 7 insertions(+), 8 deletions(-) diff --git a/object.c b/object.c index

[PATCH v2 03/13] object: add repository argument to grow_object_hash

From: Jonathan Nieder Add a repository argument to allow the caller of grow_object_hash to be more specific about which repository to handle. This is a small mechanical change; it doesn't change the implementation to handle repositories other than the_repository yet.

[PATCH v2 10/13] alloc: add repository argument to alloc_commit_index

This is a small mechanical change; it doesn't change the implementation to handle repositories other than the_repository yet. Use a macro to catch callers passing a repository other than the_repository at compile time. Signed-off-by: Stefan Beller --- alloc.c | 4 ++--

[PATCH v2 08/13] alloc: add repository argument to alloc_object_node

This is a small mechanical change; it doesn't change the implementation to handle repositories other than the_repository yet. Use a macro to catch callers passing a repository other than the_repository at compile time. Signed-off-by: Stefan Beller --- alloc.c | 2 +-

[PATCH v2 07/13] alloc: add repository argument to alloc_tag_node

This is a small mechanical change; it doesn't change the implementation to handle repositories other than the_repository yet. Use a macro to catch callers passing a repository other than the_repository at compile time. Signed-off-by: Stefan Beller --- alloc.c | 2 +- cache.h

Re: [PATCH v4 5/7] builtin/grep.c: add '--column' option to 'git-grep(1)'

On Mon, May 07, 2018 at 11:13:12PM +0900, Junio C Hamano wrote: > Taylor Blau writes: > > > diff --git a/Documentation/git-grep.txt b/Documentation/git-grep.txt > > index 18b494731f..5409a24399 100644 > > --- a/Documentation/git-grep.txt > > +++ b/Documentation/git-grep.txt > >

Re: [PATCH v2 12/18] branch-diff: use color for the commit pairs

Hi Johannes, Johannes Schindelin wrote: > Hi Todd, > > On Sat, 5 May 2018, Todd Zullinger wrote: > >>> @@ -430,6 +451,8 @@ int cmd_branch_diff(int argc, const char **argv, const >>> char *prefix) >>> struct string_list branch1 = STRING_LIST_INIT_DUP; >>> struct string_list branch2 =

Re: main url for linking to git source?

Konstantin Ryabitsev writes: > On Tue, May 08, 2018 at 01:51:30AM +, brian m. carlson wrote: >> >> I think I would also prefer a list of available repositories over a >> hard-coded choice. It may be that some places (say, Australia) have >> better bandwidth

Re: [PATCH v6 02/13] generate-cmds.sh: export all commands to command-list.h

Nguyễn Thái Ngọc Duy writes: > 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 > keep command classification a new

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

On Sat, May 05, 2018 at 03:36:12AM -0400, Eric Sunshine wrote: > 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

Re: [PATCH] alloc.c: replace alloc by mempool

Stefan Beller writes: > The replacement with mem-pool might be easier than making sure > that alloc.c has no globals and handles allocations per repository > correctly. It would make the sb/object-store-alloc series shorter than > it currently is, and maybe easier to review

Re: [PATCH v2] completion: reduce overhead of clearing cached --options

Todd Zullinger writes: > Hi Matthew, > > Matthew Coleman wrote: >> I haven't seen any discussion about this recently. What >> are the chances of getting it merged? I'd like to see this >> included in 2.18. > > Junio's last few "What's cooking" updates have mentioned it: > >> *

Re: [PATCH v2] mailmap: update brian m. carlson's email address

On Tuesday 08 May 2018 07:28 AM, brian m. carlson wrote: > An earlier change, cdb6b5ac (".mailmap: Combine more (name, email) to > individual persons", 2013-08-12), noted that there were two name > spellings and two email addresses and mapped the crustytoothpaste.net > address to the

Re: [PATCH 2/2] Documentation: render revisions correctly under Asciidoctor

On Mon, May 07, 2018 at 06:11:43AM +0200, Martin Ågren wrote: > On 6 May 2018 at 22:42, brian m. carlson wrote: > > When creating a literal block from an indented block without any sort of > > delimiters, Asciidoctor strips off all leading whitespace, resulting in >

[PATCH v2] mailmap: update brian m. carlson's email address

An earlier change, cdb6b5ac (".mailmap: Combine more (name, email) to individual persons", 2013-08-12), noted that there were two name spellings and two email addresses and mapped the crustytoothpaste.net address to the crustytoothpaste.ath.cx address. The latter is an older, obsolete address,

Re: [PATCH v2] mailmap: update brian m. carlson's email address

"brian m. carlson" writes: > An earlier change, cdb6b5ac (".mailmap: Combine more (name, email) to > individual persons", 2013-08-12), noted that there were two name > spellings and two email addresses and mapped the crustytoothpaste.net > address to the

Re: [PATCH 5/8] push doc: correct lies about how push refspecs work

Ævar Arnfjörð Bjarmason writes: > + > The is often the name of the branch you would want to push, but > -it can be any arbitrary "SHA-1 expression", such as `master~4` or > -`HEAD` (see linkgit:gitrevisions[7]). > +it can be any arbitrary "SHA-1 expression" referring to a

Re: [PATCH 8/8] fetch: stop clobbering existing tags without --force

Ævar Arnfjörð Bjarmason writes: > > Tags need not be pointing at commits so there is no way to > > guarantee "fast-forward" anyway. The observation the above statement makes is not incorrect per-se, but it does not justify "anything goes". "nothing is allowed unless

Re: [PATCH] mailmap: update brian m. carlson's email address

On Mon, May 07, 2018 at 12:37:05PM +0900, Junio C Hamano wrote: > I initially reacted to "was reversed" with "yikes, did we break the > mailmap reader and we need to update the file?", but apparently that > is not what this patch is about. I think what is happening here is > that cdb6b5ac

Re: [PATCH] alloc.c: replace alloc by mempool

Duy Nguyen writes: >> So I think we could just replace it for now and optimize again later, if it >> turns out to be a problem. I think the easiest optimisation is to increase >> the allocation size of having a lot more objects per mp_block. > > Yeah. I also tested this from a

Re: main url for linking to git source?

On Tue, May 08, 2018 at 01:51:30AM +, brian m. carlson wrote: > On Mon, May 07, 2018 at 11:15:46AM -0700, Stefan Beller wrote: > > There I would try to mirror Junios list of "public repositories" > > https://git-blame.blogspot.com/p/git-public-repositories.html > > without officially endorsing

Re: [GSoC] A blog about 'git stash' project

On Fri, May 04, 2018 at 12:48:21AM +0300, Paul-Sebastian Ungureanu wrote: > Hello everybody, > > The community bonding period started. It is well known that for a greater > rate of success, it is recommended to send weekly reports regarding project > status. But, what would be a good form for such

Re: [PATCH v6 08/13] git: support --list-cmds=list-

Nguyễn Thái Ngọc Duy writes: > 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 > much. > > This will be used

Re: [PATCH v6 10/13] help: use command-list.txt for the source of guides

Nguyễn Thái Ngọc Duy writes: > 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 lets us list guides in

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

On Sat, May 05, 2018 at 03:30:51AM -0400, Eric Sunshine wrote: > 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'. > > > >

Re: What's cooking in git.git (May 2018, #01; Mon, 7)

Elijah Newren writes: >> Rename detection logic in "diff" family that is used in "merge" has >> learned to guess when all of x/a, x/b and x/c have moved to z/a, >> z/b and z/c, it is likely that x/d added in the meantime would also >> want to move to z/d by taking the hint

Re: main url for linking to git source?

On Mon, May 07, 2018 at 11:15:46AM -0700, Stefan Beller wrote: > There I would try to mirror Junios list of "public repositories" > https://git-blame.blogspot.com/p/git-public-repositories.html > without officially endorsing one over another. I think I would also prefer a list of available

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

On Mon, May 07, 2018 at 11:44:29PM -0400, Jeff King wrote: > On Mon, May 07, 2018 at 03:24:59PM -0700, Stefan Beller wrote: > > > Hence I propose "git range-diff", similar to topic-diff, that > > was proposed earlier. > > > > * it "diffs ranges" of commits. > > * it can also deal with

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

Jeff King writes: > One of the things I don't like about "git branch --diff" is that this > feature is not _just_ about branches at all. I actually wouldn't be that much against the word "branch" in "branch-diff" on the ground that we are typically not feeding branches to the

Re: What's cooking in git.git (May 2018, #01; Mon, 7)

Elijah Newren writes: > I'm actually curious what the "Will merge to 'master'" and "Will merge > to 'next'" are intended to mean in general. I thought it meant that > the topic would be merged the following week barring further > discussion, but that hasn't always been the

Re: [PATCH] alloc.c: replace alloc by mempool

On Mon, May 7, 2018 at 5:37 PM, Junio C Hamano wrote: > Duy Nguyen writes: > >>> So I think we could just replace it for now and optimize again later, if it >>> turns out to be a problem. I think the easiest optimisation is to increase >>> the allocation

Re: [PATCH v6 05/13] git.c: convert --list-* to --list-cmds=*

Nguyễn Thái Ngọc Duy writes: > Even if these are hidden options, let's make them a bit more generic > since we're introducing more listing types shortly. The code is > structured to allow combining multiple listing types together because > we will soon add more types the

Re: [PATCH 4/8] push tests: assert re-pushing annotated tags

Ævar Arnfjörð Bjarmason writes: > Change the test that asserts that lightweight tags can only be > clobbered by a force-push to check do the same tests for annotated > tags. > > There used to be less exhaustive tests for this with the code added in > 40eff17999 ("push: require

Re: cherry-pick --no-commit does not work well with --continue in case of conflicts

Ilya Kantor writes: > P.S. I assume, `cherry-pick -n ` is meant to merge given > commits' changes into the current working directory and the index, > without making new commits, for any given set of commits, hope that's right? Hmph. One step in cherry-pick should refuse to

Re: [PATCH] mailmap: update brian m. carlson's email address

On Mon, May 07, 2018 at 12:25:09PM -0700, Stefan Beller wrote: > brian, > > sorry to break you there. I was the author of the patch Junio found, > organizing > the .mailmap file was one of my starter contributions. I recall asking all the > people if they were ok with it their names combined in

Re: [PATCH v2] completion: reduce overhead of clearing cached --options

Hi Matthew, Matthew Coleman wrote: > I haven't seen any discussion about this recently. What > are the chances of getting it merged? I'd like to see this > included in 2.18. Junio's last few "What's cooking" updates have mentioned it: > * sg/completion-clear-cached (2018-04-18) 1 commit >

Re: [GSoC] Yet another blog series about the GSoC

On Tue, May 8, 2018 at 12:20 AM, Stefan Beller wrote: > Hi Pratik, Hi Stefan, > On Sat, May 5, 2018 at 5:24 AM, Pratik Karki wrote: >> On Sat, May 5, 2018 at 5:11 PM, Alban Gruin wrote: >>> Hi everybody, >>> >>> as my fellow

Re: [PATCH 3/8] push tests: add more testing for forced tag pushing

Ævar Arnfjörð Bjarmason writes: > Improve the tests added in dbfeddb12e ("push: require force for refs > under refs/tags/", 2012-11-29) to assert that the same behavior > applies various forms other refspecs, and that "+" in a refspec will > override the "--no-force" option

Re: [PATCH 3/8] push tests: add more testing for forced tag pushing

Junio C Hamano writes: > I couldn't quite get what you meant by "(but not the other way > around)". Did you mean > > $ git push --force ../child2 refs/tags/*:refs/tags/* > > should not become non-forcing version because of the (lack of) > prefix on the refspec does not

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

On Mon, May 07, 2018 at 03:24:59PM -0700, Stefan Beller wrote: > Hence I propose "git range-diff", similar to topic-diff, that > was proposed earlier. > > * it "diffs ranges" of commits. > * it can also deal with out-of-git things like patch series, > but that is a mere by product and may not

Re: [PATCH 2/5] refs.c: do not die if locking fails in `write_pseudoref()`

On May 6, 2018 9:56:31 AM MDT, "Martin Ågren" wrote: >On 6 May 2018 at 17:48, David Turner wrote: >> On Sun, 2018-05-06 at 16:10 +0200, Martin Ågren wrote: >>> While at it, make the lock non-static. > >> Re making the lock static, I wonder about the

  1   2   >