[credential.helper] unexpectedly save credential to multiple credential files

1. git config --global credential.helper store 2. cd to a local repository directory, git config credential.helper store --file ./my_cred 3. execute some git command which need credential like git ls-remote 4. input my username & password, command done. As the result, **BOTH** the ./my_cred and

Re: [git-for-windows] [ANNOUNCE] Prerelease: Git for Windows v2.11.0-rc0

On 10 Nov 2016, at 22:39, Johannes Schindelin wrote: > Hi Lars, > > On Wed, 9 Nov 2016, Lars Schneider wrote: > >> On 05 Nov 2016, at 10:50, Johannes Schindelin >> wrote: >> >>> I finally got around to rebase the Windows-specific

Re: [PATCH v7 01/17] ref-filter: implement %(if), %(then), and %(else) atoms

On Fri, Nov 11, 2016 at 4:43 AM, Junio C Hamano wrote: > Jacob Keller writes: > >> Ok, so I have only one minor nit, but otherwise this looks quite good >> to me. A few comments explaining my understanding, but only one >> suggested >> change which is

Re: [RFC] Add way to make Git credentials accessible from clean/smudge filter

On Fri, Nov 11, 2016 at 10:28:56AM +0100, Lars Schneider wrote: > > Yeah, that is the solution I was going to suggest. The credentials are > > totally orthogonal to the filters, and I would rather not shove them > > into the protocol. It's an extra process, but with the new multi-use > > smudge

Re: [RFC] Add way to make Git credentials accessible from clean/smudge filter

On 11 Nov 2016, at 10:31, Jeff King wrote: > On Fri, Nov 11, 2016 at 10:28:56AM +0100, Lars Schneider wrote: > >>> Yeah, that is the solution I was going to suggest. The credentials are >>> totally orthogonal to the filters, and I would rather not shove them >>> into the

Re: [PATCH] t6026: ensure that long-running script really is

On Fri, Nov 11, 2016 at 07:50:14AM +0100, Johannes Sixt wrote: > Shouldn't we then move the 'kill' out of test_when_finished and make > it a proper condition of the test? Like this? > > diff --git a/t/t6026-merge-attr.sh b/t/t6026-merge-attr.sh > index 348d78b205..6ad8bd098a 100755 > ---

Re: [PATCH v1 2/2] travis-ci: disable GIT_TEST_HTTPD for macOS

On Fri, Nov 11, 2016 at 09:22:51AM +0100, Lars Schneider wrote: > There would be an alternative way to approach the problem: > Someone (GitHub?, BitBucket?, GitLab?, ...) could setup a bunch of webservers > with popular configurations and a way to reset a clean test environment. Then > the

Assalamu`Alaikum.

Greetings from Dr. mohammad ouattara. Assalamu`Alaikum. My Name is Dr. mohammad ouattara, I am a banker by profession. I'm from Ouagadougou, Burkina Faso, West Africa. My reason for contacting you is to transfer an abandoned $10.6M to your account. The owner of this fund died since 2004 with

pre-rebase, post-rewrite, ...

Hi all, I am using the pre-rebase hook to generate a tag. I am using this tag to check if my rebase lost any commits or content when i'm cleaning up my local commit history. What i now want to do is using a post-rebase hook to make a diff check and remove my generated tag in case there is no

Re: [RFC] Add way to make Git credentials accessible from clean/smudge filter

On 10 Nov 2016, at 17:08, Jeff King wrote: > On Thu, Nov 10, 2016 at 01:10:17PM +0100, Matthieu Moy wrote: > >> Lars Schneider writes: >> >>> I haven't looked at an implemenation approach at all. I wonder if this could >>> be OK from a conceptional

Re: [PATCH v1 0/2] Fix default macOS build locally and on Travis CI

On 10 Nov 2016, at 22:34, Junio C Hamano wrote: > Lars Schneider writes: > >>> I've followed what was available at the public-inbox archive, but it >>> is unclear what the conclusion was. >>> >>> For the first one your "how about" non-patch, to

Re: [PATCH v1 2/2] travis-ci: disable GIT_TEST_HTTPD for macOS

On Fri, Nov 11, 2016 at 10:13:44AM +0100, Lars Schneider wrote: > > If you did want to have a more real-world network-based test, I think > > the right solution is not for GitHub to set up a bunch of mock servers, > > but to design client-side tests that hit the _real_ GitHub (or GitLab, > > or

Re: [credential.helper] unexpectedly save credential to multiple credential files

On Fri, Nov 11, 2016 at 04:10:55PM +0800, Qi Nark wrote: > 1. git config --global credential.helper store > 2. cd to a local repository directory, git config credential.helper > store --file ./my_cred > 3. execute some git command which need credential like git ls-remote > 4. input my username &

Re: [PATCH v7 01/17] ref-filter: implement %(if), %(then), and %(else) atoms

On Fri, Nov 11, 2016 at 4:50 AM, Junio C Hamano wrote: > Karthik Nayak writes: > >>> Minor nit. I'm not sure what standard we use here at Git, but >>> traditionally, I prefer to see { } blocks on all sections even if only >>> one of them needs it. (That

Re: [PATCH v1 2/2] travis-ci: disable GIT_TEST_HTTPD for macOS

On 11 Nov 2016, at 09:47, Jeff King wrote: > On Fri, Nov 11, 2016 at 09:22:51AM +0100, Lars Schneider wrote: > >> There would be an alternative way to approach the problem: >> Someone (GitHub?, BitBucket?, GitLab?, ...) could setup a bunch of webservers >> with popular

Re: [credential.helper] unexpectedly save credential to multiple credential files

On Fri, Nov 11, 2016 at 4:36 PM, Jeff King wrote: > On Fri, Nov 11, 2016 at 04:10:55PM +0800, Qi Nark wrote: > >> 1. git config --global credential.helper store >> 2. cd to a local repository directory, git config credential.helper >> store --file ./my_cred >> 3. execute some git

Re: [PATCH v1 2/2] travis-ci: disable GIT_TEST_HTTPD for macOS

On 10 Nov 2016, at 17:10, Jeff King wrote: > On Thu, Nov 10, 2016 at 12:07:14PM +0100, Lars Schneider wrote: > >>> Using Apache in the tests has been the source of frequent portability >>> problems and configuration headaches. I do wonder if we'd be better off >>> using some

[PATCH] doc: fix location of 'info/' with $GIT_COMMON_DIR

With the introduction of the $GIT_COMMON_DIR variable, the repository layout manual was changed to reflect the location for many files in case the variable is set. While adding the new locations, one typo snuck in regarding the location of the 'info/' folder, which is falsely claimed to reside at

[PATCH v6 01/16] Git.pm: add subroutines for commenting lines

Add subroutines prefix_lines and comment_lines. Signed-off-by: Vasco Almeida --- perl/Git.pm | 24 1 file changed, 24 insertions(+) diff --git a/perl/Git.pm b/perl/Git.pm index b2732822a..69cd1ddec 100644 --- a/perl/Git.pm +++ b/perl/Git.pm @@

[PATCH v6 10/16] i18n: add--interactive: remove %patch_modes entries

Remove unnecessary entries from %patch_modes. After the i18n conversion, these entries are not used anymore. Signed-off-by: Vasco Almeida --- git-add--interactive.perl | 21 - 1 file changed, 21 deletions(-) diff --git a/git-add--interactive.perl

[PATCH v6 04/16] i18n: add--interactive: mark strings with interpolation for translation

Since at this point Git::I18N.perl lacks support for Perl i18n placeholder substitution, use of sprintf following die or error_msg is necessary for placeholder substitution take place. Signed-off-by: Vasco Almeida --- git-add--interactive.perl | 25

[PATCH v6 09/16] i18n: add--interactive: mark edit_hunk_manually message for translation

Mark message of edit_hunk_manually displayed in the editing file when user chooses 'e' option. The message had to be unfolded to allow translation of the $participle verb. Some messages end up being exactly the same for some use cases, but left it for easier change in the future, e.g., wanting

[PATCH v6 07/16] i18n: add--interactive: mark patch prompt for translation

Mark prompt message assembled in place for translation, unfolding each use case for each entry in the %patch_modes hash table. Previously, this script relied on whether $patch_mode was set to run the command patch_update_cmd() or show status and loop the main loop. Now, it uses $cmd to indicate

[PATCH v6 13/16] i18n: send-email: mark warnings and errors for translation

Mark warnings, errors and other messages for translation. Signed-off-by: Vasco Almeida --- git-send-email.perl | 34 +- 1 file changed, 17 insertions(+), 17 deletions(-) diff --git a/git-send-email.perl b/git-send-email.perl index

[PATCH v6 16/16] i18n: difftool: mark warnings for translation

Signed-off-by: Vasco Almeida --- git-difftool.perl | 22 -- 1 file changed, 12 insertions(+), 10 deletions(-) diff --git a/git-difftool.perl b/git-difftool.perl index a5790d03a..8d3632e55 100755 --- a/git-difftool.perl +++ b/git-difftool.perl @@ -22,6

[PATCH v6 08/16] i18n: add--interactive: i18n of help_patch_cmd

Mark help message of help_patch_cmd for translation. The message must be unfolded to be free of variables so we can have high quality translations. Signed-off-by: Vasco Almeida --- git-add--interactive.perl | 54 --- 1 file

[PATCH v6 14/16] i18n: send-email: mark string with interpolation for translation

Mark warnings, errors and other messages that are interpolated for translation. We call sprintf() before calling die() and in few other circumstances in order to replace the values on the placeholders. Signed-off-by: Vasco Almeida --- git-send-email.perl | 87

[PATCH v6 06/16] i18n: add--interactive: mark plural strings

Mark plural strings for translation. Unfold each action case in one entire sentence. Pass new keyword for xgettext to extract. Update test to include new subroutine __n() for plural strings handling. Update documentation to include a description of the new __n() subroutine. Signed-off-by:

[PATCH v6 12/16] i18n: send-email: mark strings for translation

Mark strings often displayed to the user for translation. Signed-off-by: Vasco Almeida --- git-send-email.perl | 54 +++-- 1 file changed, 32 insertions(+), 22 deletions(-) diff --git a/git-send-email.perl

[PATCH v6 02/16] i18n: add--interactive: mark strings for translation

Mark simple strings (without interpolation) for translation. Brackets around first parameter of ternary operator is necessary because otherwise xgettext fails to extract strings marked for translation from the rest of the file. Signed-off-by: Vasco Almeida ---

[PATCH v6 00/16] Mark strings in Perl scripts for translation

Mark messages in some perl scripts for translation. Changes in this re-roll v6: - Change implementation of prefix_lines subroutine to allow arbitrary number of strings as arguments. - Change a few marks for translation hopefully to be easier on the eyes. Interdiff included below. Vasco

[PATCH v6 15/16] i18n: send-email: mark composing message for translation

When composing an e-mail, there is a message for the user whose lines are beginning in "GIT:" that can be marked for translation. Signed-off-by: Vasco Almeida --- git-send-email.perl | 16 +--- 1 file changed, 9 insertions(+), 7 deletions(-) diff --git

[PATCH v6 11/16] i18n: add--interactive: mark status words for translation

Mark words 'nothing', 'unchanged' and 'binary' used to display what has been staged or not, in "git add -i" status command. Alternatively one could mark N__('nothing') no-op in order to xgettext(1) extract the string and then trigger the translation at run time only with __($print->{FILE}), but

[PATCH v6 05/16] i18n: clean.c: match string with git-add--interactive.perl

Change strings for help to match the ones in git-add--interactive.perl. The strings now represent one entry to translate each rather then two entries each different only by an ending newline character. Signed-off-by: Vasco Almeida --- builtin/clean.c | 10 +- 1

[PATCH v6 03/16] i18n: add--interactive: mark simple here-documents for translation

Mark messages in here-documents without interpolation for translation. The here-document delimiter \EOF, which is the same as 'EOF', indicates that the text is to be treated literally without interpolation of its content. Unfortunately xgettext is not able to extract here-documents delimited

Re: 2.11.0-rc1 will not be tagged for a few days

Hi, On Fri, 11 Nov 2016, Johannes Schindelin wrote: > On Thu, 10 Nov 2016, Junio C Hamano wrote: > > > Junio C Hamano writes: > > > > > I'll report back an updated schedule when able. > > > > I pushed some updates out on 'master' today. > > Which means that t0021 is now

Re: [PATCH] mingw: hot-fix t5615

Am 11.11.2016 um 18:06 schrieb Junio C Hamano: Johannes Schindelin writes: That test made the incorrect assumption that the path separator character is always a colon. On Windows, it is a semicolon instead. Documentation/git.txt says that

Re: [ANNOUNCE] Prerelease: Git for Windows v2.11.0-rc0

Hi Stefan, On Fri, 11 Nov 2016, Johannes Schindelin wrote: > Will keep you posted, I published the prerelease: https://github.com/git-for-windows/git/releases/tag/v2.11.0-rc0.windows.2 Thanks, Dscho

Re: [PATCH] t0021, t5615: use $PWD instead of $(pwd) in PATH-like shell variables

On Fri, Nov 11, 2016 at 06:31:48PM +0100, Johannes Sixt wrote: > We have to use $PWD instead of $(pwd) because on Windows the latter > would add a C: style path to bash's Unix-style $PATH variable, which > becomes confused by the colon after the drive letter. ($PWD is a > Unix-style path.) > >

Re: [RFC] Add way to make Git credentials accessible from clean/smudge filter

On Fri, 2016-11-11 at 10:40 +0100, Lars Schneider wrote: > On 11 Nov 2016, at 10:31, Jeff King wrote: > > > On Fri, Nov 11, 2016 at 10:28:56AM +0100, Lars Schneider wrote: > > > > > > Yeah, that is the solution I was going to suggest. The credentials are > > > > totally

Re: [PATCH] t0021, t5615: use $PWD instead of $(pwd) in PATH-like shell variables

Johannes Sixt writes: > We have to use $PWD instead of $(pwd) because on Windows the latter > would add a C: style path to bash's Unix-style $PATH variable, which > becomes confused by the colon after the drive letter. ($PWD is a > Unix-style path.) > > In the case of

Re: [git-for-windows] [ANNOUNCE] Prerelease: Git for Windows v2.11.0-rc0

Hi Lars, On Fri, 11 Nov 2016, Lars Schneider wrote: > > On 10 Nov 2016, at 22:39, Johannes Schindelin > wrote: > > > Hi Lars, > > > > On Wed, 9 Nov 2016, Lars Schneider wrote: > > > >> On 05 Nov 2016, at 10:50, Johannes Schindelin >

Re: 2.11.0-rc1 will not be tagged for a few days

> On 11 Nov 2016, at 17:13, Johannes Schindelin > wrote: > > Hi Junio, > > On Thu, 10 Nov 2016, Junio C Hamano wrote: > >> Junio C Hamano writes: >> >>> I'll report back an updated schedule when able. >> >> I pushed some updates out on

[PATCH v2] upload-pack: Optionally allow fetching any sha1

It seems a little silly to do a reachabilty check in the case where we trust the user to access absolutely everything in the repository. Also, it's racy in a distributed system -- perhaps one server advertises a ref, but another has since had a force-push to that ref, and perhaps the two HTTP

Re: 2.11.0-rc1 will not be tagged for a few days

> On 11 Nov 2016, at 18:31, Lars Schneider wrote: > >> >> On 11 Nov 2016, at 18:05, Lars Schneider wrote: >> >> >>> On 11 Nov 2016, at 17:13, Johannes Schindelin >>> wrote: >>> >>> Hi Junio, >>> >>> On Thu,

Re: 2.11.0-rc1 will not be tagged for a few days

> On 11 Nov 2016, at 18:05, Lars Schneider wrote: > > >> On 11 Nov 2016, at 17:13, Johannes Schindelin >> wrote: >> >> Hi Junio, >> >> On Thu, 10 Nov 2016, Junio C Hamano wrote: >> >>> Junio C Hamano writes: >>>

[PATCH] t0021, t5615: use $PWD instead of $(pwd) in PATH-like shell variables

We have to use $PWD instead of $(pwd) because on Windows the latter would add a C: style path to bash's Unix-style $PATH variable, which becomes confused by the colon after the drive letter. ($PWD is a Unix-style path.) In the case of GIT_ALTERNATE_OBJECT_DIRECTORIES, bash on Windows assembles a

Re: [PATCH] mingw: hot-fix t5615

On Fri, Nov 11, 2016 at 05:29:33PM +0100, Johannes Schindelin wrote: > That test made the incorrect assumption that the path separator character > is always a colon. On Windows, it is a semicolon instead. Oof, sorry about that. I remember being careful about the ";" while doing the original

Re: 2.11.0-rc1 will not be tagged for a few days

Hi Junio, On Thu, 10 Nov 2016, Junio C Hamano wrote: > Junio C Hamano writes: > > > I'll report back an updated schedule when able. > > I pushed some updates out on 'master' today. Which means that t0021 is now broken also on `master` when running in Git for Windows' SDK.

[PATCH] upload-pack: Optionally allow fetching any sha1

It seems a little silly to do a reachabilty check in the case where we trust the user to access absolutely everything in the repository. Also, it's racy in a distributed system -- perhaps one server advertises a ref, but another has since had a force-push to that ref, and perhaps the two HTTP

Re: [ANNOUNCE] Prerelease: Git for Windows v2.11.0-rc0

Hi Stefan, On Thu, 10 Nov 2016, stefan.na...@atlas-elektronik.com wrote: > Am 05.11.2016 um 10:50 schrieb Johannes Schindelin: > > Dear Git users, > > > > I finally got around to rebase the Windows-specific patches (which seem to > > not make it upstream as fast as we get new ones) on top of

[PATCH] mingw: hot-fix t5615

That test made the incorrect assumption that the path separator character is always a colon. On Windows, it is a semicolon instead. Signed-off-by: Johannes Schindelin --- Published-As: https://github.com/dscho/git/releases/tag/t5615-path-separator-v1 Fetch-It-Via: git

Re: [PATCH] mingw: hot-fix t5615

Johannes Schindelin writes: > That test made the incorrect assumption that the path separator character > is always a colon. On Windows, it is a semicolon instead. Documentation/git.txt says that GIT_ALTERNATE_OBJECT_DIRECTORIES is separated with ";" on Windows

[PATCH] fetch-pack.c: correct command at the beginning of an error message

One error message in fetch-pack.c uses 'git fetch_pack' at the beginning which is not a git command. Use 'git fetch-pack' instead. Signed-off-by: Ralf Thielow --- fetch-pack.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fetch-pack.c

Nujna response.//..

Steve Bhatti, Operations / regionalni direktor Santander Bank Plc, 47-48 Piccadilly PICCADILLY W1J0DT London, Združeno Kraljestvo Hi, Sem Steve Bhatti, od Harlesden North West London, vodja oddelka racunovodskega revidiranja in formalno višji vodja programer pri Deutsche bank, tukaj v Angliji

Re: 2.11.0-rc1 will not be tagged for a few days

Lars Schneider writes: > Part of the reason is that Hannes' squash got lost: > http://public-inbox.org/git/d36d8b51-f2d7-a2f5-89ea-369f49556...@kdbg.org/ > > @Junio: Can you apply this (see discussion with Peff linked to email above). Thanks for a quick and usable

Re: [RFC] Add way to make Git credentials accessible from clean/smudge filter

On Fri, Nov 11, 2016 at 09:02:52PM +0100, Dennis Kaarsemaker wrote: > > > Are you sure about that? If I do: > > > > > > echo url=https://example.com/repo.git | > > > git credential fill > > > > > > I get prompted for a username and password. > > > > > > Hm.. either I don't understand you or

[PATCH 2/2] diff --no-index: support reading from pipes

diff <(command1) <(command2) provides useful output, let's make it possible for git to do the same. Signed-off-by: Dennis Kaarsemaker --- diff-no-index.c | 8 diff.c | 13 +++-- 2 files changed, 19 insertions(+), 2 deletions(-) diff --git

[PATCH 1/2] diff --no-index: add option to follow symlinks

Git's diff machinery does not follow symlinks, which makes sense as git itself also does not, but stores the symlink destination. In --no-index mode however, it is useful for diff to be able to follow symlinks, matching the behaviour of ordinary diff. Signed-off-by: Dennis Kaarsemaker

[RFC/PATCH 0/2] git diff <(command1) <(command2)

Today on #git, a user asked why git diff <(command1) <(command2) gave only some gibberish about pipes as output. The answer is fairly simple: git diff gets as arguments /dev/fd/62 and /dev/fd/63, which are symlinks. So git simply readlink()s them and gets pipe:[123456] as destination of that link

Re: 2.11.0-rc1 will not be tagged for a few days

Am 11.11.2016 um 18:38 schrieb Lars Schneider: On 11 Nov 2016, at 18:31, Lars Schneider wrote: On 11 Nov 2016, at 18:05, Lars Schneider wrote: @Dscho: There is still one remaining new issue with t0021 ... investigating! "17 - required

Re: [PATCH v2] t6026: ensure that long-running script really is

Am 11.11.2016 um 22:09 schrieb Junio C Hamano: Johannes Sixt writes: Am 11.11.2016 um 21:48 schrieb Junio C Hamano: Johannes Sixt writes: Good point. Here is an updated version. Unfortunately, I already took the version before this one and started my

Re: 2.11.0-rc1 will not be tagged for a few days

Am 11.11.2016 um 22:07 schrieb Junio C Hamano: Junio C Hamano writes: OK, then let's have filter_git () { rm -f rot13-filter.log && git "$@" ... and call that -rc1. That is, to queue this on top of

Re: [RFC/PATCH 0/2] git diff <(command1) <(command2)

On Fri, Nov 11, 2016 at 12:19 PM, Dennis Kaarsemaker wrote: > Today on #git, a user asked why git diff <(command1) <(command2) gave only > some > gibberish about pipes as output. The answer is fairly simple: git diff gets as > arguments /dev/fd/62 and /dev/fd/63, which

Re: [PATCH v2 5/6] grep: enable recurse-submodules to work on objects

On 10/31/2016 03:38 PM, Brandon Williams wrote: diff --git a/Documentation/git-grep.txt b/Documentation/git-grep.txt index 17aa1ba..386a868 100644 --- a/Documentation/git-grep.txt +++ b/Documentation/git-grep.txt @@ -26,7 +26,7 @@ SYNOPSIS [--threads ] [-f ] [-e]

Re: [RFC/PATCH 0/2] git diff <(command1) <(command2)

On Fri, Nov 11, 2016 at 1:27 PM, Junio C Hamano wrote: > Dennis Kaarsemaker writes: > >> No tests or documentation updates yet, and I'm not sure whether >> --follow-symlinks in other modes than --no-index should be supported, ignored >> (as it is now)

[ANNOUNCE] Git v2.11.0-rc1

A release candidate Git v2.11.0-rc1 is now available for testing at the usual places. It is comprised of 642 non-merge commits since v2.10.0, contributed by 66 people, 14 of which are new faces. Due to the last-minute fixups and timezone differences, there might be a few more updates to test

What's cooking in git.git (Nov 2016, #02; Fri, 11)

Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. The ones marked with '.' do not appear in any of the integration branches, but I am still holding onto them. v2.11-rc1 has been tagged. There

[PATCH v3 0/6] recursively grep across submodules

Most of the changes between v2 and v3 of this series were to address the few reviewer comments. * use 'path' as the directory to cd into for the child process and use 'name' for the super_prefix * flush output from childprocess on error and print a more useful error msg * change

[PATCH v3 6/6] grep: search history of moved submodules

If a submodule was renamed at any point since it's inception then if you were to try and grep on a commit prior to the submodule being moved, you wouldn't be able to find a working directory for the submodule since the path in the past is different from the current path. This patch teaches grep

[PATCH v3 1/6] submodules: add helper functions to determine presence of submodules

Add two helper functions to submodules.c. `is_submodule_initialized()` checks if a submodule has been initialized at a given path and `is_submodule_populated()` check if a submodule has been checked out at a given path. Signed-off-by: Brandon Williams --- submodule.c | 38

[PATCH v3 5/6] grep: enable recurse-submodules to work on objects

Teach grep to recursively search in submodules when provided with a object. This allows grep to search a submodule based on the state of the submodule that is present in a commit of the super project. When grep is provided with a object, the name of the object is prefixed to all output. In

[PATCH v3 2/6] submodules: load gitmodules file from commit sha1

teach submodules to load a '.gitmodules' file from a commit sha1. This enables the population of the submodule_cache to be based on the state of the '.gitmodules' file from a particular commit. Signed-off-by: Brandon Williams --- cache.h| 2 ++ config.c

[PATCH v3 4/6] grep: optionally recurse into submodules

Allow grep to recognize submodules and recursively search for patterns in each submodule. This is done by forking off a process to recursively call grep on each submodule. The top level --super-prefix option is used to pass a path to the submodule which can in turn be used to prepend to output

[PATCH v3 3/6] grep: add submodules as a grep source type

Add `GREP_SOURCE_SUBMODULE` as a grep_source type and cases for this new type in the various switch statements in grep.c. When initializing a grep_source with type `GREP_SOURCE_SUBMODULE` the identifier can either be NULL (to indicate that the working tree will be used) or a SHA1 (the REV of the

Re: [PATCH v3 2/6] submodules: load gitmodules file from commit sha1

On Fri, Nov 11, 2016 at 3:51 PM, Brandon Williams wrote: > teach submodules to load a '.gitmodules' file from a commit sha1. This > enables the population of the submodule_cache to be based on the state > of the '.gitmodules' file from a particular commit. This is the actual

Re: [PATCH v3 6/6] grep: search history of moved submodules

On Fri, Nov 11, 2016 at 3:51 PM, Brandon Williams wrote: > + > + rm -rf parent sub This line sounds like a perfect candidate for "test_when_finished" at the beginning of the test

Re: [PATCH v2] t6026: ensure that long-running script really is

Am 11.11.2016 um 21:48 schrieb Junio C Hamano: Johannes Sixt writes: Good point. Here is an updated version. Unfortunately, I already took the version before this one and started my integration cycle today. I'll wiggle this in; it essentially is about adding a big comment to

Re: [RFC/PATCH 0/2] git diff <(command1) <(command2)

Dennis Kaarsemaker writes: > No tests or documentation updates yet, and I'm not sure whether > --follow-symlinks in other modes than --no-index should be supported, ignored > (as it is now) or cause an error, but I'm leaning towards the third option. My knee-jerk

[PATCH v2] t6026: ensure that long-running script really is

When making sure that background tasks are cleaned up in 5babb5b (t6026-merge-attr: clean up background process at end of test case, 2016-09-07), we considered to let the background task sleep longer, just to be certain that it will still be running when we want to kill it after the test. Sadly,

Re: [PATCH v2] t6026: ensure that long-running script really is

Johannes Sixt writes: > Good point. Here is an updated version. Unfortunately, I already took the version before this one and started my integration cycle today. I'll wiggle this in; it essentially is about adding a big comment to explain what is going on and then moving the

Re: 2.11.0-rc1 will not be tagged for a few days

Johannes Sixt writes: > Good to know that I am not alone. This one fails consistently for > me. I dug into it a bit today, but it drives me mad. Process Monitor > reports that the redirected-to file (git-stderr.log) gets marked as > "Delete pending" by git.exe, but I have

Re: [PATCH v2] t6026: ensure that long-running script really is

Johannes Sixt writes: > Am 11.11.2016 um 21:48 schrieb Junio C Hamano: >> Johannes Sixt writes: >> >>> Good point. Here is an updated version. >> >> Unfortunately, I already took the version before this one and >> started my integration cycle today. I'll wiggle

Re: 2.11.0-rc1 will not be tagged for a few days

Junio C Hamano writes: > OK, then let's have > > filter_git () { > rm -f rot13-filter.log && > git "$@" > ... > > and call that -rc1. That is, to queue this on top of ls/filter-process and merge it down. -- >8 -- Subject:

[PATCH v3] rebase: add --forget to cleanup rebase, leave everything else untouched

There are occasions when you decide to abort an in-progress rebase and move on to do something else but you forget to do "git rebase --abort" first. Or the rebase has been in progress for so long you forgot about it. By the time you realize that (e.g. by starting another rebase) it's already too

[PATCH 08/11] worktree move: new command

There are two options to move the main worktree, but both have complications, so it's not implemented yet. Anyway the options are: - convert the main worktree to a linked one and move it away, leave the git repository where it is. The repo essentially becomes bare after this move. - move

[PATCH 11/11] worktree remove: new command

Signed-off-by: Nguyễn Thái Ngọc Duy --- Documentation/git-worktree.txt | 21 + builtin/worktree.c | 78 ++ contrib/completion/git-completion.bash | 5 ++- t/t2028-worktree-move.sh | 26

[PATCH 03/11] copy.c: convert bb_(p)error_msg to error(_errno)

Signed-off-by: Nguyễn Thái Ngọc Duy --- copy.c | 85 -- 1 file changed, 31 insertions(+), 54 deletions(-) diff --git a/copy.c b/copy.c index b7a87f1..074b609 100644 --- a/copy.c +++ b/copy.c @@ -82,23 +82,16 @@

[PATCH 10/11] worktree move: refuse to move worktrees with submodules

Submodules contains .git files with relative paths. After a worktree move, these files need to be updated or they may point to nowhere. This is a bandage patch to make sure "worktree move" don't break people's worktrees by accident. When .git file update code is in place, this

[PATCH 07/11] worktree.c: add update_worktree_location()

Signed-off-by: Nguyễn Thái Ngọc Duy --- worktree.c | 21 + worktree.h | 6 ++ 2 files changed, 27 insertions(+) diff --git a/worktree.c b/worktree.c index 7e15ec7..db63758 100644 --- a/worktree.c +++ b/worktree.c @@ -354,6 +354,27 @@ int

[PATCH 04/11] copy.c: style fix

Signed-off-by: Nguyễn Thái Ngọc Duy --- copy.c | 50 +- 1 file changed, 29 insertions(+), 21 deletions(-) diff --git a/copy.c b/copy.c index 074b609..60c7d8a 100644 --- a/copy.c +++ b/copy.c @@ -111,8 +111,10 @@ int FAST_FUNC

[PATCH 09/11] worktree move: accept destination as directory

Similar to "mv a b/", which is actually "mv a b/a", we extract basename of source worktree and create a directory of the same name at destination if dst path is a directory. Signed-off-by: Nguyễn Thái Ngọc Duy --- builtin/worktree.c | 19 ++- 1 file changed,

Re: [PATCH] doc: fix location of 'info/' with $GIT_COMMON_DIR

On Fri, Nov 11, 2016 at 6:23 PM, Patrick Steinhardt wrote: > With the introduction of the $GIT_COMMON_DIR variable, the > repository layout manual was changed to reflect the location for > many files in case the variable is set. While adding the new > locations, one typo snuck in

[PATCH 01/11] copy.c: import copy_file() from busybox

This is busybox's unmodified copy_file() in libbb/copy_file.c from the GPL2+ commit f2c043acfcf9dad9fd3d65821b81f89986bbe54e (busybox: fix uninitialized memory when displaying IPv6 addresses - 2016-01-18). This is a no-op commit. More changes are needed before this new code can compile. This will

[PATCH 00/11] git worktree (re)move

This is mostly a resend from last time [1]. The main difference is patch 10/11 to prevent moving a worktree that contains submodules because these .git files may need rewritten to point to the right place. I'm leaving the rewriting .git files for future (preferably done by "submodules guys"). [1]

[PATCH 06/11] worktree.c: add validate_worktree()

This function is later used by "worktree move" and "worktree remove" to ensure that we have a good connection between the repository and the worktree. For example, if a worktree is moved manually, the worktree location recorded in $GIT_DIR/worktrees/.../gitdir is incorrect and we should not move

[PATCH 02/11] copy.c: delete unused code in copy_file()

- selinux preservation code - make-link code - delete link dereference code - non-recursive copy code - stat no preservation code - verbose printing code Some of these are "cp" features that we don't need (for "git worktree move"). Some do not make sense in source-control context (SELinux).

Re: [RFC/PATCH 0/2] git diff <(command1) <(command2)

On Fri, 2016-11-11 at 13:27 -0800, Junio C Hamano wrote: > Dennis Kaarsemaker writes: > > > No tests or documentation updates yet, and I'm not sure whether > > --follow-symlinks in other modes than --no-index should be supported, > > ignored > > (as it is now) or cause

Re: [RFC/PATCH 0/2] git diff <(command1) <(command2)

On Sat, Nov 12, 2016 at 07:11:34AM +0100, Dennis Kaarsemaker wrote: > > * If normal "diff" that follows symlinks by default has an option > >to disable it, then it is OK to also add --no-follow-symlinks > >that is only valid in the --no-index mode, so that we can mimick > >it better