Re: [PATCH 03/15] handle_revision_arg: stop using "dotdot" as a generic pointer

On Wed, May 24, 2017 at 11:45:39AM +0900, Junio C Hamano wrote: > > It may make sense to pull each of these into its own helper. I didn't > > really look because they're so small, and because the return semantics > > seemed confusing to me. Some of them return, and some of them keep > > parsing.

Re: [PATCH v2 0/6] Fast git status via a file system watcher

> Design > ~~ > > A new git hook (query-fsmonitor) must exist and be enabled > (core.fsmonitor=true) that takes a time_t formatted as a string and > outputs to stdout all files that have been modified since the requested > time. Is there a reason why there is a new hook, instead of a

Re: [PATCH 0/15] retain blob info for git diff HEAD:foo HEAD:bar

On Wed, May 24, 2017 at 11:44:46AM +0900, Junio C Hamano wrote: > Patches around [PATCH 06-08/15] made some unexpected (at least to > me) turns but the series told a coherent story, building on top of > what has been achieved in the previous steps. Yeah, those patches are not technically

Re: [PATCH v2 3/6] fsmonitor: teach git to optionally utilize a file system monitor to speed up detecting new or changed files.

On Thu, May 18, 2017 at 10:13 PM, Ben Peart wrote: > When the index is read from disk, the query-fsmonitor index extension is > used to flag the last known potentially dirty index and untracked cach s/cach/cache/ > entries. [...] > diff --git a/cache.h b/cache.h > index

Re: [PATCH v2 6/6] fsmonitor: add a sample query-fsmonitor hook script for Watchman

On Thu, May 18, 2017 at 10:13 PM, Ben Peart wrote: > This hook script integrates the new fsmonitor capabilities of git with > the cross platform Watchman file watching service. To use the script: > > Download and install Watchman from https://facebook.github.io/watchman/ > and

Re: [Non-Bug] cloning a repository with a default MASTER branch tries to check out the master branch

On Wed, May 24, 2017 at 12:24:52AM +0100, Philip Oakley wrote: > > > $ git clone g...@github.com:passcod/UPPERCASE-NPM.git > > > Cloning into 'UPPERCASE-NPM'... > > > remote: Counting objects: 14, done. > > > remote: Compressing objects: 100% (11/11), done. > > > remote: Total 14 (delta 3),

Re: Hide decorations in git log

On Wed, May 24, 2017 at 9:22 AM, Robert Dailey wrote: > Hello, > > Is it possible to hide decorated refs in `git log` even if they are > reachable from the refs I'm actually interested in seeing the logs of? > > For example, if I do `git log --graph --decorate --oneline

Re: Hide decorations in git log

On Wed, May 24, 2017 at 09:22:32AM -0500, Robert Dailey wrote: > Is it possible to hide decorated refs in `git log` even if they are > reachable from the refs I'm actually interested in seeing the logs of? Sadly, no, there's no way to do this right now. There was some discussion in this thread:

Hide decorations in git log

Hello, Is it possible to hide decorated refs in `git log` even if they are reachable from the refs I'm actually interested in seeing the logs of? For example, if I do `git log --graph --decorate --oneline --branches 'feature/*'`, I'd like to *only* see refnames that match the glob pattern.

Re: What's cooking in git.git (May 2017, #07; Tue, 23)

Ævar Arnfjörð Bjarmason writes: >> The tests added by grep rely on the old content of >> test 2 'grep correctly finds patterns in a submodule'. > > Sorry about the fallout. > >> The (whitespace broken) diff below fixes it. Ah, then, this was an example of maintainer not doing

Re: Passing revs to git-bundle-create via stdin

Junio C Hamano writes: > Jeff King writes: > >> I think what's happening is that git-bundle actually runs _two_ >> traversals using the command-line arguments. ... >> ... It was just a way of confirming my >> guess about the double-read. >> >> The real

Re: [PATCH 18/29] blame: move progess updates to a scoreboard callback

Jeff Smith writes: > Subject: Re: [PATCH 18/29] blame: move progess updates to a scoreboard > callback s/progess/progress/ (I can do this on my end). > Allow the interface user to decide how to handle a progress update. > > Signed-off-by: Jeff Smith >

Re: [Non-Bug] cloning a repository with a default MASTER branch tries to check out the master branch

Junio C Hamano writes: > Jeff King writes: > >> Unfortunately, it can't, because the ref doesn't exist: >> >> $ git ls-remote git://github.com/passcod/UPPERCASE-NPM.git >> efc7dbfd6ca155d5d19ce67eb98603896062f35a refs/heads/MASTER >>

Re: [Non-Bug] cloning a repository with a default MASTER branch tries to check out the master branch

Jeff King writes: > Unfortunately, it can't, because the ref doesn't exist: > > $ git ls-remote git://github.com/passcod/UPPERCASE-NPM.git > efc7dbfd6ca155d5d19ce67eb98603896062f35arefs/heads/MASTER > e60ea8e6ec45ec45ff44ac8939cb4105b16477darefs/pull/1/head >

Re: [PATCHv5 17/17] diff.c: color moved lines differently

Stefan Beller writes: > When a patch consists mostly of moving blocks of code around, it can > be quite tedious to ensure that the blocks are moved verbatim, and not > ... > cases. This leads to another thought: We could pass on '--color-moved' to > submodules such that they

Re: [PATCHv5 16/17] diff: buffer all output if asked to

Stefan Beller writes: > Introduce a new option 'use_buffer' in the struct diff_options which > controls whether all output is buffered up until all output is available. > ... > Unconditionally enable output via buffer in this patch as it yields > a great opportunity for

Re: [PATCH 00/29] Add blame to libgit

Jeff Smith writes: > Rather than duplicate large portions of builtin/blame.c in cgit, it > would be better to shift its core functionality into libgit.a. The > functionality left in builtin/blame.c mostly relates to terminal > presentation. This was a lot more pleasant to

Re: [PATCH 24/29] blame: move core structures to header

Jeff Smith writes: > The origin, entry, and scoreboard structures are core to the blame > interface and need to be exposed for blame functionality. > > Signed-off-by: Jeff Smith > --- Looks good. Thanks to "prepare everything in place before bulk

Re: [PATCH 28/29] blame: move scoreboard setup to libgit

Jeff Smith writes: > Signed-off-by: Jeff Smith > --- > blame.c | 279 > +++- > blame.h | 10 +- > builtin/blame.c | 276 --- > 3

Re: [PATCH 22/29] blame: create scoreboard setup function

Jeff Smith writes: > Create function that completes setting up blame_scoreboard structure. > > Signed-off-by: Jeff Smith > --- > builtin/blame.c | 190 > ++-- > 1 file changed, 101 insertions(+), 89

Re: What's cooking in git.git (May 2017, #07; Tue, 23)

On Wed, May 24, 2017 at 8:42 PM, Junio C Hamano wrote: > Ævar Arnfjörð Bjarmason writes: > >>> The tests added by grep rely on the old content of >>> test 2 'grep correctly finds patterns in a submodule'. >> >> Sorry about the fallout. >> >>> The (whitespace

Re: [PATCHv5 16/17] diff: buffer all output if asked to

On Wed, May 24, 2017 at 7:26 PM, Junio C Hamano wrote: > Stefan Beller writes: > >> Introduce a new option 'use_buffer' in the struct diff_options which >> controls whether all output is buffered up until all output is available. >> ... >> Unconditionally

Re: [PATCH 20/29] blame: rework methods that determine 'final' commit

Jeff Smith writes: > Either prepare_initial or prepare_final is used to determine which > commit is marked as 'final'. Call the underlying methods directly to > make this more clear. > > Signed-off-by: Jeff Smith > --- > builtin/blame.c | 49

Re: [PATCHv5 17/17] diff.c: color moved lines differently

On Wed, May 24, 2017 at 7:27 PM, Junio C Hamano wrote: > Stefan Beller writes: > >> When a patch consists mostly of moving blocks of code around, it can >> be quite tedious to ensure that the blocks are moved verbatim, and not >> ... >> cases. This leads to

Re: [PATCH 23/29] blame: create entry prepend function

Jeff Smith writes: > Create function that populates a blame_entry and prepends it to a list. > > Signed-off-by: Jeff Smith > --- > builtin/blame.c | 25 +++-- > 1 file changed, 15 insertions(+), 10 deletions(-) > > diff --git

Re: [PATCH v2 5/7] grep: un-break building with PCRE < 8.32

Ævar Arnfjörð Bjarmason writes: > Amend my change earlier in this series ("grep: add support for the > PCRE v1 JIT API", 2017-04-11) to un-break the build on PCRE v1 > versions earlier than 8.32. > ... > So just take the easy way out and disable the JIT on any version older >

Re: [PATCH v2 7/7] grep: add support for PCRE v2

Ævar Arnfjörð Bjarmason writes: > Add support for v2 of the PCRE API. This is a new major version of > PCRE that came out in early 2015[1]. > > The regular expression syntax is the same, but while the API is > similar, pretty much every function is either renamed or takes >

Re: [PATCH v2 5/7] grep: un-break building with PCRE < 8.32

Junio C Hamano writes: > So in that sense, I do not think keeping them separate in practice > has the "makes it easier to revert this change" benefit. > > If I were doing these two patches, I'd squash them together into > one, rename GIT_PCRE1_CAN_DO_MODERN_JIT to

Re: [PATCH 00/29] Add blame to libgit

I haven't had a chance to take a deeper look, but what I saw in merge conflicts with the rest of the system made all sense to me ;-) Will take a deeper look tomorrow. Thanks.

Re: [PATCH v2 25/25] cache_ref_iterator_begin(): avoid priming unneeded directories

Michael Haggerty writes: > Junio, if a reroll is not needed for other reasons, would you mind > squashing this into the last patch of my series? Will do, but won't happen until morning in Tokyo. I've just finished today's integration cycle. Thanks.

Re: [PATCH v2 25/25] cache_ref_iterator_begin(): avoid priming unneeded directories

On 05/23/2017 09:45 PM, Jeff King wrote: > On Mon, May 22, 2017 at 04:17:55PM +0200, Michael Haggerty wrote: > >> So: >> >> * Move the responsibility for doing the prefix check directly to >> `cache_ref_iterator`. This means that `cache_ref_iterator_begin()` >> never has to wrap its return

Re: [PATCH v2 4/7] grep: add support for the PCRE v1 JIT API

On Wed, May 24, 2017 at 7:17 AM, Junio C Hamano wrote: > Ævar Arnfjörð Bjarmason writes: > >> diff --git a/grep.c b/grep.c >> index 1157529115..49e9aed457 100644 >> --- a/grep.c >> +++ b/grep.c >> @@ -351,6 +351,9 @@ static void compile_pcre1_regexp(struct

[PATCHv5 07/17] diff.c: convert emit_rewrite_diff to use emit_line_*

In a later patch, I want to propose an option to detect moved lines in a diff, which cannot be done in a one-pass over the diff. Instead we need to go over the whole diff twice, because we cannot detect the first line of the two corresponding lines (+ and -) that got moved. So to prepare the diff

[PATCHv5 10/17] diff.c: convert emit_binary_diff_body to use emit_line_*

In a later patch, I want to propose an option to detect moved lines in a diff, which cannot be done in a one-pass over the diff. Instead we need to go over the whole diff twice, because we cannot detect the first line of the two corresponding lines (+ and -) that got moved. So to prepare the diff

[PATCHv5 17/17] diff.c: color moved lines differently

When a patch consists mostly of moving blocks of code around, it can be quite tedious to ensure that the blocks are moved verbatim, and not undesirably modified in the move. To that end, color blocks that are moved within the same patch differently. For example (OM, del, add, and NM are different

[PATCHv5 04/17] diff: introduce more flexible emit function

Currently, diff output is written either through the emit_line_0 function or through the FILE * in struct diff_options directly. To make it easier to teach diff to buffer its output (which will be done in a subsequent commit), introduce a more flexible emit_line() function. In this commit, direct

[PATCHv5 09/17] submodule.c: convert show_submodule_summary to use emit_line_fmt

In a later patch, I want to propose an option to detect moved lines in a diff, which cannot be done in a one-pass over the diff. Instead we need to go over the whole diff twice, because we cannot detect the first line of the two corresponding lines (+ and -) that got moved. So to prepare the diff

[PATCHv5 11/17] diff.c: convert show_stats to use emit_line_*

In a later patch, I want to propose an option to detect moved lines in a diff, which cannot be done in a one-pass over the diff. Instead we need to go over the whole diff twice, because we cannot detect the first line of the two corresponding lines (+ and -) that got moved. So to prepare the diff

[PATCHv5 15/17] diff.c: emit_line includes whitespace highlighting

Currently any whitespace highlighting happens outside the emit_line function. Teach the highlighting to emit_line, triggered by a new parameter. Signed-off-by: Stefan Beller Signed-off-by: Junio C Hamano --- diff.c | 107

[PATCHv5 01/17] diff: readability fix

We already have dereferenced 'p->two' into a local variable 'two'. Use that. Signed-off-by: Stefan Beller Signed-off-by: Junio C Hamano --- diff.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/diff.c b/diff.c index

[PATCHv5 00/17] Diff machine: highlight moved lines.

v5: * removed the color passing to the submodule to make the tests pass again. * fixed an indentation issue that was introduced from v3 -> v4. * I merged it with origin/next and tests pass here. Thanks, Stefan diff to v4: diff --git a/diff.c b/diff.c index 23e70d348e..1292d3c4ad 100644 ---

[PATCHv5 03/17] diff.c: factor out diff_flush_patch_all_file_pairs

In a later patch we want to do more things before and after all filepairs are flushed. So factor flushing out all file pairs into its own function that the new code can be plugged in easily. Signed-off-by: Stefan Beller Signed-off-by: Junio C Hamano ---

[PATCHv5 05/17] diff.c: convert fn_out_consume to use emit_line

In a later patch, I want to propose an option to detect moved lines in a diff, which cannot be done in a one-pass over the diff. Instead we need to go over the whole diff twice, because we cannot detect the first line of the two corresponding lines (+ and -) that got moved. So to prepare the diff

[PATCHv5 02/17] diff: move line ending check into emit_hunk_header

The emit_hunk_header() function is responsible for assembling a hunk header and calling emit_line() to send the hunk header to the output file. Its only caller fn_out_consume() needs to prepare for a case where the function emits an incomplete line and add the terminating LF. Instead make sure

[PATCHv5 12/17] diff.c: convert word diffing to use emit_line_*

In a later patch, I want to propose an option to detect moved lines in a diff, which cannot be done in a one-pass over the diff. Instead we need to go over the whole diff twice, because we cannot detect the first line of the two corresponding lines (+ and -) that got moved. So to prepare the diff

[PATCHv5 16/17] diff: buffer all output if asked to

Introduce a new option 'use_buffer' in the struct diff_options which controls whether all output is buffered up until all output is available. We'll have a new struct 'diff_line' in diff.h which will be used to buffer each line. The diff_line will duplicate the memory of the line to buffer as

[PATCHv5 13/17] diff.c: convert diff_flush to use emit_line_*

In a later patch, I want to propose an option to detect moved lines in a diff, which cannot be done in a one-pass over the diff. Instead we need to go over the whole diff twice, because we cannot detect the first line of the two corresponding lines (+ and -) that got moved. So to prepare the diff

[PATCHv5 06/17] diff.c: convert builtin_diff to use emit_line_*

In a later patch, I want to propose an option to detect moved lines in a diff, which cannot be done in a one-pass over the diff. Instead we need to go over the whole diff twice, because we cannot detect the first line of the two corresponding lines (+ and -) that got moved. So to prepare the diff

[PATCHv5 08/17] diff.c: convert emit_rewrite_lines to use emit_line_*

In a later patch, I want to propose an option to detect moved lines in a diff, which cannot be done in a one-pass over the diff. Instead we need to go over the whole diff twice, because we cannot detect the first line of the two corresponding lines (+ and -) that got moved. So to prepare the diff

[PATCHv5 14/17] diff.c: convert diff_summary to use emit_line_*

In a later patch, I want to propose an option to detect moved lines in a diff, which cannot be done in a one-pass over the diff. Instead we need to go over the whole diff twice, because we cannot detect the first line of the two corresponding lines (+ and -) that got moved. So to prepare the diff

Sama/Winbind AD Computer Accounts Moved

Hello, We've encountered an issue not previously seen in our environment.  We join our Linux machines (most are Oracle Enterprise Linux 6.x or 7.x) to an Active Directory domain.  We do this by using Samba/Winbind.  When joining a Linux host, we create the computer account in AD ahead of

Re: Sama/Winbind AD Computer Accounts Moved

On Wed, May 24, 2017 at 2:46 PM, Thompson, Matt wrote: > I realize this is a Samba support list but I'm curious to know if someone > may be familiar enough to render a guess. I think the primary purpose of git@ is different than samba support. ;) Wrong mailing list?