Re: [PATCH 1/2] diff: document behavior of relative diff.orderFile

On Mon, Jan 09, 2017 at 07:40:30PM -0500, Richard Hansen wrote: > Document that a relative pathname for diff.orderFile is interpreted as > relative to the top-level work directory. > > Signed-off-by: Richard Hansen > --- > Documentation/diff-config.txt | 2 ++ > 1 file

Re: [PATCH v4 14/14] mergetool: fix running in subdir when rerere enabled

Am 10.01.2017 um 00:29 schrieb Richard Hansen: The pathnames output by the 'git rerere remaining' command are relative to the top-level directory but the 'git diff --name-only' command expects its pathname arguments to be relative to the current working directory. Run cd_to_toplevel before

Re: git branch -D doesn't work with deleted worktree

On Mon, Jan 9, 2017 at 2:07 AM, Duy Nguyen wrote: > On Mon, Jan 9, 2017 at 10:44 AM, Jacob Keller wrote: >> Why not just update the documentation to be "when you are done with a >> work tree you can delete it and then run git worktree prune"? > > The

Re: [PATCH 0/4] fix mergetool+rerere+subdir regression

On Tue, Jan 03, 2017 at 07:50:38PM -0500, Richard Hansen wrote: > If rerere is enabled, no pathnames are given, and mergetool is run > from a subdirectory, mergetool always prints "No files need merging". > Fix the bug. > > This regression was introduced in >

[PATCH 1/4] read-tree: use OPT_BOOL instead of OPT_SET_INT

All occurrences of OPT_SET_INT were setting the value to 1; internally OPT_BOOL is just that. Signed-off-by: Stefan Beller --- builtin/read-tree.c | 36 ++-- 1 file changed, 18 insertions(+), 18 deletions(-) diff --git a/builtin/read-tree.c

[RFC/PATCH 0/4] working tree operations: support superprefix

As you may know, I am trying to implement "git checkout --recurse-submodules" which recurses into submodules and update the submodules to the recorded state of the superproject. I realized that such a huge change is a big endeavor, and needs to be broken up into many series. Currently I plan to

[PATCH 3/4] t1001: modernize style

The preferred style in tests seems to be test_expect_success 'short description, ended by 2 single quotes' ' here comes the test && and chains over many lines && ended by a quote ' Or going by the numbers: $ git -C t/ grep "' '$" | wc -l 9796 $ git -C t/ grep

[PATCH 4/4] unpack-trees: support super-prefix option

Add support for the super-prefix option for commands that unpack trees. For testing purposes enable it in read-tree, which has no other path related output. Signed-off-by: Stefan Beller --- git.c | 2 +- t/t1001-read-tree-m-2way.sh | 9 +

[PATCH 2/4] t1000: modernize style

The preferred style in tests seems to be test_expect_success 'short description, ended by 2 single quotes' ' here comes the test && and chains over many lines && ended by a quote ' Or going by the numbers: $ git -C t/ grep "' '$" | wc -l 9796 $ git -C t/ grep

[PATCH 2/2] diff: document the pattern format for diff.orderFile

Document the format of the patterns used for the diff.orderFile setting and diff's '-O' option by referring the reader to the gitignore[5] page. Signed-off-by: Richard Hansen --- Documentation/diff-config.txt | 3 ++- Documentation/diff-options.txt | 3 ++- 2 files changed,

[PATCH 1/2] diff: document behavior of relative diff.orderFile

Document that a relative pathname for diff.orderFile is interpreted as relative to the top-level work directory. Signed-off-by: Richard Hansen --- Documentation/diff-config.txt | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/diff-config.txt

[PATCH 0/2] minor diff orderfile documentation improvements

Richard Hansen (2): diff: document behavior of relative diff.orderFile diff: document the pattern format for diff.orderFile Documentation/diff-config.txt | 5 - Documentation/diff-options.txt | 3 ++- 2 files changed, 6 insertions(+), 2 deletions(-) -- 2.11.0.390.gc69c2f50cf-goog

Re: [PATCH v3 13/13] mergetool: fix running in subdir when rerere enabled

On 2017-01-09 18:29, Junio C Hamano wrote: Junio C Hamano writes: Junio C Hamano writes: I wonder if it makes more sense to always move to toplevel upfront and consistently use path from the toplevel, perhaps like the patch s/the patch/the attached

Re: [PATCH v3 13/13] mergetool: fix running in subdir when rerere enabled

Junio C Hamano writes: > By the way, I didn't think this through, but how is the orderfile > that comes from the configuration file handled when it is not an > absolute path? I think it is _wrong_ to take it as relative to > where the user started the program. Answering my

[PATCH v4 11/14] t7610: spell 'git reset --hard' consistently

Signed-off-by: Richard Hansen --- t/t7610-mergetool.sh | 37 +++-- 1 file changed, 19 insertions(+), 18 deletions(-) diff --git a/t/t7610-mergetool.sh b/t/t7610-mergetool.sh index 54164a320..c031ecd9e 100755 --- a/t/t7610-mergetool.sh +++

[PATCH v4 08/14] t7610: delete some now-unnecessary 'git reset --hard' lines

Tests now always run 'git reset --hard' at the end (even if they fail), so it's no longer necessary to run 'git reset --hard' at the beginning of a test. Signed-off-by: Richard Hansen --- t/t7610-mergetool.sh | 2 -- 1 file changed, 2 deletions(-) diff --git

[PATCH v4 14/14] mergetool: fix running in subdir when rerere enabled

The pathnames output by the 'git rerere remaining' command are relative to the top-level directory but the 'git diff --name-only' command expects its pathname arguments to be relative to the current working directory. Run cd_to_toplevel before running 'git diff --name-only' and adjust any

[PATCH v4 12/14] t7610: add test case for rerere+mergetool+subdir bug

If rerere is enabled and mergetool is run from a subdirectory, mergetool always prints "No files need merging". Add an expected failure test case for this situation. Signed-off-by: Richard Hansen --- t/t7610-mergetool.sh | 21 - 1 file changed, 20

[PATCH v4 10/14] t7610: don't assume the checked-out commit

Always check out the required commit at the beginning of the test so that a failure in a previous test does not cause the test to work off of the wrong commit. This is a step toward making the tests more independent so that if one test fails it doesn't cause subsequent tests to fail.

[PATCH v4 03/14] t7610: update branch names to match test number

Rename the testNN branches so that NN matches the test number. This should make it easier to troubleshoot test issues. Use $test_count to keep this future-proof. Signed-off-by: Richard Hansen --- t/t7610-mergetool.sh | 82

[PATCH v4 05/14] t7610: use test_when_finished for cleanup tasks

This is a step toward making the tests more independent so that if one test fails it doesn't cause subsequent tests to fail. Signed-off-by: Richard Hansen --- t/t7610-mergetool.sh | 71 +++- 1 file changed, 37 insertions(+), 34

[PATCH v4 13/14] mergetool: take the "-O" out of $orderfile

This will make it easier for a future commit to convert a relative orderfile pathname to either absolute or relative to the top-level directory. It also improves code readability. Signed-off-by: Richard Hansen --- git-mergetool.sh | 4 ++-- 1 file changed, 2 insertions(+),

[PATCH v4 07/14] t7610: run 'git reset --hard' after each test to clean up

Use test_when_finished to run 'git reset --hard' after each test so that the repository is left in a saner state for the next test. This is a step toward making the tests more independent so that if one test fails it doesn't cause subsequent tests to fail. Signed-off-by: Richard Hansen

[PATCH v4 06/14] t7610: don't rely on state from previous test

If the repository must be in a particular state (beyond what is already done by the 'setup' test case) before the test can run, make the necessary repository changes in the test script even if it means duplicating some lines of code from the previous test case. This is a step toward making the

[PATCH v4 04/14] t7610: Move setup code to the 'setup' test case.

Multiple test cases depend on these hunks, so move them to the 'setup' test case. This is a step toward making the tests more independent so that if one test fails it doesn't cause subsequent tests to fail. Signed-off-by: Richard Hansen --- t/t7610-mergetool.sh | 65

[PATCH v4 09/14] t7610: always work on a test-specific branch

Create and use a test-specific branch when the test might create a commit. This is not always necessary for correctness, but it improves debuggability by ensuring a commit created by test #N shows up on the testN branch, not the branch for test #N-1. Signed-off-by: Richard Hansen

[PATCH v4 02/14] rev-parse doc: use "--" in the --prefix example

The "--" argument avoids "ambiguous argument: unknown revision or path not in the working tree" errors when a pathname argument refers to a non-existent file. Signed-off-by: Richard Hansen --- Documentation/git-rev-parse.txt | 3 ++- 1 file changed, 2 insertions(+), 1

[PATCH v4 00/14] fix mergetool+rerere+subdir regression

If rerere is enabled, no pathnames are given, and mergetool is run from a subdirectory, mergetool always prints "No files need merging". Fix the bug. This regression was introduced in 57937f70a09c12ef484c290865dac4066d207c9c (v2.11.0). Changes since v3: * Update rev-parse docs to use "--" in

[PATCH v4 01/14] .mailmap: Use my personal email address as my canonical

When I changed employers my work address changed from rhan...@bbn.com to hans...@google.com. Rather than map my old work address to my new, map them both to my permanent personal email address. (I will still use my work address in commits I submit so that my employer gets some credit.)

Re: [PATCH v3 13/13] mergetool: fix running in subdir when rerere enabled

Junio C Hamano writes: > Junio C Hamano writes: > >> I wonder if it makes more sense to always move to toplevel upfront >> and consistently use path from the toplevel, perhaps like the patch > > s/the patch/the attached patch/ I meant. > >> does. The first

[PATCHv8] pathspec: give better message for submodule related pathspec error

Every once in a while someone complains to the mailing list to have run into this weird assertion[1]. The usual response from the mailing list is link to old discussions[2], and acknowledging the problem stating it is known. This patch accomplishes two things: 1. Switch assert() to die("BUG")

Re: [PATCHv7] pathspec: give better message for submodule related pathspec error

On Mon, Jan 9, 2017 at 2:53 PM, Junio C Hamano wrote: > Is it only me who sees funny black rectangles in front of these four > lines instead of blanks, by the way? I copied this part literally from Jeff. My mail display-client (gmail at the time) did mangle it apparently, (it

Re: [PATCH v3 00/38] Teach the sequencer to act as rebase -i's backend

Junio C Hamano writes: > I ran out of time for the day and haven't looked at individual > patches yet. I may find other issues, but from the interdiff, that > was the only thing that I found even worse than the previous round, > and everything else was either the same or has

Re: [PATCH v3 13/13] mergetool: fix running in subdir when rerere enabled

On 2017-01-09 14:05, Junio C Hamano wrote: Junio C Hamano writes: I wonder if it makes more sense to always move to toplevel upfront and consistently use path from the toplevel, perhaps like the patch s/the patch/the attached patch/ I meant. does. The first hunk is

Re: [PATCHv7] pathspec: give better message for submodule related pathspec error

Stefan Beller writes: > Every once in a while someone complains to the mailing list to have > run into this weird assertion[1]. The usual response from the mailing > list is link to old discussions[2], and acknowledging the problem > stating it is known. > > This patch

[PATCHv7] pathspec: give better message for submodule related pathspec error

Every once in a while someone complains to the mailing list to have run into this weird assertion[1]. The usual response from the mailing list is link to old discussions[2], and acknowledging the problem stating it is known. This patch accomplishes two things: 1. Switch assert() to die("BUG")

Re: [PATCH v3 00/38] Teach the sequencer to act as rebase -i's backend

Johannes Schindelin writes: > Changes since v2: > > - fixed a TRANSLATORS: comment > ... > - replaced a spawned `diff-tree` command by code using the diff functions > directly I just finished skimming the interdiff (the difference between the result of merging the

Re: [PATCH 00/13] gitk: tweak rendering of remote-tracking references

On 2016-12-22 03:15 AM, Michael Haggerty wrote: On 12/21/2016 08:07 PM, Marc Branchaud wrote: On 2016-12-20 07:05 PM, Michael Haggerty wrote: On 12/20/2016 04:01 PM, Marc Branchaud wrote: [...] Please don't change the remotebgcolor default. Also, perhaps the default remoterefbgcolor should

Re: [PATCH 3/3] blame: output porcelain "previous" header for each file

Jeff King writes: > /* > + * Write out any suspect information which depends on the path. This must be > + * handled separately from emit_one_suspect_detail(), because a given commit > + * may have changes in multiple paths. So this needs to appear each time > + * we mention a

Re: Test failures when Git is built with libpcre and grep is built without it

On Mon, Jan 09, 2017 at 02:05:44PM +0100, Andreas Schwab wrote: > On Jan 09 2017, "A. Wilcox" wrote: > > > Interestingly enough, you seem to be right. The failure is very > > bizarre and has nothing to do with system /bin/grep: > > > > test_must_fail: command

Re: Rebasing a branch with merges

From: "Robert Dailey" On Fri, Jan 6, 2017 at 3:28 PM, Philip Oakley wrote: From: "Robert Dailey" Here's the scenario: I create a topic branch so one other developer and myself can work on a feature that takes 2

Re: RFC: Enable delayed responses to Git clean/smudge filter requests

On Mon, Nov 14, 2016 at 1:09 PM, Lars Schneider wrote: > Hi, > > Git always performs a clean/smudge filter on files in sequential order. > Sometimes a filter operation can take a noticeable amount of time. > This blocks the entire Git process. > > I would like to give a

Re: [PATCHv6 1/2] submodule tests: don't use itself as a submodule

On Sun, Jan 8, 2017 at 6:33 PM, Junio C Hamano wrote: > Stefan Beller writes: > >> This provides an easier way to have submodules in tests, by just setting >> TEST_CREATE_SUBMODULE to a non empty string, similar to >> TEST_NO_CREATE_REPO. > > Yuck. > > I

Re: [PATCHv6 2/2] pathspec: give better message for submodule related pathspec error

On Sun, Jan 8, 2017 at 6:39 PM, Junio C Hamano wrote: > For future reference, do not bury a useful fix behind unproven new > things. The main purpose of this two-patch series is this change, > and it does not have to wait for the change to allow test_commit to > notice "-C"

Re: [PATCH] Makefile: POSIX windres

Am 09.01.2017 um 09:09 schrieb Johannes Schindelin: Hi Junio, On Sun, 8 Jan 2017, Junio C Hamano wrote: Steven Penny writes: When environment variable POSIXLY_CORRECT is set, the "input -o output" syntax is not supported.

Re: [PATCH v3 13/13] mergetool: fix running in subdir when rerere enabled

Am 09.01.2017 um 20:05 schrieb Junio C Hamano: Junio C Hamano writes: I wonder if it makes more sense to always move to toplevel upfront and consistently use path from the toplevel, perhaps like the patch s/the patch/the attached patch/ I meant. does. The first hunk is

[PATCHv2 0/5] refactor unpack-trees

v2: * Fixed the return type to be unsigned in patch 4. This replaces origin/rs/unpack-trees-reduce-file-scope-global, the first patch has the following diff to that branch diff --git a/unpack-trees.c b/unpack-trees.c index edf9fa2f6c..8e6768f283 100644 --- a/unpack-trees.c +++ b/unpack-trees.c

[PATCHv2 4/5] unpack-trees: factor file removal out of check_updates

This makes check_updates shorter and easier to understand. Signed-off-by: Stefan Beller --- unpack-trees.c | 29 + 1 file changed, 21 insertions(+), 8 deletions(-) diff --git a/unpack-trees.c b/unpack-trees.c index b564024472..ac59510251 100644

[PATCHv2 1/5] unpack-trees: move checkout state into check_updates

The checkout state was introduced via 16da134b1f9 (read-trees: refactor the unpack_trees() part, 2006-07-30). An attempt to refactor the checkout state was done in b56aa5b268e (unpack-trees: pass checkout state explicitly to check_updates(), 2016-09-13), but we can go even further. The `struct

[PATCHv2 3/5] unpack-trees: factor progress setup out of check_updates

This makes check_updates shorter and easier to understand. Signed-off-by: Stefan Beller --- unpack-trees.c | 32 1 file changed, 20 insertions(+), 12 deletions(-) diff --git a/unpack-trees.c b/unpack-trees.c index d443decb23..b564024472

[PATCHv2 2/5] unpack-trees: remove unneeded continue

The continue is the last statement in the loop, so not needed. This situation arose in 700e66d66 (2010-07-30, unpack-trees: let read-tree -u remove index entries outside sparse area) when statements after the continue were removed. Signed-off-by: Stefan Beller ---

[PATCHv2 5/5] unpack-trees: factor working tree update out of check_updates

This makes check_updates shorter and easier to understand. Signed-off-by: Stefan Beller --- unpack-trees.c | 40 ++-- 1 file changed, 26 insertions(+), 14 deletions(-) diff --git a/unpack-trees.c b/unpack-trees.c index

Re: [PATCH 4/5] unpack-trees: factor file removal out of check_updates

On Fri, Jan 6, 2017 at 5:36 PM, Jeff King wrote: >> +static int remove_workingtree_files(struct unpack_trees_options *o, >> + unsigned cnt = 0; > > "cnt" is unsigned here, as it is in the caller. Should the return value > match? Yes, obviously. :/ Thanks for catching,

Re: [PATCH v5 0/5] road to reentrant real_path

Brandon Williams writes: > On 01/09, Junio C Hamano wrote: >> Brandon Williams writes: >> >> >> How does this relate to the 5-patch real_path: series that has been >> >> on 'next' since last year? >> > >> > The only difference should be in the first patch

Re: [PATCH v4 1/4] Avoid Coverity warning about unfree()d git_exec_path()

On Sun, Jan 8, 2017 at 5:25 PM, Junio C Hamano wrote: > So with the above, are you saying "Dscho said 'hopefully', and I > confirm that this change does squelch misdiagnosis by Coverity"? I could not find the coverity issue any more. (It really misses easy access to "recently

Re: [PATCH v3 13/13] mergetool: fix running in subdir when rerere enabled

Junio C Hamano writes: > I wonder if it makes more sense to always move to toplevel upfront > and consistently use path from the toplevel, perhaps like the patch s/the patch/the attached patch/ I meant. > does. The first hunk is what you wrote but only inside MERGE_RR >

Re: Rebasing a branch with merges

On Fri, Jan 6, 2017 at 3:28 PM, Philip Oakley wrote: > From: "Robert Dailey" >> >> Here's the scenario: >> >> I create a topic branch so one other developer and myself can work on >> a feature that takes 2 weeks to complete. During that 2 week

[PATCH 2/2] real_path: set errno when max number of symlinks is exceeded

Set errno to ELOOP when the maximum number of symlinks is exceeded, as would be done by other symlink-resolving functions. Signed-off-by: Brandon Williams --- abspath.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/abspath.c b/abspath.c index 0393213e5..fce40fddc

[PATCH 1/2] real_path: prevent redefinition of MAXSYMLINKS

The macro 'MAXSYMLINKS' is already defined on macOS and Linux in . If 'MAXSYMLINKS' has already been defined, use the value defined by the OS otherwise default to a value of 32 which is more inline with what is allowed by many systems. Signed-off-by: Brandon Williams ---

Re: [PATCH v3 00/13] fix mergetool+rerere+subdir regression

On Sun, Jan 8, 2017 at 9:42 PM, Richard Hansen wrote: > If rerere is enabled, no pathnames are given, and mergetool is run > from a subdirectory, mergetool always prints "No files need merging". > Fix the bug. > > This regression was introduced in >

Re: [PATCH v5 0/5] road to reentrant real_path

On 01/09, Junio C Hamano wrote: > Brandon Williams writes: > > >> How does this relate to the 5-patch real_path: series that has been > >> on 'next' since last year? > > > > The only difference should be in the first patch of the series which > > handles the #define a bit

Re: [PATCH v5 0/5] road to reentrant real_path

Brandon Williams writes: >> How does this relate to the 5-patch real_path: series that has been >> on 'next' since last year? > > The only difference should be in the first patch of the series which > handles the #define a bit differently due to the discussion that > happened

Re: [PATCH v3 13/13] mergetool: fix running in subdir when rerere enabled

Richard Hansen writes: > If rerere is enabled and no pathnames are given, run cd_to_toplevel > before running 'git diff --name-only' so that 'git diff --name-only' > sees the files named by 'git rerere remaining', which outputs > pathnames relative to the top-level directory.

Re: [PATCH v5 0/5] road to reentrant real_path

On 01/07, Junio C Hamano wrote: > Brandon Williams writes: > > > changes in v5: > > * set errno to ELOOP when MAXSYMLINKS is exceded. > > * revert to use MAXSYMLINKS instead of MAXDEPTH. > > * If the OS hasn't defined MAXSYMLINKS, use a fallback value of 32. > > > > Brandon

Re: [PATCH v5 00/16] pathspec cleanup

On 01/07, Duy Nguyen wrote: > On Thu, Jan 5, 2017 at 1:03 AM, Brandon Williams wrote: > > Changes in v5: > > * Move GUARD_PATHSPEC to prevent checking if pathspec is null twice. > > * Mark a string containing 'mnemonic' for translation. > > Argh.. I've run out of things to

Re: [PATCH 0/6] git worktree move/remove

Nguyễn Thái Ngọc Duy writes: > This version is the same as nd/worktree-move but with the recursive > directory copy code removed. We rely on rename() to move directories. Much simpler ;-) Will replace; thanks. > Nguyễn Thái Ngọc Duy (6): > worktree.c: add

Re: [PATCH v4] log --graph: customize the graph lines with config log.graphColors

Nguyễn Thái Ngọc Duy writes: > + end = string + strlen(string); > + while (start < end) { > + const char *comma = strchrnul(start, ','); > + char color[COLOR_MAXLEN]; > + > + while (start < comma && isspace(*start)) > +

Re: Preserve/Prune Old Pack Files

On Monday, January 09, 2017 01:21:37 AM Jeff King wrote: > On Wed, Jan 04, 2017 at 09:11:55AM -0700, Martin Fick wrote: > > I am replying to this email across lists because I > > wanted to highlight to the git community this jgit > > change to repacking that we have up for review > > > >

Re: Preserve/Prune Old Pack Files

On Monday, January 09, 2017 05:55:45 AM Jeff King wrote: > On Mon, Jan 09, 2017 at 04:01:19PM +0900, Mike Hommey wrote: > > > That's _way_ more complicated than your problem, and > > > as I said, I do not have a finished solution. But it > > > seems like they touch on a similar concept (a > > >

Re: Refreshing index timestamps without reading content

On Mon, Jan 09, 2017 at 07:01:36AM -0800, Junio C Hamano wrote: > Duy Nguyen writes: > > > On Thu, Jan 5, 2017 at 6:23 PM, Quentin Casasnovas > > wrote: > >> Is there any way to tell git, after the git ls-tree command above, to > >> refresh its

Re: What's cooking in git.git (preview)

Johannes Schindelin writes: > Hi Junio, > > On Sun, 8 Jan 2017, Junio C Hamano wrote: > >> * js/difftool-builtin (2017-01-08) 4 commits >> - t7800: run both builtin and scripted difftool, for now >> - difftool: implement the functionality in the builtin >> -

Re: Refreshing index timestamps without reading content

Duy Nguyen writes: > On Thu, Jan 5, 2017 at 6:23 PM, Quentin Casasnovas > wrote: >> Is there any way to tell git, after the git ls-tree command above, to >> refresh its stat cache information and trust us that the file content has >> not

Re: [PATCH] Makefile: put LIBS after LDFLAGS for imap-send

Junio C Hamano writes: > Johannes Schindelin writes: > >> In any case, it does not break things, and it helps Cygwin, so: ACK >> >> Ciao, >> Dscho >> >> P.S.: I pushed this to Git for Windows' `master`, too: >>

Re: [PATCH v3 14/21] read-cache: touch shared index files when used

Duy Nguyen writes: > On Sun, Jan 8, 2017 at 4:46 AM, Junio C Hamano wrote: >> Christian Couder writes: >> >>> So what should we do if freshen_file() returns 0 which means that the >>> freshening failed? >> >> You tell me ;-) as

Re: [PATCH] Makefile: put LIBS after LDFLAGS for imap-send

Johannes Schindelin writes: > In any case, it does not break things, and it helps Cygwin, so: ACK > > Ciao, > Dscho > > P.S.: I pushed this to Git for Windows' `master`, too: > https://github.com/git-for-windows/git/commit/f05a26948b Hmm, I peeked it hoping that you

Re: [PATCH] connect: handle putty/plink also in GIT_SSH_COMMAND

Johannes Schindelin writes: >> > But do we really need to do that? >> >> No. > > Exactly. > But since you seem to convinced that a future bug report like this may > happen (I am not, and it contradicts my conviction that one should cross a > bridge only when

Re: [PATCH v3] log --graph: customize the graph lines with config log.graphColors

Duy Nguyen writes: > On Mon, Jan 9, 2017 at 12:30 PM, Jeff King wrote: >> I also wonder if it is worth just using argv_array. We do not care about >> ... >> It is not much shorter than ALLOC_GROW(), but IMHO it is easier to read. > > Indeed. My only complaint

Re: [PATCH] Makefile: put LIBS after LDFLAGS for imap-send

Johannes Schindelin writes: > ... > It is a bit curious that -lws2_32 *does* only show up in $(LIBS), but I > guess it is simply the fact that we use a newer GCC (gcc.exe (Rev2, Built > by MSYS2 project) 6.2.0) that allows Git for Windows to be built even > without

Hello

Please can i have your attention? I am anessa Coley. I have something to discuss with you. I hope to hear from you. With love Anessa

Re: Test failures when Git is built with libpcre and grep is built without it

On Jan 09 2017, "A. Wilcox" wrote: > Interestingly enough, you seem to be right. The failure is very > bizarre and has nothing to do with system /bin/grep: > > test_must_fail: command succeeded: git grep -G -F -P -E a\x{2b}b\x{2a}c ab > not ok 142 - grep -G -F -P -E

Re: [RFC PATCH 0/5] Localise error headers

Jeff King venit, vidit, dixit 04.01.2017 08:05: > On Mon, Jan 02, 2017 at 12:14:49PM +0100, Michael J Gruber wrote: > >> Currently, the headers "error: ", "warning: " etc. - generated by die(), >> warning() etc. - are not localized, but we feed many localized error messages >> into these

Re: Refreshing index timestamps without reading content

On Mon, Jan 09, 2017 at 01:17:24PM +0100, Quentin Casasnovas wrote: > On Mon, Jan 09, 2017 at 07:02:45PM +0700, Duy Nguyen wrote: > > On Thu, Jan 5, 2017 at 6:23 PM, Quentin Casasnovas > > wrote: > > > > > If not, I am willing to implement a

Re: Refreshing index timestamps without reading content

On Mon, Jan 09, 2017 at 07:02:45PM +0700, Duy Nguyen wrote: > On Thu, Jan 5, 2017 at 6:23 PM, Quentin Casasnovas > wrote: > > > If not, I am willing to implement a --assume-content-unchanged to the git > > update-index if you guys don't see something fundamentally

Re: Refreshing index timestamps without reading content

On Thu, Jan 5, 2017 at 6:23 PM, Quentin Casasnovas wrote: > Hi guys, > > Apologies if this is documented somewhere, I have fairly bad search vudu > skills. > > I'm looking for a way to cause a full refresh of the index without causing > any read of the files,

Re: Test failures when Git is built with libpcre and grep is built without it

On Mon, Jan 09, 2017 at 04:51:22AM -0600, A. Wilcox wrote: > Interestingly enough, you seem to be right. The failure is very > bizarre and has nothing to do with system /bin/grep: > > test_must_fail: command succeeded: git grep -G -F -P -E a\x{2b}b\x{2a}c ab > not ok 142 - grep -G -F -P -E

Re: What's cooking in git.git (preview)

Hi Junio, On Sun, 8 Jan 2017, Junio C Hamano wrote: > * js/difftool-builtin (2017-01-08) 4 commits > - t7800: run both builtin and scripted difftool, for now > - difftool: implement the functionality in the builtin > - difftool: add a skeleton for the upcoming builtin > - git_exec_path:

Re: [PATCH v3 08/21] Documentation/git-update-index: talk about core.splitIndex config var

On Sun, Jan 8, 2017 at 4:38 AM, Junio C Hamano wrote: > Christian Couder writes: > >> It feels strange that when I do things one way, you suggest another >> way, and the next time in a similar situation when I do things the way >> you suggested

Re: [PATCH] connect: handle putty/plink also in GIT_SSH_COMMAND

Hi Junio, On Mon, 9 Jan 2017, Junio C Hamano wrote: > Johannes Schindelin writes: > > > If you feel strongly about your contrived examples possibly being > > affected by this patch, we could easily make this conditional on > > > > 1) no '&&' or '||' being found on

Re: [PATCH v3 14/21] read-cache: touch shared index files when used

On Sun, Jan 8, 2017 at 4:46 AM, Junio C Hamano wrote: > Christian Couder writes: > >> So what should we do if freshen_file() returns 0 which means that the >> freshening failed? > > You tell me ;-) as you are the one who is proposing this feature.

Re: Preserve/Prune Old Pack Files

On Mon, Jan 09, 2017 at 04:01:19PM +0900, Mike Hommey wrote: > > That's _way_ more complicated than your problem, and as I said, I do not > > have a finished solution. But it seems like they touch on a similar > > concept (a post-delete holding area for objects). So I thought I'd > > mention it

Re: Test failures when Git is built with libpcre and grep is built without it

On 02/01/17 00:53, Jeff King wrote: > On Sat, Dec 31, 2016 at 10:59:11PM -0600, A. Wilcox wrote: > >> I'm attempting to package Git for our new Linux distribution and >> I have run in to a failure on our PowerPC builder while running >> the test suite. >> >> The PowerPC builder runs a tiny

Re: [PATCH] Makefile: put LIBS after LDFLAGS for imap-send

Hi Junio, On Sun, 8 Jan 2017, Junio C Hamano wrote: > Johannes Schindelin writes: > > > On Sun, 8 Jan 2017, Steven Penny wrote: > > > >> On Sun, Jan 8, 2017 at 5:54 AM, Johannes Schindelin wrote: > >> > I am curious: how do you build Git? I ask because I build Git

[PATCH v4] log --graph: customize the graph lines with config log.graphColors

If you have a 256 colors terminal (or one with true color support), then the predefined 12 colors seem limited. On the other hand, you don't want to draw graph lines with every single color in this mode because the two colors could look extremely similar. This option allows you to hand pick the

Re: [PATCH] branch_get_push: do not segfault when HEAD is detached

Jeff King writes: > On Fri, Jan 06, 2017 at 08:19:53PM -0500, Kyle Meyer wrote: > >> > The other option is just "git checkout --detach", which is also used in >> > the test suite. I tend to prefer it because it's a little more obvious >> > to a reader. >> >> True, that does seem

Re: [PATCH v3] log --graph: customize the graph lines with config log.graphColors

On Mon, Jan 9, 2017 at 12:30 PM, Jeff King wrote: > I also wonder if it is worth just using argv_array. We do not care about > NULL-terminating the list here, but it actually works pretty well as a > generic string-array class (and keeping a NULL at the end of any >

Re: git branch -D doesn't work with deleted worktree

On Mon, Jan 9, 2017 at 10:44 AM, Jacob Keller wrote: > Why not just update the documentation to be "when you are done with a > work tree you can delete it and then run git worktree prune"? The document does say that (a bit verbose though): When you are done with a linked

Re: [PATCH v3] log --graph: customize the graph lines with config log.graphColors

On Mon, Jan 9, 2017 at 12:34 PM, Jeff King wrote: >> +test_expect_success 'log --graph with merge with log.graphColors' ' >> + test_config log.graphColors " blue , cyan , red " && > > This funny syntax isn't required, right? It should work with the more > natural: > >

Re: [PATCH v4 2/2] t9813: avoid using pipes

Luke Diamand writes: > On 8 January 2017 at 16:55, Pranit Bauva wrote: >> The exit code of the upstream in a pipe is ignored thus we should avoid >> using it. By writing out the output of the git command to a file, we can >> test the exit codes of both

Re: [PATCH] Makefile: POSIX windres

Johannes Schindelin writes: >> Who other than cygwin build uses this target? Git for Windows? > > Yes, Git for Windows uses this target, as did msysGit (and I suspect > Hannes' setup). > ... > So: ACK Thanks.

Re: [PATCH v4 4/4] t7800: run both builtin and scripted difftool, for now

Johannes Schindelin writes: > And the most important point is that we do all of this only during a > hopefully brief period in time that is mostly spent on reviewing the code > and finding serious bugs and fixing them. You seem to misunderstand the purpose of the

  1   2   >