Re: [PATCH v3 0/3] Introduce log.showSignature config variable

On Thu, Jun 23, 2016 at 2:01 AM, Junio C Hamano wrote: > Mehul Jain writes: > >> Add a new configuratation variable "log.showSignature" for git-log >> and related commands. "log.showSignature=true" will enable user to >> see GPG signature by default

Re: Use docker for _some_ testing?

On Wed, Jun 22, 2016 at 9:59 PM, Jeff King wrote: > On Wed, Jun 22, 2016 at 09:01:55PM +0200, Duy Nguyen wrote: > >> Which makes me think, could we use something like this to make sure >> people (on Linux) can test more obscure cases? Sometimes there are >> featues that require

Re: [PATCH] pathspec: warn on empty strings as pathspec

Awesome. Thanks, Junio---this is exciting! As for step 2: do you have a good sense on the timing? Around how long should I wait to submit the patch for it? Otherwise, let me know if there is anything else that I need to do! - Emily -- To unsubscribe from this list: send the line "unsubscribe

Re: [PATCH] pathspec: warn on empty strings as pathspec

Emily Xie writes: > The fix for this issue requires a two-step approach. As > there may be existing scripts that knowingly use empty > strings in this manner, the first step simply invokes a > warning that (1) declares using empty strings to > match all paths will become

Re: Fast-forward able commit, otherwise fail

Junio C Hamano writes: > However, Git as a tool is not opinionated strongly enough to make it > hard to do these two things (independently). I do not think it is > unreasonable to add a new mode of "merge" that rejects a resulting > history that is not shaped the way you

Re: [PATCH v3] Refactor recv_sideband()

On Wed, 22 Jun 2016, Nicolas Pitre wrote: > On Wed, 22 Jun 2016, Lukas Fleischer wrote: > > > Before this patch, we used character buffer manipulations to split > > messages from the sideband at line breaks and insert "remote: " at the > > beginning of each line, using the packet size to

[PATCH] pathspec: warn on empty strings as pathspec

Currently, passing an empty string as a pathspec results in a match on all paths. This is because a pathspec match is a leading substring match that honors directory boundaries. So, just as pathspec "dir/" (or "dir") matches "dir/file", "" matches "file". However, this causes problems. Namely, a

Re: may be bug in svn fetch no-follow-parent

Александр Овчинников wrote: > Unfortunately this is not open source repository. I agree that it is > pointless try to handle mergeinfo (because it always fails). > Cases when it is expensive: > 1. delete and restore mergeinfo property > 2. merge trunk to very old branch > 3.

Re: [PATCH v4 8/8] use smudgeToFile filter in recursive merge

Junio C Hamano writes: >> +int smudge_to_file = can_smudge_to_file(path); > > This does not compile with decl-after-statement. I suspect other > patches in this series have the same issue but I did not check. Do > you say "make DEVELOPER=1"? As a

Re: [PATCH] doc: git-htmldocs.googlecode.com is no more

Junio C Hamano wrote: > On Wed, Jun 22, 2016 at 12:00 PM, Eric Wong wrote: > > > > Just wondering, who updates > > https://kernel.org/pub/software/scm/git/docs/ > > and why hasn't it been updated in a while? > > (currently it says Last updated 2015-06-06 at the

Re: [PATCH v4 8/8] use smudgeToFile filter in recursive merge

Joey Hess writes: > @@ -781,6 +773,7 @@ static void update_file_flags(struct merge_options *o, > } > if (S_ISREG(mode) || (!has_symlinks && S_ISLNK(mode))) { > int fd; > + int isreg = S_ISREG(mode); You

Re: [PATCH 1/1] mingw: work around t2300's assuming non-Windows paths

Hi Junio, On Wed, 22 Jun 2016, Junio C Hamano wrote: > Junio C Hamano writes: > > > I think I know that well enough; please sanity check. My > > understanding is: > > ... > > The patch under discussion is the only door left for that test, and > > a similar trickery is

Re: [PATCH v4 0/8] extend smudge/clean filters with direct file access (for pu)

Joey Hess writes: > This is the same as v3, except rebased on top of tb/convert-peek-in-index > to fix a build failure in pu. This is somewhat unfortunate, as tb/convert-peek-in-index probably needs further rerolls after getting reviewed by somebody (other than me) and this

[PATCH v4 3/8] use cleanFromFile in git add

Includes test cases. Signed-off-by: Joey Hess --- sha1_file.c | 44 ++-- t/t0021-conversion.sh | 36 2 files changed, 74 insertions(+), 6 deletions(-) diff --git a/sha1_file.c b/sha1_file.c

[PATCH v4 2/8] add smudgeToFile and cleanFromFile filter configs

This adds new smudgeToFile and cleanFromFile filter commands, which are similar to smudge and clean but allow direct access to files on disk. This interface can be much more efficient when operating on large files, because the whole file content does not need to be streamed through the filter. It

Re: What's cooking in git.git (Jun 2016, #05; Thu, 16)

Torsten Bögershausen wrote: > There is a conflict in pu: > "jh/clean-smudge-annex" does not work together with "tb/convert-peek-in-index" > > (And currently pu didn't compile) I'm sending a v4 of jh/clean-smudge-annex that is rebased on top of tb/convert-peek-in-index to fix this. > (I will

[PATCH v4 7/8] use smudgeToFile filter in git am

git am updates the work tree and so should use the smudgeToFile filter. This includes some refactoring into convert_to_working_tree_filter_to_file to make it check the file after running the smudgeToFile command, and clean up from a failing command. Signed-off-by: Joey Hess

[PATCH v4 5/8] warn on unusable smudgeToFile/cleanFromFile config

Let the user know when they have a smudgeToFile/cleanFromFile config that cannot be used because the corresponding smudge/clean config is missing. The warning is only displayed a maximum of once per git invocation, and only when doing an operation that would use the filter. Signed-off-by: Joey

[PATCH v4 8/8] use smudgeToFile filter in recursive merge

Recursive merge updates the work tree and so should use the smudgeToFile filter. At this point, smudgeToFile is run by everything that updates work tree files. Signed-off-by: Joey Hess --- merge-recursive.c | 42 --

[PATCH v4 6/8] better recovery from failure of smudgeToFile filter

If the smudgeToFile filter fails, it can leave the worktree file with the wrong content, or even deleted. Recover from this by falling back to running the smudge filter. Signed-off-by: Joey Hess --- entry.c | 55 ---

[PATCH v4 1/8] clarify %f documentation

It's natural to expect %f to be an actual file on disk; help avoid that mistake. Signed-off-by: Joey Hess --- Documentation/gitattributes.txt | 5 + 1 file changed, 5 insertions(+) diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt index

[PATCH v4 0/8] extend smudge/clean filters with direct file access (for pu)

This is the same as v3, except rebased on top of tb/convert-peek-in-index to fix a build failure in pu. Joey Hess (8): clarify %f documentation add smudgeToFile and cleanFromFile filter configs use cleanFromFile in git add use smudgeToFile in git checkout etc warn on unusable

[PATCH v4 4/8] use smudgeToFile in git checkout etc

This makes git checkout, git reset, etc use smudgeToFile. Includes test cases. (There's a call to convert_to_working_tree in merge-recursive.c that could also be made to use smudgeToFile as well.) Signed-off-by: Joey Hess --- entry.c | 37

Re: [PATCH 1/2] t/perf: fix regression in testing older versions of git

Jeff King writes: >> I can see how this works for "git -C ... rev-parse ..." or any other >> built-in commands, but I am not sure if this is sufficient when any >> non-built-in command is used in the perf framework. How does it >> interact with GIT_EXEC_PATH we set in

Re: [PATCH 1/2] t/perf: fix regression in testing older versions of git

On Wed, Jun 22, 2016 at 01:46:25PM -0700, Junio C Hamano wrote: > Jeff King writes: > > > So let's introduce a new variable, $MODERN_GIT, that we can > > use both in perf-lib and in the test setup to get a reliable > > set of git features (we might change git and break some > >

Re: [PATCH 1/2] t/perf: fix regression in testing older versions of git

Jeff King writes: > So let's introduce a new variable, $MODERN_GIT, that we can > use both in perf-lib and in the test setup to get a reliable > set of git features (we might change git and break some > tests, of course, but $MODERN_GIT is tied to the same > version of git as the

Re: [PATCH v3 0/3] Introduce log.showSignature config variable

Mehul Jain writes: > Add a new configuratation variable "log.showSignature" for git-log > and related commands. "log.showSignature=true" will enable user to > see GPG signature by default for git-log and related commands. > > Changes compared to v2: > * A

Re: [PATCH 1/2] t/perf: fix regression in testing older versions of git

Hi Peff, On Wed, 22 Jun 2016, Jeff King wrote: > diff --git a/t/perf/README b/t/perf/README > index 8848c14..15986ca 100644 > --- a/t/perf/README > +++ b/t/perf/README > @@ -115,8 +115,16 @@ After that you will want to use some of the following: > > At least one of the first two is required!

Re: [PATCH 1/2] t/perf: fix regression in testing older versions of git

Hi Peff, On Wed, 22 Jun 2016, Jeff King wrote: > Commit 7501b59 (perf: make the tests work in worktrees, > 2016-05-13) introduced the use of "git rev-parse --git-path" > in the perf-lib setup code. Because the to-be-tested version > of git is at the front of the $PATH when this code runs, > this

[PATCH v3 3/8] use cleanFromFile in git add

Includes test cases. Signed-off-by: Joey Hess --- sha1_file.c | 42 -- t/t0021-conversion.sh | 36 2 files changed, 72 insertions(+), 6 deletions(-) diff --git a/sha1_file.c b/sha1_file.c

[PATCH v3 8/8] use smudgeToFile filter in recursive merge

Recursive merge updates the work tree and so should use the smudgeToFile filter. At this point, smudgeToFile is run by everything that updates work tree files. Signed-off-by: Joey Hess --- merge-recursive.c | 42 --

[PATCH v3 4/8] use smudgeToFile in git checkout etc

This makes git checkout, git reset, etc use smudgeToFile. Includes test cases. (There's a call to convert_to_working_tree in merge-recursive.c that could also be made to use smudgeToFile as well.) Signed-off-by: Joey Hess --- entry.c | 37

[PATCH v3 7/8] use smudgeToFile filter in git am

git am updates the work tree and so should use the smudgeToFile filter. This includes some refactoring into convert_to_working_tree_filter_to_file to make it check the file after running the smudgeToFile command, and clean up from a failing command. Signed-off-by: Joey Hess

[PATCH v3 5/8] warn on unusable smudgeToFile/cleanFromFile config

Let the user know when they have a smudgeToFile/cleanFromFile config that cannot be used because the corresponding smudge/clean config is missing. The warning is only displayed a maximum of once per git invocation, and only when doing an operation that would use the filter. Signed-off-by: Joey

[PATCH v3 2/8] add smudgeToFile and cleanFromFile filter configs

This adds new smudgeToFile and cleanFromFile filter commands, which are similar to smudge and clean but allow direct access to files on disk. This interface can be much more efficient when operating on large files, because the whole file content does not need to be streamed through the filter. It

[PATCH v3 6/8] better recovery from failure of smudgeToFile filter

If the smudgeToFile filter fails, it can leave the worktree file with the wrong content, or even deleted. Recover from this by falling back to running the smudge filter. Signed-off-by: Joey Hess --- entry.c | 55 ---

[PATCH v3 0/8] extend smudge/clean filters with direct file access

Reroll of this patch set with changes: * Added additional smudgeToFile calls in git am and recursive merge. * Improved behavior when smudgeToFile filter fails. * Some small improvements to the test cases. I hope this will be the final version. Joey Hess (8): clarify %f documentation add

[PATCH v3 1/8] clarify %f documentation

It's natural to expect %f to be an actual file on disk; help avoid that mistake. Signed-off-by: Joey Hess --- Documentation/gitattributes.txt | 5 + 1 file changed, 5 insertions(+) diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt index

Re: [PATCH v3 0/2] Make find_commit_subject() consistent with --format=%s

Hi Junio, On Wed, 22 Jun 2016, Junio C Hamano wrote: > Johannes Schindelin writes: > > > In an intermediate iteration of my rebase--helper patches, I > > accidentally generated commits with more than one empty line > > between the header and the commit message. When

[PATCH v4 1/2] Make the skip_blank_lines() function public

This function will be used also in the find_commit_subject() function. While at it, rename the function to reflect that it skips not only empty lines, but any lines consisting of only whitespace, too. Signed-off-by: Johannes Schindelin --- commit.h | 1 + pretty.c

[PATCH v4 0/2] Make find_commit_subject() consistent with --format=%s

In an intermediate iteration of my rebase--helper patches, I accidentally generated commits with more than one empty line between the header and the commit message. When using find_commit_subject() to show the oneline, it turned up empty, even if the output of `git show --format=%s` looked fine.

[PATCH v4 2/2] Make find_commit_subject() more robust

Just like the pretty printing machinery, we should simply ignore blank lines at the beginning of the commit messages. This discrepancy was noticed when an early version of the rebase--helper produced commit objects with more than one empty line between the header and the commit message.

Re: [PATCH 1/1] mingw: work around t2300's assuming non-Windows paths

Junio C Hamano writes: > I think I know that well enough; please sanity check. My > understanding is: > ... > The patch under discussion is the only door left for that test, and > a similar trickery is needed for any end-user scripts used for hooks > and aliases that use 'git

Re: [PATCH] doc: git-htmldocs.googlecode.com is no more

On Wed, Jun 22, 2016 at 10:00:56AM -0700, Junio C Hamano wrote: > Peff suggested to use the github pages that are connected to the > "git" org, and helped its initial set-up. When I update the > prebuilt docs, in addition to the listed locations, I also push to > the gh-pages branch of

Re: [PATCH 1/1] mingw: work around t2300's assuming non-Windows paths

Hi Junio, On Wed, 22 Jun 2016, Junio C Hamano wrote: > So let's take that "if Windows do this" change to t2300 as-is. Thanks! Dscho -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at

Re: Use docker for _some_ testing?

On Wed, Jun 22, 2016 at 09:01:55PM +0200, Duy Nguyen wrote: > Which makes me think, could we use something like this to make sure > people (on Linux) can test more obscure cases? Sometimes there are > featues that require some dependencies that are not always present on > the developer's machine

[PATCH 2/2] p4211: explicitly disable renames in no-rename test

p4211 tests line-log performance both with and without "-M". In v2.9.0, the case without "-M" appears to have regressed badly, but that is only because we flipped on renames by default. Let's have the test explicitly disable renames to get consistent timings (and to match the presumed intent of

[PATCH 1/2] t/perf: fix regression in testing older versions of git

Commit 7501b59 (perf: make the tests work in worktrees, 2016-05-13) introduced the use of "git rev-parse --git-path" in the perf-lib setup code. Because the to-be-tested version of git is at the front of the $PATH when this code runs, this means we cannot use modern versions of t/perf to test

[PATCH 0/2] t/perf tests against older versions

One of the points of the t/perf suite is to be able to detect performance regressions between versions. But I don't think anybody really runs it systematically; we mostly just use it to show off our shiny new improvements. :) So I decided to run the suite against v2.0.0 and v2.9.0, to catch any

Re: Use docker for _some_ testing?

Duy Nguyen writes: > The story started with my problem on Debian, which I didn't have and > didn't want to install a Debian VM just for that problem. So I made a > docker image with the following script. > > Which makes me think, could we use something like this to make sure >

Re: [PATCH v6 00/11] Fix icase grep on non-ascii

Junio C Hamano writes: > I think somebody's implementation of "echo" is not POSIX kosher. Oops, I misspoke. s/POSIX/XSI/; obviously. But the conclusion is the same. echo '\\\tA' may say \\\tA or backslash HT A, depending on the system, so we cannot rely on that in tests

Re: [PATCH v2 2/2] grep: fix grepping for "intent to add" files

Duy Nguyen writes: >>> If cached is false and ce_ita() is true and either CE_VALID or >>> CE_SKIP_WORKTREE is set, we would continue to grep an _empty_ SHA-1. >>> But I think we should grep_file() instead, at least for CE_VALID. >> >> Yes, that is the breakage I noticed in the

Re: [PATCH] doc: git-htmldocs.googlecode.com is no more

On Wed, Jun 22, 2016 at 12:00 PM, Eric Wong wrote: > > Just wondering, who updates > https://kernel.org/pub/software/scm/git/docs/ > and why hasn't it been updated in a while? > (currently it says Last updated 2015-06-06 at the bottom) Nobody. It is too cumbersome to use their

Use docker for _some_ testing?

The story started with my problem on Debian, which I didn't have and didn't want to install a Debian VM just for that problem. So I made a docker image with the following script. Which makes me think, could we use something like this to make sure people (on Linux) can test more obscure cases?

Re: [PATCH] doc: git-htmldocs.googlecode.com is no more

Jonathan Nieder wrote: > I'd rather use an up-to-date https link for the rendered > documentation, but I wasn't able to find one. According to the 'todo' > branch, prebuilt documentation is pushed to > > 1. https://kernel.googlesource.com/pub/scm/git/git-htmldocs > 2.

Re: [PATCH v6 00/11] Fix icase grep on non-ascii

On Wed, Jun 22, 2016 at 11:41 AM, Duy Nguyen wrote: > On Wed, Jun 22, 2016 at 8:36 PM, Junio C Hamano wrote: >> On Wed, Jun 22, 2016 at 11:29 AM, Duy Nguyen wrote: >>> >>> Can any shell wizards explain this to me? With this code >>> >>>

Re: [PATCH v2 0/8] object_id part 4

On Tue, Jun 21, 2016 at 02:22:50PM -0700, Junio C Hamano wrote: > "brian m. carlson" writes: > > > This series is part 4 in a series of conversions to replace instances of > > unsigned char [20] with struct object_id. Most of this series touches > > the

Re: [PATCH v6 00/11] Fix icase grep on non-ascii

On Wed, Jun 22, 2016 at 8:36 PM, Junio C Hamano wrote: > On Wed, Jun 22, 2016 at 11:29 AM, Duy Nguyen wrote: >> >> Can any shell wizards explain this to me? With this code >> >> BS=\\ >> echo ${BS}${BS} >> >> Debian's dash returns a single backslash while

Re: [PATCH 1/1] git-p4: correct hasBranchPrefix verbose output

Andrew Oakley writes: > The logic here was inverted, you got a message saying the file is > ignored for each file that is not ignored. > > Signed-off-by: Andrew Oakley > --- Thanks. > git-p4.py | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > >

Re: [PATCH v6 00/11] Fix icase grep on non-ascii

On Wed, Jun 22, 2016 at 11:29 AM, Duy Nguyen wrote: > > Can any shell wizards explain this to me? With this code > > BS=\\ > echo ${BS}${BS} > > Debian's dash returns a single backslash while bash returns two > backslashes. Section 2.2.1 [1] does not say anything about one >

Re: [PATCH v2 2/2] grep: fix grepping for "intent to add" files

On Wed, Jun 22, 2016 at 8:00 PM, Junio C Hamano wrote: > Duy Nguyen writes: > >>> So I wonder if a better change would be more like >>> >>> for (...) { >>> if (!S_ISREG(ce->ce_mode)) >>> continue; /* not a

Re: [PATCH v6 00/11] Fix icase grep on non-ascii

On Sat, Jun 18, 2016 at 2:26 AM, Duy Nguyen wrote: > On Sat, Jun 18, 2016 at 6:17 AM, Junio C Hamano wrote: >> Nguyễn Thái Ngọc Duy writes: >> >>> v6 fixes comments from Ramsay and Eric. Interdiff below. >> >> Another thing I noticed

Re: How to find commits unique to a branch

Nikolaus Rath writes: > On Jun 21 2016, Junio C Hamano wrote: >> >> I find that the first sentence of the description is fuzzy >> ("Determine whether" would imply that you would get "Yes/No" but >> what we want is "here are the commits that do not have

Re: [PATCH v2 2/2] grep: fix grepping for "intent to add" files

Duy Nguyen writes: >> So I wonder if a better change would be more like >> >> for (...) { >> if (!S_ISREG(ce->ce_mode)) >> continue; /* not a regular file */ >> if (!ce_path_match(ce, pathspec, NULL) >>

Re: [PATCH 5/5] format-patch: avoid freopen()

Johannes Schindelin writes: > Well, if I change `rev.diffopt.use_color != GIT_COLOR_ALWAYS` to > `rev.diffopt.use_color == GIT_COLOR_AUTO`, then the files will contain > ugly ANSI color sequences if I run `git format-patch -o . -3`. > > The reason is, as I tried to

[PATCH v2] doc: git-htmldocs.googlecode.com is no more

http://git-htmldocs.googlecode.com/git/git.html says There was no service found for the uri requested. Link to the rendered documentation on Jekyll instead. Reported-by: Andrea Stacchiotti Signed-off-by: Jonathan Nieder --- Junio C Hamano

Re: [PATCH 5/5] format-patch: avoid freopen()

Johannes Schindelin writes: > Well, if I change `rev.diffopt.use_color != GIT_COLOR_ALWAYS` to > `rev.diffopt.use_color == GIT_COLOR_AUTO`, then the files will contain > ugly ANSI color sequences if I run `git format-patch -o . -3`. > > The reason is, as I tried to

Re: [PATCH v3 0/2] Make find_commit_subject() consistent with --format=%s

Johannes Schindelin writes: > In an intermediate iteration of my rebase--helper patches, I > accidentally generated commits with more than one empty line > between the header and the commit message. When using > find_commit_subject() to show the oneline, it turned up

Problem Following file history through sub-tree import

Having difficulty understanding how to invoke 'git log' to track the history of a file that was imported into a different location through a subtree merge. I had thought just '--follow' was needed, but I don't seem to be getting any results with that. Example below. Thanks! ~Andrew git

Re: t7610-mergetool.sh test failure

On Wed, Jun 22, 2016 at 06:53:40PM +0200, Armin Kunaschik wrote: > Another thread I'm trying to revive... the discussion went away quite a bit > from the suggested patch to conditionally run this one test only when mktemp > is available. > > I'll create a patch when there are chances it is

Re: [PATCH] doc: git-htmldocs.googlecode.com is no more

Jonathan Nieder writes: > http://git-htmldocs.googlecode.com/git/git.html says > > There was no service found for the uri requested. > > Link to the HTML documentation on repo.or.cz instead. http://thread.gmane.org/gmane.comp.version-control.git/296483/focus=296575 Peff

[PATCH v3 2/3] log: add "--no-show-signature" command line option

If an user creates an alias with "--show-signature" early in command line, e.g. [alias] logss = log --show-signature then there is no way to countermand it through command line. Teach git-log and related commands about "--no-show-signature" command line option. This will make "git logss

[PATCH v3 3/3] log: add log.showSignature configuration variable

Users may want to always use "--show-signature" while using git-log and related commands. When log.showSignature is set to true, git-log and related commands will behave as if "--show-signature" was given to them. Note that this config variable is meant to affect git-log, git-show,

Re: t7610-mergetool.sh test failure

Another thread I'm trying to revive... the discussion went away quite a bit from the suggested patch to conditionally run this one test only when mktemp is available. I'll create a patch when there are chances it is accepted. I could think of a way to replace mktemp with a perl one-liner (or

[PATCH v3 1/3] t4202: refactor test

Separate the creation of 'signed' branch so that other tests can take advantage of this branch. Signed-off-by: Mehul Jain --- t/t4202-log.sh | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/t/t4202-log.sh b/t/t4202-log.sh index

[PATCH v3 0/3] Introduce log.showSignature config variable

Add a new configuratation variable "log.showSignature" for git-log and related commands. "log.showSignature=true" will enable user to see GPG signature by default for git-log and related commands. Changes compared to v2: * A preparatory patch 1/3 has been introduced so that tests

Re: [PATCH 1/1] mingw: work around t2300's assuming non-Windows paths

Johannes Schindelin writes: > On Tue, 21 Jun 2016, Junio C Hamano wrote: > >> I said $PATH because --exec-path does not care what you do with >> %PATH% but it deeply cares that its output is usable in $PATH. > > The really, really, really important part to keep in

Re: How to find commits unique to a branch

On Jun 21 2016, Michael J Gruber wrote: > Nikolaus Rath venit, vidit, dixit 21.06.2016 01:21: >> On Jun 20 2016, Junio C Hamano wrote: >>> Nikolaus Rath writes: >>> What's the best way to find all commits in a branch A that

Re: How to find commits unique to a branch

On Jun 21 2016, Junio C Hamano wrote: > Nikolaus Rath writes: > >> On Jun 20 2016, Nikolaus Rath wrote: >>> On Jun 20 2016, Junio C Hamano wrote: Nikolaus Rath writes: > What's the

Re: [PATCH 5/5] format-patch: avoid freopen()

Hi Junio, On Wed, 22 Jun 2016, Junio C Hamano wrote: > Johannes Schindelin writes: > > > But there's a rub... If you specify --color *explicitly*, use_color is set > > to GIT_COLOR_ALWAYS and the file indeed contains ANSI sequences (i.e. my > > analysis above left

Re: [PATCH v2 2/2] grep: fix grepping for "intent to add" files

On Wed, Jun 22, 2016 at 12:49 AM, Junio C Hamano wrote: >> @@ -396,7 +396,7 @@ static int grep_cache(struct grep_opt *opt, const struct >> pathspec *pathspec, int >>* cache version instead >>*/ >> if (cached || (ce->ce_flags &

Re: [PATCH v2 2/2] grep: fix grepping for "intent to add" files

On Wed, Jun 22, 2016 at 3:13 AM, Eric Sunshine wrote: > On Tue, Jun 21, 2016 at 5:14 PM, Charles Bailey wrote: >> From: Charles Bailey >> >> This reverts commit 4d552005323034c1d6311796ac1074e9a4b4b57e and adds an >>

Re: [PATCH 5/5] format-patch: avoid freopen()

Johannes Schindelin writes: > But there's a rub... If you specify --color *explicitly*, use_color is set > to GIT_COLOR_ALWAYS and the file indeed contains ANSI sequences (i.e. my > analysis above left out the command-line part). Heh, the command-line is the _ONLY_

Re: Problem with --shallow-submodules option

On Mon, Jun 20, 2016 at 01:06:39PM +, Istvan Zakar wrote: > I'm working on a relatively big project with many submodules. During > cloning for testing I tried to decrease the amount of data need to be > fetched from the server by using --shallow-submodules option in the clone > command. It

Re: [PATCH v3 2/9] Disallow diffopt.close_file when using the log_tree machinery

Hi Junio, On Tue, 21 Jun 2016, Junio C Hamano wrote: > Junio C Hamano writes: > > > Junio C Hamano writes: > > > >> Johannes Schindelin writes: > >> > >>> We are about to teach the log_tree machinery to reuse the diffopt.file

[PATCH v4 07/10] format-patch: avoid freopen()

We just taught the relevant functions to respect the diffopt.file field, to allow writing somewhere else than stdout. Let's make use of it. Technically, we do not need to avoid that call in a builtin: we assume that builtins (as opposed to library functions) are stand-alone programs that may do

[PATCH v4 08/10] format-patch: use stdout directly

Earlier, we freopen()ed stdout in order to write patches to files. That forced us to duplicate stdout (naming it "realstdout") because we *still* wanted to be able to report the file names. As we do not abuse stdout that way anymore, we no longer need to duplicate stdout, either. Signed-off-by:

[PATCH v4 09/10] shortlog: respect the --output= setting

Thanks to the diff option parsing, we already know about this option. We just have to make use of it. Signed-off-by: Johannes Schindelin --- builtin/shortlog.c | 4 +++- t/t4201-shortlog.sh | 6 ++ 2 files changed, 9 insertions(+), 1 deletion(-) diff --git

[PATCH v4 03/10] line-log: respect diffopt's configured output file stream

The diff machinery can optionally output to a file stream other than stdout, by overriding diffopt.file. In such a case, the rest of the log tree machinery should also write to that stream. Currently, there is no user of the line level log that wants to redirect output to a file. Therefore, one

[PATCH v4 05/10] shortlog: support outputting to streams other than stdout

This will be needed to avoid freopen() in `git format-patch`. Signed-off-by: Johannes Schindelin --- builtin/shortlog.c | 13 - shortlog.h | 1 + 2 files changed, 9 insertions(+), 5 deletions(-) diff --git a/builtin/shortlog.c

[PATCH v4 02/10] log-tree: respect diffopt's configured output file stream

The diff options already know how to print the output anywhere else than stdout. The same is needed for log output in general, e.g. when writing patches to files in `git format-patch`. Let's allow users to use log_tree_commit() *without* changing global state via freopen(). Signed-off-by:

[PATCH v4 04/10] graph: respect the diffopt.file setting

When the caller overrides diffopt.file (which defaults to stdout), the diff machinery already redirects its output, and the graph display should also write to that file. Signed-off-by: Johannes Schindelin --- graph.c | 30 +- 1 file

[PATCH v4 00/10] Let log-tree and friends respect diffopt's `file` field

The idea is to allow callers to redirect log-tree's output to a file without having to freopen() stdout (which would modify global state, a big no-no-no for library functions). I reviewed log-tree.c, graph.c, line-log.c, builtin/shortlog.c and builtin/log.c line by line to ensure that all calls

[PATCH v4 10/10] Ensure that log respects --output=

The test script t4202-log.sh is already pretty long, and it is a good idea to test --output with a more obscure option, anyway. So let's test it in conjunction with line-log. The most important part of this test, of course, is to ensure that the file is not closed after writing the diff, but only

[PATCH v4 06/10] format-patch: explicitly switch off color when writing to files

We rely on the auto-detection ("is stdout a terminal?") to determine whether to use color in the output of format-patch or not. That happens to work because we freopen() stdout when redirecting the output to files. However, we are about to fix that work-around, in which case the auto-detection

Re: [PATCH v3] Refactor recv_sideband()

On Wed, 22 Jun 2016, Lukas Fleischer wrote: > Before this patch, we used character buffer manipulations to split > messages from the sideband at line breaks and insert "remote: " at the > beginning of each line, using the packet size to determine the end of a > message. However, since it is safe

[PATCH v4 01/10] Prepare log/log-tree to reuse the diffopt.close_file attribute

We are about to teach the log-tree machinery to reuse the diffopt.file field to output to a file stream other than stdout, in line with the diff machinery already writing to diffopt.file. However, we might want to write something after the diff in log_tree_commit() (e.g. with the

[PATCH] diff: let --output= default to --no-color

It is highly unlikely that any user would want to see ANSI color sequences in a file. So let's stop doing that by default. This is a backwards-incompatible change. The reason this was not caught earlier is most likely that either --output= is not used, or only when stdout is redirected anyway.

Re: [PATCH v3 1/9] am: stop ignoring errors reported by log_tree_diff()

Hi Junio, On Tue, 21 Jun 2016, Junio C Hamano wrote: > Johannes Schindelin writes: > > > Note: there are more places in the builtin am code that ignore > > errors returned from library functions. Fixing those is outside the > > purview of the current patch series,

Re: [PATCH 11/11] i18n: difftool: mark warnings for translation

A Terça, 21 de Junho de 2016 21:33:29 David Aguilar escreveu: > I'm assuming that the i18n infrastructure is prepared to deal > with perl's . dot syntax for string concatenation, though, and > I don't know whether that's true. Does that work? Yes, dot syntax does work. xgettext is able to

  1   2   >