I was trying to see how this is useful in code moving change, with
this command line:
$ git -c color.moved diff js/blame-lib~6 js/blame-lib blame.c blame.h
builtin/blame.c
Some random observations:
* You do not seem to have any command line option yet. I guess
that is OK while the series i
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 review compared to the
Jeff Smith writes:
> Signed-off-by: Jeff Smith
> ---
> blame.c | 279
> +++-
> blame.h | 10 +-
> builtin/blame.c | 276 ---
> 3 files changed, 281 insertions(+), 284 deleti
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 broken) diff below fixes it.
>
> Ah, t
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 another thought: We could pass on '--co
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 enable output via buffer in this patch as
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 movement"
approach this round takes, unlike t
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 a/builtin/blame.c b/builtin/blame.c
> index fd415
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 deletions(-)
>
> diff --git a/builtin/blame
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 +++--
>
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
> ---
> builtin/blame.c | 27 +
Æ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 a good job.
When I
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
>> e60ea8e6ec45ec45ff44ac8939cb4105b16477da refs/pull/1
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 solutions I can think of are:
>>
>> 1. Te
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 color up moved lines
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 testing, i.e. all the diff
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
> f35a73dcb151d336dc3d3
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?
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 joini
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 tha
In a later patch, I want to propose an option to detect&color
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
In a later patch, I want to propose an option to detect&color
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
In a later patch, I want to propose an option to detect&color
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
In a later patch, I want to propose an option to detect&color
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
In a later patch, I want to propose an option to detect&color
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
In a later patch, I want to propose an option to detect&color
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
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 c
In a later patch, I want to propose an option to detect&color
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
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 ++---
diff.h
In a later patch, I want to propose an option to detect&color
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
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 em
In a later patch, I want to propose an option to detect&color
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
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
---
diff.c | 17 -
1 file cha
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 u
In a later patch, I want to propose an option to detect&color
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
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 74283d9001..3f5bf8b5a4 100644
--- a/diff.c
+++ b/diff.
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
--- a/diff
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:
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 --branches
> 'feature/*'`,
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. Howeve
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), reused
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 instruct Watchman to
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 188811920c..36423c77cc
> 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
"core.fsm
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 required
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. S
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 grep_pat *p,
>> const struct grep_opt
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.
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 val
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.
50 matches
Mail list logo