Re: git show doesn't work on file names with square brackets

On Mon, Feb 08, 2016 at 02:36:32PM -0800, Junio C Hamano wrote: > Jeff King writes: > > > But having looked at this, I can't help but wonder if the rule should > > not be "does the file exist" in the first place, but "is the file in the > > index". This dwimmery is about commands

Re: [PATCH v2] config: add '--sources' option to print the source of a config value

On Wed, Feb 10, 2016 at 1:47 PM, Ramsay Jones wrote: >> Sebastian suggested "--show-origin" as a better option name over "--sources". >> I still believe "--sources" might be slightly better as I fear that users >> could >> somehow related "origin" to "remote" kind

Re: [PATCH v2] config: add '--sources' option to print the source of a config value

On Wed, Feb 10, 2016 at 4:40 PM, Jeff King wrote: >> > file:\t >> > blob:\t >> > stdin\t >> > cmd\t >> > >> > with a single delimited slot for the source, which can then be broken >> > down further if desired. I can't think of any reason to prefer one over >> > the other

Re: [PATCH] mergetool: reorder vim/gvim buffers in three-way diffs

Junio C Hamano venit, vidit, dixit 09.02.2016 23:25: > Junio C Hamano writes: > >> Dickson Wong writes: >> >>> When invoking default (g)vimdiff three-way merge, the merged file is >>> loaded as the first buffer but moved to the bottom as the fourth

Bug in Quit shortcut key

The shortcut key for quit is ctrl+q which is shown as CTRL+Q in the toolbar. But the shortcut key only work's when Caps Lock is OFF, it gives no response when caps lock is ON. -- Success is not final, failure is not fatal: it is the courage to continue that counts. -- To unsubscribe from this

Re: [PATCH v2] config: add '--sources' option to print the source of a config value

On Wed, Feb 10, 2016 at 04:33:11PM +0100, Sebastian Schuberth wrote: > > where two of the prefixes have nothing in the second slot. I expected > > something more like: > > > > file:\t > > blob:\t > > stdin\t > > cmd\t > > > > with a single delimited slot for the source, which can then be

Re: git show doesn't work on file names with square brackets

On Tue, Feb 09, 2016 at 12:37:32PM -0800, Junio C Hamano wrote: > I was leaning towards merging this version, but I became unsure > while writing an entry for "What's cooking" (which will be used as a > merge summary message and then will appear in the Release Notes). > > We would surely want >

Re: GSoC 2016: applications open, deadline = Fri, 19/2

On Wed, Feb 10, 2016 at 3:09 AM, Johannes Schindelin wrote: > Hi Matthieu, > > On Wed, 10 Feb 2016, Matthieu Moy wrote: > >> I think participating is a good thing, but it needs mentors, ie. people >> and time. I am people and I have time! ;) > > I am available for

Re: [PATCH v2] config: add '--sources' option to print the source of a config value

On 10/02/16 15:28, Sebastian Schuberth wrote: > On Wed, Feb 10, 2016 at 1:47 PM, Ramsay Jones > wrote: > >>> Sebastian suggested "--show-origin" as a better option name over >>> "--sources". >>> I still believe "--sources" might be slightly better as I fear that

Re: git show doesn't work on file names with square brackets

Jeff King writes: > Yes, because ":/" is treated specially in check_filename(), and avoids > kicking in the wildcard behavior. That is certainly preferring revs to > pathspecs, but I think preferring one over the other is preferable to > barfing. If the user wants carefulness,

Re: [PATCH] mergetool: reorder vim/gvim buffers in three-way diffs

Michael J Gruber writes: >> Second call for help. Any comments on this from anybody other than >> the author that I missed to support this change? > > OK, applied it (on top of next), looks sane and improves the situation > for the majority of people who read left to

[PATCH v4 1/6] t0027: add tests for get_stream_filter()

From: Torsten Bögershausen When a filter is configured, a different code-path is used in convert.c and entry.c via get_stream_filter(), but there are no test cases yet. Add tests for the filter API by configuring the ident filter. The result of the SHA1 conversion is not checked,

[PATCH v4 3/6] convert.c: remove input_crlf_action()

From: Torsten Bögershausen Integrate the code of input_crlf_action() into convert_attrs(), so that ca.crlf_action is always valid after calling convert_attrs(). Keep a copy of crlf_action in attr_action, this is needed for get_convert_attr_ascii(). Remove eol_attr from struct

[PATCH v4 2/6] convert.c: remove unused parameter 'path'

From: Torsten Bögershausen Some functions get a parameter path, but don't use it. Remove the unused parameter. Signed-off-by: Torsten Bögershausen --- convert.c | 19 +-- 1 file changed, 9 insertions(+), 10 deletions(-) diff --git a/convert.c

[PATCH v4 4/6] convert.c: use text_eol_is_crlf()

From: Torsten Bögershausen Add a helper function to find out, which line endings text files should get at checkout, depending on core.autocrlf and core.eol configuration variables. Signed-off-by: Torsten Bögershausen Signed-off-by: Junio C Hamano

[PATCH v4 5/6] convert.c: refactor crlf_action

From: Torsten Bögershausen Refactor the determination and usage of crlf_action. Today, when no "crlf" attribute are set on a file, crlf_action is set to CRLF_GUESS. Use CRLF_UNDEFINED instead, and search for "text" or "eol" as before. After searching for line ending attributes,

[PATCH v4 6/6] convert.c: simplify text_stat

From: Torsten Bögershausen Simplify the statistics: lonecr counts the CR which is not followed by a LF, lonelf counts the LF which is not preceded by a CR, crlf counts CRLF combinations. This simplifies the evaluation of the statistics. Signed-off-by: Torsten Bögershausen

Re: [PATCH v2] config: add '--sources' option to print the source of a config value

On Wed, Feb 10, 2016 at 04:57:00PM +0100, Sebastian Schuberth wrote: > >> I also would have expected sopme like the latter, except that I'd also > >> expect a colon after "stdin" and "cmd" (or "cmdline", as said above). > >> I.e. the colon should be part of the prefix to mark it as such. > > > >

Re: [PATCH v2] config: add '--sources' option to print the source of a config value

On Wed, Feb 10, 2016 at 11:13:18AM +0100, larsxschnei...@gmail.com wrote: > If config values are queried using 'git config' (e.g. via '--list' flag > or the '--get*' flags) then it is sometimes hard to find the > configuration file where the values were defined. > > Teach 'git config' the

Git config depth option?

I checked the documentation and scanned through the source code for clone: https://github.com/git/git/blob/master/builtin/clone.c And nothing jumps out at me as a way to specify a default depth using a global git configuration file. I see the option defined at

Re: RFC: Resumable clone based on hybrid "smart" and "dumb" HTTP

On Wed, Feb 10, 2016 at 12:11 PM, Shawn Pearce wrote: > On Wed, Feb 10, 2016 at 10:59 AM, Shawn Pearce wrote: >> >> ... Thoughts? > > Several of us at $DAY_JOB talked about this more today and thought a > variation makes more sense: > > 1. Clients

[PATCH 1/3] checkout: reorder check_filename conditional

If we have a "--" flag, we should not be doing DWIM magic based on whether arguments can be filenames. Reorder the conditional to avoid the check_filename() call entirely in this case. The outcome is the same, but the short-circuit makes the dependency more clear. Signed-off-by: Jeff King

Re: git show doesn't work on file names with square brackets

On Wed, Feb 10, 2016 at 09:35:46AM -0800, Junio C Hamano wrote: > > IOW, something like this implements the "permissive" thing I wrote above > > (i.e., be inclusive when seeing if something could plausibly be a > > filename, but exclusive when complaining that it _could_ be one): > > Yup, I

[PATCH 3/3] get_sha1: don't die() on bogus search strings

The get_sha1() function generally returns an error code rather than dying, and we sometimes speculatively call it with something that may be a revision or a pathspec, in order to see which one it might be. If it sees a bogus ":/" search string, though, it complains, without giving the caller the

Re: RFC: Resumable clone based on hybrid "smart" and "dumb" HTTP

Stefan Beller writes: >> 6. Once stored and indexed with .idx, clients run `git fsck >> --lost-found` to discover the roots of the pack it downloaded. These >> are saved as temporary references. > > jrn: >> I suspect we can do even faster by making index-pack do the work I

Re: [PATCH 1/3] checkout: reorder check_filename conditional

Jeff King writes: > If we have a "--" flag, we should not be doing DWIM magic > based on whether arguments can be filenames. Reorder the > conditional to avoid the check_filename() call entirely in > this case. The outcome is the same, but the short-circuit > makes the dependency

Re: RFC: Resumable clone based on hybrid "smart" and "dumb" HTTP

On Wed, Feb 10, 2016 at 10:59 AM, Shawn Pearce wrote: > > ... Thoughts? Several of us at $DAY_JOB talked about this more today and thought a variation makes more sense: 1. Clients attempting clone ask for /info/refs?service=git-upload-pack like they do today. 2. Servers

Re: RFC: Resumable clone based on hybrid "smart" and "dumb" HTTP

Junio C Hamano wrote: > I somehow doubt it. Both index-pack and lost-found need to trace > "object A depends on object B", but the similarity ends there. You already responded about this in another side-thread, so the following is mostly redundant. :) I think this message can still be useful

Re: RFC: Resumable clone based on hybrid "smart" and "dumb" HTTP

Stefan Beller wrote: > On Wed, Feb 10, 2016 at 12:11 PM, Shawn Pearce wrote: >> Several of us at $DAY_JOB talked about this more today and thought a >> variation makes more sense: >> >> 1. Clients attempting clone ask for /info/refs?service=git-upload-pack >> like they do

Re: RFC: Resumable clone based on hybrid "smart" and "dumb" HTTP

Jonathan Nieder writes: > --strict + --check-self-contained-and-connected check that the pack > is self-contained. In the process they mark each object that is > reachable from another object in the pack with FLAG_LINK. > > The objects not marked with FLAG_LINK are the

[PATCH 2/3] check_filename: tighten dwim-wildcard ambiguity

When specifying both revisions and pathnames, we allow " -- " to be spelled without the "--" as long as it is not ambiguous. The original logic was something like: 1. Resolve each item with get_sha1(). If successful, we know it can be a . Verify that it _isn't_ a filename, using

Re: RFC: Resumable clone based on hybrid "smart" and "dumb" HTTP

On Wed, Feb 10, 2016 at 01:22:07PM -0800, Jonathan Nieder wrote: > > I am not quite sure if that is an advantage, though. The second > > message proposes that the lost-found computation to be done by the > > client using *.pack, but any client, given the same *.pack, will > > compute the same

Re: RFC: Resumable clone based on hybrid "smart" and "dumb" HTTP

On Wed, Feb 10, 2016 at 12:11:46PM -0800, Shawn Pearce wrote: > On Wed, Feb 10, 2016 at 10:59 AM, Shawn Pearce wrote: > > > > ... Thoughts? > > Several of us at $DAY_JOB talked about this more today and thought a > variation makes more sense: > > 1. Clients attempting

Re: [PATCH 3/3] get_sha1: don't die() on bogus search strings

Jeff King writes: > The get_sha1() function generally returns an error code > rather than dying, and we sometimes speculatively call it > with something that may be a revision or a pathspec, in > order to see which one it might be. > > If it sees a bogus ":/" search string,

git-svn clone error

I'm attempting to git-svn clone a subversion repository that contains a space in the name of a branch. This is the result (after many many revisions): r148627 = fafd5730f356dcb80f72c9b93f976d9707755a03 (refs/remotes/origsvn/2.0_PriorToStuff) Found possible branch point:

Re: RFC: Resumable clone based on hybrid "smart" and "dumb" HTTP

Jeff King writes: > Clients do not have to _just_ fetch a packfile. They could get a bundle > file that contains the roots along with the packfile. I know that one of > your goals is not duplicating the storage of the packfile on the server, > but it would not be hard for the

Re: RFC: Resumable clone based on hybrid "smart" and "dumb" HTTP

Jeff King wrote: > On Wed, Feb 10, 2016 at 12:11:46PM -0800, Shawn Pearce wrote: >> Several of us at $DAY_JOB talked about this more today and thought a >> variation makes more sense: >> >> 1. Clients attempting clone ask for /info/refs?service=git-upload-pack >> like they do today. >> >> 2.

Re: [PATCHv9 4/6] git submodule update: have a dedicated helper for cloning

On Tue, Feb 9, 2016 at 6:26 PM, Jacob Keller wrote: > On Tue, Feb 9, 2016 at 12:54 PM, Stefan Beller wrote: >> This introduces a new helper function in git submodule--helper >> which takes care of cloning all submodules, which we want to >> parallelize

RFC: Resumable clone based on hybrid "smart" and "dumb" HTTP

Sorry, no code, only words today. Previously people have proposed a few different options for resumable clone, like "clone.bundle" (currently used by Android as a hack) or "skip start of regenerated pack". Here is another option. We could implement resumable clone by making a bit of a hybrid of

Business Partnership

Hello, I am Mr. LAURENT EYADEMA from Republic of Togo.please read the attached proposal. Thanks in anticipation of your urgent response, LAURENT EYADEMA proposal.docx Description: Binary data

Re: RFC: Resumable clone based on hybrid "smart" and "dumb" HTTP

Jonathan Nieder writes: > I really like this design. I'm tempted to implement it (since it > lacks a bunch of the downsides of clone.bundle). Just to see people are not stepping on each others toe, implementing slightly different components in parallel based on the same

Re: [PATCH v4 02/21] refs: add methods for misc ref operations

On 02/05/2016 08:44 PM, David Turner wrote: > From: Ronnie Sahlberg > > Add ref backend methods for: > resolve_ref_unsafe, verify_refname_available, pack_refs, peel_ref, > create_symref, resolve_gitlink_ref. > > Signed-off-by: Ronnie Sahlberg >

assert failed in pathspec.c

Hi all, I've got an assertion error when `git add .` git: pathspec.c:317: prefix_pathspec: Assertion `item->nowildcard_len <= item->len && item->prefix <= item->len' failed. Aborted (core dumped) I think the repo doesn't have anything interesting. No submodules or subrepos. It's like: repo/

Re: [PATCHv9 4/6] git submodule update: have a dedicated helper for cloning

On Wed, Feb 10, 2016 at 9:49 AM, Stefan Beller wrote: > Do you mean the separate bug fix patch as proposed by Jonathan or > this patch in general helps your idea of passing settings? > > Thanks, > Stefan This patch in general, I think. I didn't mean to reply to the whole

GSoC 2016: applications open, deadline = Fri, 19/2

Hi, The GSoC (Google Summer of Code) application for mentoring organizations is now open. The deadline is Friday, February 19 at 19:00 UTC. That is: very soon. New website here: https://summerofcode.withgoogle.com/. More info about Git's previous GSoC iterations there:

[PATCH v2] config: add '--sources' option to print the source of a config value

From: Lars Schneider If config values are queried using 'git config' (e.g. via '--list' flag or the '--get*' flags) then it is sometimes hard to find the configuration file where the values were defined. Teach 'git config' the '--sources' option to print the source

Re: GSoC 2016: applications open, deadline = Fri, 19/2

Hi Matthieu, On Wed, 10 Feb 2016, Matthieu Moy wrote: > I think participating is a good thing, but it needs mentors, ie. people > and time. I am available for mentoring. Stefan, it was really fun to co-mentor with you, would you be willing to repeat the exercise? Ciao, Dscho -- To unsubscribe

Good day

Good day, I need a foreign partner for a proposed mutual business, which refers to the transfer of a large sum of money to an account abroad, as the beneficiary of the funds. Everything about this operation, will be legally done without any bridge financial authority, both in my country and

Re: [PATCH v2] config: add '--sources' option to print the source of a config value

On 10/02/16 10:13, larsxschnei...@gmail.com wrote: > From: Lars Schneider > > If config values are queried using 'git config' (e.g. via '--list' flag > or the '--get*' flags) then it is sometimes hard to find the > configuration file where the values were defined. >

[ANNOUNCE] Git Rev News edition 12

Hi everyone, I'm happy announce that the 12th edition of Git Rev News is now published: http://git.github.io/rev_news/2016/02/10/edition-12/ Thanks a lot to all the contributors, especially Thomas Gummerer! Enjoy, Christian, Thomas and Nicola. -- To unsubscribe from this list: send the line

Re: [PATCH v2] config: add '--sources' option to print the source of a config value

On Wed, Feb 10, 2016 at 11:13:18AM +0100, larsxschnei...@gmail.com wrote: > diff to v1: > > * add documention > * produce a consistent (tab-delimited) format that can be parsed > * adhere declaration-after-statement style > * prefix every source line with the source type (file, stdin, blob, cmd)

RE: RE

Did you recieve my previous message? When can i call you? -- 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

Interim "What's cooking"

In today/tonight's pushout, the 'master' branch will have these topics merged. Thanks for contributing ;-) [Graduated to "master"] * aw/push-force-with-lease-reporting (2016-02-01) 1 commit (merged to 'next' on 2016-02-03 at facd28f) + push: fix ref status reporting for --force-with-lease

Re: RFC: Resumable clone based on hybrid "smart" and "dumb" HTTP

On Wed, Feb 10, 2016 at 02:17:58PM -0800, Jonathan Nieder wrote: > > Because the magic happens in the git protocol, that would mean this does > > not have to be limited to git-over-http. It could be "resumable=" > > to point the client anywhere (the same server over a different protocol, > >

Re: Bug in Quit shortcut key

sO YOU ARE TALKING ABOUT GITK (oops, still had the capslock on ;) I can confirm the bug that CTRL + Q is not working while capslocks is on. On Wed, Feb 10, 2016 at 5:50 AM, Shikhar wrote: > The shortcut key for quit is ctrl+q which is shown as CTRL+Q in the toolbar. > But

Business Partnership

Hello, I am Mr. LAURENT EYADEMA from Republic of Togo.please read the attached proposal. Thanks in anticipation of your urgent response, LAURENT EYADEMA proposal.docx Description: Binary data