Re: [GSoC] Move ~/.git-credential-cache to ~/.cache/git

Devin Lehmacher writes: > If I’m not mistaken magit won’t stop working with the changed > location since it will just spawn an new instance of the > daemon. The only downside would be it wouldn’t get credentials > that were cached in the default socket. I am not quite sure

Re: [GSoC] Move ~/.git-credential-cache to ~/.cache/git

If I’m not mistaken magit won’t stop working with the changed location since it will just spawn an new instance of the daemon. The only downside would be it wouldn’t get credentials that were cached in the default socket. I am going to move forward with git-credential-cache just using the new

Re: [GSoC] Move ~/.git-credential-cache to ~/.cache/git

On Fri, Mar 10, 2017 at 7:26 PM, Jonathan Nieder wrote: > I find that magit does rely on the socket path. > > Start credential daemon on magit-credential-hook > > If we let git start the daemon, Emacs will send a SIGHUP when git > finishes and closes the pty,

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

On Mon, Feb 27, 2017 at 10:12 PM, Jeff King wrote: > I didn't actually review it very carefully before, but I'll do so now > (spoiler: a few nits, but it looks fine). > >> static struct ref *wanted_peer_refs(const struct ref *refs, >> - struct refspec *refspec) >> +

Re: [PATCH v2 1/2] pathspec: allow querying for attributes

On 03/10, Jonathan Tan wrote: > Thanks - I don't think I have any more comments on this patch set > after these. > > On 03/10/2017 10:59 AM, Brandon Williams wrote: > >diff --git a/pathspec.c b/pathspec.c > >index b961f00c8..7cd5f6e3d 100644 > >--- a/pathspec.c > >+++ b/pathspec.c > >@@ -87,6

Re: [GSoC] Move ~/.git-credential-cache to ~/.cache/git

(+cc: npostavs) Hi Devin, Devin Lehmacher wrote: > I started working on this microproject and am not quite sure what is > necessary for backwards compatibility. Since the socket is recreated > whenever the credential daemon exits backwards compatibility > shouldn’t really be a concern with

Re: Stable GnuPG interface, git should use GPGME

On Fri, Mar 10, 2017 at 11:00:07AM +0100, Bernhard E. Reiter wrote: > My use case today was signing and git by default found the `gpg` binary by > default and the command failed. The reason is that I have `gpg2` installed > and most applications use it right away. So git failed signing because >

[GSoC] Move ~/.git-credential-cache to ~/.cache/git

I started working on this microproject and am not quite sure what is necessary for backwards compatibility. Since the socket is recreated whenever the credential daemon exits backwards compatibility shouldn’t really be a concern with regard to where the socket is located in the filesystem.

Re: [PATCH v2] repack: Add option to preserve and prune old pack files

James Melvin writes: > The new --preserve-and-prune option renames old pack files > instead of deleting them after repacking and prunes previously > preserved pack files. > > This option is designed to prevent stale file handle exceptions > during git operations which can

Re: [PATCH v1] Travis: also test on 32-bit Linux

René Scharfe writes: > @ depends on r @ > expression E; > @@ > - *& > E I guess my source of the confusion is that the tool that understands the semantics of the C language still needs to be told about that. I was hoping that something that

What's cooking in git.git (Mar 2017, #04; Fri, 10)

Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. The ones marked with '.' do not appear in any of the integration branches, but I am still holding onto them. You can find the changes

Re: [RFC][PATCH] index-pack: add testcases found using AFL

On Fri, Mar 10, 2017 at 8:06 PM, Jeff King wrote: > [Note: your original email didn't make it to the list because it's over > 100K; I'll quote liberally]. > > On Fri, Mar 10, 2017 at 04:15:56PM +0100, Vegard Nossum wrote: > >> I've used AFL to generate a corpus of pack files that

Re: git-push branch confusion caused by user mistake

Phil Hord writes: > I think git should be smarter about deducing the dest ref from the > source ref if the source ref is in refs/remotes, but I'm not sure how > far to take it. My knee-jerk reaction is "Don't take it anywhere". Giving a refspec from the command line is

Re: [PATCH v1] Travis: also test on 32-bit Linux

Am 10.03.2017 um 21:13 schrieb Junio C Hamano: René Scharfe writes: I think this misses the other two cases: (*dst, src) and (*dst, *src). ... and that's why I left them out. You can't get dst vs. *dst wrong with structs (at least not without the compiler complaining); only

[PATCH v2] repack: Add option to preserve and prune old pack files

The new --preserve-and-prune option renames old pack files instead of deleting them after repacking and prunes previously preserved pack files. This option is designed to prevent stale file handle exceptions during git operations which can happen on users of NFS repos when repacking is done on

Re: [PATCH] repack: Add options to preserve and prune old pack files

On 2017-03-07 13:33, Junio C Hamano wrote: James Melvin writes: ... I am not sure if I understand your design. Your model looks to me like there are two modes of operation. #1 uses "--preserve-old" and sends old ones to purgatory instead of removing them and #2

Re: [RFC PATCH] help: add optional instructions for reporting bugs

On Fri, Mar 10, 2017 at 7:13 PM, Jonathan Nieder wrote: > Hi, > > Stefan Beller wrote: > >> When reporting bugs, users will usually look at the output of >> 'git --version' at one point to write a quality bug report. >> So that is a good spot to provide additional information

git-push branch confusion caused by user mistake

This week a user accidentally did this: $ git push origin origin/master Total 0 (delta 0), reused 0 (delta 0) To parent.git * [new branch] origin/master -> origin/master He saw his mistake when the "new branch" message appeared, but he was confused about how to fix it and

Re: [RFC][PATCH] index-pack: add testcases found using AFL

On 10/03/2017 20:42, Jeff King wrote: That's something I guess, but I'm not enthused by the idea of just dumping a bunch of binary test cases that nobody, not even the author, understands. [...] My real concern is that this is the tip of the ice berg. So we increased coverage in one program

Re: [GSoC] Discussion of "Submodule related work" project

> This means I can take only any one of them as starting point for > my proposal? If it is true, than i'll try to take sh->C transition for submodule command, and as addirional part of my whole project also this: https://public-inbox.org/git/1488913150.881...@smtp.yandex.ru/T/ >> Have some

bug?: git reset --mixed ignores deinitialized submodules

Git reset --mixed ignores submodules which are not initialized. I've attached a demo script.   On one hand, this matches the documentation ("Resets the index but not the working tree"). But on the other hand, it kind of doesn't: "(i.e., the changed files are preserved but not marked for

Re: [PATCH v3 2/2] submodule--helper.c: remove duplicate code

On Fri, Mar 10, 2017 at 12:40 PM, Junio C Hamano wrote: > Stefan Beller writes: > >> On Fri, Mar 10, 2017 at 11:42 AM, Junio C Hamano wrote: >>> Brandon Williams writes: >>> On 03/09, Valery Tolstov wrote: >

Re: [PATCH v3 2/2] submodule--helper.c: remove duplicate code

Stefan Beller writes: > On Fri, Mar 10, 2017 at 11:42 AM, Junio C Hamano wrote: >> Brandon Williams writes: >> >>> On 03/09, Valery Tolstov wrote: Remove code fragment from module_clone that duplicates functionality of

[PATCH v3] ref-filter: Add --no-contains option to tag/branch/for-each-ref

Change the tag, branch & for-each-ref commands to have a --no-contains option in addition to their longstanding --contains options. The use-case I have for this is to find the last-good rollout tag given a known-bad . Right now, given a hypothetically bad commit v2.10.1-3-gcf5c7253e0, you can

Re: Stable GnuPG interface, git should use GPGME

On Fri, Mar 10, 2017 at 10:54:19AM -0800, Linus Torvalds wrote: > - library versioning. > >I don't know why, but I've never *ever* met a library developer who > realized that libraries were all about stable API's, and the library > users don't want to fight different versions. Actually, you

Re: [PATCH v1] Travis: also test on 32-bit Linux

On Fri, Mar 10, 2017 at 12:13:11PM -0800, Junio C Hamano wrote: > René Scharfe writes: > > >> I think this misses the other two cases: (*dst, src) and (*dst, *src). > > > > ... and that's why I left them out. You can't get dst vs. *dst wrong > > with structs (at least not without

Re: [PATCH] Makefile: detect errors in running spatch

Jeff King writes: > It also doesn't help that shells are awkward at passing status out of a > for-loop. I think the most "make-ish" way of doing this would actually > be to lose the for loop and have a per-cocci-per-source target. As we assume we can freely use GNUmake

Re: [PATCH v1] Travis: also test on 32-bit Linux

René Scharfe writes: >> I think this misses the other two cases: (*dst, src) and (*dst, *src). > > ... and that's why I left them out. You can't get dst vs. *dst wrong > with structs (at least not without the compiler complaining); only > safe transformations are included in this

Re: git commit --interactive patch-mode no longer allows selecting files

On Fri, Mar 10, 2017 at 11:57:04AM -0800, Junio C Hamano wrote: > Jeff King writes: > > > It's a bug. The fix is in c852bd54bd87fdcdc825f5d45c26aa745be13ba6, but > > has not yet been merged to any integration branches. I hope it will make > > it into v2.12.1. > > Wow, you got me

Re: git commit --interactive patch-mode no longer allows selecting files

Jeff King writes: > It's a bug. The fix is in c852bd54bd87fdcdc825f5d45c26aa745be13ba6, but > has not yet been merged to any integration branches. I hope it will make > it into v2.12.1. Wow, you got me worried. It has been in 'pu' (and my private edition 'jch', which is

Re: [PATCH v2 1/2] pathspec: allow querying for attributes

Thanks - I don't think I have any more comments on this patch set after these. On 03/10/2017 10:59 AM, Brandon Williams wrote: diff --git a/pathspec.c b/pathspec.c index b961f00c8..7cd5f6e3d 100644 --- a/pathspec.c +++ b/pathspec.c @@ -87,6 +89,74 @@ static void prefix_magic(struct strbuf *sb,

Re: RFC v3: Another proposed hash function transition plan

Jeff King wrote: > On Thu, Mar 09, 2017 at 12:24:08PM -0800, Jonathan Nieder wrote: >>> SHA-1 to SHA-3: lookup SHA-1 in .msha1, reverse .idx, find offset to >>> read the SHA-3. >>> SHA-3 to SHA-1: lookup SHA-3 in .idx, and reverse the .msha1 file to >>> translate offset to SHA-1. >> >> Thanks for

Re: What's cooking in git.git (Mar 2017, #03; Wed, 8)

"brian m. carlson" writes: > On Wed, Mar 08, 2017 at 03:47:20PM -0800, Junio C Hamano wrote: >> * bc/object-id (2017-02-22) 19 commits >> - wt-status: convert to struct object_id >> - builtin/merge-base: convert to struct object_id >> - Convert object iteration

Re: [PATCH v3 2/2] submodule--helper.c: remove duplicate code

On Fri, Mar 10, 2017 at 11:42 AM, Junio C Hamano wrote: > Brandon Williams writes: > >> On 03/09, Valery Tolstov wrote: >>> Remove code fragment from module_clone that duplicates functionality >>> of connect_work_tree_and_git_dir in dir.c >>> >>>

Re: [PATCH 02/10] pack-objects: add --partial-by-size=n --partial-special

On Fri, Mar 10, 2017 at 11:38:10AM -0800, Junio C Hamano wrote: > Jeff King writes: > > > I think we ended up deciding that it would be better to just disallow > > symlink .gitattributes (and .git*) from entering the index, the way we > > disallow ".git". > > Hmph, I thought we

Re: [RFC][PATCH] index-pack: add testcases found using AFL

On Fri, Mar 10, 2017 at 08:34:45PM +0100, Vegard Nossum wrote: > > That's something I guess, but I'm not enthused by the idea of just > > dumping a bunch of binary test cases that nobody, not even the author, > > understands. > > I understand your concern. This is how I see it: > > Negatives: >

Re: [PATCH v3 2/2] submodule--helper.c: remove duplicate code

Brandon Williams writes: > On 03/09, Valery Tolstov wrote: >> Remove code fragment from module_clone that duplicates functionality >> of connect_work_tree_and_git_dir in dir.c >> >> Signed-off-by: Valery Tolstov > > Looks good. I'll queue with your

Re: RFC v3: Another proposed hash function transition plan

On Thu, Mar 09, 2017 at 12:24:08PM -0800, Jonathan Nieder wrote: > > SHA-1 to SHA-3: lookup SHA-1 in .msha1, reverse .idx, find offset to > > read the SHA-3. > > SHA-3 to SHA-1: lookup SHA-3 in .idx, and reverse the .msha1 file to > > translate offset to SHA-1. > > Thanks for this suggestion. I

Re: [PATCH 02/10] pack-objects: add --partial-by-size=n --partial-special

Jeff King writes: > I think we ended up deciding that it would be better to just disallow > symlink .gitattributes (and .git*) from entering the index, the way we > disallow ".git". Hmph, I thought we would need both, though. Or do we specifically want to honor untracked

Re: [RFC][PATCH] index-pack: add testcases found using AFL

On 10/03/2017 20:06, Jeff King wrote: On Fri, Mar 10, 2017 at 04:15:56PM +0100, Vegard Nossum wrote: I've used AFL to generate a corpus of pack files that maximises the edge coverage for 'git index-pack'. This is a supplement to (and not a replacement for) the regular test cases where we know

Re: [PATCH v5 04/11] setup_git_directory_1(): avoid changing global state

Johannes Schindelin writes: > /* > * We cannot decide in this function whether we are in the work tree or > * not, since the config can only be read _after_ this function was called. > + * > + * Also, we avoid changing any global state (such as the current

Re: [GSoC] Discussion of "Submodule related work" project

So... I thought those items listed in "Submodule related work" are considered too small to be complete projects separately, and they are just "subprojects" of bigger project (maybe I have this thought because I can't estimate complexity before truly digging in). In your response you talk about

Re: [RFC][PATCH] index-pack: add testcases found using AFL

[Note: your original email didn't make it to the list because it's over 100K; I'll quote liberally]. On Fri, Mar 10, 2017 at 04:15:56PM +0100, Vegard Nossum wrote: > I've used AFL to generate a corpus of pack files that maximises the edge > coverage for 'git index-pack'. > > This is a

Re: [PATCH v5 09/11] Test read_early_config()

Johannes Schindelin writes: > Subject: Re: [PATCH v5 09/11] Test read_early_config() Let's retitle it to t1309: test read_early_config() > So far, we had no explicit tests of that function. > > Signed-off-by: Johannes Schindelin

Re: [PATCH 2/2] pathspec: allow escaped query values

On 03/09, Jonathan Tan wrote: > On 03/09/2017 01:07 PM, Brandon Williams wrote: > >diff --git a/t/t6135-pathspec-with-attrs.sh b/t/t6135-pathspec-with-attrs.sh > >index b5e5a0607..585d17bad 100755 > >--- a/t/t6135-pathspec-with-attrs.sh > >+++ b/t/t6135-pathspec-with-attrs.sh > >@@ -178,4 +178,13

[PATCH v2 1/2] pathspec: allow querying for attributes

The pathspec mechanism is extended via the new ":(attr:eol=input)pattern/to/match" syntax to filter paths so that it requires paths to not just match the given pattern but also have the specified attrs attached for them to be chosen. Based on a patch by Stefan Beller

[PATCH v2 2/2] pathspec: allow escaped query values

In our own .gitattributes file we have attributes such as: *.[ch] whitespace=indent,trail,space When querying for attributes we want to be able to ask for the exact value, i.e. git ls-files :(attr:whitespace=indent,trail,space) should work, but the commas are used in the attr magic to

[PATCH v2 0/2] bringing attributes to pathspecs

v2 addresses the comments made by Jonathan. Brandon Williams (2): pathspec: allow querying for attributes pathspec: allow escaped query values Documentation/glossary-content.txt | 21 attr.c | 17 attr.h | 1 + dir.c

Re: [PATCH v5 10/11] setup_git_directory_gently_1(): avoid die()ing

Johannes Schindelin writes: > @@ -890,14 +892,22 @@ static enum discovery_result > setup_git_directory_gently_1(struct strbuf *dir, > if (one_filesystem) > current_device = get_device_or_die(dir->buf, NULL, 0); > for (;;) { > -

Re: Stable GnuPG interface, git should use GPGME

On Fri, Mar 10, 2017 at 2:00 AM, Bernhard E. Reiter wrote: > > git uses an pipe-and-exec approach to running a GnuPG binary > as writen in the documentation [1]: > > gpg.program >Use this custom program instead of "gpg" found on $PATH when making >

Re: [GSoC] Discussion of "Submodule related work" project

On Fri, Mar 10, 2017 at 3:27 AM, Valery Tolstov wrote: > Have some questions about "Submodule related work" project > > First of all, I would like to add this task to the project, if I'll take it: > https://public-inbox.org/git/1488913150.881...@smtp.yandex.ru/T/ > What do you

Re: [PATCH v1] Travis: also test on 32-bit Linux

Am 10.03.2017 um 18:57 schrieb Jeff King: On Fri, Mar 10, 2017 at 05:20:13PM +0100, René Scharfe wrote: I think this misses the other two cases: (*dst, src) and (*dst, *src). ... and that's why I left them out. You can't get dst vs. *dst wrong with structs (at least not without the compiler

Re: [PATCH 1/2] pathspec: allow querying for attributes

On 03/09, Jonathan Tan wrote: > On 03/09/2017 01:07 PM, Brandon Williams wrote: > >diff --git a/Documentation/glossary-content.txt > >b/Documentation/glossary-content.txt > >index fc9320e59..5c32d1905 100644 > >--- a/Documentation/glossary-content.txt > >+++ b/Documentation/glossary-content.txt >

Re: [RFC PATCH] help: add optional instructions for reporting bugs

Hi, Stefan Beller wrote: > When reporting bugs, users will usually look at the output of > 'git --version' at one point to write a quality bug report. > So that is a good spot to provide additional information to the user > about e.g. additional the organizational quirks how to report a bug. > >

Re: [PATCH] Makefile: detect errors in running spatch

On Fri, Mar 10, 2017 at 06:03:47PM +0100, René Scharfe wrote: > > This shell code is getting a bit unwieldy to stick inside the Makefile, > > with all the line continuation and $-escaping. It might be worth moving > > it into a helper script. > > There is one for the kernel >

Re: [PATCH 02/10] pack-objects: add --partial-by-size=n --partial-special

On Fri, Mar 10, 2017 at 09:58:23AM -0800, Brandon Williams wrote: > > A while back when we discussed whether to allow symlinks for > > .gitattributes, etc, I think the consensus was to treat the whole > > ".git*" namespace consistently. I haven't followed up with patches yet, > > but my plan was

Re: [PATCH 02/10] pack-objects: add --partial-by-size=n --partial-special

On 03/09, Jeff King wrote: > On Wed, Mar 08, 2017 at 03:21:11PM -0500, Jeff Hostetler wrote: > > > > And not ."gitmodules"? > > > > > > What happens when we later add ".gitsomethingelse"? > > > > > > Do we have to worry about the case where the set of git "special > > > files" (can we have a

Re: [PATCH v1] Travis: also test on 32-bit Linux

On Fri, Mar 10, 2017 at 05:20:13PM +0100, René Scharfe wrote: > > I think this misses the other two cases: (*dst, src) and (*dst, *src). > > ... and that's why I left them out. You can't get dst vs. *dst wrong with > structs (at least not without the compiler complaining); only safe >

Re: [PATCH] Makefile: detect errors in running spatch

Am 10.03.2017 um 09:31 schrieb Jeff King: The "make coccicheck" target runs spatch against each source file. But it does so in a for loop, so "make" never sees the exit code of spatch. Worse, it redirects stderr to a log file, so the user has no indication of any failure. And then to top it all

Re: Git Vendor Support

On Fri, 10 Mar 2017 16:13:20 + "COLLINS, ROGER W GG-12 USAF NASIC/SCPW" wrote: > ALCON, > > Is there is a specific group or vendor backing Git? As part of our > internal approval process, our organization requires that we list a > vendor that provides active

Re: Git Vendor Support

On Fri, Mar 10, 2017 at 8:13 AM, COLLINS, ROGER W GG-12 USAF NASIC/SCPW wrote: > ALCON, > > Is there is a specific group or vendor backing Git? https://sfconservancy.org/ takes care of the financial needs of the community. > active support I guess companies that make

Re: [PATCH] branch: honor --abbrev/--no-abbrev in --list mode

Jakub Narębski writes: > W dniu 08.03.2017 o 23:16, Junio C Hamano pisze: > >> diff --git a/builtin/branch.c b/builtin/branch.c >> index cbaa6d03c0..537c47811a 100644 >> --- a/builtin/branch.c >> +++ b/builtin/branch.c >> @@ -335,9 +335,18 @@ static char *build_format(struct

Re: [PATCH v3 0/9] Fix the early config

Jeff King writes: >> > > Yes, exactly. It would have been less confusing if I picked something >> > > that passed nongit_ok. Like hash-object: >> >> ... or like testing the early config directly? > > I was trying to demonstrate that the problem existed already without > your

Git Vendor Support

ALCON, Is there is a specific group or vendor backing Git? As part of our internal approval process, our organization requires that we list a vendor that provides active support (ie. Patches) for the Git software. Thanks, Roger

Re: [PATCH v1] Travis: also test on 32-bit Linux

Am 10.03.2017 um 09:18 schrieb Jeff King: On Fri, Mar 10, 2017 at 01:14:16AM +0100, René Scharfe wrote: 2. Ones which just copy a single object, like: memcpy(, , sizeof(dst)); Perhaps we should be using struct assignment like: dst = src; here. It's safer and it

Re: [PATCH] blame: move blame_entry duplication to add_blame_entry()

Am 10.03.2017 um 09:32 schrieb Jeff King: On Fri, Mar 10, 2017 at 01:12:59AM +0100, René Scharfe wrote: All callers of add_blame_entry() allocate and copy the second argument. Let the function do it for them, reducing code duplication. I assume you found this due to the DUPLICATE()

Re: [RFC][PATCH] index-pack: add testcases found using AFL

On 10/03/2017 16:15, Vegard Nossum wrote: I've used AFL to generate a corpus of pack files that maximises the edge coverage for 'git index-pack'. This is a supplement to (and not a replacement for) the regular test cases where we know exactly what each test is checking for. These testcases are

Re: Stable GnuPG interface, git should use GPGME

On Fri, Mar 10, 2017 at 11:00 AM, Bernhard E. Reiter wrote: > Dear Git-Devs, I haven't contributed to Git's GPG code, but I'm taking the liberty of CC-ing some people who have. > git uses an pipe-and-exec approach to running a GnuPG binary > as writen in the

Re: [PATCH v2] t2027: avoid using pipes

On Thu, Mar 9, 2017 at 6:00 PM, Christian Couder wrote: > On Thu, Mar 9, 2017 at 10:53 AM, Prathamesh Chavan wrote: >> Whenever a git command is present in the upstream of a pipe, its failure >> gets masked by piping and hence it should be avoided

Re: BUG: "git branch --contains " does nothing, silently fails

On Fri, Mar 10, 2017 at 1:42 PM, Jeff King wrote: > On Fri, Mar 10, 2017 at 11:43:15AM +0100, Ævar Arnfjörð Bjarmason wrote: > >> Ran into this when preparing my --no-contains series, this is a long >> standing bug: >> >> $ ./git branch -D test; ./git branch --contains v2.8.0

Re: BUG: "git branch --contains " does nothing, silently fails

On Fri, Mar 10, 2017 at 11:43:15AM +0100, Ævar Arnfjörð Bjarmason wrote: > Ran into this when preparing my --no-contains series, this is a long > standing bug: > > $ ./git branch -D test; ./git branch --contains v2.8.0 test; echo > $?; git rev-parse test > error: branch 'test' not found.

Re: [PATCH v2] ref-filter: Add --no-contains option to tag/branch/for-each-ref

On Fri, Mar 10, 2017 at 12:46 PM, Ævar Arnfjörð Bjarmason wrote: > On Thu, Mar 9, 2017 at 9:31 PM, Christian Couder > wrote: >> On Thu, Mar 9, 2017 at 9:02 PM, Ævar Arnfjörð Bjarmason >> wrote: >>> >>> diff --git

Re: [PATCH v2] ref-filter: Add --no-contains option to tag/branch/for-each-ref

On Thu, Mar 9, 2017 at 9:31 PM, Christian Couder wrote: > On Thu, Mar 9, 2017 at 9:02 PM, Ævar Arnfjörð Bjarmason > wrote: >> >> diff --git a/Documentation/git-tag.txt b/Documentation/git-tag.txt >> index 525737a5d8..4938496194 100644 >> ---

Re: [PATCH] branch & tag: Add a --no-contains option

On Thu, Mar 9, 2017 at 3:55 PM, Jeff King wrote: > On Thu, Mar 09, 2017 at 03:52:09PM +0100, Ævar Arnfjörð Bjarmason wrote: > >> - filter->with_commit_tag_algo = 1; >> + if ((filter->merge_commit + filter->with_commit + >> filter->no_commit) > 1) >> +

[GSoC] Discussion of "Submodule related work" project

Have some questions about "Submodule related work" project First of all, I would like to add this task to the project, if I'll take it: https://public-inbox.org/git/1488913150.881...@smtp.yandex.ru/T/ What do you think about this task? > Cleanup our test suite. Do not use a repo itself as a

BUG: "git branch --contains " does nothing, silently fails

Ran into this when preparing my --no-contains series, this is a long standing bug: $ ./git branch -D test; ./git branch --contains v2.8.0 test; echo $?; git rev-parse test error: branch 'test' not found. 0 test fatal: ambiguous argument 'test': unknown revision or path not in

Stable GnuPG interface, git should use GPGME

Dear Git-Devs, git uses an pipe-and-exec approach to running a GnuPG binary as writen in the documentation [1]: gpg.program Use this custom program instead of "gpg" found on $PATH when making or verifying a PGP signature. The program must support the same

[Patch v2] t2027: avoid using pipes

From: Prathamesh Whenever a git command is present in the upstream of a pipe, its failure gets masked by piping and hence it should be avoided for testing the upstream git command. By writing out the output of the git command to a file, we can test the exit codes of both the

Re: [PATCH] blame: move blame_entry duplication to add_blame_entry()

On Fri, Mar 10, 2017 at 01:12:59AM +0100, René Scharfe wrote: > All callers of add_blame_entry() allocate and copy the second argument. > Let the function do it for them, reducing code duplication. I assume you found this due to the DUPLICATE() discussion elsewhere. Regardless of the results of

[PATCH] Makefile: detect errors in running spatch

The "make coccicheck" target runs spatch against each source file. But it does so in a for loop, so "make" never sees the exit code of spatch. Worse, it redirects stderr to a log file, so the user has no indication of any failure. And then to top it all off, because we touched the patch file's

Re: [PATCH v1] Travis: also test on 32-bit Linux

On Fri, Mar 10, 2017 at 01:14:16AM +0100, René Scharfe wrote: > > 2. Ones which just copy a single object, like: > > > >memcpy(, , sizeof(dst)); > > > > Perhaps we should be using struct assignment like: > > > >dst = src; > > > > here. It's safer and it should give