[PATCH] submodule operations: tighten pathspec errors

when the pathspec did not match any path, error out. Add the `--error-unmatch` switch to use the old behavior. Signed-off-by: Stefan Beller --- This was taken from the Left Over Bits: git submodule $cmd $pathspec may want to error out when the $pathspec does not match

[PATCH 0/2] Persistent submodule pathspec specification

This was part of the former series 'submodule groups'. However the labeling was ripped out and goes in its own series sb/pathspec-label. First we introduce a switch `--init-default-path` for `git submodule update` which will read the pathspec to initialize the submodules not from the command line

[PATCH 2/2] clone: add --init-submodule= switch

The new switch passes the pathspec to `git submodule update --init` which is called after the actual clone is done. Additionally this configures the submodule.defaultUpdatePath to be the given pathspec, such that any future invocation of `git submodule update --init-default-paths` will keep up

[PATCH 1/2] submodule update: add `--init-default-path` switch

The new switch `--init-default-path` initializes the submodules which are configured in `submodule.defaultUpdatePath` instead of those given as command line arguments before updating. In the first implementation this is made incompatible with further command line arguments as it is unclear what

Re: [PATCH v6 2/9] connect: only match the host with core.gitProxy

Mike Hommey writes: > On Fri, May 20, 2016 at 02:48:28PM -0700, Junio C Hamano wrote: >> So, even if we agree that per-port behaviour is not something we >> would use if we were building the system without any existing users >> today, I do not think we want "git now fails with

Re: [PATCH] userdiff: add built-in pattern for CSS

William Duclot writes: > CSS is widely used, motivating it being included as a built-in pattern. > > It must be noted that the word_regex for CSS (i.e. the regex defining > what is a word in the language) does not consider '.' and '#' characters > (in CSS

Re: [PATCH v6 2/9] connect: only match the host with core.gitProxy

On Fri, May 20, 2016 at 02:48:28PM -0700, Junio C Hamano wrote: > So, even if we agree that per-port behaviour is not something we > would use if we were building the system without any existing users > today, I do not think we want "git now fails with an error" at all. > It goes against the

Re: [PATCH v6 1/9] connect: call get_host_and_port() earlier

On Fri, May 20, 2016 at 03:20:23PM -0700, Junio C Hamano wrote: > Mike Hommey writes: > > >> Can never happen because? > >> > >> !*port means get_host_and_port() made the "port" pointer point at > >> a NUL byte. That does not happen because the only case port is > >>

Re: [PATCH v6 1/9] connect: call get_host_and_port() earlier

Mike Hommey writes: >> Can never happen because? >> >> !*port means get_host_and_port() made the "port" pointer point at >> a NUL byte. That does not happen because the only case port is >> moved by that function is to have it point at a byte after we >> found ':',

What's cooking in git.git (May 2016, #07; Fri, 20)

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. Almost all the topics marked as

Re: [PATCH v6 1/9] connect: call get_host_and_port() earlier

On Fri, May 20, 2016 at 01:58:26PM -0700, Junio C Hamano wrote: > Mike Hommey writes: > > > Currently, get_host_and_port() is called in git_connect() for the ssh > > protocol, and in git_tcp_connect_sock() for the git protocol. Instead > > of doing this, just call it from a

Re: [BUG] A part of an edge from an octopus merge gets colored, even with --color=never

On Tue, May 17, 2016 at 3:55 PM, Jeff King wrote: >> (It's actually the first one which triggers). I'm not familiar enough >> with the code to know whether the col_num computation is bogus, or >> whether we needed to earlier increase the size of the "new_columns" >> field. > > And

Re: [PATCH v2] pull: warn on --verify-signatures with --rebase

Thanks. -- 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: [PATCH v6 2/9] connect: only match the host with core.gitProxy

Mike Hommey writes: > Currently, core.gitProxy doesn't actually match purely on domain names > as documented: it also matches ports. > > So a core.gitProxy value like "script for kernel.org" doesn't make the > script called for an url like git://kernel.org:port/path, while it

Re: [PATCH] t0008: 4 tests fail with ksh88

On Fri, May 20, 2016 at 6:10 PM, Junio C Hamano wrote: > Junio C Hamano writes: > > From: Armin Kunaschik > Date: Fri, 20 May 2016 16:31:30 +0200 > Subject: [PATCH] t0008: 4 tests fail with ksh88 > > In t0008, we have > >

Re: [PATCH v6 1/9] connect: call get_host_and_port() earlier

Mike Hommey writes: > Currently, get_host_and_port() is called in git_connect() for the ssh > protocol, and in git_tcp_connect_sock() for the git protocol. Instead > of doing this, just call it from a single place, right after > parse_connect_url(), and pass the host and port

[PATCH v2] pull: warn on --verify-signatures with --rebase

Previously git-pull silently ignored the --verify-signatures option for --rebase, potentially leaving users in the believe that the rebase operation would check for valid GPG signatures. Implementing --verify-signatures for git-rebase was talked about, but doubts for a valid workflow rose up.

Re: [PATCH v6 1/2] http.c: implement the GIT_TRACE_CURL environment variable

Elia Pinto writes: > diff --git a/http.c b/http.c > index df6dd01..ba32bac 100644 > --- a/http.c > +++ b/http.c > @@ -11,6 +11,7 @@ > #include "gettext.h" > #include "transport.h" > > +static struct trace_key trace_curl = TRACE_KEY_INIT(CURL); > #if

Re: [PATCHv9] pathspec: allow querying for attributes

Thanks. -- 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

[PATCHv9] pathspec: allow querying for attributes

The pathspec mechanism is extended via the new ":(attr:eol=input)pattern/to/match" syntax to filter paths so that it requires paths to not just match the given pattern but also have the specified attrs attached for them to be chosen. Signed-off-by: Stefan Beller --- Junio,

Re: run-command: output owner picking strategy

Stefan Beller writes: > I choose "as much live output" as an approximation of "least amount buffered > over time, i.e. if you were to integrate the buffer size over time > that should be > minimized. (c.f. users waiting for output: http://imgur.com/gallery/lhjhbB9) > I am not

Re: run-command: output owner picking strategy

On Fri, May 20, 2016 at 11:29 AM, William Duclot wrote: >> When running in parallel we already may be out of order >> (relative to serial processing). See the second example in the >> commit message to produce a different order. > > Right, I could (should)

Re: [PATCHv9 4/4] pathspec: allow querying for attributes

Stefan Beller writes: > I checked and it looks wrong. the "exclude" section is indented below > the new attr section > ... > I can resend with your proposed fixes as well. If you do so, please make sure that the way tests check for error condition are consistent. I

Re: run-command: output owner picking strategy

> When running in parallel we already may be out of order > (relative to serial processing). See the second example in the > commit message to produce a different order. Right, I could (should) have understood that by myself. > Consider we scheduled tasks to be run in 3 parallel processes: >

Re: [PATCH 19/21] t9003: become resilient to GETTEXT_POISON

Às 17:59 de 20-05-2016, Junio C Hamano escreveu: > As long as translators do not translate "Did you mean..." to begin a > line with a tab (which I do not think there is any reason to), it is > going to work reliably to grep for "^ lgf$" here, and it will catch > such a potential future bug under

Re: [PATCHv9 4/4] pathspec: allow querying for attributes

On Fri, May 20, 2016 at 11:15 AM, Junio C Hamano wrote: > Junio C Hamano writes: > >> Stefan Beller writes: >> >>> +attr;; >>> +After `attr:` comes a space separated list of "attribute >>> +... >>> ++ >> >> The text looks OK, but does it

Re: [PATCHv8 0/5] pathspec magic extension to search for attributes

Stefan Beller writes: > As a user I'd prefer to be exposed to as few concepts as possible, > and adding yet another concept of sparseness is not a good thing > IMHO, so I'll try to keep it simple there. Yes, and as a user, I'd prefer if I (and all the users) do not have to

Re: [PATCHv9 4/4] pathspec: allow querying for attributes

Junio C Hamano writes: > Stefan Beller writes: > >> +attr;; >> +After `attr:` comes a space separated list of "attribute >> +... >> ++ > > The text looks OK, but does it format well? I didn't check this, but the remainder would look like this squashable

Re: [PATCHv8 0/5] pathspec magic extension to search for attributes

On Fri, May 20, 2016 at 10:00 AM, Junio C Hamano wrote: > Stefan Beller writes: > >> Right. But upon finding the new name for clone, I wondered why >> this has to be submodule specific. The attr pathspecs are also working >> with any other files. So if you

Re: [PATCH 19/21] t9003: become resilient to GETTEXT_POISON

Junio C Hamano writes: > Vasco Almeida writes: > >> Alternatively, we could leave sed alone as it were before this patch and >> use test_i18ngrep instead of grep to fake success under GETTEXT_POISON. >> I think I prefer this way. What do you think? > >

BowlerStudio: using GIT as a file system for distributed robots

I have spent the past year building an new open source robotics development platform and wanted to show you fine folks working on Git: BowlerStudio: https://github.com/NeuronRobotics/BowlerStudio I started working a set of robotics control libraries back in 2009 and have deployed them as the

Re: [PATCH 19/21] t9003: become resilient to GETTEXT_POISON

Vasco Almeida writes: > Alternatively, we could leave sed alone as it were before this patch and > use test_i18ngrep instead of grep to fake success under GETTEXT_POISON. > I think I prefer this way. What do you think? That is equivalent to saying that "we would translate

Re: [PATCH v6 2/2] convert: ce_compare_data() checks for a sha1 of a path

tbo...@web.de writes: > From: Torsten Bögershausen > > To compare a file in working tree with the index, convert_to_git() is used, > the result is hashed and the hash value compared with ce->sha1. > > Deep down would_convert_crlf_at_commit() is invoked, to check if CRLF > are

Re: [PATCH 19/21] t9003: become resilient to GETTEXT_POISON

Às 16:39 de 20-05-2016, Junio C Hamano escreveu: > We want to see the string appear after "Did you mean this?" and we > do not want to be fooled by a future change in the early part of the > message, which may contain a substring l-g-f that does not have > anything to do with the alias we are

Re: [PATCH 19/21] t9003: become resilient to GETTEXT_POISON

On Fri, May 20, 2016 at 12:39 PM, Junio C Hamano wrote: > Eric Sunshine writes: >> Indeed, the sed seems superfluous. The output of the test command is: >> >> git: 'lfg' is not a git command. See 'git --help'. >> >> Did you mean this? >>

[PATCH v6 1/2] read-cache: factor out get_sha1_from_index() helper

From: Torsten Bögershausen Factor out the retrieval of the sha1 for a given path in read_blob_data_from_index() into the function get_sha1_from_index(). This will be used in the next commit, when convert.c can do the analyze for "text=auto" without slurping the whole blob into

[PATCH v6 2/2] convert: ce_compare_data() checks for a sha1 of a path

From: Torsten Bögershausen To compare a file in working tree with the index, convert_to_git() is used, the result is hashed and the hash value compared with ce->sha1. Deep down would_convert_crlf_at_commit() is invoked, to check if CRLF are converted or not: When a CRLF had been

Re: run-command: output owner picking strategy

On Fri, May 20, 2016 at 6:11 AM, William Duclot wrote: > Hi, > I stumbled upon this piece of code (run-command.c:pp_collect_finish()), > picking the owner > of the output amongst parallel processes (introduced by Stephan Beller in > commit

Re: [PATCHv8 0/5] pathspec magic extension to search for attributes

Stefan Beller writes: > Right. But upon finding the new name for clone, I wondered why > this has to be submodule specific. The attr pathspecs are also working > with any other files. So if you don't use submodules, I think it would be > pretty cool to have a > > git

Re: [PATCH v2] upload-pack.c: use of parse-options API

Matthieu Moy writes: >> Using "format-patch --patience" or some other diff option, and pick >> the best one to give to "send-email" would indeed be a way to do so. > > It's a matter of taste. My flow is "send-email-only", I do as much as > possible in-tree, and when

Re: [PATCH 19/21] t9003: become resilient to GETTEXT_POISON

Eric Sunshine writes: > [cc:+junio] > > Indeed, the sed seems superfluous. The output of the test command is: > > git: 'lfg' is not a git command. See 'git --help'. > > Did you mean this? > lgf > > And, the grep'd string, "lgf" only appears once, so grep

Re: [PATCH] t0008: 4 tests fail with ksh88

On Fri, May 20, 2016 at 6:10 PM, Junio C Hamano wrote: > Junio C Hamano writes: > >>> diff --git a/t/t0008-ignores.sh b/t/t0008-ignores.sh >>> index 89544dd..b425f3a 100755 >>> --- a/t/t0008-ignores.sh >>> +++ b/t/t0008-ignores.sh >>> @@ -605,7 +605,7 @@ cat

Re: Odd Difference Between Windows Git and Standard Git

Junio C Hamano writes: > Thanks for asking a great question. I somehow expected that we > probe in init-db.c::create_default_files() for this when we probe > for case sensitivity, symlinks, etc., but apparently we don't. Ah, we do probe by using "config" as a guinea pig

Re: Odd Difference Between Windows Git and Standard Git

On 20.05.16 17:23, Junio C Hamano wrote: > Torsten Bögershausen writes: > What does git diff say ? >>> >>> Great question. For all the unexpected files it says the >>> same thing: >>> >>> old mode 100755 >>> new mode 100644 >> >> So the solution is to run >> git

Re: [PATCH] t0008: 4 tests fail with ksh88

On Fri, May 20, 2016 at 5:16 PM, Junio C Hamano wrote: > Armin Kunaschik writes: > >> From: Armin Kunaschik >> >> \" in the test t0008 is not treated the same way in bash and in ksh. > > Could you refrain from singling out

Re: [PATCH] t0008: 4 tests fail with ksh88

Junio C Hamano writes: >> diff --git a/t/t0008-ignores.sh b/t/t0008-ignores.sh >> index 89544dd..b425f3a 100755 >> --- a/t/t0008-ignores.sh >> +++ b/t/t0008-ignores.sh >> @@ -605,7 +605,7 @@ cat <<-EOF >expected-verbose >> a/b/.gitignore:8:!on* a/b/one >>

Re: t0008 test fails with ksh

Jeff King writes: > ... However, > the double-quote character ( '"' ) shall not be treated specially > within a here-document, except when the double-quote appears within > "$()", "``", or "${}". > > So OK, that sounds like ksh is doing the right thing. But what's that >

Re: Odd Difference Between Windows Git and Standard Git

On 20.05.16 16:28, Jon Forrest wrote: > > > On 5/20/2016 7:19 AM, Torsten Bögershausen wrote: > >>> Great question. For all the unexpected files it says the >>> same thing: >>> >>> old mode 100755 >>> new mode 100644 >> >> So the solution is to run >> git config core.filemode false > > This

Re: more novice-friendly behaviour of `git add -p`

Junio C Hamano pobox.com> writes: > > enrico gmail.com> writes: > > > Hello all, > > I have encountered a couple of non-necessary difficulties when editing a > > patch during a `git add -p`. > > > > Firstly, the help message says > > "To remove '-' lines, make them ' ' lines (context)." > >

Re: Odd Difference Between Windows Git and Standard Git

Torsten Bögershausen writes: >>> What does >>> git diff >>> say ? >> >> Great question. For all the unexpected files it says the >> same thing: >> >> old mode 100755 >> new mode 100644 > > So the solution is to run > git config core.filemode false Thanks for asking a great

Re: [PATCH] t0008: 4 tests fail with ksh88

Armin Kunaschik writes: > From: Armin Kunaschik > > \" in the test t0008 is not treated the same way in bash and in ksh. Could you refrain from singling out "bash"? We don't write for "bash" specifically (and the test I ran are with "dash"

[ANNOUNCE] Git for Windows 2.8.3

Dear Git users, It is my pleasure to announce that Git for Windows 2.8.3 is available from: https://git-for-windows.github.io/ Changes since Git for Windows v2.8.2 (May 3rd 2016) New Features ??? Comes with Git v2.8.3. Filename | SHA-256 | --- Git-2.8.3-64-bit.exe |

Re: more novice-friendly behaviour of `git add -p`

enrico writes: > Hello all, > I have encountered a couple of non-necessary difficulties when editing a > patch during a `git add -p`. > > Firstly, the help message says > "To remove '-' lines, make them ' ' lines (context)." > which is a bit confusing because that

[PATCH] t0008: 4 tests fail with ksh88

From: Armin Kunaschik \" in the test t0008 is not treated the same way in bash and in ksh. In ksh the \ disappears and generates false expect data to compare with. Using \\" works portable, the same way in bash and in ksh and is less ambigous. Acked-by: Jeff King

Re: Odd Difference Between Windows Git and Standard Git

On 5/20/2016 7:19 AM, Torsten Bögershausen wrote: Great question. For all the unexpected files it says the same thing: old mode 100755 new mode 100644 So the solution is to run git config core.filemode false This worked perfectly! I wonder if this should be the default for Git for

RE: [Opinion gathering] Git remote whitelist/blacklist

On May 20, 2016 10:22 AM, Francois Beutin wrote: > We (Ensimag students) plan to implement the "remote whitelist/blacklist" > feature described in the SoC 2016 ideas, but first I would like to be sure we > agree on what exactly this feature would be, and that the community sees an > interest in

Re: [PATCH v6 05/17] ref-filter: move get_head_description() from branch.c

> > Note that this expects that va/i18n-misc-updates topic, which > corrects the translator instruction around here, is already applied. > >> diff --git a/ref-filter.c b/ref-filter.c >> index 7d3af1c..fcb3353 100644 >> ... >> +char *get_head_description(void) >> +{ >> + struct strbuf desc =

Re: Odd Difference Between Windows Git and Standard Git

On 20.05.16 15:48, Jon Forrest wrote: > > > On 5/20/2016 6:19 AM, Torsten Bögershausen wrote: >> On 20.05.16 03:48, Jon Forrest wrote: >>> I'm running Git version 2.8.2 built from source on Ubuntu 16.04. >>> I'm using a repository that's stored on Dropbox. I'm the only person >>> accessing this

[Opinion gathering] Git remote whitelist/blacklist

Hi everyone, We (Ensimag students) plan to implement the "remote whitelist/blacklist" feature described in the SoC 2016 ideas, but first I would like to be sure we agree on what exactly this feature would be, and that the community sees an interest in it. The general idea is to add a way to

Re: Odd Difference Between Windows Git and Standard Git

On 5/20/2016 6:19 AM, Torsten Bögershausen wrote: On 20.05.16 03:48, Jon Forrest wrote: I'm running Git version 2.8.2 built from source on Ubuntu 16.04. I'm using a repository that's stored on Dropbox. I'm the only person accessing this repo. Everything works great. For reasons unrelated to

[PATCH] userdiff: add built-in pattern for CSS

CSS is widely used, motivating it being included as a built-in pattern. It must be noted that the word_regex for CSS (i.e. the regex defining what is a word in the language) does not consider '.' and '#' characters (in CSS selectors) to be part of the word. This behavior is documented by the test

Re: Odd Difference Between Windows Git and Standard Git

On 20.05.16 03:48, Jon Forrest wrote: > I'm running Git version 2.8.2 built from source on Ubuntu 16.04. > I'm using a repository that's stored on Dropbox. I'm the only person > accessing this repo. Everything works great. > > For reasons unrelated to Git, I decided to try Git for Windows, > so I

more novice-friendly behaviour of `git add -p`

Hello all, I have encountered a couple of non-necessary difficulties when editing a patch during a `git add -p`. Firstly, the help message says "To remove '-' lines, make them ' ' lines (context)." which is a bit confusing because that "them" refers to '-', not to 'lines'. I spent a good half

run-command: output owner picking strategy

Hi, I stumbled upon this piece of code (run-command.c:pp_collect_finish()), picking the owner of the output amongst parallel processes (introduced by Stephan Beller in commit c553c72eed64b5f7316ce227f6d5d783eae6f2ed) /* * Pick next process to output live. * NEEDSWORK: * For now we pick it

Re: [PATCH v2 4/4] bundle v3: the beginning

I am responding to this 2+ month old email because I am investigating adding an alternate object store at the same level as loose and packed objects. This alternate object store could be used for large files. I am working on this for GitLab. (Yeah, I am working, as a freelance, for both

[PATCH v6 0/2] Implement the GIT_TRACE_CURL environment variable

This is the sixty version but in reality is the complete rewriting of the patches discussed here (here called V1) $gmane/290520 $gmane/290521 *Changes from V5 ($gmane/293236) - don't export curl_trace anymore. Define it static - fix a minor cleanup (style) in setup_curl_trace - and, finally, i

[PATCH v6 2/2] imap-send.c: introduce the GIT_TRACE_CURL enviroment variable

Permit the use of the GIT_TRACE_CURL environment variable calling the setup_curl_trace http.c helper routine. Helped-by: Torsten Bögershausen Helped-by: Ramsay Jones Helped-by: Junio C Hamano Helped-by: Eric Sunshine

[PATCH v6 1/2] http.c: implement the GIT_TRACE_CURL environment variable

Implement the GIT_TRACE_CURL environment variable to allow a greater degree of detail of GIT_CURL_VERBOSE, in particular the complete transport header and all the data payload exchanged. It might be useful if a particular situation could require a more thorough debugging analysis. Document the new

Re: [PATCH v6 3/3] bisect--helper: `write_terms` shell function in C

Hey Eric, On Mon, May 16, 2016 at 12:58 PM, Eric Sunshine wrote: > On Thu, May 12, 2016 at 1:32 AM, Pranit Bauva wrote: >> Reimplement the `write_terms` shell function in C and add a `write-terms` >> subcommand to `git bisect--helper` to call it

Re: [PATCH 1/2] bisect--helper: `bisect_log` shell function in C

Hey Eric, On Mon, May 16, 2016 at 1:06 PM, Eric Sunshine wrote: > On Fri, May 13, 2016 at 4:02 PM, Pranit Bauva wrote: >> bisect--helper: `bisect_log` shell function in C > > Do you need to insert "rewrite" or "reimplement" in the subject? > >>

Re: [PATCH 2/2] bisect--helper: `bisect_voc` shell function in C

Hey Johannes, On Mon, May 16, 2016 at 12:10 PM, Johannes Schindelin wrote: > Hi Pranit, > > On Sat, 14 May 2016, Pranit Bauva wrote: > >> Reimplement the `bisect_voc` shell function in C. This is a too small >> function to be called as a subcommand though the working

Re: [PATCH v6 1/3] bisect--helper: use OPT_CMDMODE instead of OPT_BOOL

Hey Eric, On Mon, May 16, 2016 at 12:37 PM, Eric Sunshine wrote: > On Thu, May 12, 2016 at 1:32 AM, Pranit Bauva wrote: >> `--next-all` is meant to be used as a subcommand to support multiple >> "operation mode" though the current implementation

Re: [PATCH v5 0/2] bisect--helper: rewrite of check-term-format()

Hey Eric, Sorry for the late reply. I was on vacation. On Mon, May 16, 2016 at 6:05 AM, Eric Sunshine wrote: > On Sun, May 8, 2016 at 9:34 AM, Pranit Bauva wrote: >> On Sun, May 8, 2016 at 11:53 AM, Pranit Bauva wrote:

Re: [PATCH v2] upload-pack.c: use of parse-options API

Junio Hamano wrote: > Matthieu Moy writes: > > > antoine.qu...@ensimag.grenoble-inp.fr wrote: > >> come from the commit (gmane/131517) > > > > Please, use a real commit id instead of a Gmane link. > > > > We don't know how long Gmane will remain up, but a self > >

Re: [PATCH v2] upload-pack.c: use of parse-options API

Junio C Hamano wrote: > Encouraging use of "send-email" with "--patience" is a losing > approach if your goal is to present more reviewable diff, isn't it? > Using "send-email" as if it is a front-end of "format-patch" means > you lose the opportunity for the final proof-reading (not just >