Re: pathspec: problems with too long command line

On 21.11.2018 14:37, Junio C Hamano wrote: Jeff King writes: On Wed, Nov 21, 2018 at 10:23:34AM +0100, Marc Strapetz wrote: From our GUI client we are invoking git operations on a possibly large set of files. ... command line length, especially on Windows [1] and OSX [2]. To workaround

pathspec: problems with too long command line

From our GUI client we are invoking git operations on a possibly large set of files. This may result in pathspecs which are exceeding the maximum command line length, especially on Windows [1] and OSX [2]. To workaround this problem we are currently splitting up such operations by invoking

Re: [PATCH v3] Documentation: declare "core.ignorecase" as internal variable

On 27.06.2018 21:11, Junio C Hamano wrote: Marc Strapetz writes: [1. text/plain] The current description of "core.ignoreCase" reads like an option which is intended to be changed by the user while it's actually expected to be set by Git on initialization only. Subsequently,

[PATCH v4] Documentation: declare "core.ignoreCase" as internal variable

: Git on a case-insensitive filesystem (APFS, HFS+, FAT32, exFAT, vFAT, NTFS, etc.) is not designed to be run with anything other than core.ignoreCase=true. [1] https://marc.info/?l=git=152998665813997=2 mid:cagyf7-gee8jrgpkme9rhkptheq6p1+ebpmmwatmh01uo3bf...@mail.gmail.com Signed-of

[PATCH v3] Documentation: declare "core.ignorecase" as internal variable

: Git on a case-insensitive filesystem (APFS, HFS+, FAT32, exFAT, vFAT, NTFS, etc.) is not designed to be run with anything other than core.ignoreCase=true. [1] https://marc.info/?l=git=152998665813997=2 mid:cagyf7-gee8jrgpkme9rhkptheq6p1+ebpmmwatmh01uo3bf...@mail.gmail.com Signed-of

[PATCH v2] Documentation: declare "core.ignorecase" as internal variable

`git clone` set when a repository is created purely so they don't have to probe the file system each time you run a `git` command. [1] https://marc.info/?l=git=152972992729761=2 Signed-off-by: Marc Strapetz --- Documentation/config.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletion

Re: Unexpected ignorecase=false behavior on Windows

On 22.06.2018 22:58, Bryan Turner wrote: On Fri, Jun 22, 2018 at 1:45 PM Marc Strapetz wrote: On 22.06.2018 19:36, Johannes Sixt wrote: Am 22.06.2018 um 14:04 schrieb Marc Strapetz: On Windows, when creating following repository: $ git init $ echo "1" > file.txt $ git add . $

[PATCH] Documentation: declare "core.ignorecase" as internal variable

The current description of "core.ignorecase" reads like an option which is intended to be changed by the user while it's actually expected to be set by Git only [1]. [1] https://marc.info/?l=git=152972992729761=2 Signed-off-by: Marc Strapetz --- Documentation/config.txt | 4 ++

Re: Unexpected ignorecase=false behavior on Windows

On 22.06.2018 19:36, Johannes Sixt wrote: Am 22.06.2018 um 14:04 schrieb Marc Strapetz: On Windows, when creating following repository: $ git init $ echo "1" > file.txt $ git add . $ git commit -m "initial import" $ ren file.txt File.txt $ git config core.ignorecase

Unexpected ignorecase=false behavior on Windows

On Windows, when creating following repository: $ git init $ echo "1" > file.txt $ git add . $ git commit -m "initial import" $ ren file.txt File.txt $ git config core.ignorecase false Status results are: $ git status --porcelain ?? File.txt As on Unix, I would expect to see: $ git status

Re: [PATCH v5 0/3] stash push -u -- fixes

On 20.03.2018 00:21, Thomas Gummerer wrote: Thanks again Marc for all the testing and Junio for fixing up my brown paper bag copy-pasto. This iteration addresses the breakage Marc noticed with the latest version of the patches, adds some more tests, and moves all the new tests to t3905 instead

Re: [PATCH v3 0/2] stash push -u -- fixes

On 16.03.2018 21:43, Thomas Gummerer wrote: Thanks Marc for catching the regression I almost introduced and Junio for the review of the second patch. Here's a re-roll that should fix the issues of v2. Thanks, existing issues are fixed, but cleanup of the stashed files seems to not work

Re: [PATCH v2 1/2] stash push: avoid printing errors

', as there are no changes that need to be applied. Fix this by making sure to only call this command chain if there are still files that match after the call to 'git clean'. Reported-by: Marc Strapetz <marc.strap...@syntevo.com> Signed-off-by: Thomas Gummerer <t.gumme...@gmail.com> --- Either

Re: git stash push -u always warns "pathspec '...' did not match any files"

On 09.03.2018 23:18, Junio C Hamano wrote: Marc Strapetz <marc.strap...@syntevo.com> writes: Thanks, I can confirm that the misleading warning message is fixed. What I've noticed now is that when using -u option, Git won't warn if the pathspec is actually not matching a file. Also, an

Re: git stash push -u always warns "pathspec '...' did not match any files"

On 03.03.2018 16:46, Thomas Gummerer wrote: On 03/03, Marc Strapetz wrote: Reproducible in a test repository with following steps: $ touch untracked $ git stash push -u -- untracked Saved working directory and index state WIP on master: 0096475 init fatal: pathspec 'untracked' did not match

git stash push -u always warns "pathspec '...' did not match any files"

Reproducible in a test repository with following steps: $ touch untracked $ git stash push -u -- untracked Saved working directory and index state WIP on master: 0096475 init fatal: pathspec 'untracked' did not match any files error: unrecognized input The file is stashed correctly, though.

Re: Git for Windows: mingw.c's strange usage of creation time as ctime?

Hello Jonathan, On 04.10.2017 04:23, Jonathan Nieder wrote: +git-for-windows Hi Marc, Marc Strapetz wrote: compat/mingw.c assigns the Windows file creation time [1] to Git's ctime fields at line 591 and at line 705: buf->st_ctime = filetime_to_time_t(&(fdata.ftCreat

Git for Windows: mingw.c's strange usage of creation time as ctime?

compat/mingw.c assigns the Windows file creation time [1] to Git's ctime fields at line 591 and at line 705: buf->st_ctime = filetime_to_time_t(&(fdata.ftCreationTime)); ftCreationTime > ftLastWriteTime is actually possible after copying a file, so it makes sense to include this timestamp

Re: git stash --include-untracked possible destructive behavior

On 09.06.2017 00:39, Joel Teichroeb wrote: Looks like that series was merged last week, fixing this issue. Marc, the fix will probably be in git 2.14. Thanks, I can confirm that with current master "git clean" as well as "git stash" are working properly now (tested on Linux). I'm looking

git stash --include-untracked possible destructive behavior

One of our users has just discovered a destructive behavior of git stash --include-untracked: ignored files within non-ignored directories will not be stashed as untracked files (expected), but will still be removed from the working tree. The problem is reproducible by following command

git remote rename problem with trailing \\ for remote.url config entries (on Windows)

One of our users has just reported that: $ git remote rename origin origin2 will turn following remote entry: [remote "origin"] url = c:\\repo\\ fetch = +refs/heads/*:refs/remotes/origin/* into following entry for which the url is skipped: [remote "origin2"] [remote

Re: [RFC] stash: support filename argument

On 16.01.2017 01:41, Stephan Beyer wrote: Hi, On 01/16/2017 01:21 AM, Junio C Hamano wrote: I haven't spent enough time to think if it even makes sense to "stash" partially, leaving the working tree still dirty. My initial reaction was "then stashing away the dirty WIP state to get a spiffy

[PATCH 1/2] stash: fix USAGE text

Add missing usage description for stash subcommands 'create' and 'store'. Signed-off-by: Marc Strapetz <marc.strap...@syntevo.com> --- git-stash.sh | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/git-stash.sh b/git-stash.sh index 10c284d1a..c6b9db694 100755 ---

[PATCH 2/2] stash: --[no-]include-untracked option for create

Expose internal option to include untracked files for the stash 'create' subcommand. Signed-off-by: Marc Strapetz <marc.strap...@syntevo.com> --- Documentation/git-stash.txt | 2 +- git-stash.sh| 14 -- 2 files changed, 13 insertions(+), 3 deletions(-) diff

[ANNOUNCE] DeepGit - free cross-platform Git blame GUI with code move detection

We have just released the first version of DeepGit, a free cross-platform tool to investigate the history of source code. It's based on blame information and comes with a 'fuzzy' line/block move detection. http://www.syntevo.com/deepgit/ -Marc

Re: topological index field for commit objects

On 01.07.2016 05:17, Jeff King wrote: On Thu, Jun 30, 2016 at 11:12:52AM -0700, Linus Torvalds wrote: I do think that it's ok to cache generation numbers somewhere if there is an algorithm that can make use of them, but every time this comes up, it's just not been important enough to make a

Re: topological index field for commit objects

On 29.06.2016 22:39, Junio C Hamano wrote: Stefan Beller <sbel...@google.com> writes: On Wed, Jun 29, 2016 at 11:59 AM, Junio C Hamano <gits...@pobox.com> wrote: On Wed, Jun 29, 2016 at 11:31 AM, Marc Strapetz <marc.strap...@syntevo.com> wrote: This is no RFE but rather

topological index field for commit objects

This is no RFE but rather recurring thoughts whenever I'm working with commit graphs: a topological index attribute for commit objects would be incredible useful. By "topological index" I mean a simple integer for which following condition holds true: if commit C is part of the history of

Re: git submodule should honor "-c credential.helper" command line argument

On 07.02.2016 05:41, Jacob Keller wrote: On Wed, Feb 3, 2016 at 3:44 PM, Jacob Keller wrote: Ok so I am not sure we even really need to use "-c" option in git-clone considering that we can just use the same flow we do for setting core.worktree values. I'll propose a

Re: git submodule should honor "-c credential.helper" command line argument

On 03.02.2016 08:35, Jacob Keller wrote: On Tue, Feb 2, 2016 at 8:25 PM, Jeff King wrote: I think the problem is that when git "switches" to working in the submodule repository, it clears the environment, which includes any "-c" command switches. This makes sense for some

git submodule should honor "-c credential.helper" command line argument

git -c credential.helper=helper submodule update --init submodule does not invoke "helper", but falls back to the default strategies. When configuring in ~/.gitconfig: [credential] helper=helper git submodule update --init submodule works fine. This behavior is somewhat unexpected -- is

Re: branch --set-upstream-to unexpectedly fails with "starting point ... is no branch"

On 24.11.2015 17:58, Carlos Martín Nieto wrote: On 23 Nov 2015, at 19:59, Marc Strapetz <marc.strap...@syntevo.com> wrote: On 23.11.2015 18:04, Carlos Martín Nieto wrote: Hello Mark, On 23 Nov 2015, at 12:04, Marc Strapetz <marc.strap...@syntevo.com> wrote: There is a str

branch --set-upstream-to unexpectedly fails with "starting point ... is no branch"

There is a strange "branch --set-upstream-to" failure for "clones" which haven't been created using "git clone" but constructed using "git init", "git remote add" and "git fetch". Following script first creates a "main" repository and then constructs the clone. Finally, in the clone branches

Re: branch --set-upstream-to unexpectedly fails with "starting point ... is no branch"

On 23.11.2015 18:04, Carlos Martín Nieto wrote: Hello Mark, On 23 Nov 2015, at 12:04, Marc Strapetz <marc.strap...@syntevo.com> wrote: There is a strange "branch --set-upstream-to" failure for "clones" which haven't been created using "git clone" but const

Unexpected difference between core.autocrlf=true and .gitattributes text=auto

I have a file.txt which is stored with CRLF in the repository (I'm on Windows, but that should not matter). autocrlf has been set: $ git config core.autocrlf true Git considers the working tree clean: $ touch file.txt $ git status On branch master nothing to commit, working directory clean

Re: Git counterpart to SVN bugtraq properties?

On 04.10.2013 11:15, Thomas Koch wrote: On Wednesday, July 17, 2013 03:03:14 PM Marc Strapetz wrote: I'm looking for a specification or guidelines on how a Git client should integrate with bug tracking systems. For SVN, one can use bugtraq-properties [1] to specify e.g. the issue tracker URL

Re: Git counterpart to SVN bugtraq properties?

On 30.09.2013 20:55, Jonathan Nieder wrote: Hi, Marc Strapetz wrote: On Wed, Jul 17, 2013 at 03:03:14PM +0200, Marc Strapetz wrote: I'm looking for a specification or guidelines on how a Git client should integrate with bug tracking systems. [...] Finally, I've created a minimal spec

Re: Git counterpart to SVN bugtraq properties?

2013 20:02, Jonathan Nieder jrnie...@gmail.com mailto:jrnie...@gmail.com wrote: Hi, Marc Strapetz wrote: On Wed, Jul 17, 2013 at 03:03:14PM +0200, Marc Strapetz wrote: I'm looking for a specification or guidelines on how a Git client should integrate with bug

Re: Git counterpart to SVN bugtraq properties?

On 17.07.2013 15:33, John Keeping wrote: On Wed, Jul 17, 2013 at 03:03:14PM +0200, Marc Strapetz wrote: I'm looking for a specification or guidelines on how a Git client should integrate with bug tracking systems. For SVN, one can use bugtraq-properties [1] to specify e.g. the issue tracker

Re: Git counterpart to SVN bugtraq properties?

On 17.07.2013 15:33, John Keeping wrote: On Wed, Jul 17, 2013 at 03:03:14PM +0200, Marc Strapetz wrote: I'm looking for a specification or guidelines on how a Git client should integrate with bug tracking systems. For SVN, one can use bugtraq-properties [1] to specify e.g. the issue tracker

Git counterpart to SVN bugtraq properties?

I'm looking for a specification or guidelines on how a Git client should integrate with bug tracking systems. For SVN, one can use bugtraq-properties [1] to specify e.g. the issue tracker URL or how to parse the bug ID from a commit message. AFAIU, there is nothing comparable for Git [2]? If

git commit --amend --only -- nevertheless commits staged changes

When using git commit --amend --only --message message --, I'd expect to have just the commit message of my last commit changed, according to the man page: --only Make a commit only from the paths specified on the command line, disregarding any contents that have been staged so far. [...] If this