Re: [PATCH v2 11/20] refs: record the ref_store in ref_cache, not ref_dir

On 04/07/2017 01:38 PM, Duy Nguyen wrote: > On Fri, Mar 31, 2017 at 9:11 PM, Michael Haggerty > wrote: >> Instead of keeping a pointer to the ref_store in every ref_dir entry, >> store it once in `struct ref_cache`, and change `struct ref_dir` to >> include a pointer to its

Re: [PATCH v2 10/20] ref-cache: introduce a new type, ref_cache

On 04/07/2017 01:32 PM, Duy Nguyen wrote: > On Fri, Mar 31, 2017 at 9:11 PM, Michael Haggerty > wrote: >> +void free_ref_cache(struct ref_cache *cache) >> +{ >> + free_ref_entry(cache->root); >> + free(cache); >> +} > > free(NULL) is no-op (and safe). Maybe we

Re: includeIf breaks calling dashed externals

On Sat, Apr 15, 2017 at 06:49:01PM +0700, Duy Nguyen wrote: > > Probably this fixes it: > > > > diff --git a/config.c b/config.c > > index b6e4a57b9..8d66bdf56 100644 > > --- a/config.c > > +++ b/config.c > > @@ -213,6 +213,9 @@ static int include_by_gitdir(const char *cond, size_t > >

Re: [PATCH v2 04/20] refs_verify_refname_available(): implement once for all backends

On 04/07/2017 01:20 PM, Duy Nguyen wrote: > On Fri, Mar 31, 2017 at 9:11 PM, Michael Haggerty > wrote: >> It turns out that we can now implement >> `refs_verify_refname_available()` based on the other virtual >> functions, so there is no need for it to be defined at the

Re: [REQ] Allow alternatives to gpg

On Sat, Apr 15, 2017 at 08:10:41PM -0700, Nathan McSween wrote: > I would like to try to make git signing pluggable, this would allow for > using tools such as signify[1]. > Now I'm wondering if this endeavor is worth taking and what would need to be > changed besides > gpg-interface? > > [1]

Re: [PATCH v2 03/20] refs_ref_iterator_begin(): new function

On 04/07/2017 12:57 PM, Duy Nguyen wrote: > On Fri, Mar 31, 2017 at 9:11 PM, Michael Haggerty > wrote: >> Extract a new function from `do_for_each_ref()`. It will be useful >> elsewhere. >> >> Signed-off-by: Michael Haggerty >> --- >> refs.c

Re: [PATCH] doc/revisions: remove brackets from rev^-n shorthand

On Sun, Apr 16, 2017 at 12:07:57AM -0400, Kyle Meyer wrote: > Given that other instances of "{...}" in the revision documentation > represent literal characters of revision specifications, describing > the rev^-n shorthand as "^-{}" incorrectly suggests that > something like "master^-{1}" is an

Re: [PATCH] t1400: use consistent style for test_expect_success calls

On Sat, Apr 15, 2017 at 10:31:02PM -0400, Kyle Meyer wrote: > Structure calls as > > test_expect_success 'description' ' > body > ' > > Use double quotes for the description if it requires parameter > expansion or contains a single quote. > > Signed-off-by: Kyle Meyer

Re: [PATCH 3/3] reset.c: update files when using sparse to avoid data loss.

On Wed, Apr 12, 2017 at 10:37 PM, Kevin Willford wrote: > >> -Original Message- >> From: git-ow...@vger.kernel.org [mailto:git-ow...@vger.kernel.org] On >> Behalf Of Duy Nguyen >> Sent: Wednesday, April 12, 2017 7:21 AM >> To: Kevin Willford

[PATCH] doc/revisions: remove brackets from rev^-n shorthand

Given that other instances of "{...}" in the revision documentation represent literal characters of revision specifications, describing the rev^-n shorthand as "^-{}" incorrectly suggests that something like "master^-{1}" is an acceptable form. Signed-off-by: Kyle Meyer ---

[REQ] Allow alternatives to gpg

I would like to try to make git signing pluggable, this would allow for using tools such as signify[1]. Now I'm wondering if this endeavor is worth taking and what would need to be changed besides gpg-interface? [1] http://man.openbsd.org/signify

[PATCH] t1400: use consistent style for test_expect_success calls

Structure calls as test_expect_success 'description' ' body ' Use double quotes for the description if it requires parameter expansion or contains a single quote. Signed-off-by: Kyle Meyer --- This patch follows up on a recent t1400 series:

Re: Index files autocompletion too slow in big repositories (w / suggestion for improvement)

On Sat, Apr 15, 2017 at 4:59 AM, Johannes Sixt wrote: > Cc Gábor. > > Am 15.04.2017 um 00:33 schrieb Ævar Arnfjörð Bjarmason: >> >> On Sat, Apr 15, 2017 at 12:08 AM, Carlos Pita >> wrote: >>> >>> This is much faster (below 0.1s): >>> >>> __git_index_files

Re: [PATCH] Documentation/git-checkout: make doc. of checkout clearer

From: "Christoph Michelbach" While technically in the documentation, the fact that changes introduced by a checkout are staged automatically, was not obvious when reading its documentation. It is now specifically pointed out. Signed-off-by: Christoph Michelbach

[PATCH] Documentation/git-checkout: make doc. of checkout clearer

While technically in the documentation, the fact that changes introduced by a checkout are staged automatically, was not obvious when reading its documentation. It is now specifically pointed out. Signed-off-by: Christoph Michelbach ---  Documentation/git-checkout.txt |

Feature request: Configurable branch colors in git status --short --branch

It would be nice if the branch, remote tracking branch, and branch commit comparison count colors in git status --short --branch were configurable like the other git status colors. Example command output: $ git status --short --branch ## master...origin/master [ahead 1] M README.md M

Re: [PATCH v10 3/3] read-cache: speed up add_index_entry during checkout

Am 14.04.2017 um 21:12 schrieb g...@jeffhostetler.com: From: Jeff Hostetler Teach add_index_entry_with_check() and has_dir_name() to see if the path of the new item is greater than the last path in the index array before attempting to search for it. During checkout,

Re: [PATCH 3/3] rebase: pass --[no-]signoff option to git am

Damnit! I just realized that I forgot to amend before the format-patch: On Sat, Apr 15, 2017 at 4:41 PM, Giuseppe Bilotta wrote: > +signoff! passed to 'git am' This should be without the ! or --no-signoff is not accepted. Do I need to resend or ... ?

[PATCH 3/3] rebase: pass --[no-]signoff option to git am

This makes it easy to sign off a whole patchset before submission. Signed-off-by: Giuseppe Bilotta --- Documentation/git-rebase.txt | 5 + git-rebase.sh| 3 ++- t/t3428-rebase-signoff.sh| 46 3

[PATCH 1/3] builtin/am: obey --signoff also when --rebasing

Signoff is handled in parse_mail(), but not in parse_mail_rebasing(), since the latter is only used when git-rebase calls git-am with the --rebasing option, and --signoff is never passed in this case. In order to introduce (in the upcoming commits) support for `git-rebase --signoff`, we must make

[PATCH 2/3] builtin/am: fold am_signoff() into am_append_signoff()

There are no more direct calls to am_signoff(), so we can fold its logic in am_append_signoff(). (This is done in a separate commit rather than in the previous one, to make it easier to revert this specific change if additional calls are ever introduced.) Signed-off-by: Giuseppe Bilotta

[PATCH 0/3] rebase --signoff

Allow signing off a whole patchset by rebasing it with the --signoff option, which is simply passed through to git am. Compared to previous incarnations, I've split the am massaging to separate commits (for cleanliness and easier reverts if needed), and introduced a test case for both --signoff

Re: Git allow to unconditionaly remove files on other developer host

On Sat, 15 Apr 2017 14:27:00 +0200 Johannes Sixt wrote: > > That curious, but git allow to unconditionally delete files on > > other developer host when he do `git pull` [...] > Know that Git regards everything mentioned in .gitignore as > dispensible; IOW, by mentioning a file in

Re: Index files autocompletion too slow in big repositories (w / suggestion for improvement)

Cc Gábor, resent with working email (hopefully); please follow-up on this mail. Am 15.04.2017 um 00:33 schrieb Ævar Arnfjörð Bjarmason: On Sat, Apr 15, 2017 at 12:08 AM, Carlos Pita wrote: This is much faster (below 0.1s): __git_index_files () { local

Re: Git allow to unconditionaly remove files on other developer host

Am 15.04.2017 um 13:36 schrieb KES: That curious, but git allow to unconditionally delete files on other developer host when he do `git pull` How to reproduce: 1. File should be ignored: echo "somefile" >> .gitignore 2. Add this ignored file into repository git add -f somefile 3. Push

Re: [PATCH 03/12] Makefile & configure: reword outdated comment about PCRE

On Tue, Apr 11, 2017 at 12:14 PM, Jeff King wrote: > On Sat, Apr 08, 2017 at 01:24:57PM +, Ævar Arnfjörð Bjarmason wrote: > >> Reword an outdated comment which suggests that only git-grep can use >> PCRE. > > Makes sense. > >> -# Define USE_LIBPCRE if you have and want to use

Re: Index files autocompletion too slow in big repositories (w / suggestion for improvement)

Cc Gábor. Am 15.04.2017 um 00:33 schrieb Ævar Arnfjörð Bjarmason: On Sat, Apr 15, 2017 at 12:08 AM, Carlos Pita wrote: This is much faster (below 0.1s): __git_index_files () { local dir="$(__gitdir)" root="${2-.}" file; if [ -d "$dir" ]; then

Re: includeIf breaks calling dashed externals

On Fri, Apr 14, 2017 at 01:43:37PM -0400, Jeff King wrote: > On Fri, Apr 14, 2017 at 07:04:23PM +0200, Bert Wesarg wrote: > > > Dear Duy, > > > > heaving an includeIf in a git config file breaks calling external git > > commands, most prominently git-gui. > > > > $ git --version > > git version

Git allow to unconditionaly remove files on other developer host

Hi. That curious, but git allow to unconditionally delete files on other developer host when he do `git pull` How to reproduce: 1. File should be ignored: echo "somefile" >> .gitignore 2. Add this ignored file into repository git add -f somefile 3. Push changes to origin git push 4. When

Re: [PATCH] worktree add: add --lock option

On Sat, Apr 15, 2017 at 3:07 PM, Junio C Hamano wrote: > Junio C Hamano writes: > >> Nguyễn Thái Ngọc Duy writes: >> >>> -unlink_or_warn(sb.buf); >>> +if (!ret && opts->keep_locked) { >>> +/* >>> + * Don't

Fwd: Errors running gitk on OS X

I have a similar one bash-4.4$ gitk 2017-04-15 13:09:52.514 Wish[3344:197352] *** Terminating app due to uncaught exception 'CALayerInvalidGeometry', reason: 'CALayer position contains NaN: [nan 0]' *** First throw call stack: ( 0 CoreFoundation 0x7fffd119048b

[PATCH 2/3] git-p4: add read_pipe_text() internal function

The existing read_pipe() function returns an empty string on error, but also returns an empty string if the command returns an empty string. This leads to ugly constructions trying to detect error cases. Add read_pipe_text() which just returns None on error. Signed-off-by: Luke Diamand

[PATCH 0/3] git-p4: use symbolic-ref instead of name-rev

Followup to earlier discussion about use of name-rev in git-p4. http://marc.info/?l=git=148979063421355 Luke Diamand (3): git-p4: add failing test for name-rev rather than symbolic-ref git-p4: add read_pipe_text() internal function git-p4: don't use name-rev to get current branch

[PATCH 3/3] git-p4: don't use name-rev to get current branch

git-p4 was using "git name-rev" to find out the current branch. That is not safe, since if multiple branches or tags point at the same revision, the result obtained might not be what is expected. Instead use "git symbolic-ref". Signed-off-by: Luke Diamand --- git-p4.py

[PATCH 1/3] git-p4: add failing test for name-rev rather than symbolic-ref

Using name-rev to find the current git branch means that git-p4 does not correctly get the current branch name if there are multiple branches pointing at HEAD, or a tag. This change adds a test case which demonstrates the problem. Configuring which branches are allowed to be submitted from goes

What's cooking in git.git (Apr 2017, #02; draft as of Sat, 15)

This is not yet the second issue of this month, but is a draft. I haven't caught up with the list traffic yet, but have skimmed most of the discussion and even managed to pick up some new topics. Two requests to topic owners: - You'd notice that the topics in the New Topics section below do

Re: [PATCHv3] rebase: pass --[no-]signoff option to git am

Giuseppe Bilotta writes: >> We need new tests for "git rebase --signoff" that makes sure this >> works as expected and only when it should. > > Would the norm in this case be to introduce the test in the same > commit, or in a previous commit (as in: this is the

Re: [PATCH 00/12] PCREv2 & more

On Sat, Apr 15, 2017 at 10:11 AM, Junio C Hamano wrote: > Jeff King writes: > >> On Sat, Apr 08, 2017 at 01:24:54PM +, Ævar Arnfjörð Bjarmason wrote: >> >>> This adds PCRE v2 support, but as I was adding that I kept noticing >>> other related problems to

Re: [PATCHv3] rebase: pass --[no-]signoff option to git am

On Sat, Apr 15, 2017 at 11:17 AM, Junio C Hamano wrote: > Giuseppe Bilotta writes: > >> This makes it easy to sign off a whole patchset before submission. >> >> To make things work, we also fix a design issue in git-am that made it >> ignore the

Re: [PATCHv3] rebase: pass --[no-]signoff option to git am

Giuseppe Bilotta writes: > This makes it easy to sign off a whole patchset before submission. > > To make things work, we also fix a design issue in git-am that made it > ignore the signoff option during rebase (specifically, signoff was > handled in parse_mail(), but

Re: [PATCH 00/12] PCREv2 & more

Jeff King writes: > On Sat, Apr 08, 2017 at 01:24:54PM +, Ævar Arnfjörð Bjarmason wrote: > >> This adds PCRE v2 support, but as I was adding that I kept noticing >> other related problems to fix. It's all bundled up into the same >> series because much of it conflicts because

Re: [PATCH] worktree add: add --lock option

Junio C Hamano writes: > Nguyễn Thái Ngọc Duy writes: > >> -unlink_or_warn(sb.buf); >> +if (!ret && opts->keep_locked) { >> +/* >> + * Don't keep the confusing "initializing" message >> + * after it's already

Re: Index files autocompletion too slow in big repositories (w / suggestion for improvement)

Jacob Keller writes: > On Fri, Apr 14, 2017 at 3:33 PM, Ævar Arnfjörð Bjarmason > wrote: >> On Sat, Apr 15, 2017 at 12:08 AM, Carlos Pita >> wrote: >>> This is much faster (below 0.1s): >>> >>> __git_index_files () >>> { >>>

Re: [PATCH] worktree add: add --lock option

Nguyễn Thái Ngọc Duy writes: > - unlink_or_warn(sb.buf); > + if (!ret && opts->keep_locked) { > + /* > + * Don't keep the confusing "initializing" message > + * after it's already over. > + */ > +