Re: Request re git status

On Wed, Feb 8, 2017 at 12:30 AM, Jacob Keller wrote: > On Tue, Feb 7, 2017 at 10:13 PM, Duy Nguyen wrote: >> On Wed, Feb 8, 2017 at 2:18 AM, Jacob Keller wrote: >>> Personally, I think that the fact that Git forces the user to

Re: "disabling bitmap writing, as some objects are not being packed"?

On Wed, Feb 8, 2017 at 8:03 AM, David Turner wrote: > On Sat, 2016-12-17 at 14:50 +0700, Duy Nguyen wrote: >> And we can't grep for fatal errors anyway. The problem that led to >> 329e6e8794 was this line >> >> warning: There are too many unreachable loose objects; run

Re: Fwd: Possibly nicer pathspec syntax?

On Wed, Feb 8, 2017 at 12:12 PM, Linus Torvalds wrote: > Two-patch series to follow. glossary-content.txt update for both patches would be nice. -- Duy

Re: Request re git status

On Tue, Feb 7, 2017 at 10:13 PM, Duy Nguyen wrote: > On Wed, Feb 8, 2017 at 2:18 AM, Jacob Keller wrote: >> Personally, I think that the fact that Git forces the user to think >> about it in terms of "oh I have to fetch" instead of that happening >>

Re: The --name-only option for git log does not play nicely with --graph

On Wed, Feb 8, 2017 at 6:11 AM, Davide Del Vento wrote: > `git log --graph --name-only` works fine, but the name is not > properly indented as it is for `git log --graph --name-status` > > I tested this in git v1.9.1 the only one I have access at the moment Confirmed still

Re: Request re git status

On Wed, Feb 8, 2017 at 2:18 AM, Jacob Keller wrote: > Personally, I think that the fact that Git forces the user to think > about it in terms of "oh I have to fetch" instead of that happening > automatically, it helps teach the model to the user. If it happened in > the

Re: [PATCH] dir: avoid allocation in fill_directory()

On Wed, Feb 8, 2017 at 5:04 AM, René Scharfe wrote: > Pass the match member of the first pathspec item directly to > read_directory() instead of using common_prefix() to duplicate it first, > thus avoiding memory duplication, strlen(3) and free(3). How about killing

[PATCH v2] rev-list-options.txt: update --all about HEAD

This is the document patch for f0298cf1c6 (revision walker: include a detached HEAD in --all - 2009-01-16). Even though that commit is about detached HEAD, as Jeff pointed out, always adding HEAD in that case may have subtle differences with --source or --exclude. So the document mentions nothing

[PATCH 2/2] pathspec: don't error out on all-exclusionary pathspec patterns

From: Linus Torvalds Date: Tue, 7 Feb 2017 21:08:15 -0800 Subject: [PATCH 2/2] pathspec: don't error out on all-exclusionary pathspec patterns Instead of erroring out and telling the user that they should add a positive pattern that covers everything else, just

[PATCH 1/2] pathspec magic: add '^' as alias for '!'

From: Linus Torvalds Date: Tue, 7 Feb 2017 21:05:28 -0800 Subject: [PATCH 1/2] pathspec magic: add '^' as alias for '!' The choice of '!' for a negative pathspec ends up not only not matching what we do for revisions, it's also a horrible character for shell

Re: Fwd: Possibly nicer pathspec syntax?

On Tue, 7 Feb 2017, Junio C Hamano wrote: > > + // Special case alias for '!' > > /* style? */ Will fix. > I somehow do not think this is correct. I expect > > cd t && git grep -e foo -- :^perf/ > > to look into things in 't' except for things in 't/perf', but the > above

Re: Fwd: Possibly nicer pathspec syntax?

Linus Torvalds writes: > People don't expect set theory from their pathspecs. They expect their > pathspecs to limit the output. They've learnt that within a > subdirectory, the pathspec limits to that subdirectory. And now it > suddenly starts showing things

Re: Fwd: Possibly nicer pathspec syntax?

On Tue, Feb 7, 2017 at 7:12 PM, Junio C Hamano wrote: > > But that is not what I was talking about. Let's simplify. I'd say > for any command that acts on "everything" when pathspec is not > given, the two sets of actual paths affected by these two: > > git cmd --

Re: Fwd: Possibly nicer pathspec syntax?

Linus Torvalds writes: > No. The thing is, "git diff" is relative too - for path > specifications. And the negative entries are pathspecs - and they act > as relative ones. > > IOW, that whole > > cd drivers > git diff A..B -- net/ > > will actually show the

Re: Fwd: Possibly nicer pathspec syntax?

On Tue, Feb 07, 2017 at 05:48:26PM -0800, Linus Torvalds wrote: > > > On Tue, 7 Feb 2017, Linus Torvalds wrote: > > > > [ Clarification from original message, since Junio asked: I didn't > > actually want the semantics of '.' at all, since in a subdirectory it > > limits to the current

Re: Fwd: Possibly nicer pathspec syntax?

On Tue, Feb 07, 2017 at 06:49:24PM -0800, Linus Torvalds wrote: > On Tue, Feb 7, 2017 at 6:40 PM, Mike Hommey wrote: > > > > As such, the default positive match should be ':/' (which is shorter and > > less cumbersome than ':(top)', btw) > > So that's what my patch does. > >

Re: Fwd: Possibly nicer pathspec syntax?

On Tue, Feb 7, 2017 at 6:42 PM, Junio C Hamano wrote: > > 1. I think some commands limit their operands to cwd and some work > on the whole tree when given no pathspec. I think the "no > positive? then let's give you everything except these you > excluded" should

Re: Fwd: Possibly nicer pathspec syntax?

On Tue, Feb 7, 2017 at 6:40 PM, Mike Hommey wrote: > > As such, the default positive match should be ':/' (which is shorter and > less cumbersome than ':(top)', btw) So that's what my patch does. However, it's actually very counter-intuitive in a subdirectory. Git doesn't do

Re: Fwd: Possibly nicer pathspec syntax?

Linus Torvalds writes: > So here's an RFC patch, and I'm quoting the above part of my thinking > because it's what the patch does, but it turns out that it's probably not > what we want, and I suspect the "." behavior (as opposed to "no filtering > at all") is

RE: [RFC] Add support for downloading blobs on demand

Thanks Jakub. Just so you are aware, this isn't a separate effort, it actually is the same effort as the GVFS effort from Microsoft. For pragmatic reasons, we implemented the lazy clone support and on demand object downloading in our own codebase (GVFS) first and are now are working to move

Re: Fwd: Possibly nicer pathspec syntax?

On Tue, 7 Feb 2017, Linus Torvalds wrote: > > [ Clarification from original message, since Junio asked: I didn't > actually want the semantics of '.' at all, since in a subdirectory it > limits to the current subdirectory. So I'd suggest that in the absence > of any positive pattern,

[PATCH] push options: fail properly in the stateless case

When using non-builtin protocols relying on a transport helper (such as http), push options are not propagated to the helper. Fix this by propagating the push options to the transport helper and adding a test that push options using http fail properly. Signed-off-by: Stefan Beller

Re: "disabling bitmap writing, as some objects are not being packed"?

On Sat, 2016-12-17 at 14:50 +0700, Duy Nguyen wrote: > And we can't grep for fatal errors anyway. The problem that led to > 329e6e8794 was this line > > warning: There are too many unreachable loose objects; run 'git > prune' to remove them. > > which is not fatal. So, speaking of that

Re: Fwd: Possibly nicer pathspec syntax?

Linus Torvalds writes: > [ Duh, I sent this just to Junio initially due to a brainfart. Here > goes the list also ] And my earlier response goes to the list ;-) Linus Torvalds writes: > Most of the time when I use pathspecs, I

Re: git/git-scm.com GH Issue Tracker

Finished going through and nailed the rest of the open issues! # Irrelevant but it seems like someone should take a look 511 466 # Irrelevant to git-scm.com and should be closed 599 596 570 565 563 558 538 537 520 511 509 507 501 494 465 # Resolved, duplicate, or non-issue 596 593 592 588

Re: [RFC 00/14] Allow fetch-pack to send ref names (globs allowed)

Looking back at the comments I have received in reply, I think that there were two major concerns: (i) the case where a server ACKs a client "have" line and the client forever thinks that the server has it, but it may not be the case for future servers (or future invocations of the same server),

Re: Trying to use xfuncname without success.

Am 07.02.2017 um 20:21 schrieb Jack Adrian Zappa: I'm trying to setup a hunk header for .natvis files. For some reason, it doesn't seem to be working. I'm following their instructions from here, which doesn't say much in terms of restrictions of the regex, such as, is the matched item considered

Fwd: Possibly nicer pathspec syntax?

[ Duh, I sent this just to Junio initially due to a brainfart. Here goes the list also ] Most of the time when I use pathspecs, I just use the bog-standard normal ones, and everything works wonderfully. But then occasionally I want to exclude a directory (usually "drivers/"), and it all works

The --name-only option for git log does not play nicely with --graph

`git log --graph --name-only` works fine, but the name is not properly indented as it is for `git log --graph --name-status` I tested this in git v1.9.1 the only one I have access at the moment Regards, Davide Del Vento, NCAR Computational & Information Services Laboratory

Re: git-daemon shallow checkout fail

Duy Nguyen wrote: > I wonder if we should make this "git/1.9.1" information more visible. We could > > 1) Always print it when cloning > 2) Print it when cloning with -v (printing all capabilities with -v > might not be a bad idea) > 3) Include it in error messages when clone/fetch fails I don't

Re: [RFC] mailmap.blob overrides default .mailmap

On 02/07/2017 08:28 PM, Jeff King wrote: > > I think it was mostly that I had to define _some_ order. This made sense > to me as similar to things like attributes or excludes, where we prefer > clone-specific data over in-history data (so .git/info/attributes takes > precedence over

Re: [PATCH 1/5] add SWAP macro

René Scharfe writes: > Swapping between different types would then still have to be done > manually, but I wonder how common that is -- couldn't find such a case > in our tree. I do not think it is a common thing to do, and more importantly, I doubt we want to hide such a swap

Re: [PATCH 1/5] add SWAP macro

Am 01.02.2017 um 19:33 schrieb Junio C Hamano: > René Scharfe writes: > >> Size checks could be added to SIMPLE_SWAP as well. > > Between SWAP() and SIMPLE_SWAP() I am undecided. > > If the compiler can infer the type and the size of the two > "locations" given to the macro,

[PATCH] dir: avoid allocation in fill_directory()

Pass the match member of the first pathspec item directly to read_directory() instead of using common_prefix() to duplicate it first, thus avoiding memory duplication, strlen(3) and free(3). Signed-off-by: Rene Scharfe --- This updates 966de3028 (dir: convert fill_directory to use

Re: [RFC] Add support for downloading blobs on demand

I'd like to point to two (or rather one and a half) solutions that I got aware of when watching streaming of "Git Merge 2017"[0]. There should be here people who were there; and hopefully video of those presentations and slides / notes would be soon available. [0]: http://git-merge.com/ First

git push - 401 unauthorized

I try to push my commit on a private repository (which has been working since about five years). This is the output of git push: me@superstar:/var/www/scorte$ git push --verbose Pushing to http://isisenscorte:mypassword@mymachine/scorte_git Getting pack list Fetching remote heads... refs/

Re: Git clonebundles

Johannes Schindelin writes: >> If people think it might be useful to have it around to experiment, I >> can resurrect and keep that in 'pu' (or rather 'jch'), as long as it >> does not overlap and conflict with other topics in flight. Let me try >> that in today's

[PATCH/RFC v2] WIP: log: allow "-" as a short-hand for "previous branch"

Teach revision.c:setup_revisions that an argument starting with "-" can be an argument also. `left` variable needs to be incremented only when the supplied arg is neither an argument, nor an option. Teach sha1_name.c:get_sha1_1 that "-" is equivalent to "@{-1}" Signed-off-by: Siddharth Kannan

Re: [PATCH v2 2/2] grep: use '/' delimiter for paths

Junio C Hamano writes: Sorry, one shouldn't type while being sick and in bed X-<. > I am not sure if you are shooting for is "work correctly" to begin > with, to be honest. The current code always shows the "correct" > output which is "the tree-ish object name (expressed in

Re: [PATCH v2 2/2] grep: use '/' delimiter for paths

Stefan Hajnoczi writes: > Perhaps it's better to leave this than to merge code that doesn't work > correctly 100% of the time. I am not sure if you are shooting for is "work correctly" to begin with, to be honest. The current code always shows the "correct" output which is

Re: [PATCH] difftool: fix bug when printing usage

Junio C Hamano writes: > Johannes Schindelin writes: > >>> > Likewise, this would become >>> > >>> > GIT_CEILING_DIRECTORIES="$PWD/not" \ >>> > test_expect_code 129 git -C not/repo difftool -h >output && >>> > grep ^usage: output >>> >>> I

Re: [PATCH] difftool: fix bug when printing usage

Johannes Schindelin writes: >> > Likewise, this would become >> > >> >GIT_CEILING_DIRECTORIES="$PWD/not" \ >> >test_expect_code 129 git -C not/repo difftool -h >output && >> >grep ^usage: output >> >> I agree with the intent, but the execution here is

Re: What's cooking in git.git (Feb 2017, #02; Mon, 6)

SZEDER Gábor writes: > All failing tests fail with the same error: > > fatal: unrecognized %(refname:strip=2) argument: strip=2 > > That's because of this topic: > >> * kn/ref-filter-branch-list (2017-01-31) 20 commits Ahh, of course. Let's make sure the series won't

Re: [PATCH v2 2/2] grep: use '/' delimiter for paths

On Tue, Feb 07, 2017 at 03:04:14PM +, Stefan Hajnoczi wrote: > > I assume Stefan just grabbed my naive suggestion hence why it checks > > equality with a commit. So that's my fault :) Either of these may > > not be enough though, since if you do 'git grep malloc v2.9.3^{tree}' > > with this

Re: [PATCH] rev-list-options.txt: update --all about detached HEAD

On Tue, Feb 07, 2017 at 08:38:49PM +0700, Nguyễn Thái Ngọc Duy wrote: > This is the document patch for f0298cf1c6 (revision walker: include a > detached HEAD in --all - 2009-01-16) > [...] > --all:: > - Pretend as if all the refs in `refs/` are listed on the > - command line as ''. > +

Re: subtree merging fails

On Tue, Feb 07, 2017 at 08:59:06AM -0600, Samuel Lijin wrote: > Have you tried using (without -s subtree) -X subtree=path/to/add/subtree/at? > > From the man page: > > subtree[=] >This option is a more advanced form of subtree > strategy, where the strategy >

Re: ``git clean -xdf'' and ``make clean''

On Tue, Feb 7, 2017 at 7:07 AM, Cornelius Weig wrote: > On 02/07/2017 03:17 PM, Hongyi Zhao wrote: >> Hi all, >> >> In order to delete all of the last build stuff, does the following two >> methods equivalent or not? >> >> ``git clean -xdf'' and ``make clean'' > > No,

Re: [RFC] mailmap.blob overrides default .mailmap

On Tue, Feb 07, 2017 at 09:27:19AM -0800, Stefan Beller wrote: > > The code shows why (mailmap.c): > > err |= read_mailmap_file(map, ".mailmap", repo_abbrev); > > if (startup_info->have_repository) > > err |= read_mailmap_blob(map, git_mailmap_blob, > >

Trying to use xfuncname without success.

I'm trying to specify a hunk header using xfuncname, and it just doesn't want to work. The full question is on SO here: http://stackoverflow.com/questions/42078376/why-isnt-my-xfuncname-working-in-my-gitconfig-file But the basic gist is that no matter what regex I specify, git will not

Re: Request re git status

On Tue, Feb 7, 2017 at 6:54 AM, Samuel Lijin wrote: > On Mon, Feb 6, 2017 at 6:45 PM, Phil Hord wrote: >> On Mon, Feb 6, 2017 at 3:36 PM Ron Pero wrote: >>> I almost got bit by git: I knew there were changes on the remote >>> server,

Re: [PATCH/RFC] WIP: log: allow "-" as a short-hand for "previous branch"

On Mon, Feb 06, 2017 at 03:09:47PM -0800, Junio C Hamano wrote: > The focus of GSoC being mentoring those who are new to the open > source development, and hopefully retain them in the community after > GSoC is over, we do expect microprojects to be suitable for those > who are new to the

RE: [RFC] Add support for downloading blobs on demand

No worries about a late response, I'm sure this is the start of a long conversation. :) > -Original Message- > From: Christian Couder [mailto:christian.cou...@gmail.com] > Sent: Sunday, February 5, 2017 9:04 AM > To: Ben Peart > Cc: Jeff King ; git

Re: [RFC] mailmap.blob overrides default .mailmap

On Tue, Feb 7, 2017 at 3:56 AM, Cornelius Weig wrote: > Hi, > > I was reading into the mailmap handling today and I'm a bit puzzled by the > overriding behavior. > > This is what the documentation says about precedence (emphasis mine): > - > mailmap.file

Re: Git clonebundles

On Tue, Feb 7, 2017 at 4:04 AM, Johannes Schindelin wrote: > Hi Junio, > > On Mon, 6 Feb 2017, Junio C Hamano wrote: > >> Christian Couder writes: >> >> > There is also Junio's work on Bundle v3 that was unfortunately >> > recently

Re: The design of refs backends, linked worktrees and submodules

On Thu, Jan 19, 2017 at 6:55 PM, Duy Nguyen wrote: > I've started working on fixing the "git gc" issue with multiple > worktrees, which brings me back to this. Just some thoughts. Comments > are really appreciated. > > In the current code, files backend has special cases for

Re: ``git clean -xdf'' and ``make clean''

On 02/07/2017 03:17 PM, Hongyi Zhao wrote: > Hi all, > > In order to delete all of the last build stuff, does the following two > methods equivalent or not? > > ``git clean -xdf'' and ``make clean'' No, it is not equivalent. * `make clean` removes any build-related files (assuming that the

Re: [PATCH v2 2/2] grep: use '/' delimiter for paths

On Fri, Jan 20, 2017 at 03:51:33PM -0800, Brandon Williams wrote: > On 01/20, Junio C Hamano wrote: > > Stefan Hajnoczi writes: > > > > > If the tree contains a sub-directory then git-grep(1) output contains a > > > colon character instead of a path separator: > > > > > >

Re: subtree merging fails

Have you tried using (without -s subtree) -X subtree=path/to/add/subtree/at? >From the man page: subtree[=] This option is a more advanced form of subtree strategy, where the strategy makes a guess on how two trees must be shifted to match with each other

Re: Request re git status

On Mon, Feb 6, 2017 at 6:45 PM, Phil Hord wrote: > On Mon, Feb 6, 2017 at 3:36 PM Ron Pero wrote: >> I almost got bit by git: I knew there were changes on the remote >> server, but git status said I was uptodate with the remote. >> > > Do you mean you

``git clean -xdf'' and ``make clean''

Hi all, In order to delete all of the last build stuff, does the following two methods equivalent or not? ``git clean -xdf'' and ``make clean'' Regards -- Hongsheng Zhao Institute of Semiconductors, Chinese Academy of Sciences GnuPG DSA: 0xD108493

[PATCH] rev-list-options.txt: update --all about detached HEAD

This is the document patch for f0298cf1c6 (revision walker: include a detached HEAD in --all - 2009-01-16) Signed-off-by: Nguyễn Thái Ngọc Duy --- Documentation/rev-list-options.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git

Assalamu`Alaikum.

Dear Sir/Madam. Assalamu`Alaikum. I am Dr mohammad ouattara, I have ($10.6 Million us dollars) to transfer into your account, I will send you more details about this deal and the procedures to follow when I receive a positive response from you, Have a great day, Dr mohammad ouattara.

Re: Git clonebundles

Hi Junio, On Mon, 6 Feb 2017, Junio C Hamano wrote: > Christian Couder writes: > > > There is also Junio's work on Bundle v3 that was unfortunately > > recently discarded. Look for "jc/bundle" in: > > > >

Re: [PATCH 2/2] t7800: replace "wc -l" with test_line_count

Hi David, On Tue, 7 Feb 2017, David Aguilar wrote: > Make t7800 easier to debug by capturing output into temporary files and > using test_line_count to make assertions on those files. > > Signed-off-by: David Aguilar Both patches look like an obvious improvement with no

[RFC] mailmap.blob overrides default .mailmap

Hi, I was reading into the mailmap handling today and I'm a bit puzzled by the overriding behavior. This is what the documentation says about precedence (emphasis mine): - mailmap.file The location of an augmenting mailmap file. The default mailmap, located in the root of

Re: Google Doc about the Contributors' Summit

Hi team, On Thu, 2 Feb 2017, Johannes Schindelin wrote: > I just started typing stuff up in a Google Doc, and made it editable to > everyone, feel free to help and add things: > > https://docs.google.com/document/d/1KDoSn4btbK5VJCVld32he29U0pUeFGhpFxyx9ZJDDB0/edit?usp=sharing I am terribly

Non-zero exit code without error

Hi, When we execute the following lines, the exit code is 1, but it is unclear what is the reason of this exit code. Do you have any idea? git clone --mirror --depth 50 --no-single-branch g...@github.hede.com:Casual/hodo-server.git Cloning into bare repository 'hodo-server.git'... remote:

Re: [PATCH] difftool: fix bug when printing usage

Hi Junio, On Mon, 6 Feb 2017, Junio C Hamano wrote: > Johannes Schindelin writes: > > > [... and he quoted someone ...] > > > >> + # create a ceiling directory to prevent Git from finding a repo > >> + mkdir -p not/repo && > >> + ceiling="$PWD/not" && > >> +

Re: [PATCH] worktree: fix option descriptions for `prune`

On Tue, Feb 7, 2017 at 1:59 AM, Junio C Hamano wrote: > Patrick Steinhardt writes: > >> struct option options[] = { >> OPT__DRY_RUN(_only, N_("do not remove, show only")), >> - OPT__VERBOSE(, N_("report pruned

Re: git-daemon shallow checkout fail

On Tue, Feb 7, 2017 at 7:56 AM, Bob Proulx wrote: > Bob Proulx wrote: >> 17:20:40.590177 pkt-line.c:46 packet:clone< >> 34e7202270c381f4e5734180dc19426ce69f2e1e HEAD\0multi_ack thin-pack side-band >> side-band-64k ofs-delta shallow no-progress include-tag

[PATCH 2/2] t7800: replace "wc -l" with test_line_count

Make t7800 easier to debug by capturing output into temporary files and using test_line_count to make assertions on those files. Signed-off-by: David Aguilar --- t/t7800-difftool.sh | 31 +++ 1 file changed, 19 insertions(+), 12 deletions(-) diff

[PATCH 1/2] t7800: simplify basic usage test

Use "test_line_count" instead of "wc -l", use "git -C" instead of a subshell, and use test_expect_code when calling difftool. Ease debugging by capturing output into temporary files. Suggested-by: Johannes Schindelin Signed-off-by: David Aguilar

Re: [PATCH v2 0/7] completion bash: add more options and commands

Am 06.02.2017 um 22:29 schrieb Junio C Hamano: cornelius.w...@tngtech.com writes: From: Cornelius Weig This is the re-roll of patch series <2017015724.19360-1-cornelius.w...@tngtech.com>. This patch series adds all long-options that are mentioned in the

subtree merging fails

Following the instructions here: https://git-scm.com/book/en/v1/Git-Tools-Subtree-Merging will lead to an error. In particular, if the subtree is merged and then updated, this command that is supposed to update the local subtree fails with a fatal: refusing to merge unrelated histories error. $