Am 15.04.19 um 01:29 schrieb Eric Sunshine:
> On Sun, Apr 14, 2019 at 5:10 PM Thomas Gummerer wrote:
>> + strbuf_remove(&line, 0, 4);
>> + if (!strcmp(filename_a.buf, "/dev/null")) {
>> + strbuf_addstr(&buf, "new fil
Junio C Hamano writes:
> SZEDER Gábor writes:
>
>> ... therefore these should be 'test_i18ngrep'. This applies to the
>> other tests in this patch series as well.
>> ...
>
> Hmph. That would mean the following is needed,...
And a corresponding fix for step 2/2 would look like this.
t/t5702-
SZEDER Gábor writes:
> ... therefore these should be 'test_i18ngrep'. This applies to the
> other tests in this patch series as well.
> ...
Hmph. That would mean the following is needed, but I suspect that
6cdccfce ("i18n: make GETTEXT_POISON a runtime option", 2018-11-08)
is somewhat broken (
On Mon, Apr 15, 2019 at 12:16 AM Eric Sunshine wrote:
> When composing that email, I originally wrote $(wildcard
> config.mak.autogen) as the suggestion but changed it to the looser
> $(wildcard config.mak*) when I realized that the developer's own
> config.mak probably ought to be a dependency, a
On Sun, Apr 14, 2019 at 11:10 PM Junio C Hamano wrote:
> Eric Sunshine writes:
> >> +Documentation/GIT-EXCLUDED-PROGRAMS: Makefile config.mak.uname
> >> + $(QUIET_GEN)echo "EXCLUDED_PROGRAMS := $(EXCLUDED_PROGRAMS)" >$@
> >
> > Should this rule also have a dependency upon "config.mak.autoge
Eric Sunshine writes:
>> diff --git a/Makefile b/Makefile
>> @@ -2455,22 +2455,25 @@ $(VCSSVN_LIB): $(VCSSVN_OBJS)
>> +Documentation/GIT-EXCLUDED-PROGRAMS: Makefile config.mak.uname
>> + $(QUIET_GEN)echo "EXCLUDED_PROGRAMS := $(EXCLUDED_PROGRAMS)" >$@
>
> Should this rule also have a depend
"Robin H. Johnson" writes:
> On Fri, Apr 12, 2019 at 05:08:19PM +0700, Nguyễn Thái Ngọc Duy wrote:
>> @@ -2096,7 +2096,7 @@ static int absorb_git_dirs(int argc, const char
>> **argv, const char *prefix)
>> };
>>
>> const char *const git_submodule_helper_usage[] = {
>> -N_
Junio C Hamano writes:
> Do you mean more like
> ...
> I think I can agree with either of the two positions...
I am guessing from the earlier iteration that you wanted to say
"unless it is given explicitly, we turn it on".
As this last-minute style update that was botched, and a typofix in
the
Thomas Gummerer writes:
> I do feel like the filenames should probably have priority in the
> outer diffs hunk header lines though, as we can only add a limited
> amount of information there, and without the filename, the function
> name might be less useful (or it may be not useful at all, for t
On Sun, Apr 14, 2019 at 5:10 PM Thomas Gummerer wrote:
> [...]
> Introduce a new range diff hunk header, that's enclosed by "##",
> similar to how line numbers in diff hunks are enclosed by "@@", and
> give human readable information of what exactly happened to the file,
> including the file name.
On Sun, Apr 14, 2019 at 5:09 PM Thomas Gummerer wrote:
> [...]
> However it can still be useful to have the function name that 'git
> diff' extracts as additional context for the change.
> [...]
> Signed-off-by: Thomas Gummerer
> ---
> diff --git a/range-diff.c b/range-diff.c
> @@ -102,9 +102,12
When I send patches I want them to have lots of context, but when just
looking at a diff, I can always open the file for context.
-SHawn
On 04/13, Junio C Hamano wrote:
> Thomas Gummerer writes:
>
> > I'm not sure what the right solution for this is. I think one thing
> > I'd like range-diff to do is to add the filename, or some context
> > (e.g. is this part of the commit message etc.) to the @@ line (not
> > sure what that is c
From: Johannes Schindelin
Due to reasons (some XCode versions seem to include gettext, some
don't?), Homebrew does not expose the libraries and headers in
/usr/local/ by default anymore.
Let's help find them again.
Note: for some reason, this is a change of behavior caused by the
upgrade to Moj
Yesterday, the macOS agents of Azure Pipelines were upgraded to Mojave, and
since that does not support HFS+ anymore, everything will be upgraded to
APFS.
As I just found yesterday, we have one test that fails on that filesystem
(t9822, which is only run if Perforce's p4d is available).
The first
From: Johannes Schindelin
Most notably, it seems that macOS' APFS does not allow that.
Signed-off-by: Johannes Schindelin
---
t/t9822-git-p4-path-encoding.sh | 7 +++
1 file changed, 7 insertions(+)
diff --git a/t/t9822-git-p4-path-encoding.sh b/t/t9822-git-p4-path-encoding.sh
index c7847
On 04/12, Johannes Schindelin wrote:
> Hi Thomas,
>
> On Thu, 11 Apr 2019, Thomas Gummerer wrote:
>
> > On 04/11, Duy Nguyen wrote:
> > > Try
> > >
> > > git range-diff from...to
> > >
> > > with those two branches from https://gitlab.com/pclouds/git.git. The
> > > interesting part is this
>
Hi Barret,
This works pretty well for the typical reformatting use case now. I've
run it over every commit of every .c file in the git project root,
both forwards and backwards with every combination of -w/-M/-C and
can't get it to crash so I think it's good in that respect.
However, it can still
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
This series aims at improving the output of 'git range-diff',
especially in cases like the one mentioned in [*1*], where a diff
header, that was before the outer diff's hunk header was
misinterpreted as being the filename of the diff that followed it.
It does so by substituting the diff header of
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
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
Add the section headers we introduced in the previous commit 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:
@@ -77,15 +78,43 @@ modified file Documentation/config/interactive.
Hi Luke,
On Sat, 13 Apr 2019, Luke Diamand wrote:
> On Fri, 12 Apr 2019 at 12:39, Johannes Schindelin via GitGitGadget
> wrote:
> >
> > From: Johannes Schindelin
> >
> > Most notably, it seems that macOS' APFS does not allow that.
>
> Did you mean in the subject "ISO-8895-1" encoded or "ISO-885
Hello,
Just a quick request for an enhancement to the behavior of the following
command:
git pull --autostash --rebase
When executed with local, untracked files that would conflict with newly-added
files upstream, e.g.
An untracked local file `master:/foo` would be overwritten by a recently
On April 13, 2019 17:48, SZEDER Gábor wrote:
> To: Ævar Arnfjörð Bjarmason
> Cc: Randall S. Becker ; git@vger.kernel.org
> Subject: Re: [BUG] GIT_SSH_COMMAND is not being decomposed
>
> On Sat, Apr 13, 2019 at 10:39:35PM +0200, Ævar Arnfjörð Bjarmason wrote:
> > On Sat, Apr 13 2019, Randall S. Be
On 14/04/2019 02:59, wh wrote:
Thanks for the info about the upcoming "precious" attribute. Looks useful.
Hmm, unfortunately it's not looking so hopeful now [1]
I didn't get the impression that Git normally overwrites ignored
files. I ran some more experiments:
git rebase FETCH_HEAD#
On Sun, 14 Apr 2019 at 11:24, Junio C Hamano wrote:
> > If you only enable blame.markIgnoredLines then the hash for
> > "unblamable" lines appears as e.g. "*3252488f5" - this doesn't seem
> > right to me because the commit *wasn't* ignored,
>
> I think you misunderstood me. I was merely suggestin
> > + the `blame.ignoreRevsFile` config option. An empty file name, `""`,
> > will
> > + clear the list of revs from previously processed files.
>
> Maybe I haven't read this carefully enough but the use-case for this
> doesn't seem to be explained, you need this for the option, but the
>
Rohit Ashiwal writes:
> On 2019-04-13 1:34 UTC Jeff King wrote:
>
>> What is gzwrite()?
>> [...]
>> I think it would be less confusing if this just factored out
>> write_block_or_die(), which starts as a thin wrapper and then grows the
>> gzip parts in the next patch.
>
> You are right, it migh
Michael Platings writes:
> If you only enable blame.markIgnoredLines then the hash for
> "unblamable" lines appears as e.g. "*3252488f5" - this doesn't seem
> right to me because the commit *wasn't* ignored,
I think you misunderstood me. I was merely suggesting to use the
approach to mark the l
On Sun, 14 Apr 2019 at 04:45, Junio C Hamano wrote:
> Wouldn't this make it impossible to tell between what's done by such
> a commit that was marked to be ignored, and what's done locally only
> in the working tree, which the users have long accustomed to see
> with the ^0*$ object name? I think
> - I wonder if the hash used here can replace what is used in
>diffcore-delta.c as an improvement (or obviously vice versa), as
>using two (or more) ad-hoc fingerprinting function without having
>a clear reason why we need two instead of a unified one feels
>like a bad idea.
Hi J
33 matches
Mail list logo
