On Fri, May 13, 2016 at 4:06 AM, Junio C Hamano wrote:
> Pranit Bauva writes:
>
>> + /*
>> + * In theory, nothing prevents swapping completely good and bad,
>> + * but this situation could be confusing and hasn't been tested
>> + * enough. Forbid it for now.
>> + */
>> +
>
On Fri, May 13, 2016 at 12:27 PM, 李本超 wrote:
> Yes, you got the right understanding of my problem.
>
> You are right, the git behavior is quite correct. But I met this
> problem in my practical work:
>
> My colleague added a method but I didn't know. I also added the same method.
> Then I found th
It does not warn me in this case. I replayed it again, below is my process:
$ mkdir bug_test
$ cd bug_test/
$ git init
Initialized empty Git repository in /home/libenchao/tmp/bug_test/.git/
$ echo 'hello' > README.md
$ git add README.md
$ git commit -m 'Add README.md'
[master (root-commit) 9cdb3a8
On Fri, May 13, 2016 at 03:41:13PM +0800, 李本超 wrote:
> It does not warn me in this case. I replayed it again, below is my process:
>
> [...setup...]
So after you setup steps you have:
$ git log --decorate --oneline --raw
* a3ce3bc (HEAD -> B) modify
| :100644 100644 94954ab... 23509e0...
Thanks a lot for the feedback.
I read Documentation/SubmittingPatches before sending the original patch,
but it seems not everything had sunk in.
(And I definitely should have read it again before sending v2...)
I will resubmit the patch, then.
On Thu, May 12, 2016 at 09:38:59AM -0700, Juni
From: Keller Fuchs
Uniformise the vocabulary used wrt. key/signature validity with OpenPGP:
- a signature is valid if made by a key with a valid uid;
- in the default trust-model, a uid is valid if signed by a trusted key;
- a key is trusted if the (local) user set a trust level for it.
Helped-b
Hi,
t9801 and t9803 seem to be broken on next. A quick bisect indicates that
d9545c7
"fast-import: implement unpack limit" might be the reason. (@gmane/292562).
Did anyone look into that already?
Thanks,
Lars
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a m
This is not an improvement in the test coverage but it helps in making
it explicit as to know what exactly is the error as other tests are
focussed on testing other things but they do indirectly test for this.
Mentored-by: Lars Schneider
Mentored-by: Christian Couder
Signed-off-by: Pranit Bauva
Hin-Tak Leung wrote:
> I tried bin-wrappers/ from current git HEAD.
>
> $ git describe
> v2.8.2-396-g5fe494c
Which SVN version? `git svn --version`
> bin-wrappers/git svn clone https://ironpython.svn.codeplex.com/svn
> ironpython-old-codeplex
>
> always fails at this rev:
>
> M
Lars Schneider wrote:
> Hi,
>
> t9801 and t9803 seem to be broken on next. A quick bisect indicates that
> d9545c7
> "fast-import: implement unpack limit" might be the reason. (@gmane/292562).
>
> Did anyone look into that already?
Just took a look (no p4, so couldn't run tests) and I guess i
>From 50c9cbb6ce31529316ba004194f63a24ae59b4b0 Mon Sep 17 00:00:00 2001
From: Adam Dinwoodie
Date: Fri, 13 May 2016 11:52:32 +0100
Subject: [PATCH] git-gui: Remove unused Cygwin compatibility code
Cygwin-distributed builds of git-gui have patched out the
Cygwin-specific compatibility code in the
Hi Bryant,
On Thu, 5 May 2016, Bryant Bernstein wrote:
> Both windows and linux support links but both git and the git bash
> seem to have a problem with them.
>
> In my source, (originally on Linux) I have a link in my source
> directory to a config file which I normally import into python. Th
Hi Junio,
On Tue, 10 May 2016, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > On Fri, 6 May 2016, Junio C Hamano wrote:
> >
> > 2) I was under the impression that we preferred test_i18ngrep over grep...
>
> Only when the strings we are expecting are subject to i18n. I
> somehow did
Thanks for your explanation
>
> The moment where I think you'd like to be notified is when we skipped
> doing anything with patch 1. You'd prefer it to say "woah, the other
> side of the rebase did the same thing as us".
Actually this is the problem where I want to be notified.
> But rebase does
On 05/12/2016 10:25 AM, Jeff King wrote:
> On Thu, May 12, 2016 at 03:45:28AM -0400, Jeff King wrote:
>
>> So I'd expect us to hit that lock_ref_for_update() for each of the new
>> refs. But then we end up in verify_refname_available_dir(), which wants
>> to read all of the loose refs again. So we
Before committing ref updates, split symbolic ref updates into two
parts: an update to the underlying ref, and a log-only update to the
symbolic ref. This ensures that both references are locked correctly
during the transaction, including while their reflogs are updated.
Similarly, if the referenc
On Fri, May 13, 2016 at 02:33:20PM +0200, Michael Haggerty wrote:
> The problem in this case is a misguided call to
> verify_refname_available_dir() in the case that read_raw_ref() fails
> with ENOENT. In that case it is not possible for there to be a conflict
> with another loose reference, becau
On Fri, May 13, 2016 at 02:35:40PM +0200, Michael Haggerty wrote:
> + if (read_raw_ref(refname, lock->old_oid.hash, referent, type)) {
> + if (errno == ENOENT) {
> + if (mustexist) {
> + /* Garden variety missing reference. */
> +
Hi Eric,
On Wed, 11 May 2016, Eric Sunshine wrote:
> On Wed, May 11, 2016 at 4:42 AM, Johannes Schindelin
> wrote:
> > This patch makes perf-lib.sh more robust so that it can run correctly
> > even inside a worktree. For example, it assumed that $GIT_DIR/objects is
> > the objects directory (whi
Hi Junio,
On Wed, 11 May 2016, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > diff --git a/t/perf/p3404-rebase-interactive.sh
> > b/t/perf/p3404-rebase-interactive.sh
> > new file mode 100755
> > index 000..382163c
> > --- /dev/null
> > +++ b/t/perf/p3404-rebase-interactive.sh
>
This patch makes perf-lib.sh more robust so that it can run correctly
even inside a worktree. For example, it assumed that $GIT_DIR/objects is
the objects directory (which is not the case for worktrees) and it used
the commondir file verbatim, even if it contained a relative path.
Furthermore, the
This developer spent a lot of time trying to speed up the interactive
rebase, in particular on Windows. And will continue to do so.
To make it easier to demonstrate the performance improvement, let's have
a reproducible performance test.
The topic branch we use to test performance was found using
We already have a perfectly fine prereq to tell us whether it is safe to
use symlinks. So let's use it.
This fixes the performance tests in Git for Windows' SDK, where symlinks
are not really available ([*1*]). This is not an issue with Git for
Windows itself because it configures core.symlinks=fa
This is the second preparatory patch series for my rebase--helper work
(i.e. moving parts of the interactive rebase into a builtin).
It simply introduces a perf test (and ensures that it runs in my
environment) so as to better determine how much the performance changes,
really.
Johannes Schindel
If you use .gitattributes to enable CRLF->LF rewriting, then commit a
file that would have its line endings rewritten, the "CRLF will be
replaced by LF" warning is printed several times over; I'd expect it to
be printed only once.
There's a test case in t0020 -- "safecrlf: print warning only once"
After running
git init .
git config foo.bar baz
git config --unset foo.bar# 1
git config foo.bar baz# 2
.git/config contains
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[foo]
[foo]
Hello,
in t3404 test 91 - static check of bad SHA-1 fails (with ksh) with a
syntax error in git-rebase.
git-rebase[6]: test: argument expected
Reason is, again, a test -z without quotes in git-rebase--interactive:
*** ../git-rebase--interactive.orig Tue May 10 17:36:59 2016
--- ../git-rebase-
On Tue, May 10, 2016 at 10:17 AM, Nguyễn Thái Ngọc Duy
wrote:
> So far we haven't needed to identify an existing worktree from command
> line. Future commands such as lock or move will need it. There are of
> course other options for identifying a worktree, for example by branch
> or even by inter
Eric Wong writes:
> Lars Schneider wrote:
>> Hi,
>>
>> t9801 and t9803 seem to be broken on next. A quick bisect indicates that
>> d9545c7
>> "fast-import: implement unpack limit" might be the reason. (@gmane/292562).
>>
>> Did anyone look into that already?
>
> Just took a look (no p4, so c
On Tue, May 10, 2016 at 10:17 AM, Nguyễn Thái Ngọc Duy
wrote:
> Main worktree _is_ different. You can lock a linked worktree but not the
> main one, for example. Provide an API for checking that.
>
> Signed-off-by: Nguyễn Thái Ngọc Duy
> ---
> diff --git a/worktree.c b/worktree.c
> @@ -238,6 +238
Adam Dinwoodie writes:
> If you use .gitattributes to enable CRLF->LF rewriting, then commit a
> file that would have its line endings rewritten, the "CRLF will be
> replaced by LF" warning is printed several times over; I'd expect it to
> be printed only once.
>
> There's a test case in t0020 --
Jonas Bernoulli writes:
> The only possible combination which doesn't make sense is to not remove
> an empty section and to also not reuse an empty section - unfortunately
> that's what Git currently does.
It is not that simple.
The configuration sections can have comments and they are preserve
On Tue, May 10, 2016 at 10:17 AM, Nguyễn Thái Ngọc Duy
wrote:
> This provides an API for checking if a worktree is locked. We need to
> check this to avoid double locking a worktree, or try to unlock one when
> it's not even locked.
>
> Signed-off-by: Nguyễn Thái Ngọc Duy
> ---
> diff --git a/wor
The changes are described in CHANGES.
Signed-off-by: Matthieu Moy
---
contrib/hooks/multimail/CHANGES | 8
contrib/hooks/multimail/README | 2 +-
contrib/hooks/multimail/README.Git | 4 ++--
contrib/hooks/multimail/git_multimail.py | 10 +-
4 files ch
On
Fri, 13/5/16, Eric Wong wrote:
Hin-Tak Leung
wrote:
> I tried bin-wrappers/ from
current git HEAD.
>
>
$ git describe
> v2.8.2-396-g5fe494c
> Which SVN version? `git
svn --version`
$ git svn --version
git-svn version 2.5.5 (svn 1
Hello,
Currently "git submodule update" appears to be optimized for updating
existing submodules - which isn't surprising given its name. However it
is also used for the "initial setup" of submodules, i.e. right after
running "git submodule init" or with the "--init" argument.
Below you find a l
On Fri, 2016-05-13 at 00:10 +0100, Ramsay Jones wrote:
>
> On 12/05/16 21:20, David Turner wrote:
> > From: Nguyễn Thái Ngọc Duy
> [snip]
>
> >
> > +/* in ms */
> > +#define WATCHMAN_TIMEOUT 1000
> > +
> > +static int poke_and_wait_for_reply(int fd)
> > +{
> > + struct strbuf buf = STRBUF_IN
Johannes Schindelin writes:
> Hi Junio,
>
> On Thu, 12 May 2016, Junio C Hamano wrote:
>
>> I took these separately already, and plan to fast-track them as they are
>> both "trivially correct"; I double checked that what I have match these
>> two, too.
>
> Oh, okay. I just wanted to make things e
Pranit Bauva writes:
> Not just that, it would also be fundamentally more correct as there is
> a difference between " !strcmp("good") " and " strcmp("bad") ".
Not really. As long as you are in tight control of the callers,
because we'd never call $2 with anything other than good and bad in
the
On Fri, May 13, 2016 at 02:49:53PM +0100, Adam Dinwoodie wrote:
> (Tangentially: what's the accepted practice for submitting failing test
> scripts? I've written a short test case to add to t0020 that shows this
> bugged behaviour, but I've got the vague impression from past emails
> that leading
+cc Heiko and Jens as they are submodule experts.
On Fri, May 13, 2016 at 10:32 AM, Jonas Bernoulli wrote:
> Hello,
>
> Currently "git submodule update" appears to be optimized for updating
> existing submodules - which isn't surprising given its name. However it
> is also used for the "initial
Hi all,
I have been running into a bug in gitk, wherein it doesn't show the complete
contents of the repository in the Tree view, when invoked from a subdirectory
of the working tree (as opposed to the top level).
The bug is very simple to reproduce:
$ git --version
git version 2.8.2
$ m
On Fri, May 13, 2016 at 06:09:35PM +0200, Armin Kunaschik wrote:
> in t3404 test 91 - static check of bad SHA-1 fails (with ksh) with a
> syntax error in git-rebase.
> git-rebase[6]: test: argument expected
Here's a fix that covers these and another I found:
-- >8 --
Subject: [PATCH] always quot
From: Nguyễn Thái Ngọc Duy
Watchman is hidden behind index-helper. Before git tries to read the
index from shm, it notifies index-helper through the socket and waits
for index-helper to prepare a file for sharing memory (with
MAP_SHARED). index-helper then contacts watchman, updates 'WAMA'
extens
I tried your svn diff directly, and got the same error:
$ /usr/bin/time -v -o /tmp/svn-log svn diff -r7604:8870
https://ironpython.svn.codeplex.com/svn > /dev/null
svn: E000104: Error running context: Connection reset by peer
$ more /tmp/svn-log
Command exited with non-zero status 1
Comm
Hi Dscho,
On Fri, May 13, 2016 at 8:32 AM, Johannes Schindelin
wrote:
> Hi Chris,
>
> On Wed, 11 May 2016, Christian Couder wrote:
>
>> I consider that the apply functionality is properly libified before
>> these patches, and that they should be in a separate series, but
>> unfortunately using th
On Thu, May 12, 2016 at 9:56 PM, Junio C Hamano wrote:
> Christian Couder writes:
>
>> This is just a small cleanup.
>
> ... which may have been better happened at 09/94.
Ok, I will squash it in 09/94.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
On Thu, May 12, 2016 at 10:43 PM, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>> Up to this point, the conversion looks quite sensible, even though I
>> think the organization of fields in apply_state do not look logical.
>
> I'd stop here for now, as everything before this step looks
> unco
Jeff King writes:
> On Fri, May 13, 2016 at 02:49:53PM +0100, Adam Dinwoodie wrote:
>
>> (Tangentially: what's the accepted practice for submitting failing test
>> scripts? I've written a short test case to add to t0020 that shows this
>> bugged behaviour, but I've got the vague impression from
On Fri, May 13, 2016 at 02:23:25PM -0400, Jeff King wrote:
> This covers all cases detected by:
>
> git grep 'test -z [^"]'
>
> (though note that has a few false positives for tests which
> need an extra layer of quoting to do '\"').
I looked at those false positives, and they're really gratu
These variables were added in 16805d3 (t/t91XX-svn: start
removing use of "git-" from these tests, 2008-09-08) so that
running:
git grep git-
would return fewer hits. At the time, we were transitioning
away from the use of the "dashed" git-foo form.
That transition has been over for years, and
A few tests here use double-quotes around the snippets of
shell code to run the tests. None of these tests wants to do
any interpolation at all, and it just leads to an extra
layer of quoting around all double-quotes and dollar signs
inside the snippet. Let's switch to single quotes, like
most oth
When a test runs a loop, it cannot rely on the usual
&&-chaining to propagate a failure inside the loop; it needs
to break out with a failure signal. However, unless you are
in a subshell, doing so with "exit 1" will exit the entire
test script, not just the test snippet we are in (and cause
the ha
Jeff King writes:
> On Fri, May 13, 2016 at 06:09:35PM +0200, Armin Kunaschik wrote:
>
>> in t3404 test 91 - static check of bad SHA-1 fails (with ksh) with a
>> syntax error in git-rebase.
>> git-rebase[6]: test: argument expected
>
> Here's a fix that covers these and another I found:
>
> -- >8
On Fri, May 13, 2016 at 12:46:57PM -0700, Junio C Hamano wrote:
> > We don't want commits that fail the test suite, since it makes bisection
> > more difficult. But you can mark known bugs like:
> >
> >test_expect_failure 'git-foo should output bar' '
> > ...
> >'
> >
> > I think it's
On Fri, May 13, 2016 at 12:52:44PM -0700, Junio C Hamano wrote:
> I _think_ "test -z" should succeed according to POSIX, because
>
> (1) it is not "test -z string" because it lacks string,
>
> (2) it is not any of the other "test - thing" because -z,
> and
>
> (3) the only thing it match
On Fri, May 13, 2016 at 03:59:11PM -0400, Jeff King wrote:
> On Fri, May 13, 2016 at 12:52:44PM -0700, Junio C Hamano wrote:
>
> > I _think_ "test -z" should succeed according to POSIX, because
> >
> > (1) it is not "test -z string" because it lacks string,
> >
> > (2) it is not any of the ot
Jeff King writes:
> On Fri, May 13, 2016 at 12:52:44PM -0700, Junio C Hamano wrote:
>
>> I _think_ "test -z" should succeed according to POSIX, because
>>
>> (1) it is not "test -z string" because it lacks string,
>>
>> (2) it is not any of the other "test - thing" because -z,
>> and
>>
Reimplement the `bisect_log` shell function in C and add a
`--bisect-log` subcommand to `git bisect--helper` to call it from
git-bisect.sh .
Using `--bisect-log` subcommand is a temporary measure to port shell
function to C so as to use the existing test suite. As more functions
are ported, this s
Reimplement the `bisect_voc` shell function in C. This is a too small
function to be called as a subcommand though the working of this
function has been tested by calling it as a subcommand.
Mentored-by: Lars Schneider
Mentored-by: Pranit Bauva
Signed-off-by: Pranit Bauva
---
The PR for testin
On Sat, May 14, 2016 at 1:32 AM, Pranit Bauva wrote:
> Reimplement the `bisect_voc` shell function in C. This is a too small
> function to be called as a subcommand though the working of this
> function has been tested by calling it as a subcommand.
>
> Mentored-by: Lars Schneider
> Mentored-by:
On 13/05/16 19:27, David Turner wrote:
> From: Nguyễn Thái Ngọc Duy
[snip]
> +
> +static void reply_to_poke(int client_fd, const char *pid_buf)
> +{
> + char *capabilities;
> + struct strbuf sb = STRBUF_INIT;
> +
> +#ifdef USE_WATCHMAN
> + pid_t client_pid = strtoull(pid_buf, NULL,
I have used Junios proposal/changes for the commit message as I
liked it and it is probably more in line with the usual commit
messages of the git project. I hope this is ok.
Let me know if you need me to do any more changes or what the
next steps are if the patch is ok.
Alexander
Alexander Rin
When running diff commands, a pathspec containing decomposed
unicode code points is not converted to precomposed unicode form
under Mac OS X, but we normalize the paths in the index and the
history to precomposed form on that platform. As a result, the
pathspec would not match and no diff is shown
On Fri, May 13, 2016 at 01:03:41PM -0700, Junio C Hamano wrote:
> > And sadly,
> >
> > git grep 'test -n [^"]'
> >
> > is not empty.
>
> Are you doing an audit? Otherwise I'm interested in taking a brief
> look.
There was only one buggy case there (in git-stash). The rest were false
positives
These variables were added in 16805d3 (t/t91XX-svn: start
removing use of "git-" from these tests, 2008-09-08) so that
running:
git grep git-
would return fewer hits. At the time, we were transitioning
away from the use of the "dashed" git-foo form.
That transition has been over for years, and
A few tests here use double-quotes around the snippets of
shell code to run the tests. None of these tests wants to do
any interpolation at all, and it just leads to an extra
layer of quoting around all double-quotes and dollar signs
inside the snippet. Let's switch to single quotes, like
most oth
One of the test snippets in t9107 is enclosed in double
quotes, but then uses single quotes to surround an
interpolated variable inside the snippet, like:
test_expect_success '...' "
test -n '$head'
"
This happens to work because the variable is interpolated
_before_ the snippet is ru
In shell code like:
test -z $foo
test -n $foo
that does not quote its arguments, it's easy to think that
it is actually looking at the contents of $foo in each case.
But if $foo is empty, then "test" does not see any argument
at all! The results are quite subtle.
POSIX specifies that test's
When a test runs a loop, it cannot rely on the usual
&&-chaining to propagate a failure inside the loop; it needs
to break out with a failure signal. However, unless you are
in a subshell, doing so with "exit 1" will exit the entire
test script, not just the test snippet we are in (and cause
the ha
The main goal here was to avoid double-quotes for
surrounding the test snippet, since it makes the code hard
to read (and to grep for common problems).
But while we're here, we can fix a few other things:
- use test_path_* helpers, which are more robust and give
better error messages
- o
On Fri, May 13, 2016 at 03:47:16PM -0400, Jeff King wrote:
> On Fri, May 13, 2016 at 02:23:25PM -0400, Jeff King wrote:
>
> > This covers all cases detected by:
> >
> > git grep 'test -z [^"]'
> >
> > (though note that has a few false positives for tests which
> > need an extra layer of quoti
From: Nguyễn Thái Ngọc Duy
Watchman is hidden behind index-helper. Before git tries to read the
index from shm, it notifies index-helper through the socket and waits
for index-helper to prepare a file for sharing memory (with
MAP_SHARED). index-helper then contacts watchman, updates 'WAMA'
extens
Hi I am using 2.8.2.windows.1 and writing Powershell scripts doing
some Git stuff.
I have to use the --quiet option for git because it constantly outputs
progress to stderr.
However, it seems that --quiet does not actually work in git push. The
output still goes to stderr.
When there are changes
Jeff King writes:
> Anyway. Here's a series that fixes the -n/-z cases, along with a bunch
> of cleanups that remove the false positives (most of which I sent out
> just a few minutes ago as "minor fixes to some svn tests").
>
> [1/6]: t/lib-git-svn: drop $remote_git_svn and $git_svn_id
> [2/
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'. The ones marked with '.' do not appear in any of
the integration branches, but I am still holding onto them.
The 'master' branch now has the el
On Fri, May 13, 2016 at 05:21:30PM -0400, Chris B wrote:
> Hi I am using 2.8.2.windows.1 and writing Powershell scripts doing
> some Git stuff.
>
> I have to use the --quiet option for git because it constantly outputs
> progress to stderr.
>
> However, it seems that --quiet does not actually wo
Jeff King wrote:
> + git diff --exit-code refs/remotes/origin/$i
> refs/remotes/origin/$j ||
> + return 1
80 columns; but I guess Junio picked it up, already.
Otherwise the rest of the series looks good. Thanks.
--
To unsubscribe from this list: s
Hin-Tak Leung wrote:
> I suppose I could keep fetching to see if I can get past that rev one day :-(.
Maybe try and see if you can create a mirror using svnsync
and go from there? Or see if you can get a closer machine to
test this on.
It could also be a bug in your particular version of svn, t
I am happy with the results of the label experiments. (Mainly writing the tests)
>> Isn't the former be "label="
> I do not know what you mean by the latter. I would understand
>"pretend this has all the labels under the sun", though.
See the new tests what I mean. It cleared up for me as well
Labels were originally designed to manage large amount of
submodules, the discussion steered this in a more general
direction, such that other files can be labeled as well.
Labels are meant to describe arbitrary set of files, which
is not described via the tree layout.
Signed-off-by: Stefan Belle
The prefix check is not related the check of pathspec magic; also there
is no code that is relevant after we'd break the loop on a match for
"prefix:". So move the check before the loop and shortcircuit the outer
loop.
Signed-off-by: Stefan Beller
---
pathspec.c | 19 ++-
1 file
`prefix_pathspec` is quite a lengthy function and we plan on adding more.
Split it up for better readability. As we want to add code into the
inner loop of the long magic parsing, we also benefit from lower
indentation.
Signed-off-by: Stefan Beller
---
pathspec.c | 84 +++
The introductory text of the example has a typo in the
specification which makes it harder to follow that example.
Signed-off-by: Stefan Beller
---
Documentation/technical/api-gitattributes.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/technical/api-gitatt
Signed-off-by: Stefan Beller
---
Documentation/gitattributes.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt
index e3b1de8..af2c682 100644
--- a/Documentation/gitattributes.txt
+++ b/Documentation/gitattribu
On Fri, May 13, 2016 at 4:47 PM, Jeff King wrote:
> When a test runs a loop, it cannot rely on the usual
> &&-chaining to propagate a failure inside the loop; it needs
> to break out with a failure signal. However, unless you are
> in a subshell, doing so with "exit 1" will exit the entire
> test
Hi all,
Subj. ...even though it's explicitly mentioned in the subcommand's man
page. Git version 2.7.4 here.
To elaborate:
- Call 'git config --global diff.algorithm histogram'.
- Try the example from http://stackoverflow.com/a/36551123/615245.
'git diff test.css' gives the expected output
On Fri, May 13, 2016 at 07:45:42PM -0400, Eric Sunshine wrote:
> > + >expect &&
>
> What's this 'expect' file for? Is it leftover gunk from before you
> settled on 'diff --exit-code'?
Oops, yes, that's exactly it.
-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
On 13.05.16 18:43, Junio C Hamano wrote:
> Adam Dinwoodie writes:
>
>> If you use .gitattributes to enable CRLF->LF rewriting, then commit a
>> file that would have its line endings rewritten, the "CRLF will be
>> replaced by LF" warning is printed several times over; I'd expect it to
>> be print
On 13.05.16 22:41, Alexander Rinass wrote:
> When running diff commands, a pathspec containing decomposed
> unicode code points is not converted to precomposed unicode form
> under Mac OS X, but we normalize the paths in the index and the
> history to precomposed form on that platform. As a resu
Hi Chris,
On Fri, 13 May 2016, Christian Couder wrote:
> On Fri, May 13, 2016 at 8:32 AM, Johannes Schindelin
> wrote:
> >
> > On Wed, 11 May 2016, Christian Couder wrote:
> >
> >> I consider that the apply functionality is properly libified before
> >> these patches, and that they should be in
91 matches
Mail list logo