Re: [PATCH 1/2] t0051: test GIT_TRACE to a windows named pipe

On 9/7/2018 8:19 PM, Jeff Hostetler via GitGitGadget wrote: +test_expect_success MINGW 'o_append write to named pipe' ' Shouldn't this be "test_expect_failure" here, and then be changed to "test_expect_success" by your second patch? -- Sebastian Schuberth

Re: [PATCH 0/9] Offer to run CI/PR builds in Visual Studio Team Services

that log. I'm sorry if this has been discussed before, but as this recap doesn't mention it: Has AppVeyor been considered as an option? It seems to be the defacto standard for Windows CI for projects on GitHub. -- Sebastian Schuberth

Re: [PATCH 2/9] ci/lib.sh: encapsulate Travis-specific things

travis-ci.com/user/environment-variables/ -- Sebastian Schuberth

Re: Colorize matches for git log --grep=pattern?

hacky. Thanks anyway. I was also considering something like this, but likewise found it to be too hacky. -- Sebastian Schuberth

Colorize matches for git log --grep=pattern?

Hi, is there a way to colorize / highlight the pattern matched by git log -E -i --grep=pattern in the console output? Regards, Sebastian

[PATCH] docs: fix formatting of rev-parse's --show-superproject-working-tree

Signed-off-by: Sebastian Schuberth <sschube...@gmail.com> --- Documentation/git-rev-parse.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/git-rev-parse.txt b/Documentation/git-rev-parse.txt index 0917b8207b9d6..95326b85ff68e 100644 --- a/Documentation/g

Re: Commit dropped when swapping commits with rebase -i -p

ke missing commits, > wrong merges, merges combining two unrelated histories and > similar things. "can produce" is much too soft, IMO. Reordering commits goes wrong, period. Like wise "unexpected and useless results" is inappropriate. The results are wrong in case

Re: Commit dropped when swapping commits with rebase -i -p

that would be welcome. As a first step, I indeed believe the wording must the stronger / clearer. How about this: >From f69854ce7b9359603581317d152421ff6d89f345 Mon Sep 17 00:00:00 2001 From: Sebastian Schuberth <sschube...@gmail.com> Date: Mon, 11 Sep 2017 10:41:27 +0200 Subject: [PATCH

Re: Commit dropped when swapping commits with rebase -i -p

lve any merge commits). If these options are fundamentally incompatible as you say, would you agree that it makes sense to disallow their usage together (instead of just documenting that you should know what you're doing)? -- Sebastian Schuberth

Re: Commit dropped when swapping commits with rebase -i -p

s, the warning must be harsher in my opinion. Maybe we should even abort rebase -i-p if reordering of commits is detected. -- Sebastian Schuberth

Commit dropped when swapping commits with rebase -i -p

Hi, I believe stumbled upon a nasty bug in Git: It looks like a commits gets dropped during interactive rebase when asking to preserve merges. Steps: $ git clone -b git-bug --single-branch https://github.com/heremaps/scancode-toolkit.git $ git rebase -i -p HEAD~2 # In the editor, swap the

Re: Best way to check whether working tree matches a commit's tree

cking if the tree exactly matches. In fact, I was considering to use "git diff HEAD $that_commit" as I don't really care whether the SHA1s are equal, but just about the file contents / tree. -- Sebastian Schuberth

Best way to check whether working tree matches a commit's tree

nored --porcelain" - check that the output of "git rev-parse HEAD" matches the given commit While this works, it feels sub-optimal. Is there a better / smarter way? -- Sebastian Schuberth

Re: [BUG] fast-export --anonymize does not maintain fixup! commits

Teach it to store the mapping of anonymized messages, using > anonymize_mem(). > > 2. Parse "fixup! " and just anonymize_mem() the second half. I > think technically this wouldn't handle a fixup-of-fixup, but I > don't think rebase handles recursive ones anyway. Thanks. I'll give it a try. -- Sebastian Schuberth

Re: Possible bug in includeIf / conditional includes on non git initialised directories

an directory which hasn’t been `git > init`ed I get the user.email configured globally. I don't think that's a bug surprise: The condition in the conditional include is "gitdir:". Before running "git init", it simply *is* no gitdir. -- Sebastian Schuberth

[BUG] fast-export --anonymize does not maintain fixup! commits

Unfortunately, "fast-export --anonymize" does not maintain these (or any other command prefixes in commit messages). Given that the --anonymize option is explicitly designed to help reproducing bugs, I consider this to be a bug in the --anonymize option itself. -- Sebastian Schuberth

Re: Possible bug in includeIf / conditional includes

figuration: ~/.gitconfig [includeIf "gitdir:~/Work/git-repos/oss/"] path = .oss-gitconfig My guess is, because includeIf might contain other conditionals than "gitdir", the generic convention is to always use an absolute path for "path". -- Sebastian Schuberth

Re: [PATCH] fetch-pack: always allow fetching of literal SHA1s

it's really a waste of network resources to fetch all of the history. -- Sebastian Schuberth

Re: git-clone --config order & fetching extra refs during initial clone

On 5/3/2017 22:22, Jeff King wrote: >> My patch deals with 'remote..refspec', i.e. 'remote->fetch'. >> Apparently some extra care is necessary for 'remote..tagOpt' and >> 'remote->fetch_tags', too. Perhaps there are more, I haven't checked >> again, and maybe we'll add similar config variables

Cloning a custom refspec does not work as expected

dows.2. [1] https://git-scm.com/docs/git-clone#git-clone---configltkeygtltvaluegt -- Sebastian Schuberth

Re: [PATCH v2] git-gui--askpass: generalize the wording

+ Pat On 2017-04-27 08:38, Sebastian Schuberth wrote: git-gui--askpass is not only used for SSH authentication, but also for HTTPS. In that context it is confusing to only rfer to "OpenSSH", also because another SSH client like PuTTY might be in use. So generalize wording and also

[PATCH v2] git-gui--askpass: generalize the wording

n. Signed-off-by: Sebastian Schuberth <sschube...@gmail.com> --- git-gui/git-gui--askpass | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/git-gui/git-gui--askpass b/git-gui/git-gui--askpass index 4277f30..4e3f00d 100755 --- a/git-gui/git-gui--askpass +++ b/git-gui/

[PATCH] gitmodules: clarify the ignore option values

Add more structure and describe each possible option in a self-contained way, not referring to any of the previously described options. Signed-off-by: Sebastian Schuberth <sschube...@gmail.com> --- Documentation/gitmodules.txt | 31 --- 1 file changed, 20 inse

[PATCH] gitmodules: clarify what history depth a shallow clone has

Signed-off-by: Sebastian Schuberth <sschube...@gmail.com> --- Documentation/gitmodules.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/gitmodules.txt b/Documentation/gitmodules.txt index 8f7c50f..6f39f24 100644 --- a/Documentation/gitmodules.txt

Re: Fwd: Failed shallow submodule clone for fixed SHA1 falls back to checking out HEAD

are more interested in "less data" rather than "correct data" because otherwise you would not have asked for shallow. I do believe this is an awkward choice. What does it help to get less data if it's the wrong data? -- Sebastian Schuberth

Failed shallow submodule clone for fixed SHA1 falls back to checking out HEAD

Hi, this is using "git version 2.12.2.windows.2" on Windows / "git version 2.12.2-639-g584f897" on Linux. I have configured my superproject with .gitmodules saying ---8<--- [submodule "src/funTest/resources/projects/external/jgnash"] path = src/funTest/resources/projects/external/jgnash

Re: [PATCH] submodule: remove a superfluous second check for the "new" variable

argv_array_pushl(, "update-ref", "HEAD", >> new, NULL); > > EMPTY_TREE_SHA1_HEX != NULL? > > Can you clarify the intent in the commit message? Sure. A few lines up (3 lines out of the diff) we have "if (new) {" [1], thus there's no need to check "new != NULL" here again. [1] https://github.com/git/git/pull/345/files#diff-471db3ea6697763218bb8335a95ece57R1392 -- Sebastian Schuberth

Re: Feature request: --format=json

/libgit2/libgit2 [2] https://github.com/eclipse/jgit -- Sebastian Schuberth

[PATCH] submodule: remove a superfluous second check for the "new" variable

Signed-off-by: Sebastian Schuberth <sschube...@gmail.com> --- submodule.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/submodule.c b/submodule.c index c52d663..68623bd 100644 --- a/submodule.c +++ b/submodule.c @@ -1396,8 +1396,7 @@ int submodule_move_head(cons

[PATCH] sha1_file: remove an used fd variable

Signed-off-by: Sebastian Schuberth <sschube...@gmail.com> --- sha1_file.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/sha1_file.c b/sha1_file.c index 7106389..9ecf71f 100644 --- a/sha1_file.c +++ b/sha1_file.c @@ -3970,7 +3970,6 @@ int read_loose_object(const char

Re: [PATCH v1] travis-ci: add static analysis build job to run coccicheck

scan service for OSS projects: https://scan.coverity.com/projects/git?tab=overview Maybe it makes sense to at least link to this page, too? -- Sebastian Schuberth

Re: [PATCH v2] travis-ci: build and test Git on Windows

MSYS2 that's already installed in AppVeyor nodes [1]. [1] https://www.appveyor.com/docs/build-environment/#mingw-msys-cygwin -- Sebastian Schuberth

Re: [PATCH 1/3] t7504: document regression: reword no longer calls commit-msg

for my addressing his problem. I fail to see how this is "my" problem just because I happened to notice it first. While I'm grateful that you've addressed it timely, I believe this is a naturalness since you've introduced the regression. -- Sebastian Schuberth

Re: [PATCH 1/3] t7504: document regression: reword no longer calls commit-msg

On Wed, Mar 22, 2017 at 4:01 PM, Johannes Schindelin <johannes.schinde...@gmx.de> wrote: > Noticed by Sebastian Schuberth. Thanks for working on the fix. > +# set up fake editor to replace `pick` by `reword` > +cat > reword-editor <<'EOF' > +#!/bin/sh > +mv &q

Re: Regression: Reword during rebase -i does not seem to trigger commit-msg hook anymore

On 3/20/2017 18:43, Stefan Beller wrote: With this version, when I do a "reword" during an inteactive rebase session, the commit-msg hook doe snot seem to be triggered anymore. This was particularly useful to let Gerrit's commit-msg hook add missing ChangeId footers. I can work-aorund the

Regression: Reword during rebase -i does not seem to trigger commit-msg hook anymore

Hi, I'm using $ git --version git version 2.12.0.windows.1 With this version, when I do a "reword" during an inteactive rebase session, the commit-msg hook doe snot seem to be triggered anymore. This was particularly useful to let Gerrit's commit-msg hook add missing ChangeId footers. I

Re: diff.ignoreSubmoudles config setting broken?

ignore = untracked in .gitmodules, which explains why globally setting "diff.ignoreSubmodules" to "all" had no effect. -- Sebastian Schuberth

Re: diff.ignoreSubmoudles config setting broken?

--ignore-submodules=all > > Hrm. Isn't "all" the default? That's what git-diff(1) says (but I've > never used the feature myself). > > That would imply to me that there's another config option set somewhere > (perhaps in the repo-level config). What does: > > git config --show-origin --get-all diff.ignoresubmodules > > say? It says: file:/home/seschube/.gitconfig all -- Sebastian Schuberth

Re: diff.ignoreSubmoudles config setting broken?

looks right, so my guess is probably the wrong direction. > Peeking at the code, it looks like there may be some per-submodule > magic, but I don't know how it all works. So I'll stop looking and wait > for somebody more clueful to respond. + Jens -- Sebastian Schuberth

diff.ignoreSubmoudles config setting broken?

Hi, with $ git --version git version 2.12.0.windows.1 I'm getting $ git config --global diff.ignoreSubmodules all $ git diff diff --git a/scanners/scancode-toolkit b/scanners/scancode-toolkit index 65e5c9c..6b021a8 16 --- a/scanners/scancode-toolkit +++ b/scanners/scancode-toolkit @@ -1 +1

Re: [RESEND PATCH] git-gui--askpass: generalize the window title

On Tue, Mar 7, 2017 at 7:30 PM, Stefan Beller <sbel...@google.com> wrote: > Although the following are included in git.git repository, they have their > own authoritative repository and maintainers: Thanks. I continuously get confused by this fact. -- Sebastian Schuberth

[RESEND PATCH] git-gui--askpass: generalize the window title

git-gui--askpass is not only used for SSH authentication, but also for HTTPS. In that context it is confusing to have a window title of "OpenSSH". So generalize the title so that it also says which parent process, i.e. Git, requires authentication. Signed-off-by: Sebastian Schubert

Re: [PATCH] Do not require Python for the git-remote-{bzr,hg} placeholder scripts

On Fri, Mar 3, 2017 at 8:10 PM, Junio C Hamano <gits...@pobox.com> wrote: >> Just a niggle: This change moves the warning message from stderr to stdout. > > Right. Here is what I'll queue. Indeed, thanks for the note, and also Junio for fixing while queuing. -- Sebastian Schuberth

[PATCH] Do not require Python for the git-remote-{bzr,hg} placeholder scripts

It does not make sense for these placeholder scripts to depend on Python just because the real scripts do. At the example of Git for Windows, we would not even be able to see those warnings as it does not ship with Python. So just use plain shell scripts instead. Signed-off-by: Sebastian

Re: [PATCH v4 0/3] git-p4: fix Git LFS pointer parsing

On Thu, Apr 28, 2016 at 8:26 AM, wrote: > diff to v3: > * fix missing assignment of pointerFile variable > ($gmane/292454, thanks Sebastian for making me aware) > * fix s/brake/break/ in commit message > ($gmane/292451, thanks Eric) The series looks good to me

Re: [PATCH v3 3/3] git-p4: fix Git LFS pointer parsing

terFile variable in the version I sent around :-( > > This is how it should be: > > pointerFile = re.sub(r'Git LFS pointer for.*\n\n', '', pointerFile) Right. Good you've catched that! -- Sebastian Schuberth -- 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

Re: [PATCH v3 3/3] git-p4: fix Git LFS pointer parsing

On Sun, Apr 24, 2016 at 8:58 PM, wrote: > --- a/git-p4.py > +++ b/git-p4.py > @@ -1064,8 +1064,15 @@ class GitLFS(LargeFileSystem): > if pointerProcess.wait(): > os.remove(contentFile) > die('git-lfs pointer command failed. Did you

Re: [PATCH v2 2/2] git-p4: fix Git LFS pointer parsing

On Fri, Apr 22, 2016 at 9:53 AM, Lars Schneider <larsxschnei...@gmail.com> wrote: > What would be the best way forward? A v3 with a better commit message > mentioning the array -> string change? I'd vote for that, yes. Also v3 could then properly incorporate my regexp. -- Seba

Re: [PATCH v1 2/2] git-p4: fix Git LFS pointer parsing

output targeted at script goes to stdout, and output targeted at humans goes to stderr. [1] https://github.com/github/git-lfs/pull/1105 -- Sebastian Schuberth -- 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

Re: [PATCH v2 2/2] git-p4: fix Git LFS pointer parsing

t; is a separate word. But then again, I wonder why there's so much split() logic involved in extracting the oid. Couldn't we replace all of that with a regexp like oid = re.search(r"^oid \w+:(\w+)", pointerFile, re.MULTILINE).group(1) -- Sebastian Schuberth -- To unsubscribe from this list

Re: [PATCH v1 2/2] git-p4: fix Git LFS pointer parsing

nt on the client code impossible. If clients rely on output targeted at human consumption it's not surprising that these clients need to be adjusted from time to time. What's troubling is not the change to git-lfs, but the very un-generic way git-p4 is implemented. -- Sebastian Schuberth --

[PATCH] doc: Clarify which objects notes can be attached to

Explicitly name the supported object types, and ensure patches cannot be misinterpreted as non-objects that can have notes attached. Signed-off-by: Sebastian Schuberth <sschube...@gmail.com> --- Documentation/git-notes.txt | 9 + 1 file changed, 5 insertions(+), 4 deletions(-)

Re: [PATCH] doc: clarify that notes can be attached to any type of stored object

quot;attach" after all. Also, in the description it says "Adds, removes, or reads notes attached to objects", so it includes "[...] removes [...] notes attached to objects", and if you read it like this the word "attach" is not specific to the "add" subcommand. So I left this as-is in my patch. -- Sebastian Schuberth -- 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

Re: [PATCH] doc: clarify that notes can be attached to any type of stored object

On Fri, Apr 1, 2016 at 5:31 PM, Junio C Hamano <gits...@pobox.com> wrote: > Sebastian Schuberth <sschube...@gmail.com> writes: > >> Signed-off-by: Sebastian Schuberth <sschube...@gmail.com> >> --- >> Documentation/git-notes.txt | 5 +++-- >&g

Re: What is an efficient way to get all blobs / trees that have notes attached?

ore than one path (copies of files in the repo), I do not see another way of getting that information other than iterating over all blobs and checking what path(s) they belong to. -- Sebastian Schuberth -- 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

What is an efficient way to get all blobs / trees that have notes attached?

Hi, I'm curious whether there's a more efficient way to get a list of blobs / trees (and their names) that have notes attached than doing this: 1) Get all notes refs I'm interested in (git-for-each-ref). 2) For each notes ref, get the list of notes (git-notes list) and store them in a hash

[PATCH] doc: clarify that notes can be attached to any type of stored object

Signed-off-by: Sebastian Schuberth <sschube...@gmail.com> --- Documentation/git-notes.txt | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/Documentation/git-notes.txt b/Documentation/git-notes.txt index 8de3499..5375d98 100644 --- a/Documentation/git-notes.txt

Re: Trouble with cat-file on tags

On 4/1/2016 11:32, Sebastian Schuberth wrote: However, I still get information about the commit oject iintsead of the tag object. Is this expected? Solved this one, too: Yes it is. I was misreading the docs: "If is specified, the raw (though uncompressed) contents of the will be ret

Re: Trouble with cat-file on tags

On 4/1/2016 11:26, Sebastian Schuberth wrote: ---8<--- $ git tag test-tag $ git tag -l test-tag v0.0.3 v0.0.4 v0.1.0 v0.1.1 v0.1.2 $ git cat-file tag refs/tags/test-tag fatal: git cat-file refs/tags/test-tag: bad file ---8<--- Alright, I just found out why that is: Lighweigh

Trouble with cat-file on tags

Hi, I was trying to use cat-file to get the hash of a tag object (not the hash of the commit object the tag points to), and I'm running into some issues. At the example of a cloned gerry [1] repository: ---8<--- $ git tag test-tag $ git tag -l test-tag v0.0.3 v0.0.4 v0.1.0 v0.1.1 v0.1.2 $

Re: [PATCH 2/2 V3] MSVC: Use shipped headers instead of fallback definitions

On 3/30/2016 13:37, Sven Strickroth wrote: VS2010 comes with stdint.h [1] VS2013 comes with inttypes.h [2] [1] https://stackoverflow.com/a/2628014/3906760 [2] https://blogs.msdn.microsoft.com/vcblog/2013/07/19/c99-library-support-in-visual-studio-2013/ Signed-off-by: Sven Strickroth

Re: [PATCH 2/2 V2] MSVC: VS2013 comes with inttypes.h

On 3/29/2016 19:23, Sven Strickroth wrote: > --- a/compat/mingw.h > +++ b/compat/mingw.h > @@ -415,7 +415,7 @@ int mingw_offset_1st_component(const char *path); > extern void build_libgit_environment(void); > extern const char *program_data_config(void); > #define git_program_data_config

Re: [PATCH 1/2] MSVC: vsnprintf in Visual Studio 2015 doesn't need SNPRINTF_SIZE_CORR any more

followed Visual C's lead. > > Of course, evidence speaks louder than assumptions. > > Therefore I would prefer to keep the current version, at least until we > encounter a case where it is incorrect. Fine with me. It's probably better not to change the logic as we wouldn't know wheth

Re: [PATCH 1/2] MSVC: vsnprintf in Visual Studio 2015 doesn't need SNPRINTF_SIZE_CORR any more

, shouldn't this better say #if defined(WIN32) && (defined(__GNUC__) && __GNUC__ < 4) || (defined(_MSC_VER) && _MSC_VER < 1900)) #define SNPRINTF_SIZE_CORR 1 #else #define SNPRINTF_SIZE_CORR 0 -- Sebastian Schuberth -- To unsubscribe from this list: sen

Re: [PATCH 1/2] MSVC: vsnprintf in Visual Studio 2015 doesn't need SNPRINTF_SIZE_CORR any more

he UCRT in Visual Studio 2015 and Windows 10, vsnprintf is no longer identical to _vsnprintf. The vsnprintf function complies with the C99 standard; _vnsprintf is retained for backward compatibility" statement? [1] https://msdn.microsoft.com/en-us/library/1kt27hek.aspx -- Sebastian Schub

Re: [PATCH] (exit 1) is silly

On 3/22/2016 17:16, Junio C Hamano wrote: IMO, this is such a minor thing that once it _is_ in the tree, it's not really worth the patch noise to go and fix it up. IMO, instead of writing this you could have just accepted the patch, reducing the patch noise ;-) Regards, Sebastian -- To

Re: [RFC_PATCHv4 4/7] submodule init: redirect stdout to stderr

ndication. Thanks for the clarification. -- Sebastian Schuberth -- 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

Re: [RFC_PATCHv4 4/7] submodule init: redirect stdout to stderr

you do here. -- Sebastian Schuberth -- 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

Re: [ANNOUNCE] Git v2.8.0-rc0

On 2/27/2016 0:41, Junio C Hamano wrote: * Some calls to strcpy(3) triggers a false warning from static analysers that are less intelligent than humans, and reducing the number of these false hits helps us notice real issues. A few calls to strcpy(3) in test-path-utils that are

Re: [PATCH] git-completion.bash: always swallow error output of for-each-ref

he follow-up, I was about to ask for a status update on this. As my patch it ready now, and we don't know how long we'd have to wait for the other solution, I'd vote for applying my patch. -- Sebastian Schuberth -- To unsubscribe from this list: send the line "unsubscribe git" in the bo

Re: [PATCH v3 0/3] config: add '--sources' option to print the source of a config value

now that I am late to the party here, but why not make the option > `--verbose` or `-v`? `git config` doesn't have that now, and this > seems like a logical thing to include as verbose data. I would `--verbose` would be fine with me. -- Sebastian Schuberth -- To unsubscribe from this li

Re: [PATCH] git-gui--askpass: generalize the window title

On 01.02.2016 13:11, Sebastian Schuberth wrote: git-gui--askpass is not only used for SSH authentication, but also for HTTPS. In that context it is confusing to have a window title of "OpenSSH". So generalize the title so that it also says which parent process, i.e. Git, requires auth

Re: [PATCH] git-completion.bash: always swallow error output of for-each-ref

On 04.02.2016 11:34, Sebastian Schuberth wrote: This avoids output like warning: ignoring broken ref refs/remotes/origin/HEAD while completing branch names. Signed-off-by: Sebastian Schuberth <sschube...@gmail.com> The discussion got a bit off the point with the "short&qu

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

y* prefer --show-origin, since I don't think > there will be any confusion. However, I think --source may be OK too > (for some reason it sounds better than the plural). Another idea > may be --show-source. ;-) > > I agree that using --source sounds better than --sources, as the l

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

sonal preference. On the other hand, I find discussions like these often prematurely waved aside as bikeshedding, just because e.g. Perl can parse the one as good as the other. But it's not about Perl, it's about humans. IMO Git has historically made many mistakes by not caring enough about consis

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

s that deal with remotes have "remote" and not "origin" in their name, so I think the risk of confusion is rather low. But I'd be fine with "--show-config-origin", too. Although it's verbose, it's probably not used very often, so personally I could live with typing t

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

On 2/5/2016 14:58, Jeff King wrote: Yeah, I agree it's unlikely. And the output is already ambiguous, as the first field could be a blob (though I guess the caller knows if they passed "--blob" or not). If we really wanted an unambiguous output, we could have something like "file:...",

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

On 2/5/2016 9:42, larsxschnei...@gmail.com wrote: Teach 'git config' the '--sources' option to print the source configuration file for every printed value. Yay, not being able to see where a config setting originates from has bothered me in the past, too. So thanks for working on this.

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

On 2/5/2016 12:20, Jeff King wrote: Hmm. I had originally envisioned this only being used with "--list", but I guess it makes sense to say "--sources --get" to show where the value for a particular option is coming from. Being able to use "--sources --get" is a feature that I'd definitely

[PATCH] git-completion.bash: always swallow error output of for-each-ref

This avoids output like warning: ignoring broken ref refs/remotes/origin/HEAD while completing branch names. Signed-off-by: Sebastian Schuberth <sschube...@gmail.com> --- contrib/completion/git-completion.bash | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff

[PATCH] git-gui--askpass: generalize the window title

From: Sebastian Schuberth <sschube...@gmail.com> git-gui--askpass is not only used for SSH authentication, but also for HTTPS. In that context it is confusing to have a window title of "OpenSSH". So generalize the title so that it also says which parent process, i.e. Git, require

Re: [PATCH 3/5] submodule-config: keep labels around

On Sat, Jan 23, 2016 at 1:31 AM, Stefan Beller <sbel...@google.com> wrote: > We need the submodule groups in a later patch. The commit message should now say "labels", too, I guess. -- Sebastian Schuberth -- To unsubscribe from this list: send the line "unsu

Re: [PATCH 0/4] Submodule Groups

asked above, how many comma separated things do we have in git configs? > I'd really not want to add more mental complexity to Git. As far as I I don't think it can get much worse anyway ;-) > remember we have > rather double configs than one long line separated somehow. > (The only thing

Re: [PATCH 0/4] Submodule Groups

"gcc"] groups = default,devel followed by [submodule "gcc"] group = default group = devel -- Sebastian Schuberth -- 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

Re: Questions on passing --depth to git-clone vs. git-fetch

his being documented as part of --single-branch instead of --depth, which I think is confusing. I'll send a patch. -- Sebastian Schuberth -- 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 ht

[PATCH] docs: clarify that passing --depth to git-clone implies --single-branch

It is confusing to document how --depth behaves as part of the --single-branch docs. Better move that part to the --depth docs, saying that it implies --single-branch by default. Signed-off-by: Sebastian Schuberth <sschube...@gmail.com> --- Documentation/git-clone.txt | 9 -

Questions on passing --depth to git-clone vs. git-fetch

ndows 2.7. Any comments? [1] https://git-scm.com/docs/git-clone [1] https://git-scm.com/docs/git-fetch -- Sebastian Schuberth -- 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

Re: [PATCH 2/2] contrib/git-candidate: Add README

, and with the reviewnotes plugin [1] also the outcome of a review in refs/notes/review. [1] https://gerrit.googlesource.com/plugins/reviewnotes/+/refs/heads/master/src/main/resources/Documentation/refs-notes-review.md -- Sebastian Schuberth -- To unsubscribe from this list: send the line "unsubscrib

Re: [PATCH] contrib/subtree: Remove --annotate

o name examples for such more suitable tools as part of the commit message. -- Sebastian Schuberth -- 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

Re: [PATCH v3] ls-files: Add eol diagnostics

er all just one letter (i.e. "attr/" becomes "a/"), or all multi-letter abbreviations (i.e. "i/" becomes "idx/" and "w/" becomes "wt/" or "wtree/" or "tree/")? -- Sebastian Schuberth -- To unsubscribe from this list: send

Re: [PATCH v3] ls-files: Add eol diagnostics

> + ;; Personally, I'm not a big fan of supposedly funny output like this. How about printing a proper message rather than "huh", even for cases that should not happen? -- Sebastian Schuberth -- To unsubscribe from this list: send the line "unsubscribe git" in t

Re: [PATCH v4 4/4] Add Travis CI support

more configurations than manually feasible. But that should be done as part of a different job then. E.g. we could have a "fast" PR validation job, and a "slow" nightly build job. -- Sebastian Schuberth -- To unsubscribe from this list: send the line "unsubscribe gi

Re: [PATCH v4 4/4] Add Travis CI support

to > run all 8 configurations on maint, master, next and maybe pu. All other > branches on peoples own forks should be fine with the default Linux build > (~10min). > > What do you think? I think running different configuration per branch makes sense, yes. -- Sebastian Sch

Re: [PATCH v4 4/4] Add Travis CI support

eration? No. I think this could be addressed later as an improvements. To me it's more important to finally get *some* sane Travis CI configuration in. -- Sebastian Schuberth -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.o

Re: [PATCH v2] ls-files: Add eol diagnostics

s there a (potential) difference between line endings in the index and repo? AFAIK there is not. Any I find it a bit confusing to refer to the index where, as e.g. for a freshly cloned repo the index should be empty, yet you do have specific line endings in the repo. Long story short, how ab

Re: [PATCH v2] ls-files: Add eol diagnostics

ee the content of the index, because > your HEAD is still broken. Ok, I'm convinced. Thanks again! -- Sebastian Schuberth -- 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

Re: [PATCH 3/3] clone: Allow an explicit argument for parallel submodule clones

immediate question would be "What's the default for n if not specified?" -- Sebastian Schuberth -- 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

Re: [PATCH v3 1/3] Add Travis CI support

On 10/11/2015 19:55, larsxschnei...@gmail.com wrote: + sudo apt-get update -qq + sudo apt-get install -y apt-transport-https + sudo apt-get install perforce-server git-lfs Why no "-y" also in this line, or append these to the previous line? Or maybe even better, like [1] does,

Re: [RFC/PATCH v1] Add Travis CI support

On 10/4/2015 19:46, Junio C Hamano wrote: The very nice thing with Travis-CI is that it does not only test the repository's branches, but also all pull-requests. OK, that is the first real argument I heard for enabling it on git/git that is worth listening to. I was mentioning that very

Re: [PATCH v3 1/3] Add Travis CI support

) I like that idea, but I think we should save that for a future improvement to .travis.yml. [1] http://docs.travis-ci.com/user/installing-dependencies/ -- Sebastian Schuberth -- 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

  1   2   3   >