[PATCH 1/2] Resumable clone: create git-prime-clone (Draft)

Create a bare-bones version of git-prime-clone, which returns the location of an alternate resource specified by the server that the client should fetch and build before returning to perform an incremental fetch. At this point, no validation is performed of the file's existence, the file's

[PATCH 2/2] Resumable clone: add endpoints for prime clone (Draft)

Add endpoints for prime-clone in http service and git daemon --- daemon.c | 7 +++ http-backend.c | 1 + 2 files changed, 8 insertions(+) diff --git a/daemon.c b/daemon.c index 8d45c33..2ddc7f7 100644 --- a/daemon.c +++ b/daemon.c @@ -475,10 +475,17 @@ static int receive_pack(void)

[PATCH 0/2] git-prime-clone

Hey, all, I asked about writing a portion of resumable clone about two months ago, and decided to write the prime-clone program. I got bogged down by work in the time since and have just gotten started working on the feature maybe a week or two ago. Anyway, I sent along a very rough version of

Re: [Bug] git-log prints wrong unixtime with --date=format:%s

On Thu, May 19, 2016 at 01:05:28AM +0200, Michael Heerdegen wrote: > Jeff King writes: > > > 3. The epoch times for the latter lines should match. > > FWIW, I think the epoch time is the most practical way to transfer the > time of a commit into a different program. When this

Re: git fetch origin $SHA1 doesn't work as often as it could

On Wed, May 18, 2016 at 06:40:37PM -0400, JP Sugarbroad wrote: > > I just fear that it is a wrong approach to solve the real issue and > > instead make it worse by relieving the pressure from the project and > > hosting site to configure their repository to support their users > > properly. > >

[PATCHv8 1/5] string list: improve comment

Signed-off-by: Stefan Beller --- string-list.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/string-list.h b/string-list.h index d3809a1..465a1f0 100644 --- a/string-list.h +++ b/string-list.h @@ -106,7 +106,7 @@ void

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

This goes on top of origin/jc/attr, (396bf756f95, attr: expose validity check for attribute names) Patches 1 and 2 are small fixes, which could go independently as well. Patches 3 and 4 are refactoring pathspec.c a little. These did not change since v7 diff to v7: diff --git

[PATCHv8 4/5] pathspec: move prefix check out of the inner loop

The prefix check is not related the check of pathspec magic; also there is no code that is relevant after we'd break the loop on a match for "prefix:". So move the check before the loop and shortcircuit the outer loop. Signed-off-by: Stefan Beller --- pathspec.c | 19

[PATCHv8 3/5] pathspec: move long magic parsing out of prefix_pathspec

`prefix_pathspec` is quite a lengthy function and we plan on adding more. Split it up for better readability. As we want to add code into the inner loop of the long magic parsing, we also benefit from lower indentation. Signed-off-by: Stefan Beller --- pathspec.c | 84

[PATCHv8 5/5] 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 ---

[PATCHv8 2/5] Documentation: fix a typo

Signed-off-by: Stefan Beller --- Documentation/gitattributes.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt index e3b1de8..af2c682 100644 --- a/Documentation/gitattributes.txt +++

Re: [sort-of-BUG] merge-resolve cannot resolve "content/mode" conflict

On Mon, Apr 04, 2016 at 10:34:34AM -0700, Junio C Hamano wrote: > Jeff King writes: > > > Imagine a merge where one side changes the content of a path and the > > other changes the mode. Here's a minimal reproduction: > > > > git init repo && cd repo && > > > > echo base

Re: [PATCH 6/6] upload-pack: provide a hook for running pack-objects

On Wed, May 18, 2016 at 06:45:37PM -0400, Jeff King wrote: > @@ -93,6 +94,14 @@ static void create_pack_file(void) > int i; > FILE *pipe_fd; > > + if (!pack_objects_hook) > + pack_objects.git_cmd = 1; > + else { > + argv_array_push(_objects.args,

Re: [PATCH 4/6] config: return configset value for current_config_ functions

On Wed, May 18, 2016 at 06:43:23PM -0400, Jeff King wrote: > cache.h| 1 + > config.c | 51 > +- > t/helper/test-config.c | 20 > t/t1308-config-set.sh | 23 +++ > [...] >

Re: [Bug] git-log prints wrong unixtime with --date=format:%s

Jeff King writes: > 3. The epoch times for the latter lines should match. FWIW, I think the epoch time is the most practical way to transfer the time of a commit into a different program. When this program wants to do it's own date arithmetic with it, unix time is just nice

Re: [PATCHv7 5/5] pathspec: allow querying for attributes

Stefan Beller writes: > and those are not yet codified, but for discussion then: > > - "`?`" the attribute must not be unspecified, i.e. set, unset or has any > value > - "`+`" the attribute must be set or has any value I'd suggest not to support these until we see any

[PATCH] Allow the short-hand - replacing @{-1} in git worktree add

Since `git worktree add` uses `git checkout` when `[]` is used, and `git checkout -` is already supported, it makes sense to allow the same shortcut in `git worktree add`. Signed-off-by: Matthieu Moy , Jordan DE GEA ---

Re: [Bug] git-log prints wrong unixtime with --date=format:%s

Jeff King writes: > This is probably a totally separate issue, as it would not be using > strftime (or IIRC, any of the standard time functions at all). Do you > have a detailed example that shows the problem? Ok, this was probably false alarm. Magit (An Emacs Git front end)

[PATCH 6/6] upload-pack: provide a hook for running pack-objects

When upload-pack serves a client request, it turns to pack-objects to do the heavy lifting of creating a packfile. There's no easy way to intercept the call to pack-objects, but there are a few good reasons to want to do so: 1. If you're debugging a client or server issue with fetching,

[PATCH 5/6] config: add a notion of "scope"

A config callback passed to git_config() doesn't know very much about the context in which it sees a variable. It can ask whether the variable comes from a file, and get the file name. But without analyzing the filename (which is hard to do accurately), it cannot tell whether it is in system-level

[PATCH 4/6] config: return configset value for current_config_ functions

When 473166b (config: add 'origin_type' to config_source struct, 2016-02-19) added accessor functions for the origin type and name, it taught them only to look at the "cf" struct that is filled in while we are parsing the config. This is sufficient to make it work with git-config, which uses

[PATCH 3/6] config: set up config_source for command-line config

When we parse a config file, we set up the global "cf" variable as a pointer to a "struct config_source" describing the file we are parsing. This is used for error messages, as well as for lookup functions like current_config_name(). The "cf" variable is NULL in two cases: 1. When we are

Re: git fetch origin $SHA1 doesn't work as often as it could

On Wed, May 18, 2016 at 5:59 PM, Junio C Hamano wrote: > The commit from the submodule that is bound to the superproject may > no longer be sitting at the tip of any branch in the submodule. The > hack you are outlining here would not help, and invites "the feature > works

[PATCH 2/6] git_config_parse_parameter: refactor cleanup code

We have several exits from the function, each of which has to do some cleanup. Let's consolidate these in an "out" label we can jump to. This doesn't save us much now, but it will help as we add more things that need cleanup. Signed-off-by: Jeff King --- config.c | 13

[PATCH 1/6] git_config_with_options: drop "found" counting

Prior to 1f2baa7 (config: treat non-existent config files as empty, 2010-10-21), we returned an error if any config files were missing. That commit made this a non-error, but returned the number of sources found, in case any caller wanted to distinguish this case. In the past 5+ years, no caller

[PATCH/RFC 0/6] pack-objects hook for upload-pack

I've often wanted to intercept the call from upload-pack to pack-objects. The final patch in this series goes into more detail, but basically it's good for: 1. Capturing the output from pack-objects for debugging/inspection. 2. Capturing the input to pack-objects to replay for debugging or

Re: [PATCHv7 5/5] pathspec: allow querying for attributes

On Wed, May 18, 2016 at 12:47 PM, Junio C Hamano wrote: > Stefan Beller writes: > >> + - "`+`" the attribute must be set >> + - "`-`" the attribute must be unset >> + - "`~`" the attribute must be unspecified Well the '-' is in line, at least. So you're

Re: git fetch origin $SHA1 doesn't work as often as it could

JP Sugarbroad writes: > So I'm trying to make cloning the rust repo a little easier, and I > noticed there's a new feature to `git submodule update --depth=1` -- > but it doesn't work for this, even though it could. > > Reason is that fetch-pack will only fetch by sha1 if the

Re: [PATCH] attr: expose validity check for attribute names

On Wed, May 18, 2016 at 2:05 PM, Junio C Hamano wrote: > Export attr_name_valid() function, and a helper function that > returns the message to be given when a given pair > is not a good name for an attribute. > > We could later update the message to exactly spell

Re: [PATCH] attr: add counted string version of git_attr()

On Wed, May 18, 2016 at 2:03 PM, Junio C Hamano wrote: > Often a potential caller has pair that > represents the name it wants to create an attribute out of. > > When name[namelen] is not NUL, the caller has to xmemdupz() > only to call git_attr(). > > Add

Re: [PATCH 03/21] i18n: advice: internationalize message for conflicts

Vasco Almeida writes: >>> + else >>> + error(_("%s is not possible because you have unmerged >>> files."), >>> + me); >> >> Despite the commit message, I still don't understand this change. 'me' >> is a literal git command which

[PATCH] attr: expose validity check for attribute names

Export attr_name_valid() function, and a helper function that returns the message to be given when a given pair is not a good name for an attribute. We could later update the message to exactly spell out what the rules for a good attribute name are, etc. Signed-off-by: Junio C Hamano

[PATCH] attr: add counted string version of git_attr()

Often a potential caller has pair that represents the name it wants to create an attribute out of. When name[namelen] is not NUL, the caller has to xmemdupz() only to call git_attr(). Add git_attr_counted() that takes such a counted string instead of "const char *name".

Re: [PATCH 05/21] i18n: sequencer: mark entire sentences for translation

Às 19:28 de 18-05-2016, Eric Sunshine escreveu: > On Wed, May 18, 2016 at 11:27 AM, Vasco Almeida wrote: >> Mark entire sentences of error message rather than assembling one using >> placeholders (e.g. "Cannot %s during a %s"). That would facilitate >> translation work. >>

[PATCH] attr: add counted string version of git_check_attr()

Often a potential caller has pair that represents the path it wants to ask attributes for; when path[pathlen] is not NUL, the caller has to xmemdupz() only to call git_check_attr(). Add git_check_attr_counted() that takes such a counted string instead of "const char *path".

Re: [PATCHv7 5/5] pathspec: allow querying for attributes

Junio C Hamano writes: >> +static int match_attrs(const char *name, int namelen, >> + const struct pathspec_item *item) >> +{ >> +char *path; >> +int i; >> + >> +path = xmemdupz(name, namelen); >> +git_check_attr(path, item->attr_check); > ...

git fetch origin $SHA1 doesn't work as often as it could

So I'm trying to make cloning the rust repo a little easier, and I noticed there's a new feature to `git submodule update --depth=1` -- but it doesn't work for this, even though it could. Reason is that fetch-pack will only fetch by sha1 if the remote specifies allow_tip/unreachable_sha1, even if

[PATCH v3 4/5] t1500: avoid setting configuration options outside of tests

Ideally, each test should be responsible for setting up state it needs rather than relying upon transient global state. Toward this end, teach test_rev_parse() to accept a "-b " option to allow callers to set "core.bare" explicitly or undefine it. Take advantage of this new option to avoid setting

[PATCH v3 2/5] t1500: test_rev_parse: facilitate future test enhancements

Tests run by test_rev_parse() are nearly identical; each invokes git-rev-parse with a single option and compares the result against an expected value. Such duplication makes it onerous to extend the tests since any change needs to be repeated in each test. Avoid the duplication by parameterizing

[PATCH v3 1/5] t1500: be considerate to future potential tests

The final batch of git-rev-parse tests work against a non-local object database named repo.git. This is done by renaming .git to repo.git and pointing GIT_DIR at it, but the name is never restored to .git at the end of the script, which can be problematic for tests added in the future. Be more

[PATCH v3 3/5] t1500: avoid changing working directory outside of tests

Ideally, each test should be responsible for setting up state it needs rather than relying upon transient global state. Toward this end, teach test_rev_parse() to accept a "-C " option to allow callers to instruct it explicitly in which directory its tests should be run. Take advantage of this new

[PATCH v3 5/5] t1500: avoid setting environment variables outside of tests

Ideally, each test should be responsible for setting up state it needs rather than relying upon transient global state. Toward this end, teach test_rev_parse() to accept a "-g " option to allow callers to specify the value of the GIT_DIR environment variable explicitly. Take advantage of this new

[PATCH v3 0/5] modernize t1500

This is a re-roll of [1] which modernizes t1500 by updating tests to set up their own needed state rather than relying upon manipulation of global state. Changes since v2[1]: Avoid POSIX ${dir:+-C "$dir"} since some older broken shells incorrectly expand this to a single argument ("-C ") rather

Re: [PATCHv7 5/5] pathspec: allow querying for attributes

Junio C Hamano writes: Just this part: > The last part "set, unset or value matches" does not make sense, > though. I re-read the line and I think you meant ?VAR makes a path match if VAR attribute is set, set to false, or set to value for the path and I shouldn't

Re: [PATCHv7 5/5] pathspec: allow querying for attributes

Stefan Beller writes: > + - "`+`" the attribute must be set > + - "`-`" the attribute must be unset > + - "`~`" the attribute must be unspecified I think using these three, not the way how .gitattributes specify them, is highly confusing to the users. > + - "`?`" the

Re: [PATCHv7 5/5] pathspec: allow querying for attributes

On Wed, May 18, 2016 at 12:02 PM, Stefan Beller wrote: > void free_pathspec(struct pathspec *pathspec) > { > + int i, j; > + for (i = 0; i < pathspec->nr; i++) { > + for (j = 0; j < pathspec->items[j].attr_match_nr; j++) > +

Re: [PATCH 05/21] i18n: sequencer: mark entire sentences for translation

On Wed, May 18, 2016 at 11:27 AM, Vasco Almeida wrote: > Mark entire sentences of error message rather than assembling one using > placeholders (e.g. "Cannot %s during a %s"). That would facilitate > translation work. > > Signed-off-by: Vasco Almeida

Re: [PATCH 03/21] i18n: advice: internationalize message for conflicts

On Wed, May 18, 2016 at 11:27 AM, Vasco Almeida wrote: > Mark message for translation telling the user she has conflicts to > resolve. Expose each particular use case, in order to enable translating > entire sentences which would facilitate translating into other >

[PATCHv7 1/5] string list: improve comment

Signed-off-by: Stefan Beller --- string-list.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/string-list.h b/string-list.h index d3809a1..465a1f0 100644 --- a/string-list.h +++ b/string-list.h @@ -106,7 +106,7 @@ void

proposal

Dear Friend, It is obvious that we are not friend's neither are we acquaintance, hence my mail will be a great surprise to you, but my Intents are not to delve into your privacy without caution and permission,but for a project opportunity worth $98.6 Million that will benefit both of us

[PATCHv7 5/5] 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 ---

[PATCHv7 3/5] pathspec: move long magic parsing out of prefix_pathspec

`prefix_pathspec` is quite a lengthy function and we plan on adding more. Split it up for better readability. As we want to add code into the inner loop of the long magic parsing, we also benefit from lower indentation. Signed-off-by: Stefan Beller --- pathspec.c | 84

[PATCHv7 4/5] pathspec: move prefix check out of the inner loop

The prefix check is not related the check of pathspec magic; also there is no code that is relevant after we'd break the loop on a match for "prefix:". So move the check before the loop and shortcircuit the outer loop. Signed-off-by: Stefan Beller --- pathspec.c | 19

[PATCHv7 0/5] pathspec magic extension to search for attributes

This goes on top of origin/jc/attr, (8195c5cde01, SQUASH???, 2016-05-17 14:08:50) Patches 1 and 2 are small fixes, which could go independently as well. (1 is new compared to v6) Patches 3 and 4 are refactoring pathspec.c a little. The last patch is the most exciting patch as it adds the new

[PATCHv7 2/5] Documentation: fix a typo

Signed-off-by: Stefan Beller --- Documentation/gitattributes.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt index e3b1de8..af2c682 100644 --- a/Documentation/gitattributes.txt +++

Re: [PATCH v2 00/12] revamping git_check_attr() API

Stefan Beller writes: >> The patches in the earliest part of the series have been sent to the >> list already; there is no substantial change (I think I made a >> typofix in the commit log message found by Eric). > > and a new patch got added here: > > attr.c: tighten

Re: [RFC/PATCH] Formatting variables in the documentation

On Wed, May 18, 2016 at 05:58:29PM +0200, Tom Russello wrote: > There is no agreement on this topic (the CodingGuidelines does not > mention it), it would be better if everyone follows the same rule: put > each environment variable in monospace style and write this rule in > the guide. > > It is

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

On Wed, May 18, 2016 at 06:40:19PM +0200, Antoine Queru wrote: > Option parsing now uses the parser API instead of a local parser. > Code is now more compact. Sounds like a good goal. > -static const char upload_pack_usage[] = "git upload-pack [--strict] > [--timeout=] "; > +static const char

Re: [Bug] git-log prints wrong unixtime with --date=format:%s

On Wed, May 18, 2016 at 12:44:43PM -0400, Randall S. Becker wrote: > Off the wall: Dealing in a dispersed team sharing a server that has a > timezone local for only two of the members, git log messes with me also from > a TZ POV. I would like to suggest a more general solution, like configuring >

Re: [Bug] git-log prints wrong unixtime with --date=format:%s

On Wed, May 18, 2016 at 09:21:34AM -0700, Junio C Hamano wrote: > Jeff King writes: > > > I tried a few obvious things, but couldn't make anything work. Setting > > "timezone" manually seems to do nothing. It's supposed to be set by > > putting the right thing in $TZ and then

Re: [PATCH v2 2/5] t1500: test_rev_parse: facilitate future test enhancements

On Wed, May 18, 2016 at 1:32 PM, Eric Sunshine wrote: > On Wed, May 18, 2016 at 12:38 PM, SZEDER Gábor wrote: >> Quoting Eric Sunshine : >>> + for o in is-bare-repository \ >>> +is-inside-git-dir \ >>> +

Re: [PATCH v2 2/5] t1500: test_rev_parse: facilitate future test enhancements

On Wed, May 18, 2016 at 12:38 PM, SZEDER Gábor wrote: > Quoting Eric Sunshine : >> + for o in is-bare-repository \ >> +is-inside-git-dir \ >> +is-inside-work-tree \ >> +show-prefix \ >> +

Re: [PATCH 13/21] rev-parse: add '--absolute-git-dir' option

Quoting Mike Rappazzo : On Thu, Feb 25, 2016 at 5:54 PM SZEDER Gábor wrote: Some scripts can benefit from not having to deal with the possibility of relative paths to the repository, but the output of 'git rev-parse --git-dir' can be a relative path.

[PATCH 2/2] cat-file: default to --buffer when --batch-all-objects is used

Traditionally cat-file's batch-mode does not do any output buffering. The reason is that a caller may have pipes connected to its input and output, and would want to use cat-file interactively, getting output immediately for each input it sends. This may involve a lot of small write() calls,

[PATCH 1/2] cat-file: avoid noop calls to sha1_object_info_extended

It is not unreasonable to ask cat-file for a batch-check format of simply "%(objectname)". At first glance this seems like a noop (you are generally already feeding the object names on stdin!), but it has a few uses: 1. With --batch-all-objects, you can generate a listing of the sha1s

Re: [PATCH 0/2] minor cat-file optimizations

On Wed, May 18, 2016 at 12:52:53PM -0400, Jeff King wrote: > At Git Merge, Charles suggested that "--buffer" should be the default > for "--batch-all-objects". This bit me again yesterday, so I thought I'd > actually implement it. :) > > That's in the second patch. The first one is another

[PATCH 0/2] minor cat-file optimizations

At Git Merge, Charles suggested that "--buffer" should be the default for "--batch-all-objects". This bit me again yesterday, so I thought I'd actually implement it. :) That's in the second patch. The first one is another micro-optimization that happens to help the use case I was working on (the

Re: [PATCH v2 00/12] revamping git_check_attr() API

> The patches in the earliest part of the series have been sent to the > list already; there is no substantial change (I think I made a > typofix in the commit log message found by Eric). and a new patch got added here: attr.c: tighten constness around "git_attr" structure I cannot find it

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

Option parsing now uses the parser API instead of a local parser. Code is now more compact. Signed-off-by: Antoine Queru Signed-off-by: Matthieu Moy --- This is our first project as a warm up. It was taken from the GSoC microproject

RE: [Bug] git-log prints wrong unixtime with --date=format:%s

On May 18, 2016 12:22 PM Jeff King wrote: > > I tried a few obvious things, but couldn't make anything work. Setting > > "timezone" manually seems to do nothing. It's supposed to be set by > > putting the right thing in $TZ and then calling tzset(). So I tried > > munging $TZ to something like

Re: [PATCH v2 2/5] t1500: test_rev_parse: facilitate future test enhancements

Quoting Eric Sunshine : Tests run by test_rev_parse() are nearly identical; each invokes git-rev-parse with a single option and compares the result against an expected value. Such duplication makes it onerous to extend the tests since any change needs to be repeated in

Re: [PATCH v2 10/12] attr: convert git_all_attrs() to use "struct git_attr_check"

On Tue, May 17, 2016 at 2:08 PM, Junio C Hamano wrote: > Junio C Hamano writes: > >> Given that one of the two expected callers, namely, "check-attr" and >> Stefan's pathspec label magic, of this "alloc and then append" side >> of the API wants to have an

Re: [Bug] git-log prints wrong unixtime with --date=format:%s

Jeff King writes: > I tried a few obvious things, but couldn't make anything work. Setting > "timezone" manually seems to do nothing. It's supposed to be set by > putting the right thing in $TZ and then calling tzset(). So I tried > munging $TZ to something like "+0200". It did

[RFC/PATCH] Formatting variables in the documentation

Put each environment variable in the same format for more consistency. Currently, in Documentation/git-config.txt GIT_CONFIG (l.138) has no particular style whereas in Documentation/config.txt GIT_PROXY_COMMAND has italic style ('GIT_PROXY_COMMAND' - l.437) and GIT_EDITOR is monospaced

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

Alexander 'z33ky' Hirsch <1ze...@gmail.com> writes: > Previously git-pull silently ignored the --verify-signatures option for > --rebase. Missing pieces information that would have made the patch more complete are answers to these questions: - Is that a bad thing? Why? - Assuming it is a

Re: [RFC-PATCHv6 4/4] pathspec: allow querying for attributes

Junio C Hamano writes: > The mention of the possibility is purely as a hint useful for a > possible enhancement in the far future. If we ever want to support > something like this: > > ":(attr-expression (VAR1=VAL1 | VAR1=VAL2) & VAR2)" > > you can remember that you can

[PATCH 14/21] i18n: rebase-interactive: mark strings for translation

Mark strings in git-rebase--interactive.sh for translation. There is no need to source git-sh-i18n since git-rebase.sh already does so. Add git-rebase--interactive.sh to LOCALIZED_SH in Makefile in order to enabled extracting strings marked for translation by xgettext. Signed-off-by: Vasco

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

The test t9003-help-autocorrect.sh fails when run under GETTEXT_POISON, because it's expecting to filter out the original output. Accommodate gettext poison case by also filtering out the default simulated output. Signed-off-by: Vasco Almeida ---

[PATCH 18/21] tests: unpack-trees: update to use test_i18n* functions

Use functions test_i18ncmp and test_i18ngrep to successfully pass tests running under GETTEXT_POISON. The output strings compared to in these test were marked for translation in ed47fdf ("i18n: unpack-trees: mark strings for translation", 2016-04-09) and later improved in 2e3926b ("i18n:

[PATCH 21/21] t5523: use test_i18ngrep for negation

Replace the first form by the second one: ! grep expected actual test_i18ngrep ! expected actual The latter syntax is supported by test_i18ngrep defined in t/test-lib.sh. Although the test already passes whether GETTEXT_POSION is enabled, use the i18n grep variant for the sake of

[PATCH 15/21] i18n: rebase-interactive: mark here-doc strings for translation

Use pipe to send gettext output to git stripspace instead of the original method of using shell here-document, because command substitution '$(...)' would not take place inside the here-documents. The exception is the case of the last here-document redirecting to cat, in which commands

[PATCH 17/21] tests: use test_i18n* functions to suppress false positives

The test functions test_i18ncmp and test_i18ngrep pretend success if run under GETTEXT_POISON. By using those functions to test output which is correctly marked as translatable, enables one to detect if the strings newly marked for translation are from plumbing output. If they are indeed from

[PATCH 16/21] i18n: rebase-interactive: mark comments of squash for translation

Mark comment messages of squash/fixup file ($squash_msg) for translation. Helper functions this_nth_commit_message and skip_nth_commit_message replace the previous method of making the comment messages (such as "This is the 2nd commit message:") aided by nth_string helper function. This step was

[PATCH 20/21] t4153: fix negated test_i18ngrep call

The function test_i18ngrep fakes success when run under GETTEXT_POISON. Hence, running in the following manner will always fail under gettext poison: ! test_i18ngrep expected actual Use correct syntax: test_i18ngrep ! expected actual For other instance of this issue see 41ca19b ("tests:

[PATCH 13/21] i18n: git-sh-setup.sh: mark strings for translation

Positional arguments, such as $0, $1, etc, need to be stored on shell variables for use in translatable strings, according to gettext manual. Add git-sh-setup.sh to LOCALIZED_SH variable in Makefile to enable extraction of string marked for translation by xgettext. Although git-sh-setup.sh is a

[PATCH 09/21] i18n: rebase: fix marked string to use eval_gettext variant

The string message marked for translation should use eval_gettext variant instead of the gettext one, since we want to dollar-substitute $head_name in the result. Signed-off-by: Vasco Almeida --- git-rebase.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff

[PATCH 02/21] i18n: advice: mark string about detached head for translation

Mark string with advice seen by the user when in detached head. Signed-off-by: Vasco Almeida --- advice.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/advice.c b/advice.c index 4dc5cf1..703a847 100644 --- a/advice.c +++ b/advice.c @@ -107,13

[PATCH 12/21] t6030: update to use test_i18ncmp

Since the git bisect output tested here is subject to translation, the helper function test_i18ncmp should be used over test_cmp. Signed-off-by: Vasco Almeida --- t/t6030-bisect-porcelain.sh | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git

[PATCH 10/21] i18n: rebase: mark placeholder for translation

Mark placeholder "" in git-rebase.sh for translation. The string containing the named placeholder is passed to shell function error_on_missing_default_upstream in git-parse-remote.sh which uses it to display a command hint for the user. Signed-off-by: Vasco Almeida ---

[PATCH 05/21] i18n: sequencer: mark entire sentences for translation

Mark entire sentences of error message rather than assembling one using placeholders (e.g. "Cannot %s during a %s"). That would facilitate translation work. Signed-off-by: Vasco Almeida --- sequencer.c | 11 --- 1 file changed, 8 insertions(+), 3 deletions(-)

[PATCH 04/21] i18n: transport: mark strings for translation

Mark one printf string and one error string for translation. Signed-off-by: Vasco Almeida --- transport.c | 20 ++-- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/transport.c b/transport.c index 095e61f..59b911e 100644 --- a/transport.c

[PATCH 01/21] i18n: builtin/remote.c: fix mark for translation

The second string inside _() was not being extracted for translation by xgettext, meaning that, although the string was passed to gettext, there was no translation available. Mark each individual string instead of marking the result of ternary if. Signed-off-by: Vasco Almeida

[PATCH 06/21] i18n: sequencer: mark string for translation

Mark informative string ": fast-forward" for translation. Signed-off-by: Vasco Almeida --- sequencer.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sequencer.c b/sequencer.c index 88a7c78..57b3671 100644 --- a/sequencer.c +++ b/sequencer.c @@ -225,7

[PATCH 03/21] i18n: advice: internationalize message for conflicts

Mark message for translation telling the user she has conflicts to resolve. Expose each particular use case, in order to enable translating entire sentences which would facilitate translating into other languages. Change "Pull" to lowercase to match other messages. Signed-off-by: Vasco Almeida

[PATCH 08/21] merge-octupus: use die shell function from git-sh-setup.sh

Source git-sh-setup in order to use die shell function from git-sh-setup.sh library instead of using the one defined in git-merge-octopus.sh. Remove the former die function. Signed-off-by: Vasco Almeida --- git-merge-octopus.sh | 6 +- 1 file changed, 1 insertion(+),

[PATCH 11/21] i18n: bisect: simplify error message for i18n

The message was not being extracted by xgettext, although it was marked for translation, seemingly because it contained a command substitution. Moreover, eval_gettext should be used instead of gettext for strings with substitution. See step 4. of section 15.5.2.1 Preparing Shell Scripts for

[PATCH 07/21] i18n: merge-octopus: mark messages for translation

Mark messages in git-merge-octopus.sh for translation. Signed-off-by: Vasco Almeida --- git-merge-octopus.sh | 18 ++ 1 file changed, 10 insertions(+), 8 deletions(-) diff --git a/git-merge-octopus.sh b/git-merge-octopus.sh index dc2fd1b..89e967a 100755

[PATCH 00/21] i18n and tests updates

Marks several messages for translation and updates tests to pass under GETTEXT_POISON. Some tests were updated to fit previous i18n marks, others were updated to fit marks made by these patches. Patches that only touch test file refer to marks done in commits previous to these ones. Vasco Almeida

Re: [RFD PATCH 0/3] Free all the memory!

On Tue, May 17, 2016 at 7:58 PM, Stefan Beller wrote: > On Mon, May 16, 2016 at 8:41 PM, Eric Sunshine > wrote: >> On Mon, May 16, 2016 at 11:22 PM, Stefan Beller wrote: >>> When using automated tools to find memory leaks, it is

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

On 18.05.16 06:26, Torsten Bögershausen wrote: > On 05/17/2016 08:58 PM, Junio C Hamano wrote: >> tbo...@web.de writes: >> >>> #define HASH_WRITE_OBJECT 1 >>> #define HASH_FORMAT_CHECK 2 >>> +#define HASH_CE_HAS_SHA1 4 >> >> How does one pronounce the words in this constant? Does it make a

  1   2   >