Hi guys,
I work with submodules and use git grep a lot.
I noted that when it is invoked used with --recurse-submodules, the result is
not as expected for the submodules. I get submodules results as if no files
were modified (like --cached option) although I would expect results taking
into acc
Hi Gábor,
On Sat, 6 Jul 2019, SZEDER Gábor wrote:
> A comment in 'ci/lib.sh' claims that the "OS X build installs the
> latest available versions" of P4 and Git-LFS, but since 02373e56bd
> (ci: don't update Homebrew, 2019-07-03) that's no longer the case, as
> it will install the versions which w
On 07/05, Johannes Schindelin wrote:
> Hi Thomas,
>
>
> On Fri, 5 Jul 2019, Thomas Gummerer wrote:
>
> > Currently range-diff uses the 'strbuf_getline()' function for doing
> > its line by line processing. In a future patch we want to do parts of
> > that parsing using the 'parse_git_header()'
On 07/05, Johannes Schindelin wrote:
> Hi Thomas,
>
> On Fri, 5 Jul 2019, Thomas Gummerer wrote:
>
> > It's been quite a while since I sent the RFC [1] (thanks all for the
> > comments on that), and the series changed shapes quite a bit since the
> > last round.
> >
> > Since it's been such a lon
On 07/05, Johannes Schindelin wrote:
> > range-diff.c | 35
> > t/t3206-range-diff.sh | 91 +++---
> > t/t3206/history.export | 84 --
> > 3 files changed, 193 insertions(+), 17 deletions(-)
> >
> >
Hi Ævar,
On Fri, 5 Jul 2019, Ævar Arnfjörð Bjarmason wrote:
> On Wed, Jul 03 2019, Karsten Blees via GitGitGadget wrote:
>
> > From: Karsten Blees
> >
> > On native Windows, Git exclusively uses UTF-8 for console output (both
> > with MinTTY and native Win32 Console). Gettext uses `setlocale()`
Hi Thomas,
On Mon, 8 Jul 2019, Thomas Gummerer wrote:
> On 07/05, Johannes Schindelin wrote:
>
> > >*/
> > > continue;
> > > else if (line[0] == '>') {
> > > diff --git a/t/t3206-range-diff.sh b/t/t3206-range-diff.sh
> > > index 9f89af7178..c2777560
public-inbox.org links include the whole message ID by default. This
means the message can still be found even if the site goes away, which
is not the case with the marc.info link. Replace the marc.info link
with a more future proof one.
Signed-off-by: Thomas Gummerer
---
apply.c | 2 +-
1 fil
Thanks Dscho for the review of the previous round [1]. This rounds
addresses all the comments from that review.
In particular
- update commit messages where necessary.
- rename the function in apply.c to 'parse_git_diff_header()'
- code cleanups in 09/14
- fix a memory leak introduced in 09/14
-
Currently the 'git_header_name()' function takes 'struct apply_state'
as parameter, even though it only needs the p_value from that struct.
This function is in the callchain of 'parse_git_header()', which we
want to make more generally useful in a subsequent commit. To make
that happen we only wa
Currently the 'check_header_line()' function takes 'struct
apply_state' as parameter, even though it only needs the linenr from
that struct.
This function is in the callchain of 'parse_git_header()', which we
want to make more generally useful in a subsequent commit. To make
that happen we only w
Currently the 'skip_tree_prefix()' function takes 'struct apply_state'
as parameter, even though it only needs the p_value from that struct.
This function is in the callchain of 'parse_git_header()', which we
want to make more generally useful in a subsequent commit. To make
that happen we only w
Currently the 'find_name_*()' functions take 'struct apply_state' as
parameter, even though they only need the 'root' member from that
struct.
These functions are in the callchain of 'parse_git_header()', which we
want to make more generally useful in a subsequent commit. To make
that happen we o
Make parse_git_header a "public" function in apply.h, so we can re-use
it in range-diff in a subsequent commit.
Signed-off-by: Thomas Gummerer
---
apply.c | 69 -
apply.h | 48 +++
2 files changed, 67 ins
Currently the 'gitdiff_*()' functions take 'struct apply_state' as
parameter, even though they only needs the root, linenr and p_value
from that struct.
These functions are in the callchain of 'parse_git_header()', which we
want to make more generally useful in a subsequent commit. To make
that h
The line count in the outer diff's hunk headers of a range diff is not
all that interesting. It merely shows how far along the inner diff
are on both sides. That number is of no use for human readers, and
range-diffs are not meant to be machine readable.
In a subsequent commit we're going to add
Currently range-diff keeps the diff header of the inner diff
intact (apart from stripping lines starting with index). This diff
header is somewhat useful, especially when files get different
names in different ranges.
However there is no real need to keep the whole diff header for that.
The main
Currently range-diff uses the 'strbuf_getline()' function for doing
its line by line processing. In a future patch we want to do parts of
that parsing using the 'parse_git_diff_header()' function. That
function does its own line by line reading of the input, and doesn't
use strbufs. This doesn't
Add the section headers/hunk headers we introduced in the previous
commits to the outer diff's hunk headers. This makes it easier to
understand which change we are actually looking at. For example an
outer hunk header might now look like:
@@ Documentation/config/interactive.txt
while previ
In a range-diff it's not always clear which file a certain funcname of
the inner diff belongs to, because the diff header (or section header
as added in a previous commit) is not always visible in the
range-diff.
Add the filename to the inner diffs header, so it's always visible to
users.
This al
Fix the indentation of the function parameters for a couple of
functions, to match the style in the rest of the file.
Signed-off-by: Thomas Gummerer
---
range-diff.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/range-diff.c b/range-diff.c
index 48b0e1b4ce..9242b8975f 1
When postprocessing the inner diff in range-diff, we currently replace
the whole hunk header line with just "@@". This matches how 'git
tbdiff' used to handle hunk headers as well.
Most likely this is being done because line numbers in the hunk header
are not relevant without other changes. They
Dear Dinwoodie,
Please,I want to negotiate with you a transaction on inheritance
related matters in the value of $17 Million based on the same surname
you have with my late client Engineer Victor Dinwoodie
Barrister Tam David
Jeff King writes:
> On Wed, Jul 03, 2019 at 11:10:22AM -0700, Junio C Hamano wrote:
>
>> > Or perhaps we could differentiate our temporary locks from "real" .keep
>> > files by looking at the content; I think our locks always say something
>> > like "(receive|receive)-pack \d+ on .*", and it woul
Duy Nguyen writes:
> The command is to dump .git/index, not the shared one. And since this
> is not a split index test, rather a (quite low-level) json dump test,
> I did not bother to also dump the shared index, which should look like
> a regular one. Producing a unified view in json might not b
Ævar Arnfjörð Bjarmason writes:
>> -# ifdef HAVE_LIBCHARSET_H
>> +# ifdef GIT_WINDOWS_NATIVE
>> + ... new windows-only code ...
>> +# elif defined HAVE_LIBCHARSET_H
>> # include
>> # else
>> # include
> ...
> It looks to me that with this patch the HAVE_LIBCHARSET
Heiko Voigt writes:
> In commit 4d5e1b1319 ("gitk: Show detached HEAD if --all is specified",
> 2014-09-09) the intention was to have detached HEAD shown when the --all
> argument is given.
The "do we have --all?" test added by that old commit is not quite
satisfying in the first place. E.g. we
On 7/1/2019 10:29 AM, Derrick Stolee via GitGitGadget wrote:
> Here is a second run at this RFC, which aims to create a "meta" config
> setting that automatically turns on other settings according to a user's
> willingness to trade new Git behavior or new feature risk for performance
> benefits. Th
"Johannes Schindelin via GitGitGadget"
writes:
> From: Johannes Schindelin
>
> A `+` is not a valid part of a filename with Windows file systems (it is
> reserved because the `+` operator meant file concatenation back in the
> DOS days).
The title of the cover letter had "windows" in it, so cal
"Johannes Schindelin via GitGitGadget"
writes:
> On Windows, it is not possible to overwrite a file as long as any process
> holds a read handle to it. Even keeping regions memory-mapped prevents that.
That second sentence was quite helpful, as I do recall us closing
after mmapping. Without it,
BEGIN:VCARD
VERSION:3.0
PRODID:-//Apple Inc.//iPhone OS 12.3//EN
N:Camaisa;Gabriel;;;
FN: Gabriel Camaisa
ORG:Reyes;
EMAIL;type=INTERNET;type=HOME;type=pref:gabrielreyes...@gmail.com
EMAIL;type=INTERNET:asawaqoh...@icloud.com
EMAIL;type=INTERNET:gabriel...@gmail.com
TEL;type=pref:(0995) 146 551
Edmundo Carmona Antoranz writes:
> variable ret used in cmd_merge introduced in d5a35c114ab was already
> a local variable used inside a for loop inside the function.
Strictly speaking, there was a local variable 'ret' inside for loop,
which is unrelated to the variable introduced by the said co
On 2019-07-05 at 22:01:59, scott douglass wrote:
> Hi,
>
> I’d like to be able to discover the new parents-to-be SHA-1s during
> the hooks that run before a commit*. Essentially I’d like be able to
> distinguish the ‘git commit’ case from ‘git commit —amend’. Is there
> already a way to do this t
Edmundo Carmona Antoranz writes:
> Previous code was a little convoluted to follow logic
> New code is shorter and logic is easier to follow
In the body of the proposed commit log message, please finish each
sentence with a full-stop.
> - Easier to see what happens when merge is successful
>
Christian Couder writes:
> This is an RFC patch series that is not intended to be merged for now,
> as it looks like we don't need oidmaps that can handle several entries
> with the same key yet.
What does it even mean for a map to allow multiple entries per key?
When you have a key and its valu
How to Tweet.pdf
Description: Adobe PDF document
gabrielreyes...@gmail.com
On Mon, Jul 8, 2019 at 2:15 PM Junio C Hamano wrote:
> In the body of the proposed commit log message, please finish each
> sentence with a full-stop.
Ok
>
> These bullets are all subjective, and do not add any value to what
> you already said in the second sentence.
Ok
>
> These are facts th
SafariViewService - Jul 9 1 Reiwa at 5_48 AM.pdf
Description: Adobe PDF document
gabrielreyes...@gmail.com
"Johannes Schindelin via GitGitGadget"
writes:
> From: Johannes Schindelin
>
> When running an external diff from, say, a diff tool, it is safe to
> assume that we want to write the files in question. On Windows, that
> means that there cannot be any other process holding an open handle to
> sai
Johannes Schindelin writes:
> Hi Junio,
>
> On Wed, 3 Jul 2019, Junio C Hamano wrote:
>
>> * kb/windows-force-utf8 (2019-06-27) 1 commit
>> - gettext: always use UTF-8 on native Windows
>>
>> Windows update.
>>
>> On hold.
>> cf.
>
> I submitted v2 in
> https://public-inbox.org/git/pull.217.
Phillip Wood writes:
>> * pw/rebase-progress-test-cleanup (2019-07-01) 1 commit
>> - t3420: remove progress lines before comparing output
>> (this branch uses sg/rebase-progress.)
>>
>> Test cleanup.
>>
>> Will merge to 'next'.
>
> I've just posted an update to this which avoids the repeate
Thanks for the review. I'll address those issues in v8.
Best,
Matheus
On Wed, Jul 3, 2019 at 5:57 AM SZEDER Gábor wrote:
>
> > diff --git a/t/t0066-dir-iterator.sh b/t/t0066-dir-iterator.sh
> > index c739ed7911..8f996a31fa 100755
> > --- a/t/t0066-dir-iterator.sh
> > +++ b/t/t0066-dir-iterator.
On Fri, Jul 5, 2019 at 3:17 PM Johannes Schindelin
wrote:
>
> Hi Matheus,
>
> On Fri, 5 Jul 2019, Matheus Tavares Bernardino wrote:
> >
> > So, should I send a fixup patch removing find_recursive_symlinks() or
> > reroll the series? There's also the option to use stat()+lstat() to
> > reduce calls
Untitled 15.pdf
Description: Adobe PDF document
gabrielreyes...@gmail.com
Privacy - Apple 1.pdf
Description: Adobe PDF document
gabrielreyes...@gmail.com
The cmd_merge() function has a loop that tries different
merge strategies in turn, and stops when a strategy gets a
clean merge, while keeping the "best" conflicted merge so
far.
Make the loop easier to follow by moving the code around,
ensuring that there is only one "break" in the loop where
an
Junio C Hamano writes:
> Heiko Voigt writes:
>
>> In commit 4d5e1b1319 ("gitk: Show detached HEAD if --all is specified",
>> 2014-09-09) the intention was to have detached HEAD shown when the --all
>> argument is given.
>
> The "do we have --all?" test added by that old commit is not quite
> sat
Junio C Hamano writes:
> The "--all" in rev-list family (including "git log") unconditionally
> include HEAD. The glitch here is that "--all" in rev-parse does
> not. And 4d5e1b1319 was an attempt to "fix" that, i.e. make "--all"
> imply "HEAD".
And it becomes really tempting to get rid of tha
48 matches
Mail list logo
