Re: [PATCH v3 5/6] trailer: allow non-trailers in trailer block

On 10/17/2016 06:42 PM, Junio C Hamano wrote: Stefan Beller writes: On Fri, Oct 14, 2016 at 10:38 AM, Jonathan Tan wrote: Existing trailers are extracted from the input message by looking for -a group of one or more lines that contain a colon

Re: [PATCH v3 5/6] trailer: allow non-trailers in trailer block

Stefan Beller writes: > On Fri, Oct 14, 2016 at 10:38 AM, Jonathan Tan > wrote: >> >> Existing trailers are extracted from the input message by looking for >> -a group of one or more lines that contain a colon (by default), where >> +a group of

Re: [PATCH v3 6/6] trailer: support values folded to multiple lines

On Fri, Oct 14, 2016 at 10:38 AM, Jonathan Tan wrote: > 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

Re: [PATCH v3 5/6] trailer: allow non-trailers in trailer block

On Fri, Oct 14, 2016 at 10:38 AM, Jonathan Tan wrote: > > Existing trailers are extracted from the input message by looking for > -a group of one or more lines that contain a colon (by default), where > +a group of one or more lines in which at least one line contains a

Re: [PATCH v3 4/6] trailer: make args have their own struct

On Fri, Oct 14, 2016 at 10:38 AM, Jonathan Tan wrote: > 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

Re: [PATCH v3 3/6] trailer: streamline trailer item create and add

On Fri, Oct 14, 2016 at 10:38 AM, Jonathan Tan wrote: > 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 >

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

On Mon, Oct 17, 2016 at 3:49 PM, Junio C Hamano wrote: > Stefan Beller writes: > >> +static void strip_url_ending(char *url, size_t *_len) >> +{ >> + int check_url_stripping = 1; >> + size_t len = _len ? *_len : strlen(url); >> + >> + while

Re: [PATCH v3 1/6] trailer: improve const correctness

On Fri, Oct 14, 2016 at 10:37 AM, Jonathan Tan wrote: > 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

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

Stefan Beller writes: > +static void strip_url_ending(char *url, size_t *_len) > +{ > + int check_url_stripping = 1; > + size_t len = _len ? *_len : strlen(url); > + > + while (check_url_stripping) { > + check_url_stripping = 0; > + if

Re: What's cooking in git.git (Oct 2016, #04; Mon, 17)

Hey Junio, On Tue, Oct 18, 2016 at 3:58 AM, Junio C Hamano wrote: > * pb/bisect (2016-10-14) 28 commits > - SQUASH??? > - bisect--helper: remove the dequote in bisect_start() > - bisect--helper: retire `--bisect-auto-next` subcommand > - bisect--helper: retire

Re: [PATCH v4 08/25] sequencer: completely revamp the "todo" script parsing

Johannes Schindelin writes: > - for (i = 1; *p; i++) { > + for (i = 1; *p; i++, p = next_p) { > char *eol = strchrnul(p, '\n'); > - commit = parse_insn_line(p, eol, opts); > - if (!commit) > - return

[RFD] should all merge bases be equal?

People can see how fast the usual merges I see everyday are by looking at output from $ git log --first-parent --format='%ct %s' master..pu and noticing the seconds since epoch. Most of the days, these are recreated directly on top of 'master' from scratch, and they get timestamps that are

What's cooking in git.git (Oct 2016, #04; Mon, 17)

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. We may have to start thinking

[PATCH] submodule--helper: normalize funny urls

Currently a URL for the superproject ending in (A).../path/to/dir (B).../path/to/dir/ (C).../path/to/dir/. (D).../path/to/dir/./. (E).../path/to/dir/.///.//. is treated the same in (A) and (B), but (C, D, E) are different. We never produce the URLs in (C,D,E) ourselves, they

Re: [PATCH] t0040: convert all possible tests to use `test-parse-options --expect`

Pranit Bauva writes: > Use "test-parse-options --expect" to rewrite the tests to avoid checking > the whole variable dump by just testing what is required. This commit is > based on 8ca65aeb (t0040: convert a few tests to use test-parse-options; > Junio C Hamano; May 6,

Re: [PATCH] convert: mark a file-local symbol static

On 17/10/16 21:07, Junio C Hamano wrote: > Ramsay Jones writes: > >> Heh, I actually have the following in my config.mak already: >> >> extra-clean: clean >> find . -iname '*.o' -exec rm {} \; >> >> But for some reason I _always_ type 'make clean' and then, to

Problems with "git svn clone"

I'm trying to create a git-svn repository with: git svn clone --username=pixleyr --stdlayout --branches branches --branches branches2 svn://mumble.com/mumble/mumble but the command dies about 11seconds in with: A

Re: [PATCH] cocci: avoid self-references in object_id transformations

René Scharfe writes: > I get these instead with 6513eabcbcbcfa684d4bb2d57f61c662b870b5ca on > Debian testing with its "spatch version 1.0.4 with Python support and > with PCRE support", which look legit: They do look good. So I'd stop worrying about it and see how painful to

Re: [PATCH] convert: mark a file-local symbol static

On Mon, Oct 17, 2016 at 1:07 PM, Junio C Hamano wrote: > Ramsay Jones writes: > >> Heh, I actually have the following in my config.mak already: >> >> extra-clean: clean >> find . -iname '*.o' -exec rm {} \; >> >> But for some reason I

Re: [PATCH] convert: mark a file-local symbol static

Am 17.10.2016 um 22:07 schrieb Junio C Hamano: Ramsay Jones writes: Heh, I actually have the following in my config.mak already: extra-clean: clean find . -iname '*.o' -exec rm {} \; But for some reason I _always_ type 'make clean' and then, to top it

Re: [GIT PULL] l10n updates for 2.10.0 maint branch

Jiang Xin writes: > Hi Junio, > > Please pull the following l10n updates for Git 2.10 to the maint branch. > > The following changes since commit 9a4b694c539fead26833c2104c1a93d3a2b4c50a: > > l10n: zh_CN: review for git v2.10.0 l10n (2016-09-11 21:34:23 +0800)

Re: [PATCH 1/2] submodule: ignore trailing slash on superproject URL

Johannes Sixt writes: >> "../." taken relative to "$(pwd)/." must be "$(pwd)/." >> "../." taken relative to "$PWD/." must be "$(pwd)/." >> >> test, because of the limitation of your bash, cannot have the latter >> half of the pair, so you'd need to comment it out with

Re: [PATCH] convert: mark a file-local symbol static

Ramsay Jones writes: > Heh, I actually have the following in my config.mak already: > > extra-clean: clean > find . -iname '*.o' -exec rm {} \; > > But for some reason I _always_ type 'make clean' and then, to top > it off, I _always_ type the 'find' command by

Re: [PATCH] cocci: avoid self-references in object_id transformations

Am 17.10.2016 um 20:08 schrieb Junio C Hamano: > ... oops. Totally unrelated to this patch, but I see these in > strbuf.cocci.patch (this is at the tip of 'pu'), which are total > nonsense. Perhaps I am running a way-stale spatch? It claims to be > "spatch version 1.0.0-rc19 with Python support

Re: [PATCH v2 2/3] gitweb: Link to 7-char+ SHA1s, not only 8-char+

On Mon, Oct 17, 2016 at 6:54 PM, Junio C Hamano wrote: > Ævar Arnfjörð Bjarmason writes: > >> As far as I can tell the only outstanding "change this" is your >> s/SHA1/SHA-1/ in , do >> you want to fix that up or

Re: [PATCH 1/2] submodule: ignore trailing slash on superproject URL

Am 17.10.2016 um 09:10 schrieb Junio C Hamano: And I agree from that point of view that having to spell both sides as $(pwd) would mean you are not testing that "Unixy input to Windowsy output" expectation, but at the same time, I think you would want "Windowsy input to Windowsy output"

Re: [PATCH 1/2] submodule: ignore trailing slash on superproject URL

Stefan Beller writes: >> Where at the end-user facing level does this trailing "/." surface >> and how does the difference appear to them? I think that is the >> crucial question. >> >> Unless there is some convincing argument why "." is not special >> (i.e. counter-argument

Re: [PATCH v4 00/25] Prepare the sequencer for the upcoming rebase -i patches

Johannes Schindelin writes: > This patch series marks the '4' in the countdown to speed up rebase -i > by implementing large parts in C (read: there will be three more patch > series after that before the full benefit hits git.git: sequencer-i, > rebase--helper and

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

Johannes Schindelin writes: > The sequencer is our attempt to lib-ify cherry-pick. Yet it behaves > like a one-shot command when it reads its configuration: memory is > allocated and released only when the command exits. > > This is kind of okay for git-cherry-pick,

Re: [PATCH 1/2] submodule: ignore trailing slash on superproject URL

On Mon, Oct 17, 2016 at 11:28 AM, Junio C Hamano wrote: > Stefan Beller writes: > >>> In any case, I find it more disturbing that we somehow ended up with >>> a system where these three things are expected to behave differently: >>> >>> A -

Re: [PATCH v11 00/14] Git filter protocol

larsxschnei...@gmail.com writes: > The goal of this series is to avoid launching a new clean/smudge filter > process for each file that is filtered. > > A short summary about v1 to v5 can be found here: > https://git.github.io/rev_news/2016/08/17/edition-18/ > > This series is also published on

Re: [PATCH 1/2] submodule: ignore trailing slash on superproject URL

Stefan Beller writes: >> In any case, I find it more disturbing that we somehow ended up with >> a system where these three things are expected to behave differently: >> >> A - path/to/dir >> B - path/to/dir/ >> C - path/to/dir/. >> >> Is that

Re: [PATCH] cocci: avoid self-references in object_id transformations

"brian m. carlson" writes: > On Sat, Oct 15, 2016 at 10:25:34AM +0200, René Scharfe wrote: >> The object_id functions oid_to_hex, oid_to_hex_r, oidclr, oidcmp, and >> oidcpy are defined as wrappers of their legacy counterparts sha1_to_hex, >> sha1_to_hex_r, hashclr,

Re: [PATCH 1/2] submodule: ignore trailing slash on superproject URL

On Mon, Oct 17, 2016 at 12:10 AM, Junio C Hamano wrote: > Johannes Schindelin writes: > >>> > expecting success: >>> > actual=$(git submodule--helper resolve-relative-url-test >>> > '(null)' '/usr/src/git/wip/t/trash

Re: Merge conflicts in .gitattributes can cause trouble

Johannes Schindelin writes: > I would vote for: > > 4. We keep letting Git read in the *current* version of .gitattributes >*before* the merge, and apply those attributes while performing the >merge. Even though this needs a major surgery to the way the attr

Re: [RFC] Case insensitive Git attributes

Duy Nguyen writes: > I agree. Which is why I wrote "we probably want something in the same > spirit but limited to .gitattributes and .gitignore only". In other > words we could have core.someName that makes .gitattributes and > .gitignore patterns case-insensitive (or

Re: [RFC] test-lib: detect common misuse of test_expect_failure

Jeff King writes: > I like the general idea, but I'm not sure how this would interact with > the tests in t that test the test suite. I tried but gave up adding a new test for this to t ;-) >> test_expect_failure () { >> +if test "$test_in_progress" = 1 >> +then

Re: [PATCH] fetch: use "quick" has_sha1_file for tag following

Jeff King writes: > Still an impressive speedup as a percentage, but negligible in absolute > terms. But that's on a local filesystem on a Linux machine. I'd worry > much more about a system with a slow readdir(), e.g., due to NFS. > Somebody's real-world NFS case[1] was what

Re: [PATCH v3 16/25] sequencer: support amending commits

Johannes Schindelin writes: > This teaches the run_git_commit() function to take an argument that will > allow us to implement "todo" commands that need to amend the commit > messages ("fixup", "squash" and "reword"). Likewise to 15/25, i.e. Good, though the growth

Re: [PATCH] convert: mark a file-local symbol static

On 17/10/16 10:37, Jeff King wrote: > On Mon, Oct 17, 2016 at 11:04:19AM +0200, Johannes Schindelin wrote: > >>> Gross. I would not be opposed to a Makefile rule that outputs the >>> correct set of OBJECTS so this (or other) scripts could build on it. >> >> You could also use the method I use

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

Johannes Schindelin writes: > +/* > + * Reads a file that was presumably written by a shell script, i.e. > + * with an end-of-line marker that needs to be stripped. > + * > + * Returns 1 if the file was read, 0 if it could not be read or does not > exist. > + */ >

Re: [PATCH v3 15/25] sequencer: allow editing the commit message on a case-by-case basis

Johannes Schindelin writes: > In the upcoming commits, we will implement more and more of rebase -i's > functionality inside the sequencer. One particular feature of the > commands to come is that some of them allow editing the commit message > while others don't,

Re: [PATCH] convert: mark a file-local symbol static

On 17/10/16 03:18, Jeff King wrote: > On Mon, Oct 17, 2016 at 02:37:58AM +0100, Ramsay Jones wrote: > >> Hmm, well, you have to remember that 'make clean' sometimes >> doesn't make clean. Ever since the Makefile was changed to only >> remove $(OBJECTS), rather than *.o xdiff/*.o etc., you have

Re: [PATCH v10 13/14] convert: add filter..process option

Torsten Bögershausen writes: >> +test_cmp_count () { >> +expect=$1 actual=$2 > > That could be > expect="$1" > actual="$2" Yes, but it does not have to ;-).

Re: What's cooking in git.git (Oct 2016, #03; Tue, 11)

Johannes Schindelin writes: >> I'll mark it as "wait for follow-up fix" in whats-cooking.txt (on >> 'todo' branch) to remind myself not to merge it yet. > > May I request your guidance as to your preference how to proceed? > ... I guess I didn't see this before I

Re: [PATCH v2 2/3] gitweb: Link to 7-char+ SHA1s, not only 8-char+

Ævar Arnfjörð Bjarmason writes: > As far as I can tell the only outstanding "change this" is your > s/SHA1/SHA-1/ in , do > you want to fix that up or should I submit another series? I think I did that already myself while queuing.

Re: Merge conflicts in .gitattributes can cause trouble

Hi Lars, On Tue, 4 Oct 2016, Lars Schneider wrote: > If there is a conflict in the .gitattributes during a merge then it looks > like as if the attributes are not applied I tried to replicate this behavior, to the point where I wrote a patch that demonstrates the breakage so I could

RE: Uninitialized submodules as symlinks

> -Original Message- > From: Duy Nguyen [mailto:pclo...@gmail.com] > Sent: Monday, October 17, 2016 5:46 AM > To: David Turner > Cc: Stefan Beller; git@vger.kernel.org > Subject: Re: Uninitialized submodules as symlinks > > On Sat, Oct 8, 2016 at 2:59 AM, David Turner

RE: Uninitialized submodules as symlinks

> -Original Message- > From: Heiko Voigt [mailto:hvo...@hvoigt.net] > Sent: Thursday, October 13, 2016 12:10 PM > To: David Turner > Cc: git@vger.kernel.org > Subject: Re: Uninitialized submodules as symlinks > > On Fri, Oct 07, 2016 at 06:17:05PM +, David Turner wrote: > >

[PATCH 1/4] i18n: apply: mark error message for translation

Update test to reflect changes. Signed-off-by: Vasco Almeida --- apply.c | 4 ++-- t/t4254-am-corrupt.sh | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/apply.c b/apply.c index 8215874..705cf56 100644 --- a/apply.c +++ b/apply.c @@

[PATCH 2/4] i18n: convert mark error messages for translation

Mark error messages about CRLF for translation. Update test to reflect changes. Signed-off-by: Vasco Almeida --- convert.c | 12 t/t0020-crlf.sh | 6 +- 2 files changed, 13 insertions(+), 5 deletions(-) diff --git a/convert.c b/convert.c index

[PATCH 4/4] i18n: diff: mark warnings for translation

Mark rename_limit_warning and degrade_cc_to_c_warning and rename_limit_warning for translation. Signed-off-by: Vasco Almeida --- diff.c | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/diff.c b/diff.c index 1d304e0..1687317 100644 ---

[PATCH 3/4] i18n: credential-cache--daemon: mark advice for translation

Mark permissions_advice for translation. Signed-off-by: Vasco Almeida --- credential-cache--daemon.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/credential-cache--daemon.c b/credential-cache--daemon.c index 1e5f16a..46c5937 100644 ---

Re: Automagic `git checkout branchname` mysteriously fails

On Sat, Oct 15, 2016 at 4:06 AM, Martin Langhoff wrote: > On Fri, Oct 14, 2016 at 4:58 PM, Kevin Daudt wrote: >> Correct, this only works when it's unambiguous what branch you actually >> mean. > > That's not surprising, but there isn't a warning. IMHO,

Re: [RFC] Case insensitive Git attributes

On Mon, Oct 17, 2016 at 5:46 PM, Johannes Schindelin wrote: > Hi Duy, > > On Mon, 17 Oct 2016, Duy Nguyen wrote: > >> On Mon, Oct 17, 2016 at 3:57 PM, Johannes Schindelin >> wrote: >> > Hi Stefan, >> > >> > On Sun, 16 Oct 2016, Stefan

Re: [RFC] Case insensitive Git attributes

Hi Duy, On Mon, 17 Oct 2016, Duy Nguyen wrote: > On Mon, Oct 17, 2016 at 3:57 PM, Johannes Schindelin > wrote: > > Hi Stefan, > > > > On Sun, 16 Oct 2016, Stefan Beller wrote: > > > >> Conceptually I would prefer if we had a single switch that indicates a > >> case

Re: [PATCH v1 1/2] config.mak.in: set NO_OPENSSL and APPLE_COMMON_CRYPTO for macOS >10.11

On Sun, Oct 16, 2016 at 05:25:49PM -0700, larsxschnei...@gmail.com wrote: > From: Lars Schneider > > Apple removed the OpenSSL header files in macOS 10.11 and above. OpenSSL > was deprecated since macOS 10.7. > > Set `NO_OPENSSL` and `APPLE_COMMON_CRYPTO` to

Re: Uninitialized submodules as symlinks

On Sat, Oct 8, 2016 at 2:59 AM, David Turner wrote: > > >> -Original Message- >> From: Stefan Beller [mailto:sbel...@google.com] >> Sent: Friday, October 07, 2016 2:56 PM >> To: David Turner >> Cc: git@vger.kernel.org >> Subject: Re: Uninitialized submodules as

Re: [PATCH] convert: mark a file-local symbol static

On Mon, Oct 17, 2016 at 11:04:19AM +0200, Johannes Schindelin wrote: > > Gross. I would not be opposed to a Makefile rule that outputs the > > correct set of OBJECTS so this (or other) scripts could build on it. > > You could also use the method I use in Git for Windows to "extend" the >

Re: [PATCH v3 07/25] sequencer: completely revamp the "todo" script parsing

[tl;dr: the version in your repo is fine, and there's a trivial fix below if we want to silence the warning in the meantime] On Mon, Oct 17, 2016 at 10:37:52AM +0200, Johannes Schindelin wrote: > > I'm not sure I agree. IIRC, Assigning values outside the range of an enum > > has > > always

Re: Uninitialized submodules as symlinks

On Fri, Oct 14, 2016 at 09:48:16AM -0700, Junio C Hamano wrote: > Kevin Daudt writes: > > > On Thu, Oct 13, 2016 at 06:10:17PM +0200, Heiko Voigt wrote: > >> On Fri, Oct 07, 2016 at 06:17:05PM +, David Turner wrote: > >> > Presently, uninitialized submodules are materialized

Re: [RFC] Case insensitive Git attributes

On Mon, Oct 17, 2016 at 3:57 PM, Johannes Schindelin wrote: > Hi Stefan, > > On Sun, 16 Oct 2016, Stefan Beller wrote: > >> Conceptually I would prefer if we had a single switch that indicates a >> case insensitive FS. > > AFAIU Lars' use case is where the FS is *case

Re: [PATCH] convert: mark a file-local symbol static

Hi Ramsay & Peff, On Sun, 16 Oct 2016, Jeff King wrote: > On Mon, Oct 17, 2016 at 02:37:58AM +0100, Ramsay Jones wrote: > > > Hmm, well, you have to remember that 'make clean' sometimes doesn't > > make clean. Ever since the Makefile was changed to only remove > > $(OBJECTS), rather than *.o

Re: [RFC] Case insensitive Git attributes

Hi Stefan, On Sun, 16 Oct 2016, Stefan Beller wrote: > Conceptually I would prefer if we had a single switch that indicates a > case insensitive FS. AFAIU Lars' use case is where the FS is *case sensitive*, but he still needs the .gitattributes to be *case insensitive* because that file

Re: [RFC] Case insensitive Git attributes

Hi Lars, On Sun, 16 Oct 2016, Lars Schneider wrote: > One idea could be to add an attribute "case-sensitive" (or > "caseSensitive") and set it to false (if desired) for all files in > .gitattributes for a given repo. > > ### .gitattributes example ### > > * case-sensitive=false > *.bar

Re: [PATCH v3 07/25] sequencer: completely revamp the "todo" script parsing

Hi Peff, On Sun, 16 Oct 2016, Jeff King wrote: > On Sun, Oct 16, 2016 at 10:09:12AM +0200, Johannes Schindelin wrote: > > > > Good catch. It technically needs to check the lower bound, too. In > > > theory, if somebody wanted to add an enum value that is negative, you'd > > > use a signed cast

Re: [PATCH 1/2] submodule: ignore trailing slash on superproject URL

Johannes Schindelin writes: >> > expecting success: >> > actual=$(git submodule--helper resolve-relative-url-test >> > '(null)' '/usr/src/git/wip/t/trash directory.t0060-path-utils/.' '../.') && >> > test "$actual" =