Re: [PATCH v3] config: make git_config_set die on failure

Patrick Steinhardt writes: > Furthermore, I do think it's more explicit what the functions are > doing when there is a 'or_die' suffix. Without this suffix it may > be unexpected that the functions simply abort the program > whenever an error occurs. That largely depends on what

Re: [PATCH] completion: verify-tag is not plumbing

John Keeping writes: > I can accept that argument about verify-commit and verify-tag, but > listing verify-tag as plumbing is incorrect according to > command-list.txt (and thus git(1)). If we're going to classify > commands, shouldn't we be consistent in how we do so?

Re: Plans for 2.7.1?

Johannes Schindelin writes: > at tinyurl.com/gitCal I see a pretty timeline regarding 2.8.0, but I do > not see 2.7.1 planned anywhere. Yup, because maintenance releases are inherently "not planned" ;-) Unlike feature releases that are largely time-based, we cut

Re: [PATCH] travis-ci: run previously failed tests first, then slowest to fastest

On Mon, Feb 01, 2016 at 10:17:24AM -0800, Junio C Hamano wrote: > > Your proposal is to redefine "is the working tree dirty?"; it would > check if "git checkout -f" would change what is in the working tree. I like this definition. Sounds obviously right. > > Regarding performance impact: We

Re: [RFC/PATCH 0/5] [WAS: Submodule Groups] Labels and submodule.autoInitialize

On Sun, Jan 31, 2016 at 1:09 PM, Jens Lehmann wrote: >>> After all this config is >>> just about which submodules are chosen to be updated on clone and >>> submodule update, not on all the other work tree manipulating >>> commands. >> >> >> So you'd imagine that "git

Re: [PATCH 3/5] notes: read copied notes with strbuf_getline()

Same comment as 1/5 and 2/5 applies. You need to think if strbuf_rtim(split[1]) is necessary here. -- 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] t6302: drop unnecessary GPG requirement

Johannes Schindelin writes: > An even easier solution might be to *not* set up the signed tags in the > 'setup' part, but only in the respective test case, and delete them right > away after said test case? After reading your patch, I do not find it an "easier

Re: [PATCH 2/5] clean: read user input with strbuf_getline()

The same comment (including "think if this trim is still necessary") as 1/5 applies here. -- 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 1/5] bisect: read bisect paths with strbuf_getline()

Moritz Neeb writes: > The lines read from BISECT_NAMES are trimmed with strbuf_trim() > immediately. There is thus no logic expecting CR, so > strbuf_getline_lf() can be replaced by its CRLF counterpart. We do not indent the whole log message. You would also

Re: AW: [PATCH 1/2] stash--helper: implement "git stash--helper"

Michael Blume writes: > Maybe this isn't important given that it looks like the patch is going > to be rewritten, but I have > > stash.c:43:18: warning: incompatible pointer types assigning to 'const > char *const *' from 'const char *'; take the address with & >

[RFC] GPG-Signed pushes & commits: differentiating between no signature and an unknown key

Format string %G? includes state 'N', which is described as "no signature". If you try to verify a commit or push for which you have no key (and you don't automatically fetch from the keyservers [1]), then the format string ALSO contains 'N', which is incorrect. It should be possible to

Re: [PATCH v4 03/12] ref-filter: bump 'used_atom' and related code to the top

Karthik Nayak writes: > Bump code to the top for usage in further patches. > --- Sign-off? > ref-filter.c | 30 +++--- > 1 file changed, 15 insertions(+), 15 deletions(-) > > diff --git a/ref-filter.c b/ref-filter.c > index 38f38d4..c3a8372

Re: [PATCH 6/6] apply, ls-files: simplify "-z" parsing

Junio C Hamano writes: > Of course, a patch adding a "--nul" can be the one that does the > polarity flipping, so in that sense, this simplification is probably > OK, as long as there is some comment that warns a time-bomb you just > planted here ;-) I'll queue it with this

Re: AW: [PATCH 1/2] stash--helper: implement "git stash--helper"

On Fri, Jan 29, 2016 at 11:58 AM, Junio C Hamano wrote: > Matthias Aßhauer writes: > > [administrivia: please wrap your lines to reasonable lengths] > >>> Honestly, I had high hopes after seeing the "we are rewriting it >>> in C" but I am not enthused after

Re: [PATCH V5 2/2] object name: introduce '^{/!-}' notation

Thanks. -- 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: git log -g bizarre behaviour

Dennis Kaarsemaker writes: > I'm attempting to understand the log [-g] / reflog code enough to > untangle them and make reflog walking work for more than just commit > objects [see gmane 283169]. I found something which I think is wrong, > and would break after my

Re: [PATCH 6/6] apply, ls-files: simplify "-z" parsing

Jeff King writes: > As a short option, we cannot handle negation. Thus a > callback handling "unset" is overkill, and we can just use > OPT_SET_INT instead to handle setting the option. > > Signed-off-by: Jeff King > --- > I left this one for last, because it's the

Re: [RFC] GPG-Signed pushes & commits: differentiating between no signature and an unknown key

"Robin H. Johnson" writes: > Format string %G? includes state 'N', which is described as "no > signature". > > If you try to verify a commit or push for which you have no key (and you > don't automatically fetch from the keyservers [1]), then the format > string ALSO contains

Re: [PATCH 5/5] wt-status: read rebase todolist with strbuf_getline()

Moritz Neeb writes: > In read_rebase_todolist() every line is, after reading, checked > for a comment_line_char. After that it is trimmed via strbuf_trim(). > Assuming we do never expect a CR as comment_line_char, > strbuf_getline_lf() can be safely replaced

Re: [PATCH v4 00/12] ref-filter: use parsing functions

Karthik Nayak writes: > This series cleans up populate_value() in ref-filter, by moving out > the parsing part of atoms to separate parsing functions. This ensures > that parsing is only done once and also improves the modularity of the > code. > > v1:

parse_object does check_sha1_signature but not parse_object_buffer?

Hi, You might or might not be aware of this thread: https://groups.google.com/forum/#!topic/binary-transparency/f-BI4o8HZW0 Anyways, this got me to take a look around, and I noticed that parse_object does SHA-1 validation through check_sha1_signature. What surprised me is that

Re: parse_object does check_sha1_signature but not parse_object_buffer?

On Tue, Feb 02, 2016 at 10:57:01AM +0900, Mike Hommey wrote: > Hi, > > You might or might not be aware of this thread: > https://groups.google.com/forum/#!topic/binary-transparency/f-BI4o8HZW0 > > Anyways, this got me to take a look around, and I noticed that > parse_object does SHA-1 validation

Re: [PATCH v4 00/12] ref-filter: use parsing functions

On Mon, Feb 1, 2016 at 5:25 PM, Junio C Hamano wrote: > Karthik Nayak writes: > >> This series cleans up populate_value() in ref-filter, by moving out >> the parsing part of atoms to separate parsing functions. This ensures >> that parsing is only done

Re: [RFC] GPG-Signed pushes & commits: differentiating between no signature and an unknown key

On Mon, Feb 01, 2016 at 02:49:09PM -0800, Junio C Hamano wrote: > Are you talking about something other than prepare_push_cert_sha1()? I went and verified it, and what was reported to me was slightly wrong. Only some of the field are empty, notably CERT_KEY and SIGNER. Signed push with an

Re: [PATCH v4 10/12] ref-filter: introduce remote_ref_atom_parser()

On Tue, Feb 2, 2016 at 6:29 AM, Eric Sunshine wrote: > This is a re-send of patch 10/12 on Karthik's behalf to give other > reviewers a chance at it. The original did not make it to the mailing > list since it contained a rather large binary resource Karthik >

Re: parse_object does check_sha1_signature but not parse_object_buffer?

Mike Hommey writes: > Shouldn't parse_object_buffer also do check_sha1_signature? In general, it shouldn't; its callers are supposed to do it as additional check when/if needed. Callers like the one in fsck.c does not want to die after seeing one bad one. We want to report

Re: [PATCH v4 10/12] ref-filter: introduce remote_ref_atom_parser()

This is a re-send of patch 10/12 on Karthik's behalf to give other reviewers a chance at it. The original did not make it to the mailing list since it contained a rather large binary resource Karthik accidentally included in the commit (which has been stripped from this re-send). On Sun, Jan 31,

Re: [RFC/PATCH] Git doc: GPL2 does not apply to repo data

On Mon, Feb 01, 2016 at 08:49:55AM +0100, Matthieu Moy wrote: > - Original Message - > > For less tech-savvy managers, I found that name dropping works quite well > > (read: naming a couple of well-known companies/products that switched to > > Git). > > In the same category: "GitHub has

Re: [RFC/PATCH] Git doc: GPL2 does not apply to repo data

On Mon, Feb 01, 2016 at 03:14:31AM -0500, Jeff King wrote: > On a more serious note, this FAQ (and the one right after) might be > useful for convincing people: > > http://www.gnu.org/licenses/gpl-faq.en.html#GPLOutput > > Data that git stores is not strictly "output", but I think the answers

Re: [RFC/PATCH] Git doc: GPL2 does not apply to repo data

From: "Jeff King" On Mon, Feb 01, 2016 at 08:49:55AM +0100, Matthieu Moy wrote: - Original Message - > For less tech-savvy managers, I found that name dropping works quite > well > (read: naming a couple of well-known companies/products that switched > to > Git). In

Re: [RFC/PATCH] Git doc: GPL2 does not apply to repo data

From: "Junio C Hamano" Philip Oakley writes: diff --git a/Documentation/git.txt b/Documentation/git.txt index bff6302..137c89c 100644 --- a/Documentation/git.txt +++ b/Documentation/git.txt @@ -1132,6 +1132,17 @@ of clones and fetches. - any

[PATCH v3] config: make git_config_set die on failure

Failure to write the configuration file may be caused by multiple conditions, the most common one being the case where the configuration is locked because of a leftover lock file or because another process is currently writing to it. We used to ignore those errors in many cases, possibly leading

Re: [PATCH] completion: verify-tag is not plumbing

On Sun, Jan 31, 2016 at 02:37:59PM +0100, SZEDER Gábor wrote: > > Quoting John Keeping : > > > According to command-list.txt, verify-tag is an ancillary interrogator, > > which means that it should be completed by "git verify-" in the > > same way as verify-commit. > > > >

Re: [RFC/PATCH] Git doc: GPL2 does not apply to repo data

From: "Philip Oakley" We should leave the lawyering to real lawyers and we should not add unnecessary work of interpreting our amateurish loose statement to our laywers. Given Jonathan's question, and your earlier feedback, it did feel that a bit of clear blue water

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

From: Sebastian Schuberth 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.

Git for Windows

Hi, I am using Windows 10 and am getting "The signature for git-2.7.0-64-bit.exe is corrupt or invalid" ! Same for the 32bit version. Regards, Aaron -- 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

[PATCH] test-lib: limit the output of the yes utility

On Windows, there is no SIGPIPE. A consequence of this is that the upstream process of a pipe does not notice the death of the downstream process until the pipe buffer is full and writing more data returns an error. This behavior is the reason for an annoying delay during the execution of

Re: [PATCH] travis-ci: run previously failed tests first, then slowest to fastest

On 2016-02-01 19.17, Junio C Hamano wrote: > Clemens Buchacher writes: [] > > IIRC, autocrlf=true would strip CR at the end of line in to-git > conversion, and would add CR in to-worktree conversion. So some eol > conversion may only act in to-git, but some others do affect both,

Re: Plans for 2.7.1?

Hi Junio, On Mon, 1 Feb 2016, Junio C Hamano wrote: > Johannes Schindelin writes: > > > at tinyurl.com/gitCal I see a pretty timeline regarding 2.8.0, but I > > do not see 2.7.1 planned anywhere. > > Yup, because maintenance releases are inherently "not planned"

Re: [PATCH] t6302: drop unnecessary GPG requirement

Hi Junio, On Mon, 1 Feb 2016, Junio C Hamano wrote: > Johannes Schindelin writes: > > > An even easier solution might be to *not* set up the signed tags in the > > 'setup' part, but only in the respective test case, and delete them right > > away after said test

Re: [RFC] GPG-Signed pushes & commits: differentiating between no signature and an unknown key

"Robin H. Johnson" writes: > On Mon, Feb 01, 2016 at 02:49:09PM -0800, Junio C Hamano wrote: >> Are you talking about something other than prepare_push_cert_sha1()? > I went and verified it, and what was reported to me was slightly wrong. Only > some of the field are empty,

Re: parse_object does check_sha1_signature but not parse_object_buffer?

On Mon, Feb 01, 2016 at 07:10:04PM -0800, Junio C Hamano wrote: > Mike Hommey writes: > > > Shouldn't parse_object_buffer also do check_sha1_signature? > > In general, it shouldn't; its callers are supposed to do it as > additional check when/if needed. Callers like the one

Re: [PATCH v4 00/12] ref-filter: use parsing functions

On Tue, Feb 2, 2016 at 6:07 AM, Eric Sunshine wrote: > On Mon, Feb 1, 2016 at 5:25 PM, Junio C Hamano wrote: >> Karthik Nayak writes: >> >>> This series cleans up populate_value() in ref-filter, by moving out >>> the parsing

Re: [PATCH 6/6] apply, ls-files: simplify "-z" parsing

On Mon, Feb 01, 2016 at 02:52:30PM -0800, Junio C Hamano wrote: > Junio C Hamano writes: > > > Of course, a patch adding a "--nul" can be the one that does the > > polarity flipping, so in that sense, this simplification is probably > > OK, as long as there is some comment

Re: [PATCH v3 6/6] worktree add: switch to worktree version 1

On Mon, Feb 01, 2016 at 01:05:05PM +0700, Duy Nguyen wrote: > On Mon, Feb 1, 2016 at 12:33 PM, Max Kirillov wrote: >> 1. For submodules (which must be left per-worktree) this >> approach is not going to work, because you don't know all >> variables in advance. You could scan the

Re: [PATCH v3 1/6] worktree: new repo extension to manage worktree behaviors

On wo, 2016-01-27 at 14:12 -0800, Junio C Hamano wrote: > More seriously, are we confident that the overall worktree support > is mature enough by now that once we add an experimental feature X > at version 1, we can promise to keep maintaining it forever at > version N for any positive integer

Re: [PATCH] travis-ci: run previously failed tests first, then slowest to fastest

Clemens Buchacher writes: > Ok, then let's take a step back. I do not actually care if git diff and > friends say the worktree is clean or not. You may not, but many existing scripts people have do. > But I know that I did not make > any modifications to the worktree, because I

Re: [PATCH v3 1/6] worktree: new repo extension to manage worktree behaviors

Duy Nguyen writes: > On Mon, Feb 1, 2016 at 9:41 AM, Stefan Monnier > wrote: >>> One lessor key phrase above is "so far", I think, and another one >>> you forgot to use is s/which requires/that we know &/, which to me >>> is a more serious one.

Plans for 2.7.1?

Hi Junio, at tinyurl.com/gitCal I see a pretty timeline regarding 2.8.0, but I do not see 2.7.1 planned anywhere. Due to signature problems (I failed to realize that SHA-1 based .exe signatures are no longer considered valid starting from January 1st, 2016), I got a metric ton of private and

Re: Git for Windows

Hi Aaron, On Mon, 1 Feb 2016, Aaron Gray wrote: > I am using Windows 10 and am getting "The signature for > git-2.7.0-64-bit.exe is corrupt or invalid" ! > > Same for the 32bit version. See https://github.com/git-for-windows/git/issues/592 Ciao, Johannes -- To unsubscribe from this list: send