Re: [PATCH v2] diff: run arguments through precompose_argv

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

Re: Bug report: Duplicate CRLF rewrite warnings on commit

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

Re: [PATCH 3/6] t9107: use "return 1" instead of "exit 1"

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

Re: [PATCH 3/6] t9107: use "return 1" instead of "exit 1"

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

'git diff-index' doesn't honor the 'diff.algorithm' variable

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

[PATCH 2/5] Documentation: correct typo in example for querying attributes

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

[PATCH 1/5] Documentation: fix a typo

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 +++

[PATCH 5/5] pathspec: record labels

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

[PATCH 4/5] pathspec: move prefix check out of the inner loop

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

[PATCH 3/5] pathspec: move long magic parsing out of prefix_pathspec

`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

[PATCHv2 0/5] pathspec labels [WAS: submodule groups]

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

Re: git svn clone cannot go beyond a specific rev on codeplex

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

Re: [PATCH 3/6] t9107: use "return 1" instead of "exit 1"

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

Re: git push --quiet option does not seem to work

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

What's cooking in git.git (May 2016, #05; Fri, 13)

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

Re: [PATCH 0/6] test -z/-n quoting fix + misc cleanups

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 push --quiet option does not seem to work

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

[PATCH v10 ter] index-helper: use watchman to avoid refreshing index with lstat()

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,

Re: [PATCH 0/3] minor fixes to some svn tests

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

[PATCH 4/6] t9107: switch inverted single/double quotes in test

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

[PATCH 6/6] always quote shell arguments to test -z/-n

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

[PATCH 3/6] t9107: use "return 1" instead of "exit 1"

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

[PATCH 5/6] t9103: modernize test style

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 -

[PATCH 1/6] t/lib-git-svn: drop $remote_git_svn and $git_svn_id

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,

[PATCH 2/6] t9100,t3419: enclose all test code in single-quotes

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

[PATCH 0/6] test -z/-n quoting fix + misc cleanups

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

[PATCH v2] diff: run arguments through precompose_argv

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

[PATCH v2] diff: run arguments through precompose_argv

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

Re: [PATCH] index-helper: use watchman to avoid refreshing index with lstat()

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 =

Re: [PATCH 2/2] bisect--helper: `bisect_voc` shell function in C

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

[PATCH 2/2] bisect--helper: `bisect_voc` shell function in C

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

[PATCH 1/2] bisect--helper: `bisect_log` shell function in C

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

Re: t3404 static check of bad SHA-1 failure

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,

Re: t3404 static check of bad SHA-1 failure

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

Re: t3404 static check of bad SHA-1 failure

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

Re: Bug report: Duplicate CRLF rewrite warnings on commit

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

Re: t3404 static check of bad SHA-1 failure

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

[PATCH 3/3] t9107: use "return 1" instead of "exit 1"

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

[PATCH 2/3] t9100: enclose all test code in single-quotes

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

[PATCH 1/3] t/lib-git-svn: drop $remote_git_svn and $git_svn_id

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,

[PATCH 0/3] minor fixes to some svn tests

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

Re: Bug report: Duplicate CRLF rewrite warnings on commit

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

Re: [PATCH v2 48/94] builtin/apply: rename 'prefix_' parameter to 'prefix'

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

Re: [PATCH v2 48/94] builtin/apply: rename 'prefix_' parameter to 'prefix'

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

Re: [PATCH v2 00/94] libify apply and use lib in am

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,

Re: git svn clone cannot go beyond a specific rev on codeplex

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

[PATCH] index-helper: use watchman to avoid refreshing index with lstat()

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,

Re: t3404 static check of bad SHA-1 failure

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

gitk bug? Tree view doesn't show all contents in non-top-level directory

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 $

Re: Improve initial setup of submodules

+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

Re: Bug report: Duplicate CRLF rewrite warnings on commit

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

Re: [PATCH v6 2/3] bisect: rewrite `check_term_format` shell function in C

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

Re: [PATCH v2 0/2] Work on t3404 in preparation for rebase--helper

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

Re: [PATCH v10 11/20] index-helper: use watchman to avoid refreshing index with lstat()

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

Improve initial setup of submodules

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

Re: git svn clone cannot go beyond a specific rev on codeplex

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` $

[PATCH] git-multimail: update to release 1.3.1

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

Re: [PATCH 3/5] worktree.c: add is_worktree_locked()

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

Re: Empty config sections are neither deleted nor reused

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

Re: Bug report: Duplicate CRLF rewrite warnings on commit

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

Re: [PATCH 2/5] worktree.c: add is_main_worktree()

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

Re: [BUG] t9801 and t9803 broken on next

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

Re: [PATCH 1/5] worktree.c: add find_worktree_by_path()

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

t3404 static check of bad SHA-1 failure

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 ---

Empty config sections are neither deleted nor reused

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]

Bug report: Duplicate CRLF rewrite warnings on commit

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

[PATCH v3 1/3] perf: let's disable symlinks when they are not available

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

[PATCH v3 0/3] Introduce a perf test for interactive rebase

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

[PATCH v3 3/3] Add a perf test for rebase -i

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

[PATCH v3 2/3] perf: make the tests work in worktrees

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,

Re: [PATCH v2 3/3] Add a perf test for rebase -i

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 > > +++

Re: [PATCH v2 2/3] perf: make the tests work in worktrees

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 >

Re: [PATCH v3 29/33] refs: resolve symbolic refs first

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. */ > +

Re: [PATCH v2 29/33] refs: resolve symbolic refs first

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,

[PATCH v3 29/33] refs: resolve symbolic refs first

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

Re: [PATCH v2 29/33] refs: resolve symbolic refs first

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

Re: bug report

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

Re: What's cooking in git.git (May 2016, #02; Fri, 6)

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

Re: possible problem / bug

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.

[PATCH] git-gui: Remove ancient Cygwin compatibility code

>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

Re: [BUG] t9801 and t9803 broken on next

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

Re: git svn clone cannot go beyond a specific rev on codeplex

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

[PATCH] t6030: explicitly test for bisection cleanup

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

[BUG] t9801 and t9803 broken on next

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

[PATCH] Documentation: clarify signature verification

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

Re: bug report

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...

Re: bug report

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)

Re: bug report

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

Re: [PATCH v6 2/3] bisect: rewrite `check_term_format` shell function in C

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 >> + *

Re: bug report

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 that I didn't need the method actually, so I deleted it. My

Re: [PATCH v2 0/2] Work on t3404 in preparation for rebase--helper

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 easier for you, and now that I have a

Re: bug report

On Fri, May 13, 2016 at 11:28 AM, 李本超 wrote: > git version 2.6.4 (Apple Git-63) > system version: OS X EI Capitan 10.11.4 > > below is the steps: > $ mkdir test_repo > $ cd test_repo > $ git init > $ echo "hello" > README.md > $ git commit -a -m 'Add README.md' It was my

Re: [PATCH v2 00/94] libify apply and use lib in am

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 the libified apply in "git am" unmasks the fact that > "git am", since it was a

Re: [PATCH 4/4] pathspec: record labels

Stefan Beller writes: > Would it make sense to mark a file as > > "follows the labeling system, but has no label" (TRUE) > "doesn't follow the labeling system at all" (FALSE) Isn't the former be "label=" I do not know what you mean by the latter. I would understand

Re: [PATCH v4 2/2] travis-ci: build documentation

> On 10 May 2016, at 19:12, Junio C Hamano wrote: > > larsxschnei...@gmail.com writes: > >> From: Lars Schneider >> >> Build documentation as separate Travis CI job to check for >> documentation errors. >> >> Signed-off-by: Lars Schneider