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

Duy Nguyen wrote: > On Fri, May 20, 2016 at 4:45 AM, David Turner wrote: > > diff --git a/read-cache.c b/read-cache.c > > index 1719f5a..8ec4be3 100644 > > --- a/read-cache.c > > +++ b/read-cache.c > > @@ -1235,7 +1235,7 @@ int

Re: [PATCH] pathspec: prevent empty strings as pathspecs

On 06/18/2016 11:10 PM, Junio C Hamano wrote: Emily Xie writes: For any command that takes a pathspec, passing an empty string will execute the command on all files in the current directory. This results in unexpected behavior. For example, git add "" adds all files to

Re: [PATCH] prune: keep files created after process start

Junio C Hamano wrote: > Eric Wong writes: > > I'm somewhat surprised this check didn't already exist; > > but maybe nobody else runs prune manually, anymore. > > The only time an end user would run "git prune" in their > repositories with working trees these

Re: [PATCH] prune: keep files created after process start

Eric Wong writes: > Avoid pruning files which were written after the prune process > starts, as it possible to concurrently create new objects while > "git prune" is running. > > Tested on git.git by starting "git prune" in one terminal, > creating a random loose object via "git

Re: [PATCH] git-sh-setup.sh: fix missing double quotes variables

LE Manh Cuong writes: > It's not only people shooting their foot, but also from malicious user. > Given that `curl url | sudo sh/bash` is often found in many instructions, > an end user may not be noticed about the environment variable injection > from their side. > >

[PATCH] prune: keep files created after process start

Avoid pruning files which were written after the prune process starts, as it possible to concurrently create new objects while "git prune" is running. Tested on git.git by starting "git prune" in one terminal, creating a random loose object via "git hash-object --stdin -w" in a different

Re: [PATCH] pathspec: prevent empty strings as pathspecs

Emily Xie writes: > For any command that takes a pathspec, passing an empty string will > execute the command on all files in the current directory. This > results in unexpected behavior. For example, git add "" adds all > files to staging, while git rm -rf "" recursively

Re: [PATCH] git-sh-setup.sh: fix missing double quotes variables

> Given that LESS, LV and GIT_OBJECT_DIRECTORY are expected to be free > of any "expensive to expand" strings, I am not sure if this actually > matters, though. And more importantly, these are what the end users > are expected to set to whatever sensible values for them. The problem is the end

Re: [PATCH] pathspec: prevent empty strings as pathspecs

On Sat, Jun 18, 2016 at 9:49 PM, David Turner wrote: > On Sat, 2016-06-18 at 20:57 -0400, Emily Xie wrote: >> + while (argv[n]) { >> + if (*argv[n] == '\0') { >> + die("Empty string is not a valid pathspec."); >> + } > > nit:

Re: [PATCH] pathspec: prevent empty strings as pathspecs

On Sat, 2016-06-18 at 20:57 -0400, Emily Xie wrote: > For any command that takes a pathspec, passing an empty string will > execute the command on all files in the current directory. This > results in unexpected behavior. For example, git add "" adds all > files to staging, while git rm -rf ""

Re: [PATCH] git-sh-setup.sh: fix missing double quotes variables

LE Manh Cuong writes: > Leaving shell variables un-quotes can lead to security vulnerabilities. In: > > : ${x=.} > > `$x` is always expanded, cause `glob+split` on its result. There're some > globs is too expensive to expand, like: > >

Re: What's cooking in git.git (May 2016, #08; Thu, 26)

Jeff King writes: > On Thu, May 26, 2016 at 03:50:14PM -0700, Junio C Hamano wrote: > >> * jk/upload-pack-hook (2016-05-24) 6 commits >> - upload-pack: provide a hook for running pack-objects >> - config: add a notion of "scope" >> - config: return configset value for

[PATCH] pathspec: prevent empty strings as pathspecs

For any command that takes a pathspec, passing an empty string will execute the command on all files in the current directory. This results in unexpected behavior. For example, git add "" adds all files to staging, while git rm -rf "" recursively removes all files from the working tree and index.

Managing sub-projects

I'm trying to create a git repository for a tool chain for a proprietary processor. I'd like to create a private repo with documentation, build scripts, etc., which includes several sub-projects: binutils, gcc, newlib, etc. Each of the sub-projects will have a branch which has support for the

[PATCH v2 4/8] Rename struct diff_filespec's sha1_valid member.

Now that this struct's sha1 member is called "oid", update the comment and the sha1_valid member to be called "oid_valid" instead. The following Coccinelle semantic patch was used to implement this, followed by the transformations in object_id.cocci: @@ struct diff_filespec o; @@ - o.sha1_valid

[PATCH v2 8/8] merge-recursive: convert merge_recursive_generic to object_id

Convert this function and the git merge-recursive subcommand to use struct object_id. Signed-off-by: brian m. carlson --- builtin/merge-recursive.c | 20 ++-- merge-recursive.c | 14 +++--- merge-recursive.h | 6 +++--- 3

[PATCH v2 1/8] Add basic Coccinelle transforms.

Coccinelle (http://coccinelle.lip6.fr/) is a program which performs mechanical transformations on C programs using semantic patches. These semantic patches can be used to implement automatic refactoring and maintenance tasks. Add a set of basic semantic patches to convert common patterns related

[PATCH v2 7/8] merge-recursive: convert leaf functions to use struct object_id

Convert all but two of the static functions in this file to use struct object_id. Signed-off-by: brian m. carlson --- merge-recursive.c | 236 +++--- 1 file changed, 118 insertions(+), 118 deletions(-) diff --git

[PATCH v2 3/8] Convert struct diff_filespec to struct object_id

Convert struct diff_filespec's sha1 member to use a struct object_id called "oid" instead. The following Coccinelle semantic patch was used to implement this, followed by the transformations in object_id.cocci: @@ struct diff_filespec o; @@ - o.sha1 + o.oid.hash @@ struct diff_filespec *p; @@ -

[PATCH v2 5/8] merge-recursive: convert struct stage_data to use object_id

Convert the anonymous struct within struct stage_data to use struct object_id. The following Coccinelle semantic patch was used to implement this, followed by the transformations in object_id.cocci: @@ struct stage_data o; expression E1; @@ - o.stages[E1].sha + o.stages[E1].oid.hash @@ struct

[PATCH v2 0/8] object_id part 4

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 merge-recursive code. New in this series is the use of Coccinelle (http://coccinelle.lip6.fr/) semantic patches. These semantic patches can make

[PATCH v2 6/8] merge-recursive: convert struct merge_file_info to object_id

Convert struct merge_file_info to use struct object_id. The following Coccinelle semantic patch was used to implement this, followed by the transformations in object_id.cocci: @@ struct merge_file_info o; @@ - o.sha + o.oid.hash @@ struct merge_file_info *p; @@ - p->sha + p->oid.hash

[PATCH v2 2/8] Apply object_id Coccinelle transformations.

Apply the set of semantic patches from contrib/examples/coccinelle to convert some leftover places using struct object_id's hash member to instead use the wrapper functions that take struct object_id natively. Signed-off-by: brian m. carlson --- bisect.c

[PATCH] git-sh-setup.sh: fix missing double quotes variables

Leaving shell variables un-quotes can lead to security vulnerabilities. In: : ${x=.} `$x` is always expanded, cause `glob+split` on its result. There're some globs is too expensive to expand, like: x='/*/*/*/*/../../../../*/*/*/*/../../../../*/*/*/*' sh -c ': ${x=.}' Run it and our

[no subject]

Sorry, the example in commit message is wrong, due to editor auto wrapping line. -- 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 http://vger.kernel.org/majordomo-info.html

[PATCH] git-sh-setup.sh: fix missing double quotes variables

Leaving shell variables un-quotes can lead to security vulnerabilities. In: : ${x=.} `$x` is always expanded, cause `glob+split` on its result. There're some globs is too expensive to expand, like: x='/*/*/*/*/../../../../*/*/*/*/../../../../*/*/*/*' sh -c ': ${x=.}' Run it and our

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

Michael Haggerty writes: > On 06/17/2016 05:20 AM, Junio C Hamano wrote: >> [...] >> * mh/ref-iterators (2016-06-03) 13 commits >> (merged to 'next' on 2016-06-06 at c8e79dc) >> + ... >> (this branch is used by mh/ref-store; uses mh/split-under-lock; is tangled >> with

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

On 06/18/2016 12:05 AM, Lars Schneider wrote: > >> On 17 Jun 2016, at 05:20, Junio C Hamano wrote: >> >> ... >> >> * mh/split-under-lock (2016-05-13) 33 commits >> (merged to 'next' on 2016-06-03 at 2e71330) >> [...] > > This topic seems break two git-p4 tests (t9801 and

Hello........

-- Hello, Can i talk with you ..? -- 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 http://vger.kernel.org/majordomo-info.html

Re: URL rewrite in local config unable to override global config rule

On Sat, Jun 18, 2016 at 11:06:41AM +0530, Saksham Saxena wrote: > Thanks a lot Peff. This cleared a lot of things. Would it be okay if I > cite some parts of this conversation on my personal blog? Sure, that is fine with me. -Peff -- To unsubscribe from this list: send the line "unsubscribe

[PATCH] Make find_commit_subject() more robust

Just like the pretty printing machinery, we should simply ignore empty 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.

[PATCH] perf: accommodate for MacOSX

As this developer has no access to MacOSX developer setups anymore, Travis becomes the best bet to run performance tests on that OS. However, on MacOSX /usr/bin/time is that good old BSD executable that no Linux user cares about, as demonstrated by the perf-lib.sh's use of GNU-ish extensions. And

[PATCH] mingw: let the build succeed with DEVELOPER=1

The recently introduced developer flags identified a couple of old-style function declarations in the Windows-specific code where the parameter list was left empty instead of specifying "void" explicitly. Let's just fix them. Signed-off-by: Johannes Schindelin ---

[PATCH v2 2/2] 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,

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

If an user creates an alias with "--show-signature" 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 v2 0/2] 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: * Order of patches is reversed as suggested by Junio[1]. * A new test has

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

On Windows, we have to juggle two different schemes of representing paths: the native, Windows paths (the only ones known to the main Git executable) on the one hand, and POSIX-ish ones used by the Bash through MSYS2's POSIX emulation layer on the other hand. A Windows path looks like this:

[PATCH 0/1] Fix testing of `master` on Windows

Sorry, I missed this (trivially-fixed) test breakage... FWIW this is *not* part of the rebase--helper patches ;-) Johannes Schindelin (1): mingw: work around t2300's assuming non-Windows paths t/t2300-cd-to-toplevel.sh | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-)

[PATCH 3/5] 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 2/5] 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 4/5] 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 5/5] 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 1/5] 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 0/5] 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