ee all the changes
Developer A has made.
On my machine DEV I am on my local branch develop. Since I did not pull or
merge from origin already, I am not able to see any of those changes
developer A has made. So far so good. But I would expect, that git status
(which results in "On branch develop.
like "Branch develop is
> following remote branch develop from origin". I can see all the changes
> Developer A has made.
>
> On my machine DEV I am on my local branch develop. Since I did not pull or
> merge from origin already, I am not able to see any of those changes
&g
pull
or merge from origin already, I am not able to see any of those changes
developer A has made. So far so good. But I would expect, that git
status (which results in "On branch develop. Your branch is up to date
with origin/develop) or "git diff origin/develop develop" or &quo
to the
last few lines that end without a trailing comma. Literal string
concatenation taking place to form a single string here, in which
case both are giving us the same string?
By the way, sorry for an earlier response based on what I
misremembered, which may have confused the discussion unneces
I've figured it out. It's not a bug, it's a peculiarity of pprint().
It splits strings to avoid long lines and abuses the fact that in
Python strings split with whitespace are concatenated by the parser.
Also, in my example newlines are not parsed correctly in the shell.
Escaping them, I get the e
On Fri, 30 Aug 2019 at 17:27, Jeff King wrote:
> I think you have an extra "old-filename" in the second list.
Agreed. My misunderstanding was that I had thought that when
documentation said "path", it meant "argv[0], the path to the diff
executable".
> Interesting. I _don't_ see that splitting w
e on my small demo repo [1]:
>
> $ env GIT_EXTERNAL_DIFF=./print_argv.py git diff -M origin/branch1
> origin/branch1-mv -- file1.txt file1-mv.txt
> ['./print_argv.py',
> 'file1.txt',
> '/tmp/EWaCSc_file1.txt',
> '2b
e on my small demo repo [1]:
>
> $ env GIT_EXTERNAL_DIFF=./print_argv.py git diff -M origin/branch1
> origin/branch1-mv -- file1.txt file1-mv.txt
> ['./print_argv.py',
> 'file1.txt',
> '/tmp/EWaCSc_file1.txt',
> '2b
_DIFF=./print_argv.py git diff -M origin/branch1
origin/branch1-mv -- file1.txt file1-mv.txt
['./print_argv.py',
'file1.txt',
'/tmp/EWaCSc_file1.txt',
'2bef330804cb3f6962e45a72a12a3071ee9b5888',
'100644',
'/tmp/mtEiSc_file1-mv.txt',
On Fri, 30 Aug 2019 at 13:16, Phillip Wood wrote:
> I'm not sure why the last argument is being split in
> your example. It is not split in the example below
I have replicated the splitting issue on my small demo repo [1]:
$ env GIT_EXTERNAL_DIFF=./print_argv.py git diff -M ori
=./print_argv.py git diff -M master coursera --
week02_value_based/seminar_vi.ipynb
week2_model_based/practice_vi.ipynb
['./print_argv.py',
'week02_value_based/seminar_vi.ipynb',
'/tmp/amudWz_seminar_vi.ipynb',
'8f8016963c888b7dd8dd20f60b7d6fdb41b26c1d',
&#
Thank you for the reply.
On Thu, 29 Aug 2019 at 06:54, Junio C Hamano wrote:
> $ git diff -M branch1 branch2 -- file1 file2
>
> if file1 and file2 have similar-enough contents, may have a better
> chance of what you wanted to ask Git (if I am guessing what it is,
> that is
Dmitry Nikulin writes:
> $ env GIT_EXTERNAL_DIFF=./print_argv.py git diff
> origin/branch1:file1.txt origin/branch2:file2.txt
I didn't even know external-diff driver is called (and does not even segfaut)
in the "compare two blobs" hack codepath.
The syntax : you hav
I have put up a demo repo here: https://github.com/dniku/git-external-diff-argv
On Tue, 27 Aug 2019 at 21:24, Dmitry Nikulin wrote:
>
> I wrote a very simple Python script to see which arguments git-diff
> passes to the external diff program when comparing files across
> branche
I wrote a very simple Python script to see which arguments git-diff
passes to the external diff program when comparing files across
branches:
$ env GIT_EXTERNAL_DIFF=./print_argv.py git diff
origin/branch1:file1.txt origin/branch2:file2.txt
['./print_argv.py',
'file1.txt',
On Aug 26 2019, Dhaval Patel wrote:
> If it is only about files and revisions both being handled by git
> diff, would it not ne possible to do something like this?
>
> For files
>
> git diff -f a[PRESS TAB]
>
> For revisions
>
> git diff -r a[PRESS TAB]
>
>
If it is only about files and revisions both being handled by git
diff, would it not ne possible to do something like this?
For files
git diff -f a[PRESS TAB]
For revisions
git diff -r a[PRESS TAB]
Some sort of flag which says we are handling files or revisions.
On Sun, Aug 18, 2019 at 08:14:15AM +0530, Dhaval Patel wrote:
> How to reproduce
>
> [snip]
> Suggested feature -
>
> when I press tab, git diff should autocomplete just like git add.
I think this is somewhat harder of a usecase, as git add generally takes
paths and diff can
How to reproduce
git init
touch abc.txt
touch abd.txt
git add a*
git commit -m 'first commit'
echo 'hello' > abc.txt
git add a[PRESS TAB]
(This will autocomplete 'git add abc.txt')
git diff a[PRESS TAB]
(This will not give 'git diff abc.txt')
Sugg
Actually, I was actually using git log (not git diff... sorry for the mistake)
because I also mine other information I(dates, author, summary, etc)
'git log -m --first-parent --pretty=fuller --decorate=short --name-only
REL1..REL2'
That being said, I can work with the git diff
list of all files changed between two
> > > successive releases of software. I was using 'git diff' but have run into
> > > a
> > > problem.
> > >
> > > Consider the following situation: A development branch comes off of
> > > commit A
On Tue, Jul 9, 2019 at 4:13 PM Elijah Newren wrote:
>
> Hi John,
>
> On Tue, Jul 9, 2019 at 3:57 PM McRoberts, John wrote:
> >
> > I am responsible for generating a list of all files changed between two
> > successive releases of software. I was using 'git di
Hi John,
On Tue, Jul 9, 2019 at 3:57 PM McRoberts, John wrote:
>
> I am responsible for generating a list of all files changed between two
> successive releases of software. I was using 'git diff' but have run into a
> problem.
>
> Consider the following situation: A
I am responsible for generating a list of all files changed between two
successive releases of software. I was using 'git diff' but have run into a
problem.
Consider the following situation: A development branch comes off of commit A
and files are changed three times. A tag (REL1) is
On Tue, Jun 25, 2019 at 11:09:08PM +, Pugh, Logan wrote:
> > Or in your case I suppose even better would just be an
> > option like "--if-not-configured-just-use-regular-diff". Then it would
> > do what you want, without impacting users who do want the interactive
> > setup.
>
> If such an op
> Well, it _is_ true that you can use it the same way. It's just that you
> need to configure it to use whatever 3rd-party tool you want (and if you
> do not want to configure a tool, then you are better off just using
> git-diff directly). It was only due to a bug/historical
ocumentation (https://git-scm.com/docs/git-difftool) which near the top
> states:
Well, it _is_ true that you can use it the same way. It's just that you
need to configure it to use whatever 3rd-party tool you want (and if you
do not want to configure a tool, then you are better off just usi
> Prior to 287ab28bfa, we would not have respected any external diff
> command when running git-diff. But after it, we do.
>
> In the case that he user has not provided --no-index, then this all
> works as I guess difftool is meant to: it runs the helper and says "hey,
> you have n
ab28bfa was
not intentional. It would run git-diff, expecting it to trigger the
helper, but it never did (and instead just did a normal no-index diff).
So it seems like the new behavior is actually the right thing, as it
makes the --no-index case consistent with the regular one? I'm not
at
Prior to Git version 2.22.0 I was able to use git difftool without
> > configuring diff.tool or merge.tool and it would show the diff using git
> > diff.
> >
> > E.g. with Git 2.21.0:
> >
> > ~/gits/src/git$ git difftool --no-index color.c color.h
>
l or merge.tool and it would show the diff using git diff.
>
> E.g. with Git 2.21.0:
>
> ~/gits/src/git$ git difftool --no-index color.c color.h
> diff --git a/color.c b/color.h
> index ebb222ec33..98894d6a17 100644
>
> In Git version 2.22.0 an error message about diff.to
Note: This issue was originally discussed on this StackOverflow thread:
https://stackoverflow.com/q/56675863
Prior to Git version 2.22.0 I was able to use git difftool without configuring
diff.tool or merge.tool and it would show the diff using git diff.
E.g. with Git 2.21.0:
~/gits/src/git
Hi Johannes,
Thanks a lot for the clarification!
Regards,
Oussama
On 5/22/19 4:54 PM, Johannes Schindelin wrote:
> Hi Oussama,
>
> On Wed, 22 May 2019, Oussama Ghorbel wrote:
>
>> git diff-index is giving me incorrect information, however if I run git
>> diff, then git
Hi Oussama,
On Wed, 22 May 2019, Oussama Ghorbel wrote:
> git diff-index is giving me incorrect information, however if I run git diff,
> then git diff-index again it will show the correct information.
> The steps are the following:
> $ git diff-index --name-only HEAD
> git appe
Hi,
git diff-index is giving me incorrect information, however if I run git diff,
then git diff-index again it will show the correct information.
The steps are the following:
$ git diff-index --name-only HEAD
git appears to list all files in the project irrespective if they modified or
not
he index and can be in this group, its unique
functionality is resetting HEAD, which should be the "grow, mark,
tweak history" group.
Moving it there will also avoid the confusion because both 'restore'
and 'reset' are in the same group, next to each other.
While look
But my first impression is diff-files,
> as a low-level plumbing sometimes requires you to refresh the index
> first. Sometimes without that, you'll get wrong output.
>
> "git diff" is a more high-level command that always refreshes the
> index internally.
>
> >
> > System Information
> >
> > Arch Linux 5.0.7-arch1-1-ARCH
> > git version 2.21.0
>
>
>
> --
> Duy
he index and can be in this group, its unique
functionality is resetting HEAD, which should be the "grow, mark,
tweak history" group.
Moving it there will also avoid the confusion because both 'restore'
and 'reset' are in the same group, next to each other.
While look
7;t seem to have this problem.
I haven't tried to reproduce. But my first impression is diff-files,
as a low-level plumbing sometimes requires you to refresh the index
first. Sometimes without that, you'll get wrong output.
"git diff" is a more high-level command that always refres
't seem to have this problem.
Try running `git update-index --refresh` before running `diff-files`.
Unlike git-diff, git-diff-files is plumbing that is meant to be called
from scripts. So it is up to the script writer to decide when the index
should be refreshed from the actual filesystem (wh
Summary
`git -C (folder path) diff-files --name-only` output is not correct
Steps to Reproduce
1. Apply change to a clean git repository. Go to another folder (not
within this repository) and apply the command
`git -C repo-path diff-files --name-only`
The above command lists dirty files in t
Asciidoctor versions v1.5.7 or later print the following warning while
building the documentation:
ASCIIDOC git-diff-tree.xml
asciidoctor: WARNING: diff-format.txt: line 2: unterminated listing block
This highlights an issue (even with older Asciidoctor versions) where
the "Raw o
Asciidoctor versions v1.5.7 or later print the following warning while
building the documentation:
ASCIIDOC git-diff-tree.xml
asciidoctor: WARNING: diff-format.txt: line 2: unterminated listing block
This highlights an issue (even with older Asciidoctor versions) where
the "Raw o
Some more recent versions of Asciidoctor issue the following warning
while building the documentation:
ASCIIDOC git-diff-tree.xml
asciidoctor: WARNING: diff-format.txt: line 2: unterminated listing block
This highlights an issue where the "Raw output format" header is not
ren
On Mon, Mar 18, 2019 at 10:11 AM Michal Suchánek wrote:
>
> On Mon, 18 Mar 2019 10:07:08 -0700
> Elijah Newren wrote:
>
> > On Tue, Mar 12, 2019 at 2:01 PM Ævar Arnfjörð Bjarmason
> > wrote:
> > > On Tue, Mar 12 2019, Andreas Schwab wrote:
> > > > On Mär 12 2019, Junio C Hamano wrote:
> > > >
>
On Mon, Mar 18 2019, Elijah Newren wrote:
> On Tue, Mar 12, 2019 at 2:01 PM Ævar Arnfjörð Bjarmason
> wrote:
>> On Tue, Mar 12 2019, Andreas Schwab wrote:
>> > On Mär 12 2019, Junio C Hamano wrote:
>> >
>> >> I however think it may be worth making sure that our docs do not
>> >> encourage "dif
On Mon, 18 Mar 2019 10:07:08 -0700
Elijah Newren wrote:
> On Tue, Mar 12, 2019 at 2:01 PM Ævar Arnfjörð Bjarmason
> wrote:
> > On Tue, Mar 12 2019, Andreas Schwab wrote:
> > > On Mär 12 2019, Junio C Hamano wrote:
> > >
> > >> I however think it may be worth making sure that our docs do not
On Tue, Mar 12, 2019 at 2:01 PM Ævar Arnfjörð Bjarmason
wrote:
> On Tue, Mar 12 2019, Andreas Schwab wrote:
> > On Mär 12 2019, Junio C Hamano wrote:
> >
> >> I however think it may be worth making sure that our docs do not
> >> encourage "diff A..B" and teach "diff A B" when comparing two
> >> e
On Mär 13 2019, Duy Nguyen wrote:
> A..B from fetch is the same as branch@{1}..branch. If we have some
> shortcut similar to ^! but for reflog, that would be perfect (the
> branch part does not require much typing with tab completion).
Tab completion is much slower than c&p, especially if the co
Am 12.03.19 um 22:01 schrieb Ævar Arnfjörð Bjarmason:
>
> On Tue, Mar 12 2019, Andreas Schwab wrote:
>
>> On Mär 12 2019, Junio C Hamano wrote:
>>
>>> I however think it may be worth making sure that our docs do not
>>> encourage "diff A..B" and teach "diff A B" when comparing two
>>> endpoints.
On Wed, Mar 13, 2019 at 12:26 AM Andreas Schwab wrote:
>
> On Mär 12 2019, Junio C Hamano wrote:
>
> > I however think it may be worth making sure that our docs do not
> > encourage "diff A..B" and teach "diff A B" when comparing two
> > endpoints. That can be done without changing anything in t
On Tue, Mar 12 2019, Andreas Schwab wrote:
> On Mär 12 2019, Junio C Hamano wrote:
>
>> I however think it may be worth making sure that our docs do not
>> encourage "diff A..B" and teach "diff A B" when comparing two
>> endpoints. That can be done without changing anything in the code.
>
> Th
On Mär 12 2019, Junio C Hamano wrote:
> I however think it may be worth making sure that our docs do not
> encourage "diff A..B" and teach "diff A B" when comparing two
> endpoints. That can be done without changing anything in the code.
The nice thing about "diff A..B" is that you can c&p the
Denton Liu writes:
> =>content="$(git diff HEAD^! | tail -n 1)"
> ...
> It gets caught in my attempt to only deprecate ..'s. Technically, it's
> undocumented behaviour and it only happens to work because git-diff
> accept ranges but it doesn
Denton Liu writes:
> I was in the process of deprecating `git diff ..` as
> discussed here[1].
>
> [1]: https://public-inbox.org/git/xmqqmumy6mxe@gitster-ct.c.googlers.com/
I didn't (and don't) advocate such a deprecation, FWIW, in that
message. I simply do not thin
Hi,
On Mon, Mar 11, 2019 at 2:37 AM Denton Liu wrote:
>
> Hello all,
>
> I was in the process of deprecating `git diff ..` as
> discussed here[1]. However, I ran into a weird case that I'm not sure
> how to deal with.
>
> In t3430-rebase-merges.sh:382, we have
Hi Denton,
On Mon, 11 Mar 2019, Denton Liu wrote:
> I was in the process of deprecating `git diff ..` as
> discussed here[1]. However, I ran into a weird case that I'm not sure
> how to deal with.
>
> In t3430-rebase-merges.sh:382, we have the following test case whic
Hello all,
I was in the process of deprecating `git diff ..` as
discussed here[1]. However, I ran into a weird case that I'm not sure
how to deal with.
In t3430-rebase-merges.sh:382, we have the following test case which
invokes git diff:
test_expect_success 'with --auto
> On Mar 4, 2019, at 8:09 AM, Олег Самойлов wrote:
>
> A small pull request.
>
> https://github.com/git/git/pull/580
>
> Git diff can work with a tree in the form git diff tree..tree too, only
> the form git diff commit...commit can't accept a tree instead
A small pull request.
https://github.com/git/git/pull/580
Git diff can work with a tree in the form git diff tree..tree too, only
the form git diff commit...commit can't accept a tree instead of a commit.
Also added useful example about using a tree with git diff.
But what is stran
"Robert P. J. Day" writes:
> was perusing the git FAQ and ran across this:
>
> How do I obtain a list of files which have changed in a given commit?
>
> $ git diff --name-only ^!
>
>
> after playing with "git rev-parse", i figured out that
On Fri, Feb 22 2019, Robert P. J. Day wrote:
> was perusing the git FAQ and ran across this:
>
> How do I obtain a list of files which have changed in a given commit?
>
> $ git diff --name-only ^!
>
>
> after playing with "git rev-parse", i figured o
was perusing the git FAQ and ran across this:
How do I obtain a list of files which have changed in a given commit?
$ git diff --name-only ^!
after playing with "git rev-parse", i figured out that the above was
equivalent to (using kernel "v4.19" tag as an e
On 15-02-19, 08:09, Elijah Newren wrote:
> Hi Viresh,
>
> On Thu, Feb 14, 2019 at 10:40 PM Viresh Kumar wrote:
> >
> > On 14-02-19, 13:23, Elijah Newren wrote:
> > > I think you're getting tripped up by double-dot vs triple-dot with
> > > diff being di
Philip Oakley writes:
> It was my understanding that the end point would be total removal of
> any options and the typing of the double dot would be an error. Given
> that hard end point I was looking to ensure that users of double dots
> have a manageable route to unlearning old bad habits. Thus
Hi Junio,
On 17/02/2019 03:34, Junio C Hamano wrote:
Philip Oakley writes:
Those who do *not* opt into that "early warning" configuration dance
would eventually be warned whenever they type "diff A..B", and the
timing for that eventuality is not under their control, so quite
honestly, I do no
Philip Oakley writes:
>> Those who do *not* opt into that "early warning" configuration dance
>> would eventually be warned whenever they type "diff A..B", and the
>> timing for that eventuality is not under their control, so quite
>> honestly, I do not see much point in "giving users the chance"
recate and then
completely remove", as I do not think it would help people very much
if "git diff A B" can be spelled with two-dots.
But in a distant future long after that happens, by the time nobody
remembers what A..B meant for "git diff", I do not think I'd
strongly be
d then
>> completely remove", as I do not think it would help people very much
>> if "git diff A B" can be spelled with two-dots.
>>
>> But in a distant future long after that happens, by the time nobody
>> remembers what A..B meant for "git dif
ough. That is why I stopped "warn to deprecate and then
completely remove", as I do not think it would help people very much
if "git diff A B" can be spelled with two-dots.
But in a distant future long after that happens, by the time nobody
remembers what A..B meant for "git dif
On Thu, Feb 14, 2019 at 02:10:53PM -0800, Junio C Hamano wrote:
> Elijah Newren writes:
>
> > The only thing I seem to be able to retain is the following: "git
> > diff D..E is totally useless and should be an error because (1) it
> > doesn't do what I expe
ught things
through. That is why I stopped "warn to deprecate and then
completely remove", as I do not think it would help people very much
if "git diff A B" can be spelled with two-dots.
But in a distant future long after that happens, by the time nobody
remembers what A..B
Denton Liu writes:
> On Thu, Feb 14, 2019 at 02:10:53PM -0800, Junio C Hamano wrote:
>
>> It might be _possible_ to spend a year (i.e. 4 cycles) to start
>> warning when two-dot notation is used for "git diff" (only, not any
>> plumbing like "git diff-fi
On Fri, Feb 15, 2019 at 10:52 AM Denton Liu wrote:
>
> On Thu, Feb 14, 2019 at 02:10:53PM -0800, Junio C Hamano wrote:
> > Elijah Newren writes:
> >
> > > The only thing I seem to be able to retain is the following: "git
> > > diff D..E is totally usel
Hi Viresh,
On Thu, Feb 14, 2019 at 10:40 PM Viresh Kumar wrote:
>
> On 14-02-19, 13:23, Elijah Newren wrote:
> > I think you're getting tripped up by double-dot vs triple-dot with
> > diff being different than log:
> >
> > `git diff D..E` means the same thi
On 14-02-19, 13:23, Elijah Newren wrote:
> I think you're getting tripped up by double-dot vs triple-dot with
> diff being different than log:
>
> `git diff D..E` means the same thing as `git diff D E`, i.e. diff the
> two commits D and E.
Right, so both the branches hav
Elijah Newren writes:
> The only thing I seem to be able to retain is the following: "git
> diff D..E is totally useless and should be an error because (1) it
> doesn't do what I expect and (2) for folks that want the behavior
> currently gotten with that syntax can in
eady has Branch B merged in it (with an
> earlier pull request).
>
> Branch C (7c139d3f0f99) is a merge of Branch A and Branch B. When I
> try to generate diff-stat with:
>
> git diff -M --stat pm/linux-next..7c139d3f0f99
>
> It shows me the diffstat between v5.0-rc1..v5.0-rc2 as well.
&g
in it (with an
> earlier pull request).
>
> Branch C (7c139d3f0f99) is a merge of Branch A and Branch B. When I
> try to generate diff-stat with:
>
> git diff -M --stat pm/linux-next..7c139d3f0f99
>
> It shows me the diffstat between v5.0-rc1..v5.0-rc2 as well.
>
>
nused parameter of _generic_set_opp_clk_only()
bfeffd155283 (tag: v5.0-rc1) Linux 5.0-rc1
pm/linux-next branch already has Branch B merged in it (with an
earlier pull request).
Branch C (7c139d3f0f99) is a merge of Branch A and Branch B. When I
try to generate diff-stat with:
git diff -M --st
to avoid that? I have checked several git versions and they
> all do the same.
Not an attempt to offer a solution (I don't do windows), but just
trying to see what random things we can try, I wonder what you'd get
if you did something like
$ git diff --numstat //c/diff //c/base
git diff –numstat FOLDER1 FOLDER2 works strange when run from a git
controlled folder.
The output shrinks some symbols in the diff file paths.
For example:
Create a folder and call git init, for example: `C:\test`.
mkdir C:\test
cd C:\test
git init
On 2018-09-23 06:23 PM, Jeff King wrote:
> On Sun, Sep 23, 2018 at 05:56:03PM -0700, Stas Bekman wrote:
>
>>> You probably want "--ext-diff", not "--textconv".
>> [...]
>> Would it be safe to ask the maintainer of the application to include
>>
On Sun, Sep 23, 2018 at 05:56:03PM -0700, Stas Bekman wrote:
> > You probably want "--ext-diff", not "--textconv".
> [...]
> Would it be safe to ask the maintainer of the application to include
> both --textconv and --ext-diff in that 'git diff-tree'
On 2018-09-23 05:43 PM, Jeff King wrote:
> On Sun, Sep 23, 2018 at 03:41:45PM -0700, Stas Bekman wrote:
>
>> $ git config --get diff.jupyternotebook.command
>> git-nbdiffdriver diff
>
> That's an "external diff driver", not a textconv driver.
>
>
On Sun, Sep 23, 2018 at 03:41:45PM -0700, Stas Bekman wrote:
> $ git config --get diff.jupyternotebook.command
> git-nbdiffdriver diff
That's an "external diff driver", not a textconv driver.
So here:
> $ GIT_TRACE=1 git diff-tree -p HEAD --textconv test/test.ipynb
>
Hi,
I'm using a 3rd party application that internally uses 'git diff-tree'
instead of 'git diff'. I'm trying to add filter and it works with 'git
diff' but it gets ignored with 'git diff-tree' despite having --textconv.
I was able to reproduce t
On Fri, Aug 31, 2018 at 2:39 PM Johannes Schindelin
wrote:
>
> Hi,
>
> On Thu, 30 Aug 2018, Stefan Beller wrote:
>
> > On Thu, Aug 30, 2018 at 12:20 PM Jeff King wrote:
> > >
> > > [...] Myers does not promise to find the absolute minimal diff. [...]
> >
> > The `Myers` (our default) diff algorit
Hi,
On Thu, 30 Aug 2018, Stefan Beller wrote:
> On Thu, Aug 30, 2018 at 12:20 PM Jeff King wrote:
> >
> > [...] Myers does not promise to find the absolute minimal diff. [...]
>
> The `Myers` (our default) diff algorithm is really the Myers algorithm +
> a heuristic that cuts off the long tail
On Thu, Aug 30, 2018 at 12:20 PM Jeff King wrote:
>
> On Thu, Aug 30, 2018 at 12:16:22PM -0700, Stefan Beller wrote:
>
> > On Wed, Aug 29, 2018 at 7:54 PM Jeff King wrote:
> > >
> > > On Wed, Aug 29, 2018 at 10:10:25PM -0400, Gabriel Holodak wrote:
> > >
> > > > > Could you cut down to a real min
On Thu, Aug 30, 2018 at 12:16:22PM -0700, Stefan Beller wrote:
> On Wed, Aug 29, 2018 at 7:54 PM Jeff King wrote:
> >
> > On Wed, Aug 29, 2018 at 10:10:25PM -0400, Gabriel Holodak wrote:
> >
> > > > Could you cut down to a real minimal reproduction, i.e. just these 20
> > > > lines or so?
> > >
>
On Wed, Aug 29, 2018 at 7:54 PM Jeff King wrote:
>
> On Wed, Aug 29, 2018 at 10:10:25PM -0400, Gabriel Holodak wrote:
>
> > > Could you cut down to a real minimal reproduction, i.e. just these 20
> > > lines or so?
> >
> > I'm working on getting down to a minimal reproduction, a few lines at
> > a
use the duplicated diffs.
>
> I'll upload again when I've figured out all the unimportant lines to remove.
Yeah, I reproduced based on your initial post, but noticed that when I
cut it down the problem went away.
An easy and pretty mechanical reproduction is:
git diff --no-index
so I tested
> git diff --no-index old new
> git diff --patience --no-index old new
> git diff --histogram --no-index old new
>
> all of which do not reproduce the issue.
I don't believe I had any settings to change the algorithm. Using any
of --minimal, --patience,
Hello there,
I was looking for the possibility of sorting the output of the command "git
diff --stat" by the number of modifications. Currently, the output of this
command show the modified files by alphabetic order.
I didn't find a "builtin" option which allows to so
On Sun, Aug 26, 2018 at 6:54 PM Gabriel Holodak wrote:
>
> I think I'm running into a bug with git diff on v2.18.0.
I cannot reproduce with the two files attached.
I suspected you might have a different diff algorithm configured,
so I tested
git diff --no-index old new
I think I'm running into a bug with git diff on v2.18.0. When I diff
the attached files, part of the diff ends up looking like:
...
STARTCHAR U+00F0
ENCODING 240
SWIDTH 500 0
-DWIDTH 8 0
-BBX 7 12 1 0
-BITMAP
-12
-0C
-14
-22
-02
-3E
-42
-42
-82
-84
-84
-78
+DWIDTH 8 0
+BBX 8 12 0 0
+BITMA
ke --show-abs-paths to implicitly
> supply --src-prefix, but not --dst-prefix? If so, why?
notice I didn't use `--show-abs-paths` in that example; I'm showing
what `git diff` currently outputs (the `could show` meant depending on
your use case; eg when `get_file1` returns an absolute path
On Thu, Aug 23, 2018 at 11:16 AM Timothee Cour wrote:
>
> This has all the context:
> https://stackoverflow.com/questions/22698505/how-to-show-full-paths-in-git-diff
It's helpful to copy it anyway, so we can discuss it here:
QUOTE
How do I show full paths in git diff? One can use
This has all the context:
https://stackoverflow.com/questions/22698505/how-to-show-full-paths-in-git-diff
I'd like `--show-abs-path` to show absolute paths in:
git diff --show-abs-path args...
eg:
git diff --no-index `get_file1` `get_file2`
could show:
--- a/Users/timothee/temp/ripgrep/help
1 - 100 of 611 matches
Mail list logo
