Re: Drastic jump in the time required for the test suite

Am 20.10.2016 um 23:38 schrieb Jeff King: test_cmp () { # optimize for common "they are the same" case # without any subshells or subprograms We do this already on Windows; it's the function mingw_test_cmp in our test suite:

Prove "Tests out of sequence" Error

Hi, on TravisCI I see these weird "Tests out of sequence" errors with prove and they seem to not go away. I assume the reason that they not go away is that the ".prove" file is carried over from on build to another (but I can't look into this file on TravisCI). Has anyone an idea where these

Re: t9000-addresses.sh: unexpected pases

Ramsay Jones writes: > I have started seeing unexpected passes in this test (am I the > only one?) on the next and pu branch, which seems to be caused > by commit e3fdbcc8 ("parse_mailboxes: accept extra text after > <...> address", 13-10-2016). Thus: > > $ tail

Re: [PATCH] doc: fix merge-base ASCII art tab spacing

Jeff King writes: > On Fri, Oct 21, 2016 at 12:40:09AM +0100, Philip Oakley wrote: > >> The doc-tool stack does not always respect the 'tab = 8 spaces' rule, >> particularly the git-scm doc pages https://git-scm.com/docs/git-merge-base >> and the Git generated html pages. > > Hmm,

Re: [PATCH] doc: fix merge-base ASCII art tab spacing

Philip Oakley writes: > The doc-tool stack does not always respect the 'tab = 8 spaces' rule, > particularly the git-scm doc pages https://git-scm.com/docs/git-merge-base > and the Git generated html pages. Sorry, but I do not understand this change.

[BUG] fetch output is ugly in 'next'

I recently started using lt/abbrev-auto via 'next'. This is the fetch output I saw today: $ git fetch remote: Counting objects: 332, done. remote: Compressing objects: 100% (237/237), done. remote: Total 332 (delta 182), reused 64 (delta 64), pack-reused 31 Receiving objects: 100% (332/332),

t9000-addresses.sh: unexpected pases

Hi Matthieu, I have started seeing unexpected passes in this test (am I the only one?) on the next and pu branch, which seems to be caused by commit e3fdbcc8 ("parse_mailboxes: accept extra text after <...> address", 13-10-2016). Thus: $ tail -15 ntest-out [15:17:44] All tests successful.

Re: [PATCH] doc: fix merge-base ASCII art tab spacing

On Fri, Oct 21, 2016 at 12:40:09AM +0100, Philip Oakley wrote: > The doc-tool stack does not always respect the 'tab = 8 spaces' rule, > particularly the git-scm doc pages https://git-scm.com/docs/git-merge-base > and the Git generated html pages. Hmm, I thought git-scm.com was fixed by:

Re: [PATCH v4 5/8] trailer: clarify failure modes in parse_trailer

Jonathan Tan writes: > That is true - I think we can take the allowed separators as an > argument (meaning that we can have different behavior for file parsing > and command line parsing), and since we already have that string, we > can use strcspn. I'll try this out in

Re: A couple errors dealing with uninitialized submodules

On Thu, Oct 20, 2016 at 4:29 PM, Aaron Schrab wrote: > I was working with a fresh clone of a repository where I'd forgotten that > one of the directories was setup as a submodule, so I hadn't initialized it. > > I tried to add a symlink to a location outside the repository and

[PATCH] doc: fix merge-base ASCII art tab spacing

The doc-tool stack does not always respect the 'tab = 8 spaces' rule, particularly the git-scm doc pages https://git-scm.com/docs/git-merge-base and the Git generated html pages. Use just spaces within the block of the ascii art. Noticed when reviewing Junio's suggested update to `git

A couple errors dealing with uninitialized submodules

I was working with a fresh clone of a repository where I'd forgotten that one of the directories was setup as a submodule, so I hadn't initialized it. I tried to add a symlink to a location outside the repository and this failed with an assertion (exact text in comment below). When looking

Re: Drastic jump in the time required for the test suite

On Thu, Oct 20, 2016 at 05:00:13PM -0400, Jeff King wrote: > > I am not an expert on perl nor tracing, but is it feasible to find out > > how many internal calls there are? i.e. either some shell script (rebase, > > submodule) calling git itself a couple of times or even from compile/git/git > >

Re: [PATCH v2 2/3] serialize collection of refs that contain submodule changes

> Thanks. So I do not completely get what you are suggesting: args or kept > it the way it is? Since in the end you are saying it is ok here ;) I > mainly chose this name because I am substituting the argv variable which > is already called 'argv' with this array. That might also be the reason >

What's cooking in git.git (Oct 2016, #05; Thu, 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. The last batch of topics before

Re: [PATCH v4 5/8] trailer: clarify failure modes in parse_trailer

On 10/20/2016 03:45 PM, Junio C Hamano wrote: Jonathan Tan writes: If we do that, there is also the necessity of creating a string that combines the separators and '=' (I guess '\n' is not necessary now, since all the lines are null terminated). I'm OK either way.

Re: [PATCH v4 5/8] trailer: clarify failure modes in parse_trailer

Jonathan Tan writes: > If we do that, there is also the necessity of creating a string that > combines the separators and '=' (I guess '\n' is not necessary now, > since all the lines are null terminated). I'm OK either way. > > (We could cache that string, although I

Re: [PATCH v4 5/8] trailer: clarify failure modes in parse_trailer

On 10/20/2016 03:40 PM, Jonathan Tan wrote: On 10/20/2016 03:14 PM, Junio C Hamano wrote: Stefan Beller writes: +static int find_separator(const char *line) +{ + const char *c; + for (c = line; ; c++) { + if (!*c || *c == '\n') +

Re: [PATCH v4 5/8] trailer: clarify failure modes in parse_trailer

On 10/20/2016 03:14 PM, Junio C Hamano wrote: Stefan Beller writes: +static int find_separator(const char *line) +{ + const char *c; + for (c = line; ; c++) { + if (!*c || *c == '\n') + return -1; + if (*c ==

Re: [PATCH v4 5/8] trailer: clarify failure modes in parse_trailer

Stefan Beller writes: >> +static int find_separator(const char *line) >> +{ >> + const char *c; >> + for (c = line; ; c++) { >> + if (!*c || *c == '\n') >> + return -1; >> + if (*c == '=' || strchr(separators, *c))

Re: Fwd: New Defects reported by Coverity Scan for git

Jeff King writes: > On Thu, Oct 20, 2016 at 10:58:39AM -0700, Stefan Beller wrote: > >> > By the way, do you know who is managing the service on our end >> > (e.g. approving new people to be "defect viewer")? >> >> I do it most of the time, but I did not start managing it. >> And

Re: [PATCH v4 5/8] trailer: clarify failure modes in parse_trailer

On Thu, Oct 20, 2016 at 2:39 PM, Jonathan Tan wrote: > The parse_trailer function has a few modes of operation, all depending > on whether the separator is present in its input, and if yes, the > separator's position. Some of these modes are failure modes, and these >

Re: Drastic jump in the time required for the test suite

On Thu, Oct 20, 2016 at 02:53:36PM -0700, Stefan Beller wrote: > >> That said I really like the idea of having a helper that would eliminate > >> the cat > >> for you, e.g. : > >> > >> git_test_helper_equal_stdin_or_diff_and_die -C super_repo status > >> --porcelain=v2 --branch

Re: Drastic jump in the time required for the test suite

On Thu, Oct 20, 2016 at 05:38:03PM -0400, Jeff King wrote: > I think that helper still ends up using "cat" and "diff" under the hood, > unless you write those bits in pure shell. But at that point, I suspect > we could "cat" and "test_cmp" in pure shell, something like: > [...] > Those are both

Re: Drastic jump in the time required for the test suite

On Thu, Oct 20, 2016 at 2:38 PM, Jeff King wrote: > On Thu, Oct 20, 2016 at 12:54:32PM -0700, Stefan Beller wrote: > >> Maybe we should stop introducing un-optimized tests. >> [...] >> * heavy use of the "git -C " pattern. When applying that >> thouroughly we'd save spanning the

Re: Fwd: New Defects reported by Coverity Scan for git

On Thu, Oct 20, 2016 at 10:58:39AM -0700, Stefan Beller wrote: > > By the way, do you know who is managing the service on our end > > (e.g. approving new people to be "defect viewer")? > > I do it most of the time, but I did not start managing it. > And I have been pretty lax/liberal about

Re: Fwd: New Defects reported by Coverity Scan for git

On Thu, Oct 20, 2016 at 10:05:38AM -0700, Stefan Beller wrote: > Not sure what triggered the new finding of coverity as seen below as the > parse_commit() was not touched. Junios series regarding the merge base > optimization touches a bit of code nearby though. I have noticed that "old"

[PATCH v4 4/8] trailer: make args have their own struct

Improve type safety by making arguments (whether from configuration or from the command line) have their own "struct arg_item" type, separate from the "struct trailer_item" type used to represent the trailers in the buffer being manipulated. This change also prepares "struct trailer_item" to be

[PATCH v4 3/8] trailer: streamline trailer item create and add

Currently, creation and addition (to a list) of trailer items are spread across multiple functions. Streamline this by only having 2 functions: one to parse the user-supplied string, and one to add the parsed information to a list. Signed-off-by: Jonathan Tan ---

[PATCH v4 6/8] trailer: allow non-trailers in trailer block

Currently, interpret-trailers requires all lines of a trailer block to be trailers (or comments) - if not it would not identify that block as a trailer block, and thus create its own trailer block, inserting a blank line. For example: echo -e "\nSigned-off-by: x\nnot trailer" | git

[PATCH v4 2/8] trailer: use list.h for doubly-linked list

Replace the existing handwritten implementation of a doubly-linked list in trailer.c with the functions and macros from list.h. This significantly simplifies the code. Signed-off-by: Jonathan Tan Signed-off-by: Ramsay Jones --- trailer.c |

[PATCH v4 7/8] trailer: forbid leading whitespace in trailers

Currently, interpret-trailers allows leading whitespace in trailer lines. This leads to false positives, especially for quoted lines or bullet lists. Forbid leading whitespace in trailers. Signed-off-by: Jonathan Tan --- Documentation/git-interpret-trailers.txt | 2

[PATCH v4 8/8] trailer: support values folded to multiple lines

Currently, interpret-trailers requires that a trailer be only on 1 line. For example: a: first line second line would be interpreted as one trailer line followed by one non-trailer line. Make interpret-trailers support RFC 822-style folding, treating those lines as one logical trailer.

[PATCH v4 5/8] trailer: clarify failure modes in parse_trailer

The parse_trailer function has a few modes of operation, all depending on whether the separator is present in its input, and if yes, the separator's position. Some of these modes are failure modes, and these failure modes are handled differently depending on whether the trailer line was sourced

[PATCH v4 0/8] allow non-trailers and multiple-line trailers

Main changes are: - implemented the previously discussed trailer block recognizing rule (recognized trailer + 25% trailers or 100% trailers) - forbidding leading whitespace in trailers to avoid false positives Once the recognized trailer + 25% trailers rule is implemented, implementing the

[PATCH v4 1/8] trailer: improve const correctness

Change "const char *" to "char *" in struct trailer_item and in the return value of apply_command (since those strings are owned strings). Change "struct conf_info *" to "const struct conf_info *" (since that struct is not modified). Signed-off-by: Jonathan Tan ---

Re: [PATCH 2/2] tag: send fully qualified refnames to verify_tag_and_format

On Thu, Oct 20, 2016 at 12:57:01PM -0400, Santiago Torres wrote: > > I think you'd really just squash the various bits of this into your > > series at the right spots, though I don't mind it on top, either. > > > > The big question is to what degree we should care about the verify-tag > > case.

Re: Drastic jump in the time required for the test suite

On Thu, Oct 20, 2016 at 12:54:32PM -0700, Stefan Beller wrote: > Maybe we should stop introducing un-optimized tests. > [...] > * heavy use of the "git -C " pattern. When applying that > thouroughly we'd save spanning the subshells. Yeah, I imagine with some style changes we could drop quite a

Re: [ANNOUNCE] git-log-compact v1.0

On Wed, Oct 19, 2016 at 05:13:34PM -0700, Kyle J. McKay wrote: > > The project page with detailed help and many screen shots is located at: > > https://mackyle.github.io/git-log-compact/ > > Alternatively the repository can be cloned from: > > https://github.com/mackyle/git-log-compact.git

Re: Drastic jump in the time required for the test suite

On Thu, Oct 20, 2016 at 10:38:23PM +0200, Johannes Sixt wrote: > Am 20.10.2016 um 14:31 schrieb Jeff King: > > Close to 1/3 of those processes are just invoking the bin-wrapper > > script to set up the EXEC_PATH, etc. I imagine it would not be too hard > > to just do that in the test script. In

Re: Drastic jump in the time required for the test suite

On Thu, Oct 20, 2016 at 09:30:27AM -0700, Stefan Beller wrote: > On Thu, Oct 20, 2016 at 5:31 AM, Jeff King wrote: > > > > > $ perl -lne '/execve\("(.*?)"/ and print $1' /tmp/foo.out | sort | uniq -c > > | sort -rn | head > > 152271 /home/peff/compile/git/git > > 57340

[PATCH v3] rev-list: use hdr_termination instead of a always using a newline

From: Jacob Keller When adding support for prefixing output of log and other commands using --line-prefix, commit 660e113ce118 ("graph: add support for --line-prefix on all graph-aware output", 2016-08-31) accidentally broke rev-list --header output. In order to make the

Re: Drastic jump in the time required for the test suite

On Thu, 2016-10-20 at 08:31 -0400, Jeff King wrote: > I'm also not entirely convinced that the test suite being a shell script > is the main culprit for its slowness. We run git a lot of times, and > that's inherent in testing it. I ran the whole test suite under > "strace -f -e execve". There

Re: Drastic jump in the time required for the test suite

Am 20.10.2016 um 14:31 schrieb Jeff King: Close to 1/3 of those processes are just invoking the bin-wrapper script to set up the EXEC_PATH, etc. I imagine it would not be too hard to just do that in the test script. In fact, it looks like: make prefix=/wherever install

[PATCH v2] rev-list: use hdr_termination instead of a always using a newline

From: Jacob Keller When adding support for prefixing output of log and other commands using --line-prefix, commit 660e113ce118 ("graph: add support for --line-prefix on all graph-aware output", 2016-08-31) accidentally broke rev-list --header output. In order to make the

Re: [PATCH v4 23/25] sequencer: quote filenames in error messages

Junio C Hamano writes: > Johannes Schindelin writes: > >> This makes the code consistent by fixing quite a couple of error messages. >> >> Suggested by Jakub Narębski. >> >> Signed-off-by: Johannes Schindelin >> --- > >

Re: [PATCH v4 23/25] sequencer: quote filenames in error messages

Johannes Schindelin writes: > This makes the code consistent by fixing quite a couple of error messages. > > Suggested by Jakub Narębski. > > Signed-off-by: Johannes Schindelin > --- These finishing touches in 21-23 look all sensible to

Re: [PATCH v4 20/25] sequencer: refactor write_message()

Junio C Hamano writes: > If I were doing this, I would make this into three separate steps: > > - move the strbuf_release(msgbuf) to the caller in > do_pick_commit(); > > - add the missing rollback_lock_file(), which is a bugfix; and > then finally > >

Re: [PATCH v4 20/25] sequencer: refactor write_message()

Johannes Schindelin writes: > The write_message() function safely writes an strbuf to a file. > Sometimes it is inconvenient to require an strbuf, though: the text to > be written may not be stored in a strbuf, or the strbuf should not be > released after writing. > >

Re: [PATCH v4 18/25] sequencer: do not try to commit when there were merge conflicts

Johannes Schindelin writes: > The return value of do_recursive_merge() may be positive (indicating merge > conflicts), or 0 (indicating success). It also may be negative, indicating > a fatal error that requires us to abort. > > Now, if the return value indicates that

Re: [PATCH v4 17/25] sequencer: support cleaning up commit messages

Johannes Schindelin writes: > The run_git_commit() function already knows how to amend commits, and > with this new option, it can also clean up commit messages (i.e. strip > out commented lines). This is needed to implement rebase -i's 'fixup' > and 'squash' commands

Re: [PATCH] rev-list: use hdr_termination instead of a always using a newline

On Thu, Oct 20, 2016 at 11:54 AM, Junio C Hamano wrote: > > The main part of the patch looks good. For "passing NUL to sed", > I'd probably work it around like so: > Yep. I wasn't sure on the test as it was, because of the portability concern. > t/t6000-rev-list-misc.sh |

Re: tools for easily "uncommitting" parts of a patch I just commited?

On Thu, Oct 20, 2016 at 11:41 AM, Junio C Hamano wrote: > Jacob Keller writes: > >>> I am not sure if that is OK. I think it is less not-OK than the use >>> case I mentioned in my earlier message, in that this is not a case >>> that "please don't do

Re: Drastic jump in the time required for the test suite

On Thu, Oct 20, 2016 at 3:50 AM, Johannes Schindelin wrote: > Hi peff, > > On Wed, 19 Oct 2016, Jeff King wrote: > >> On Wed, Oct 19, 2016 at 10:32:12AM -0700, Junio C Hamano wrote: >> >> > > Maybe we should start optimizing the tests... >> > Maybe we should stop

Re: [PATCHv3] submodule--helper: normalize funny urls

Stefan Beller writes: > My thought was to fix it nevertheless, such that the url recorded as > remote.origin.url is always the first case (no l or /. at the end). > > If we were to add this fix to clone, then it may be easier to debug > submodule url schemes for users as the

Re: [PATCHv3] submodule--helper: normalize funny urls

On Thu, Oct 20, 2016 at 12:26 PM, Junio C Hamano wrote: > Stefan Beller writes: > >> Do we actually want to fix git-clone as well? > > If I understand correctly, the point of this fix is to make it not > to matter whether the original URL the end user gives

Re: [PATCHv3] submodule--helper: normalize funny urls

Stefan Beller writes: > Do we actually want to fix git-clone as well? If I understand correctly, the point of this fix is to make it not to matter whether the original URL the end user gives or recorded as the remote by "git clone" in the repository is any one of:

Re: [PATCHv3] submodule--helper: normalize funny urls

On Tue, Oct 18, 2016 at 7:05 PM, Junio C Hamano wrote: > Stefan Beller writes: > >>> I am not sure. Certainly we would want to make sure that the normal >>> case (i.e. no funny trailing junk) to work correctly, but we do want >>> to protect the fix from

Re: [PATCH] rev-list: use hdr_termination instead of a always using a newline

Jacob Keller writes: > diff --git a/t/t6000-rev-list-misc.sh b/t/t6000-rev-list-misc.sh > index 3e752ce03280..e8c6979baf59 100755 > --- a/t/t6000-rev-list-misc.sh > +++ b/t/t6000-rev-list-misc.sh > @@ -4,6 +4,12 @@ test_description='miscellaneous rev-list tests' > >

Re: [PATCH] rev-list: use hdr_termination instead of a always using a newline

On Thu, 2016-10-20 at 11:19 -0700, Jacob Keller wrote: > Here's my solution, with an updated test using a helper function based > on using sed (which I think is more portable than tail -n1 ?). The > change actually is very simple. I ran the test suite and it appears to > be not breaking anyone

Re: [PATCH] rev-list: restore the NUL commit separator in --header mode

Jacob Keller writes: > I did some searching, and we do use sed so I replaced it with sed \$!d > which appears to work. I think we should probably implement a > test_ends_with_nul or something. As it is "a stream editor that shall read one or more text files", I do not

Re: tools for easily "uncommitting" parts of a patch I just commited?

Jacob Keller writes: >> I am not sure if that is OK. I think it is less not-OK than the use >> case I mentioned in my earlier message, in that this is not a case >> that "please don't do it" breaks. It however is an inconvenience >> that the user has to say "git add

[PATCH] rev-list: use hdr_termination instead of a always using a newline

From: Jacob Keller When adding support for prefixing output of log and other commands using --line-prefix, commit 660e113ce118 ("graph: add support for --line-prefix on all graph-aware output", 2016-08-31) accidentally broke rev-list --header output. In order to make the

Re: tools for easily "uncommitting" parts of a patch I just commited?

On Thu, Oct 20, 2016 at 10:39 AM, Junio C Hamano wrote: > Jacob Keller writes: > >> I still think we're misunderstanding. I want git commit to complain >> *only* under the following circumstance: >> >> I run "git add -p" and put a partial change into

Re: Fwd: New Defects reported by Coverity Scan for git

On Thu, Oct 20, 2016 at 11:05 AM, Junio C Hamano wrote: > > Good to know that you have been managing it; I was mostly worried > about not having anybody managing it (i.e. imagining Coverity > nominated/volunteered me as manager with everybody else as viewers) > and the new

Re: [PATCH] rev-list: restore the NUL commit separator in --header mode

On Thu, Oct 20, 2016 at 11:04 AM, Dennis Kaarsemaker wrote: > On Wed, 2016-10-19 at 15:41 -0700, Junio C Hamano wrote: >> Dennis Kaarsemaker writes: >> >> > + touch expect && >> > + printf "\0" > expect && >> >> >> What's the point of that

[PATCH] commit parsing: replace unchecked parse_commit by parse_commit_or_die

The reason parse_commit() would fail at these points would be because the repository is corrupt. This was noticed by coverity. Signed-off-by: Stefan Beller --- developed on pu as that's where coverity spotted it. I have no overview if these areas are being worked on. (It

Re: Fwd: New Defects reported by Coverity Scan for git

Stefan Beller writes: > I do it most of the time, but I did not start managing it. > And I have been pretty lax/liberal about handing out rights to do stuff, > because I did not want to tip on anyone's toes giving to few rights > and thereby annoying them. Good to know that

Re: [PATCH] rev-list: restore the NUL commit separator in --header mode

On Wed, 2016-10-19 at 15:41 -0700, Junio C Hamano wrote: > Dennis Kaarsemaker writes: > > > + touch expect && > > + printf "\0" > expect && > > > What's the point of that "touch", especially if you are going to > overwrite it immediately after? Leftover debugging

Re: [PATCH] rev-list: restore the NUL commit separator in --header mode

On Wed, 2016-10-19 at 15:39 -0700, Junio C Hamano wrote: > Jacob Keller writes: > > > Hi, > > > > On Wed, Oct 19, 2016 at 2:04 PM, Dennis Kaarsemaker > > wrote: > > > Commit 660e113 (graph: add support for --line-prefix on all graph-aware > > >

Re: Fwd: New Defects reported by Coverity Scan for git

On Thu, Oct 20, 2016 at 10:50 AM, Junio C Hamano wrote: > Stefan Beller writes: > >> Not sure what triggered the new finding of coverity as seen below as the >> parse_commit() was not touched. Junios series regarding the merge base >> optimization touches a

Re: Fwd: New Defects reported by Coverity Scan for git

Stefan Beller writes: > Not sure what triggered the new finding of coverity as seen below as the > parse_commit() was not touched. Junios series regarding the merge base > optimization touches a bit of code nearby though. > > Do we want to replace the unchecked places of

Re: tools for easily "uncommitting" parts of a patch I just commited?

Jacob Keller writes: > I still think we're misunderstanding. I want git commit to complain > *only* under the following circumstance: > > I run "git add -p" and put a partial change into the index in . > There are still other parts which were not added to the index yet. >

Re: tools for easily "uncommitting" parts of a patch I just commited?

On Thu, Oct 20, 2016 at 9:30 AM, Junio C Hamano wrote: > Jeff King writes: > >>> I still think it's worth while to add a check for git-commit which >>> does something like check when we say "git commit " and if the >>> index already has those files marked as

Re: Drastic jump in the time required for the test suite

Junio C Hamano writes: > Are you proposing to replace the tests written as shell scripts with > scripts in another language or framework that run equivalent > sequences of git commands that is as portable as, if not more, > Bourne shell? The language (/bin/sh) is probably not

Re: [PATCH v4 05/14] i18n: add--interactive: mark plural strings

Vasco Almeida writes: > A Seg, 10-10-2016 às 12:54 +, Vasco Almeida escreveu: >> @@ -70,6 +72,8 @@ Git::I18N - Perl interface to Git's Gettext localizations >> >> printf __("The following error occurred: %s\n"), $error; >> >> + printf __n("commited %d

Fwd: New Defects reported by Coverity Scan for git

Not sure what triggered the new finding of coverity as seen below as the parse_commit() was not touched. Junios series regarding the merge base optimization touches a bit of code nearby though. Do we want to replace the unchecked places of parse_commit with parse_commit_or_die ? Thanks, Stefan

Re: [PATCH 2/2] tag: send fully qualified refnames to verify_tag_and_format

On Wed, Oct 19, 2016 at 04:39:44PM -0400, Jeff King wrote: > The ref-filter code generally expects to see fully qualified > refs, so that things like "%(refname)" and "%(refname:short)" > work as expected. We can do so easily from git-tag, which > always works with refnames in the refs/tags

Re: Drastic jump in the time required for the test suite

Am 20.10.2016 um 13:02 schrieb Duy Nguyen: > On Wed, Oct 19, 2016 at 4:18 PM, Johannes Schindelin > wrote: >> Hi Junio, >> >> I know you are a fan of testing things thoroughly in the test suite, but I >> have to say that it is getting out of hand, in particular due to

Re: [PATCH v4 05/14] i18n: add--interactive: mark plural strings

A Seg, 10-10-2016 às 12:54 +, Vasco Almeida escreveu: > @@ -70,6 +72,8 @@ Git::I18N - Perl interface to Git's Gettext localizations >   > printf __("The following error occurred: %s\n"), $error; >   > +   printf __n("commited %d file", "commited %d files", $files), $files; > + I

Re: tools for easily "uncommitting" parts of a patch I just commited?

Jeff King writes: >> I still think it's worth while to add a check for git-commit which >> does something like check when we say "git commit " and if the >> index already has those files marked as being changed, compare them >> with the current contents of the file as in the

Re: Drastic jump in the time required for the test suite

On Thu, Oct 20, 2016 at 5:31 AM, Jeff King wrote: > > $ perl -lne '/execve\("(.*?)"/ and print $1' /tmp/foo.out | sort | uniq -c | > sort -rn | head > 152271 /home/peff/compile/git/git > 57340 /home/peff/compile/git/t/../bin-wrappers/git > 16865 /bin/sed > 12650 /bin/rm >

Re: [regression] `make profile-install` fails in 2.10.1

Jeff King writes: > I usually just try to recreate the actual environment (e.g., run the > tests as root, run them on a loopback case-insensitive fs, etc) as that > gives a more realistic recreation. True. I just do not want to run the tests as root myself ;-) I wonder if

Re: [PATCH v4 05/14] i18n: add--interactive: mark plural strings

A Qua, 19-10-2016 às 11:40 -0700, Junio C Hamano escreveu: > Vasco Almeida writes: > > > > > @@ -669,12 +669,18 @@ sub status_cmd { > >  sub say_n_paths { > >   my $did = shift @_; > >   my $cnt = scalar @_; > > - print "$did "; > > - if (1 < $cnt) { > > -

Re: [PATCH v4 01/14] i18n: add--interactive: mark strings for translation

Vasco Almeida writes: >> Not a big deal, but this makes me wonder if we want to do this >> instead ... For future reference (for others as well), when I say "makes me wonder" or "I wonder", I am never demanding to change what the original author wrote. I just am trying

Re: [PATCH v4 01/14] i18n: add--interactive: mark strings for translation

A Qua, 19-10-2016 às 11:14 -0700, Junio C Hamano escreveu: > Vasco Almeida writes: > > > > >   } else { > > - print "No untracked files.\n"; > > + print __("No untracked files.\n"); > >   } > > Not a big deal, but this makes me wonder if we want

Re: Drastic jump in the time required for the test suite

Johannes Schindelin writes: > Of course, if you continue to resist (because the problem is obviously not > affecting you personally, so why would you care), I won't even try to find > the time to start on that project. Sorry, but I did not know I was resisting, as I

Re: [PATCH] rev-list: restore the NUL commit separator in --header mode

On Wed, 2016-10-19 at 15:39 -0700, Junio C Hamano wrote: > Jacob Keller writes: > > > > > Hi, > > > > On Wed, Oct 19, 2016 at 2:04 PM, Dennis Kaarsemaker > > wrote: > > > > > > Commit 660e113 (graph: add support for --line-prefix on all > > >

Re: How to rename remote branches if I only have "client access"?

Manuel Reimer writes: > I have the following branches on my remote repo: > > new_version > master > > I now want the "new_version" branch to be the "master" and the old > "master" has to be renamed to the old version number (in my case > 0.2.0). > > How to do this?

Re: [PATCH] doc: remove reference to the traditional layout in git-tag.txt

Younes Khoudli writes: > This is the only place in the documentation that the traditional layout > is mentioned, and it is confusing. Remove it. Yeah, the information is not incorrect per-se, but certainly is out of place and immaterial to what this part of the

How to rename remote branches if I only have "client access"?

Hello, I have the following branches on my remote repo: new_version master I now want the "new_version" branch to be the "master" and the old "master" has to be renamed to the old version number (in my case 0.2.0). How to do this? Currently this causes me much trouble as I can't delete the

[PATCH] doc: remove reference to the traditional layout in git-tag.txt

This is the only place in the documentation that the traditional layout is mentioned, and it is confusing. Remove it. * Documentation/git-tag.txt: Here. Signed-off-by: Younes Khoudli --- Documentation/git-tag.txt | 5 ++--- 1 file changed, 2 insertions(+), 3

Re: Drastic jump in the time required for the test suite

On Thu, Oct 20, 2016 at 12:17:33PM +0200, Johannes Schindelin wrote: > If you want to know just how harmful this reliance on shell scripting is > to our goal of keeping Git portable: already moving from Linux to MacOSX > costs you roughly 3x as long to run the build & test (~12mins vs ~36mins >

Re: [PATCH v4 05/25] sequencer: eventually release memory allocated for the option values

Hi Junio, On Tue, 18 Oct 2016, Junio C Hamano wrote: > Johannes Schindelin writes: > > >> > To remedy that, we now take custody of the option values in question, > >> > requiring those values to be malloc()ed or strdup()ed > >> > >> That is the approach this patch

Re: [PATCH v3 14/25] sequencer: introduce a helper to read files written by scripts

Hi Junio, On Tue, 18 Oct 2016, Junio C Hamano wrote: > Johannes Schindelin writes: > > > In the meantime, I'd be happy to just add a comment that this function is > > intended for oneliners, but that it will also read multi-line files and > > only strip off the EOL

[REQUEST PULL] git-gui 0.20.0 to 0.21.0

The following changes since commit 4498b3a50a0e839788682f672df267cbc1ba9292: git-gui: set version 0.20 (2015-04-18 12:15:32 +0100) are available in the git repository at: git://repo.or.cz/git-gui.git tags/gitgui-0.21.0 for you to fetch changes up to

Re: Drastic jump in the time required for the test suite

On Thu, Oct 20, 2016 at 12:50:32PM +0200, Johannes Schindelin wrote: > That reflects my findings, too. I want to add that I found preciously > little difference between running slow-to-fast and running in numeric > order, so I gave up on optimizing on that front. Interesting. It makes a 10-15%

Re: Drastic jump in the time required for the test suite

On Wed, Oct 19, 2016 at 4:18 PM, Johannes Schindelin wrote: > Hi Junio, > > I know you are a fan of testing things thoroughly in the test suite, but I > have to say that it is getting out of hand, in particular due to our > over-use of shell script idioms (which really

Re: Drastic jump in the time required for the test suite

Hi peff, On Wed, 19 Oct 2016, Jeff King wrote: > On Wed, Oct 19, 2016 at 10:32:12AM -0700, Junio C Hamano wrote: > > > > Maybe we should start optimizing the tests... > > > > Yup, two things that come to mind are to identify long ones and see if > > each of them can be split into two halves

Re: Drastic jump in the time required for the test suite

Hi Junio, On Wed, 19 Oct 2016, Junio C Hamano wrote: > Johannes Schindelin writes: > > > What I can also say for certain is that the version from yesterday (commit > > 4ef44ce) was the first one in a week that built successfully and hence > > reached the test phase,

  1   2   >