[PATCH] change 'commands' to comments and improve wording

--- Documentation/git-stash.txt | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/Documentation/git-stash.txt b/Documentation/git-stash.txt index 70191d06b69e..3899d36b2bab 100644 --- a/Documentation/git-stash.txt +++ b/Documentation/git-stash.txt @@ -233,7 +233,7 @@

Re: [PATCH v4 03/10] rebase -i: remove useless indentation

Hi Stefan, On 26/05/17 01:50 PM, Stefan Beller wrote: > On Thu, May 25, 2017 at 8:15 PM, Liam Beguin wrote: >> Hi Johannes, >> >> Johannes Schindelin writes: >>> The commands used to be indented, and it is nice to look at, but when we >>>

Re: [GSoC][PATCH v5 1/3] submodule: fix buggy $path and $sm_path variable's value

On 26/05/17 18:07, Stefan Beller wrote: > On Fri, May 26, 2017 at 9:31 AM, Ramsay Jones > wrote: >> Hmm, I'm not sure which documentation you are referring to, > > Quite likely our fine manual pages. ;) > >foreach [--recursive] >Evaluates an

Re: [GSoC][PATCH v5 3/3] submodule: port subcommand foreach from shell to C

Am 26.05.2017 um 17:17 schrieb Prathamesh Chavan: + argv_array_pushf(_array, "path=%s", list_item->name); Not good! On Windows, environment variables are case insensitive. The environment variable "path" has a very special purpose, although it is generally spelled "PATH" (actually

[PATCH] wildmatch test: remove redundant duplicate test

Remove a test line that's exactly the same as the preceding line. This was brought in in commit feabcc173b ("Integrate wildmatch to git", 2012-10-15), these tests are originally copied from rsync.git, but the duplicate line was never present there, so must have just snuck in during integration

Re: [GSoC][PATCH v5 3/3] submodule: port subcommand foreach from shell to C

On 05/26, Johannes Sixt wrote: > Am 26.05.2017 um 17:17 schrieb Prathamesh Chavan: > >+argv_array_pushf(_array, "path=%s", list_item->name); > > Not good! On Windows, environment variables are case insensitive. > The environment variable "path" has a very special purpose, although > it is

[PATCH 1/1] diff.c: color moved lines differently

When a patch consists mostly of moving blocks of code around, it can be quite tedious to ensure that the blocks are moved verbatim, and not undesirably modified in the move. To that end, color blocks that are moved within the same patch differently. For example (OM, del, add, and NM are different

Re: [PATCHv4 00/17] Diff machine: highlight moved lines.

On Mon, May 22, 2017 at 7:40 PM, Stefan Beller wrote: > v4: > * interdiff to v3 (what is currently origin/sb/diff-color-move) below. > * renamed the "buffered_patch_line" to "diff_line". Originally I planned > to not carry the "line" part as it can be a piece of a line as

Re: [GSoC][PATCH v5 3/3] submodule: port subcommand foreach from shell to C

On 26/05/17 22:54, Johannes Sixt wrote: > Am 26.05.2017 um 17:17 schrieb Prathamesh Chavan: >> +argv_array_pushf(_array, "path=%s", list_item->name); > > Not good! On Windows, environment variables are case insensitive. The > environment variable "path" has a very special purpose, although

Re: [Non-Bug] cloning a repository with a default MASTER branch tries to check out the master branch

adding and updating an example.. From: "Philip Oakley" been trying to keep up... From: "Jeff King" On Thu, May 25, 2017 at 11:59:24AM -0400, Jeff King wrote: The just-HEAD case could look like: This patch does work, in the sense that upload-pack

[PATCH 0/1] Diff machine: highlight moved lines.

This is a new version of the latest patch of sb/diff-color-move. It seems as if different people prefer different settings for the boundary/alternate coloring, so let's have all of them. (As the block detection is rather simple we do not need a lot of overhead to support multiple modes). With

Re: [Non-Bug] cloning a repository with a default MASTER branch tries to check out the master branch

been trying to keep up... From: "Jeff King" On Thu, May 25, 2017 at 11:59:24AM -0400, Jeff King wrote: The just-HEAD case could look like: This patch does work, in the sense that upload-pack advertises the unborn HEAD symref. But the client doesn't actually do anything with

Re: [PATCHv5 00/17] Diff machine: highlight moved lines.

On Thu, May 25, 2017 at 6:20 PM, Junio C Hamano wrote: > Stefan Beller writes: > >> As you turn on/off normal coloring via "color.diff" and this only extends >> the coloring scheme, I have the impression "color" is the right section. >> Maybe

[PATCH 7/8] builtin/push.c: respect 'submodule.recurse' option

The closest mapping from the boolean 'submodule.recurse' set to "yes" to the variety of submodule push modes is "on-demand", so implement that. Signed-off-by: Stefan Beller Signed-off-by: Junio C Hamano --- builtin/push.c | 4

[PATCH 2/8] submodule test invocation: only pass additional arguments

In a later patch we want to introduce a config option to trigger the submodule recursing by default. As this option should be available and uniform across all commands that deal with submodules we'd want to test for this option in the submodule update library. So instead of calling the whole test

[PATCH 6/8] builtin/grep.c: respect 'submodule.recurse' option

In builtin/grep.c we parse the config before evaluating the command line options. This makes the task of teaching grep to respect the new config option 'submodule.recurse' very easy by just parsing that option. As an alternative I had implemented a similar structure to treat submodules as the

[PATCH 3/8] reset/checkout/read-tree: unify config callback for submodule recursion

The callback function is essentially duplicated 3 times. Remove all of them and offer a new callback function, that lives in submodule.c By putting the callback function there, we no longer need the function 'set_config_update_recurse_submodules', nor duplicate the global variable in each builtin

[PATCH 5/8] Introduce 'submodule.recurse' option for worktree manipulators

Any command that understands '--recurse-submodules' can have its default changed to true, by setting the new 'submodule.recurse' option. This patch includes read-tree/checkout/reset for working tree manipulating commands. Later patches will cover other commands. Signed-off-by: Stefan Beller

[PATCH 5/6] verify_filename(): treat ":(magic)" as a pathspec

For commands that take revisions and pathspecs, magic pathspecs like ":(exclude)foo" require the user to specify a disambiguating "--", since they do not match a file in the filesystem, like: git grep foo -- :(exclude)bar This makes them more annoying to use than they need to be. We loosened

[PATCHv2 0/8] A reroll of sb/submodule-blanket-recursive

v2: * A reroll of sb/submodule-blanket-recursive. * This requires ab/grep-preparatory-cleanup * It changed a lot from v1, as in v1 the tests did not work, hence the code was broken. Now it actually works. * it also includes grep, fetch, push in addition to plain working tree manipulators.

[PATCH 8/8] builtin/fetch.c: respect 'submodule.recurse' option

Signed-off-by: Stefan Beller --- builtin/fetch.c | 7 +++ t/t5526-fetch-submodules.sh | 10 ++ 2 files changed, 17 insertions(+) diff --git a/builtin/fetch.c b/builtin/fetch.c index 5f2c2ab23e..c1ec3b03c3 100644 --- a/builtin/fetch.c +++

[PATCH 6/6] verify_filename(): flip order of checks

The looks_like_pathspec() check is much cheaper than check_filename(), which actually stats the file. Since either is sufficient for our return value, we should do the cheaper one first, potentially short-circuiting the other. Signed-off-by: Jeff King --- Probably doesn't matter,

[PATCH 1/8] submodule recursing: do not write a config variable twice

The command line option for '--recurse-submodules' is implemented using an OPTION_CALLBACK, which takes both the callback (that sets the file static global variable) as well as passes the same file static global variable to the option parsing machinery to assign it. This is fixed in this commit by

[PATCH 4/8] submodule loading: separate code path for .gitmodules and config overlay

The .gitmodules file is not supposed to have all the options available, that are available in the configuration so separate it out. A configuration option such as the hypothetical submodule.color.diff that determines in which color a submodule change is printed, is a very user specific thing,

[PATCH 4/6] check_filename(): handle ":^" path magic

We special-case "git log :/foo" to work when "foo" exists in the working tree. But :^ (and its alias :!) do not get the same treatment, requiring the user to supply a disambiguating "--". Let's make them work without requiring the user to type the "--". Signed-off-by: Jeff King

[PATCH 2/6] check_filename(): refactor ":/" handling

We handle arguments with the ":/" pathspec magic specially, making sure the name exists at the top-level. We'll want to handle more pathspec magic in future patches, so let's do a little rearranging to make that easier. Instead of relying on an if/else cascade to avoid the prefix_filename()

[PATCH 3/6] check_filename(): use skip_prefix

This avoids some magic numbers (and we'll be adding more similar calls in a minute). Signed-off-by: Jeff King --- setup.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/setup.c b/setup.c index 000ffa810..f2a8070bd 100644 --- a/setup.c +++ b/setup.c @@

[PATCH 1/6] t4208: add check for ":/" without matching file

The DWIM magic in check_filename() doesn't just recognize ":/". It actually makes sure that the file it points to exists. t4208 checks only the case where the path is present, not the opposite. Since the next patches will be touching this area, let's add a test to make sure it continues working.

[PATCH 0/6] make "^:foo" work without disambiguating "--"

On Fri, May 26, 2017 at 09:24:32AM -0400, Jeff King wrote: > The middle ground would be to replicate a simple subset of the rules in > verify_filename(). If we assume that all arguments with ":(" are > pathspecs (which seem rather unlikely to have false positives), then > that leaves only a few

Re: [PATCH] doc: filter-branch does not require re-export of vars

On Fri, May 26, 2017 at 07:36:54PM +0200, Andreas Heiduk wrote: > The function `set_ident` in `filter-branch` exported the variables > GIT_(AUTHOR|COMMITTER)_(NAME|EMAIL|DATE) at least since 6f6826c52b in 2007. > Therefore the filter scripts don't need to re-eport them again. Some old shells

git-2.13.0: log --date=format:%z not working

The following commands work as expected (using commit b06d364310 in the git://git.kernel.org/pub/scm/git/git.git repo as test case): $ export TZ=Europe/Berlin $ git --no-pager log -1 --pretty="%ad" --date=iso b06d364310 2017-05-09 23:26:02 +0900 $ git --no-pager log -1 --pretty="%ad"

Re: [PATCH v4 03/10] rebase -i: remove useless indentation

On Thu, May 25, 2017 at 8:15 PM, Liam Beguin wrote: > Hi Johannes, > > Johannes Schindelin writes: >> The commands used to be indented, and it is nice to look at, but when we >> transform the SHA-1s, the indentation is removed. So let's do away

[PATCH] doc: filter-branch does not require re-export of vars

The function `set_ident` in `filter-branch` exported the variables GIT_(AUTHOR|COMMITTER)_(NAME|EMAIL|DATE) at least since 6f6826c52b in 2007. Therefore the filter scripts don't need to re-eport them again. Signed-off-by: Andreas Heiduk ---

Re: [GSoC][PATCH v5 1/3] submodule: fix buggy $path and $sm_path variable's value

On Fri, May 26, 2017 at 9:31 AM, Ramsay Jones wrote: > > > On 26/05/17 16:17, Prathamesh Chavan wrote: >> According to the documentation about git-submodule foreach subcommand's >> $path variable: >> $path is the name of the submodule directory relative to the

Re: [GSoC][PATCH v5 3/3] submodule: port subcommand foreach from shell to C

On 05/26, Prathamesh Chavan wrote: > This aims to make git-submodule foreach a builtin. This is the very > first step taken in this direction. Hence, 'foreach' is ported to > submodule--helper, and submodule--helper is called from git-submodule.sh. > The code is split up to have one function to

Re: [GSoC][PATCH v5 2/3] t7407: test "submodule foreach --recursive" from subdirectory added

On 05/26, Prathamesh Chavan wrote: > Additional test cases added to the submodule-foreach test suite > to check the submodule foreach --recursive behavior from a > subdirectory as this was missing from the test suite. > > Helped-by: Brandon Williams > Mentored-by: Christian

Re: [GSoC][PATCH v5 1/3] submodule: fix buggy $path and $sm_path variable's value

On 26/05/17 16:17, Prathamesh Chavan wrote: > According to the documentation about git-submodule foreach subcommand's > $path variable: > $path is the name of the submodule directory relative to the superproject > > But it was observed when the value of the $path value deviates from this > for

Re: persistent-https, url insteadof, and `git submodule`

Hi! Thanks for the responses (I hope reply-all isn't bad mailing-list etiquette? Feel free to yell at with a direct reply!). For whatever it's worth, as a random user, here's my thoughts: On Sat, May 20, 2017 at 2:07 AM, Jeff King wrote: > On Fri, May 19, 2017 at 11:55:34PM +0200,

Re: [GSoC][PATCH v5 2/3] t7407: test "submodule foreach --recursive" from subdirectory added

On Fri, May 26, 2017 at 8:17 AM, Prathamesh Chavan wrote: > Additional test cases added to the submodule-foreach test suite > to check the submodule foreach --recursive behavior from a > subdirectory as this was missing from the test suite. As this demonstrates the fixture of

Re: [GSoC][PATCH v5 3/3] submodule: port subcommand foreach from shell to C

On Fri, May 26, 2017 at 8:17 AM, Prathamesh Chavan wrote: > This aims to make git-submodule foreach a builtin. Cool. I reviewed the code and only have one minor nit. > +static void runcommand_in_submodule(const struct cache_entry *list_item, > +

Re: [PATCH v2 6/6] fsmonitor: add a sample query-fsmonitor hook script for Watchman

On 5/26/2017 5:47 AM, Ævar Arnfjörð Bjarmason wrote: On Wed, May 24, 2017 at 3:12 PM, Christian Couder wrote: On Thu, May 18, 2017 at 10:13 PM, Ben Peart wrote: This hook script integrates the new fsmonitor capabilities of git with the cross

[GSoC][PATCH v5 2/3] t7407: test "submodule foreach --recursive" from subdirectory added

Additional test cases added to the submodule-foreach test suite to check the submodule foreach --recursive behavior from a subdirectory as this was missing from the test suite. Helped-by: Brandon Williams Mentored-by: Christian Couder Mentored-by:

[GSoC][PATCH v5 3/3] submodule: port subcommand foreach from shell to C

This aims to make git-submodule foreach a builtin. This is the very first step taken in this direction. Hence, 'foreach' is ported to submodule--helper, and submodule--helper is called from git-submodule.sh. The code is split up to have one function to obtain all the list of submodules. This

[GSoC][PATCH v5 1/3] submodule: fix buggy $path and $sm_path variable's value

According to the documentation about git-submodule foreach subcommand's $path variable: $path is the name of the submodule directory relative to the superproject But it was observed when the value of the $path value deviates from this for the nested submodules when the is run from a

Re: [PATCHv3 2/4] Documentation/clone: document ignored configuration variables

On Mon, May 15, 2017 at 1:05 PM, SZEDER Gábor wrote: > Due to limitations/bugs in the current implementation, some > configuration variables specified via 'git clone -c var=val' (or 'git > -c var=val clone') are ignored during the initial fetch and checkout. > > Let the

Re: [PATCHv3 1/4] clone: respect additional configured fetch refspecs during initial fetch

On Fri, May 26, 2017 at 12:04:03PM +0200, SZEDER Gábor wrote: > > but given that it lazy-parses in > > some cases, it feels a little dangerous. > > I'm not sure about lazy parsing. > remote_get() returns a fully-parsed, cached struct remote instance > without re-reading the configuration, so all

Re: [RFC/PATCH] recognize pathspec magic without "--" disambiguation

On Fri, May 26, 2017 at 11:13:55AM +0900, Junio C Hamano wrote: > >- git log :^foo > > (when "^foo" exists in your index) > > > > The same logic applies; it would continue to work. And > > ditto for any other weird filenames in your index like > > "(attr)foo". > >

GREETINGS,

GREETINGS, I AM BORTE ,MY DOCTOR JUST CONFIRM THAT I HAVE OVARIAN CANCER AND I HAVE FEW WEEKS TO LIVE, SO I HAVE DECIDED TO DONATE EVERYTHING I HAVE TO THE ORPHANAGE AND THE POOR WIDOWS THROUGH YOU IN YOUR AREA.PLEASE KINDLY REPLY ME ONLY ON MY EMAIL ADDRES HERE (missboteogotai@gmail. com)

Re: .Setting Up Charity Foundation !

***. Peace be with you, Gladly seek for your sincere help in setting up a Charitable Organization to help the less privileged, old aged and vulnerable people under your care, It is my desire to use my late husband wealth of $3,000,000.00 to set up a charity foundation to help the needy and the

Re: [PATCHv3 1/4] clone: respect additional configured fetch refspecs during initial fetch

On Tue, May 16, 2017 at 1:07 AM, Jeff King wrote: >> @@ -989,6 +994,10 @@ int cmd_clone(int argc, const char **argv, const char >> *prefix) >> strbuf_reset(); >> >> remote = remote_get(option_origin); >> + REALLOC_ARRAY(remote->fetch, remote->fetch_refspec_nr + 1);

Re: [PATCH v2 1/7] grep: don't redundantly compile throwaway patterns under threading

Ævar Arnfjörð Bjarmason writes: > To be clear the point of my mail was not to say "I can't think of a > way to support both of these things, help!", obviously we can continue > to maintain two codepaths. The point was to raise the idea that we > could simply remove the more

Re: [PATCH v2 6/6] fsmonitor: add a sample query-fsmonitor hook script for Watchman

On Wed, May 24, 2017 at 3:12 PM, Christian Couder wrote: > On Thu, May 18, 2017 at 10:13 PM, Ben Peart wrote: >> This hook script integrates the new fsmonitor capabilities of git with >> the cross platform Watchman file watching service. To use the

Re: Hide decorations in git log

On Wed, May 24, 2017 at 4:22 PM, Robert Dailey wrote: > Is it possible to hide decorated refs in `git log` even if they are > reachable from the refs I'm actually interested in seeing the logs of? > > For example, if I do `git log --graph --decorate --oneline --branches

Re: [PATCH v2 1/7] grep: don't redundantly compile throwaway patterns under threading

On Fri, May 26, 2017 at 2:58 AM, Junio C Hamano wrote: > Ævar Arnfjörð Bjarmason writes: > >> I think it's a pointless distraction to start speculating in this >> commit message what we're going to do with --debug it if it ever >> starts emitting some

Re: Bug report: Corrupt pack file after committing a large file (>4 GB?)

On 2017-05-26 07:51, Yu-Hsuan Chen wrote: > Dear maintainer, > > There is a bug where committing a large file corrupts the pack file in > Windows. Steps to recreate are: > > 1. git init > 2. stage and commit a file larger than 4 GB (not entirely sure about this > size) > 3. git checkout -f > >

Re: Bug report: Corrupt pack file after committing a large file (>4 GB?)

On Fri, May 26, 2017 at 01:51:34PM +0800, Yu-Hsuan Chen wrote: > There is a bug where committing a large file corrupts the pack file in > Windows. Steps to recreate are: > > 1. git init > 2. stage and commit a file larger than 4 GB (not entirely sure about this > size) > 3. git checkout -f > >