Re: submodule: allow submodule directory in gitignore

On 17.10.2015 19:46, Jiang Xin wrote: > 2015-10-12 14:30 GMT+08:00 Aleksey Komarov : >> Hi all! >> >> I'm sorry if the letter came twice. I have troubles with my post client. >> >> I want to organize my repository so its submodules would be located at the >> root >> of

problem with modification time of packfiles

git (2.6.1) sometimes updates the modification time of a packfile, even if it has not changed at all. On my system this triggers quite expensive an d unnecessary backup operations, which I would prefer to avoid. Is there a simple way to keep the mtime of packfiles fixed, once they are created?

Re: problem with modification time of packfiles

On Sun, Oct 18, 2015 at 10:37:55PM +0100, Andreas Amann wrote: > git (2.6.1) sometimes updates the modification time of a packfile, even if it > has not changed at all. > > On my system this triggers quite expensive an d unnecessary backup > operations, which I would prefer to avoid. Is there a

Re: [PATCH v2 00/10] port branch.c to use ref-filter's printing options

Karthik Nayak writes: > ... While doing so I realized I was moving a lot of code around > and this had me thinking it's perhaps easier to do the cleaning up > first as Junio suggested. > > Maybe then it'd be simpler to do implement this rather than move > code around now

[PATCH] worktree: usage: denote as optional with 'add'

Although 1eb07d8 (worktree: add: auto-vivify new branch when is omitted, 2015-07-06) updated the documentation when became optional, it neglected to update the in-code usage message. Fix this oversight. Reported-by: ch3co...@gmail.com Signed-off-by: Sidhant Sharma ---

Re: [PATCH] Add ls-files --eol-staged, --eol-worktree

On 18/10/15 21:00, Junio C Hamano wrote: Torsten Bögershausen writes: Make it possible to show the line endings of files. Files which are staged and/or files in the working tree: git ls-files --eol-staged git ls-files --eol-worktree Two unrelated (to the issues raised in

Re: git-credential-cache--daemon quits on SIGHUP, can we change it to ignore instead?

On Sun, Oct 18, 2015 at 1:58 PM, Junio C Hamano wrote: > I cannot speak for the person who was primarily responsible for > designing this behaviour, but I happen to agree with the current > behaviour in the situation where it was designed to be used. Upon > the first use in

Re: [PATCH] Add ls-files --eol-staged, --eol-worktree

Junio C Hamano writes: > If you say 1 and 2 are with LF, 4 and 6 are with CRLF, eveyrything > else is mixed, then you are losing the distinction between 1 and 2 > (and 4 and 6) that you made when the files were a single liner (with > or without the incomplete line ending). Is

Re: [PATCH] Add ls-files --eol-staged, --eol-worktree

Torsten Bögershausen writes: > Make it possible to show the line endings of files. > Files which are staged and/or files in the working tree: > > git ls-files --eol-staged > git ls-files --eol-worktree Two unrelated (to the issues raised in other review responses) issues in the

Re: [PATCH v2 00/10] port branch.c to use ref-filter's printing options

On Tue, Oct 13, 2015 at 12:37 AM, Matthieu Moy wrote: > Junio C Hamano writes: > >> If you design a new infrastructure to help refactoring early >> (i.e. before adding many copies of code that need to be cleaned up >> later), it would make the

Re: [PATCH] Add ls-files --eol-staged, --eol-worktree

From: "Torsten Bögershausen" Make it possible to show the line endings of files. Files which are staged and/or files in the working tree: git ls-files --eol-staged git ls-files --eol-worktree Both will show an output like this: emptyempty_file bin

Re: git tag --contains now takes a long time

On Sun, Oct 18, 2015 at 2:58 AM, Junio C Hamano wrote: > Karthik Nayak writes: > >> So I did poke around a little. I think I missed this out on the >> original commit (b7cc53e92c806b73e14b03f60c17b7c29e52b4a4). >> >> diff --git a/builtin/tag.c

[PATCH v2] tag.c: use the correct algorithm for the '--contains' option

In b7cc53e92c806b73e14b03f60c17b7c29e52b4a4 we port tag.c to use ref-filter APIs for filtering and printing refs. In ref-filter we have two implementations for filtering refs when the '--contains' option is used. Although they do the same thing, one is optimized for filtering branches and the

[PATCH] Fix missing brackets in worktree usage

H, I'm just starting out with development for Git. Found this super easy to fix, so here is a patch :) Sidhant Sharma (1): builtin/worktree.c: Fix usage message builtin/worktree.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- 2.6.2 >From 6b9bc79b698d4c9e1a0f74c37887caf2a05f9978

[PATCH] Fix worktree usage message

Mark optional in worktree command line usage to maintain consistency with man pages. Reported-by: ch3co...@gmail.com Signed-off-by: Sidhant Sharma --- It was reported here: http://marc.info/?l=git=144514145804787=2 builtin/worktree.c | 2 +- 1 file changed, 1

[PATCH] Fix worktree usage message

Mark as optional in worktree command line usage. Hi, just starting out with development for Git. Found this one super easy to fix, so made a patch :) --- builtin/worktree.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/builtin/worktree.c b/builtin/worktree.c index

Re: [Feature Request] git blame showing only revisions from git rev-list --first-parent

On Tue, Sep 15, 2015 at 06:05:39AM -0400, Jeff King wrote: > It seems like nobody is actually that interested in what "blame > --first-parent --reverse" does in the first place, though, and there's > no reason for its complexity to hold up vanilla --first-parent. So what > do you think of: ... >

Re: [PATCH] Fix worktree usage message

On Sun, Oct 18, 2015 at 04:32:24PM +0530, Sidhant Sharma wrote: > Mark as optional in worktree command line usage. Thank you for the patch. Can you also explain why you mark it as optional in the commit message? That way it's clear why this patch is needed. > > Hi, just starting out with

Re: git-credential-cache--daemon quits on SIGHUP, can we change it to ignore instead?

On Sat, Oct 10, 2015 at 12:45 PM, Noam Postavsky wrote: > I noticed that git-credential-cache--daemon quits on SIGHUP. This > seems like surprising behaviour for a daemon. Would it be acceptable > to change it to ignore SIGHUP? ping? -- To unsubscribe from this

Re: How to rebase when some commit hashes are in some commit messages

On Mon, Oct 12, 2015 at 9:59 PM, Francois-Xavier Le Bail wrote: > Hello, > > [I try some search engines without success, perhaps I have missed something]. > > For example, if I rebase the following commits, I would want that if > the commit hash 222... become

Re: How to rebase when some commit hashes are in some commit messages

On Thursday 15 October 2015 09:44:59 Francois-Xavier Le Bail wrote: > >> On Tue, 13 Oct 2015 10:50:40 +0200 > >> Francois-Xavier Le Bail wrote: > >>> >> For example, if I rebase the following commits, I would want that > >>> >> if the commit hash 222... become

Re: [PATCH v2 3/4] stripspace: Implement --count-lines option

Eric Sunshine writes: > Is there any application beyond git-rebase--interactive where a > --count-lines options is expected to be useful? It's not obvious from > the commit message that this change is necessarily a win for later > porting of git-rebase--interactive to C

Re: [PATCH] Add ls-files --eol-staged, --eol-worktree

Torsten Bögershausen writes: > Make it possible to show the line endings of files. > Files which are staged and/or files in the working tree: > > git ls-files --eol-staged > git ls-files --eol-worktree > > Both will show an output like this: > > emptyempty_file > bin

Re: git-credential-cache--daemon quits on SIGHUP, can we change it to ignore instead?

Noam Postavsky writes: > On Sat, Oct 10, 2015 at 12:45 PM, Noam Postavsky > wrote: >> I noticed that git-credential-cache--daemon quits on SIGHUP. This >> seems like surprising behaviour for a daemon. Would it be acceptable >> to

Re: [PATCH] Fix worktree usage message

On Sun, Oct 18, 2015 at 8:15 AM, Sidhant Sharma wrote: > Mark optional in worktree command line usage to maintain consistency > with man pages. Thanks for the patch. To clarify that it is the in-code usage string which is incorrect, rather than the man page, how about

Re: [Feature Request] git blame showing only revisions from git rev-list --first-parent

Max Kirillov writes: > I might be late for this discussion, but I seem to have > a case when blame --reverse --first-parent seems to work. I think during the discussion we already established that there are cases where the mode happens to do the right thing (the most trivial is