Re: [PATCH 1/4] clarify %f documentation

Joey Hess writes: > Junio C Hamano wrote: >> I agree that "the name of the file" can be interpreted in many ways, >> and I agree that it would be a good idea to find a better phrase to >> name the path that is being worked on, but I do not think "the file >> in the git

What's cooking in git.git (Jun 2016, #05; Thu, 16)

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. Let's start a new cycle by

Re: [PATCH 1/4] clarify %f documentation

Junio C Hamano wrote: > I agree that "the name of the file" can be interpreted in many ways, > and I agree that it would be a good idea to find a better phrase to > name the path that is being worked on, but I do not think "the file > in the git repository" is that phrase. > I think using the

Re: [bug] assertion in 2.8.4 triggering on old-ish worktree

On Fri, Jun 17, 2016 at 7:48 AM, Stefan Beller wrote: > On Thu, Jun 16, 2016 at 10:59 AM, Junio C Hamano wrote: >> Chris Packham writes: >> >>> On Thu, Jun 16, 2016 at 4:59 PM, Chris Packham >>> wrote:

Re: [PATCH] bisect: always call setup_revisions after init_revisions

On Thu, Jun 16, 2016 at 05:03:53PM -0700, Junio C Hamano wrote: > Jeff King writes: > > > The former initializes the rev_info struct to default > > values, and the latter parsers any command-line arguments > > and finalizes the struct. > > The former refers to init and the

Re: [PATCH] bisect: always call setup_revisions after init_revisions

Jeff King writes: > The former initializes the rev_info struct to default > values, and the latter parsers any command-line arguments > and finalizes the struct. The former refers to init and the latter setup? > In e22278c (bisect: display first bad commit without forking > a

Re: [PATCH] add--interactive: respect diff.compactionHeuristic

On Thu, Jun 16, 2016 at 09:50:45AM -0700, Stefan Beller wrote: > > -- >8 -- > > Subject: add--interactive: respect diff.compactionHeuristic > > > > We use plumbing to generate the diff, so it doesn't > > automatically pick up UI config like compactionHeuristic. > > Let's forward it on, since

[PATCH] bisect: always call setup_revisions after init_revisions

The former initializes the rev_info struct to default values, and the latter parsers any command-line arguments and finalizes the struct. In e22278c (bisect: display first bad commit without forking a new process, 2009-05-28), a show_diff_tree() was added that calls the former but not the latter.

Re: [PATCH v2] Documentation: GPG capitalization

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

[PATCH v2] Documentation: GPG capitalization

When "GPG" is used in a sentence it is now consistently capitalized. When referring to the binary it is left as "gpg". Signed-off-by: David Nicolson --- Documentation/git-tag.txt | 2 +- Documentation/git-verify-commit.txt | 2 +- 2 files changed, 2

Re: [PATCH 2/4] add smudge-to-file and clean-from-file filter configuration

Joey Hess writes: > diff --git a/Documentation/config.txt b/Documentation/config.txt > index 2e1b2e4..bbb9296 100644 > --- a/Documentation/config.txt > +++ b/Documentation/config.txt > @@ -1299,14 +1299,29 @@ format.useAutoBase:: > format-patch by default. > >

Re: [PATCH] diff compaction heuristic: favor shortest neighboring blank lines

> > The heuristic I proposed was > > * Prefer to start and end hunks *following* lines with the least > indentation. > > * Define the "indentation" of a blank line to be the indentation of > the previous non-blank line minus epsilon. > > * In the case of a tie, prefer to slide the hunk down as

Re: [PATCH 1/4] clarify %f documentation

Joey Hess writes: > It's natural to expect %f to be an actual file on disk; help avoid that > mistake. I agree that "the name of the file" can be interpreted in many ways, and I agree that it would be a good idea to find a better phrase to name the path that is being worked

Re: What's cooking in git.git (Jun 2016, #04; Tue, 14)

Jeff King writes: > On Wed, Jun 15, 2016 at 09:35:20AM +0200, Elia Pinto wrote: > >> > * ep/http-curl-trace (2016-05-24) 2 commits >> > - imap-send.c: introduce the GIT_TRACE_CURL enviroment variable >> > - http.c: implement the GIT_TRACE_CURL environment variable >> > >> >

Re: [PATCH] diff compaction heuristic: favor shortest neighboring blank lines

On 06/16/2016 07:46 PM, Stefan Beller wrote: > The compaction heuristic for diffs was deemed quite good, but in 5580b27 > we have an example demonstrates a common case, that fails with the existing > heuristic. That is why we disabled the heuristic in the v2.9.0 release. > > With this patch a

Re: [PATCH] diff compaction heuristic: favor shortest neighboring blank lines

On Thu, Jun 16, 2016 at 1:27 PM, Junio C Hamano wrote: >> ... >> because there is less space between line start and {end, def bal} >> than for {do_bal_stuff, common_ending}. > > I haven't thought this carefully yet, but would this equally work > well for Python, where it does

Re: [PATCH 4/4] use smudge-to-file in git checkout etc

Joey Hess wrote: > + int smudge_to_file = can_smudge_to_file(ce->name); > if (ce_mode_s_ifmt == S_IFREG && > + ! smudge_to_file && > convert_to_working_tree(ce->name, new, size, )) { > free(new); >

Re: [PATCH v2 5/6] bisect--helper: `is_expected_rev` & `check_expected_revs` shell function in C

On Thu, Jun 16, 2016 at 9:25 PM, Pranit Bauva wrote: > Hey Eric, > > On Fri, Jun 17, 2016 at 12:46 AM, Eric Sunshine > wrote: >> On Thu, Jun 16, 2016 at 3:05 PM, Pranit Bauva wrote: >>> On Thu, Jun 16, 2016 at 2:44 AM,

Re: [PATCH v2 6/6] bisect--helper: `bisect_write` shell function in C

On Thu, Jun 16, 2016 at 9:01 PM, Pranit Bauva wrote: > Hey Eric, > > On Fri, Jun 17, 2016 at 12:25 AM, Eric Sunshine > wrote: >> On Wed, Jun 15, 2016 at 10:00 AM, Pranit Bauva >> wrote: >>> >>> Note: bisect_write() uses

[PATCH 4/4] use smudge-to-file in git checkout etc

This makes git checkout, git reset, etc use smudge-to-file. Includes test cases. (There's a call to convert_to_working_tree in merge-recursive.c that could also be made to use smudge-to-file as well.) Signed-off-by: Joey Hess --- entry.c | 34

[PATCH 0/4] extend smudge/clean filters with direct file access

As discussed in this thread: http://thread.gmane.org/gmane.comp.version-control.git/294425 This adds smudge-to-file and clean-from-file commands supplimenting the smudge and clean filters. This interface can be much more efficient when operating on large files, because the whole file content does

[PATCH 1/4] clarify %f documentation

It's natural to expect %f to be an actual file on disk; help avoid that mistake. Signed-off-by: Joey Hess --- Documentation/gitattributes.txt | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/Documentation/gitattributes.txt

[PATCH 2/4] add smudge-to-file and clean-from-file filter configuration

This adds new smudge-to-file and clean-from-file filter commands, which are similar to smudge and clean but allow direct access to files on disk. In smudge-to-file and clean-from-file, "%p" is expanded to the path to the file that should be cleaned from, or smudged to. This interface can be much

[PATCH 3/4] use clean-from-file in git add

Includes test cases. Signed-off-by: Joey Hess --- sha1_file.c | 42 -- t/t0021-conversion.sh | 36 2 files changed, 72 insertions(+), 6 deletions(-) diff --git a/sha1_file.c b/sha1_file.c

Re: [PATCH] diff compaction heuristic: favor shortest neighboring blank lines

Stefan Beller writes: > +def bal > +do_bal_stuff() > + > +common_ending() > +end > + > def baz > do_baz_stuff() > > common_ending() > end > > whereas before we had: > > WIP

Re: [bug] assertion in 2.8.4 triggering on old-ish worktree

On Thu, Jun 16, 2016 at 10:59 AM, Junio C Hamano wrote: > Chris Packham writes: > >> On Thu, Jun 16, 2016 at 4:59 PM, Chris Packham >> wrote: >>> Hi All, >>> >>> I have the git-sh-prompt configured in my .bashrc today I

Re: [PATCH v2 5/6] bisect--helper: `is_expected_rev` & `check_expected_revs` shell function in C

Hey Eric, On Fri, Jun 17, 2016 at 12:46 AM, Eric Sunshine wrote: > On Thu, Jun 16, 2016 at 3:05 PM, Pranit Bauva wrote: >> On Thu, Jun 16, 2016 at 2:44 AM, Eric Sunshine >> wrote: >>> On Wed, Jun 15, 2016 at 10:00 AM,

Re: [PATCH v2 5/6] bisect--helper: `is_expected_rev` & `check_expected_revs` shell function in C

On Thu, Jun 16, 2016 at 3:05 PM, Pranit Bauva wrote: > On Thu, Jun 16, 2016 at 2:44 AM, Eric Sunshine > wrote: >> On Wed, Jun 15, 2016 at 10:00 AM, Pranit Bauva >> wrote: >>> Reimplement `is_expected_rev` &

Re: [PATCH v2 4/6] bisect--helper: `bisect_reset` shell function in C

Hey Eric, On Thu, Jun 16, 2016 at 2:35 AM, Eric Sunshine wrote: > On Wed, Jun 15, 2016 at 10:00 AM, Pranit Bauva wrote: >> Reimplement `bisect_reset` shell function in C and add a `--bisect-reset` >> subcommand to `git bisect--helper` to call it

Re: [PATCH v2 5/6] bisect--helper: `is_expected_rev` & `check_expected_revs` shell function in C

Hey Eric, On Thu, Jun 16, 2016 at 2:44 AM, Eric Sunshine wrote: > On Wed, Jun 15, 2016 at 10:00 AM, Pranit Bauva wrote: >> Reimplement `is_expected_rev` & `check_expected_revs` shell function in >> C and add a `--check-expected-revs` subcommand

Re: [PATCH v2 6/6] bisect--helper: `bisect_write` shell function in C

Hey Eric, On Fri, Jun 17, 2016 at 12:25 AM, Eric Sunshine wrote: > On Wed, Jun 15, 2016 at 10:00 AM, Pranit Bauva wrote: >> Reimplement the `bisect_write` shell function in C and add a >> `bisect-write` subcommand to `git bisect--helper` to call

Re: [PATCH] gnome-keyring: Don't hard-code pkg-config executable

On Thu, Jun 16, 2016 at 2:50 AM, Jeff King wrote: > On Tue, Jun 14, 2016 at 01:27:05PM +0200, Heiko Becker wrote: > >> Helpful if your pkg-config executable has a prefix based on the >> architecture, for example. >> >> Signed-off-by: Heiko Becker > > Sounds

Re: [PATCH v2 6/6] bisect--helper: `bisect_write` shell function in C

On Wed, Jun 15, 2016 at 10:00 AM, Pranit Bauva wrote: > Reimplement the `bisect_write` shell function in C and add a > `bisect-write` subcommand to `git bisect--helper` to call it from > git-bisect.sh > > Using `--bisect-write` subcommand is a temporary measure to port

Re: final git bisect step leads to: "fatal: you want to use way too much memory"

Jeff King writes: > Interesting. But `git show` on the commit in question (f216419e5) does > not have any problems. It looks like bisect's internal "show the commit" > code does not properly call setup_revisions() to finalize the "struct > rev_info". That leaves the

Re: [PATCH 0/2] Log pretty format alignment improvements

Nguyễn Thái Ngọc Duy writes: > The first patch was from a long time ago. The concern was it may be > breaking existing user expectation [1]. I still maintain that it's a good > thing to do and should not break anything. Hence the resubmission. I do not think "it's a good

Re: [PATCH 0/7] gpg-interface cleanups

Jeff King writes: > This started off with Michael's patch to sign_buffer, which is at the > tip, and then me trying to address the possible deadlocks there and in > verify_signed_buffer. While I was in the area, I took the opportunity to > do a few cleanups. > > It's unclear to me

Re: [PATCH] grep: fix grepping for "intent to add" files

Duy Nguyen writes: >> You don't think the revert is correct or you don't think the revert is >> sufficient? (I wasn't able to find a test case which proved that the >> change to line 399 was necessary, so perhaps I don't understand.) > > OK insufficient. > >> I would have

Re: [PATCH] grep: fix grepping for "intent to add" files

Charles Bailey writes: > http://thread.gmane.org/gmane.comp.version-control.git/272363/focus=276358 > > http://thread.gmane.org/gmane.comp.version-control.git/283001/focus=283002 > > Unless I've misunderstood the conversation and commit message, the > referenced commit was

Re: [bug] assertion in 2.8.4 triggering on old-ish worktree

Chris Packham writes: > On Thu, Jun 16, 2016 at 4:59 PM, Chris Packham > wrote: >> Hi All, >> >> I have the git-sh-prompt configured in my .bashrc today I visited an >> old worktree that I haven't really touched in a few years (sorry can't >>

Re: [PATCH 0/2] friendlier handling of overflows in archive-tar

Both patches looked good to me. 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

[PATCH] diff compaction heuristic: favor shortest neighboring blank lines

The compaction heuristic for diffs was deemed quite good, but in 5580b27 we have an example demonstrates a common case, that fails with the existing heuristic. That is why we disabled the heuristic in the v2.9.0 release. With this patch a diff looks like: def bar

Re: [PATCH] verify-tag: allow to verify signed blob objects

Michael J Gruber writes: > Currently, there is no easy way to verify push certificates. They have > the same structure as signed tags: "attached detached signatures", that > is: the concatenation of the signed material and its detached signature. > > Introduce a

Re: I lost my commit signature

Jeff King writes: > But why does somebody run "commit -S" for a single commit, but not all > the time? Is it because that commit is special? Or is that particular > moment special? One implies that it's important for the signature to be > retained during a rebase, and one does

Re: [bug] assertion in 2.8.4 triggering on old-ish worktree

On Thu, Jun 16, 2016 at 9:55 AM, Dennis Kaarsemaker wrote: > On do, 2016-06-16 at 17:02 +1200, Chris Packham wrote: >> On Thu, Jun 16, 2016 at 4:59 PM, Chris Packham > om> wrote: >> > >> > Hi All, >> > >> > I have the git-sh-prompt configured in my

Re: [bug] assertion in 2.8.4 triggering on old-ish worktree

On do, 2016-06-16 at 17:02 +1200, Chris Packham wrote: > On Thu, Jun 16, 2016 at 4:59 PM, Chris Packham om> wrote: > > > > Hi All, > > > > I have the git-sh-prompt configured in my .bashrc today I visited > > an > > old worktree that I haven't really touched in a few

Re: [PATCH] add--interactive: respect diff.compactionHeuristic

On Thu, Jun 16, 2016 at 5:27 AM, Jeff King wrote: > On Wed, Jun 15, 2016 at 08:24:47AM +0200, Alex Prengère wrote: > >> I see, it makes sense ;-) Indeed it would seem logical to have all >> commands showing diffs (diff, add -p, log -p, reset -p, etc..) respect >> the diff options.

Re: [bug] assertion in 2.8.4 triggering on old-ish worktree

On Wed, Jun 15, 2016 at 10:02 PM, Chris Packham wrote: > On Thu, Jun 16, 2016 at 4:59 PM, Chris Packham > wrote: >> Hi All, >> >> I have the git-sh-prompt configured in my .bashrc today I visited an >> old worktree that I haven't really touched

Re: final git bisect step leads to: "fatal: you want to use way too much memory"

On Thu, Jun 16, 2016 at 03:29:52PM +0200, Markus Trippelsdorf wrote: > On 2016.06.16 at 14:53 +0200, Markus Trippelsdorf wrote: > > markus@x4 gcc % git bisect good > > f216419e5c4c41df70dbe00a6ea1faea46484dc8 is the first bad commit > > commit f216419e5c4c41df70dbe00a6ea1faea46484dc8 > > fatal:

Re: final git bisect step leads to: "fatal: you want to use way too much memory"

On 2016.06.16 at 14:53 +0200, Markus Trippelsdorf wrote: > markus@x4 gcc % git bisect good > f216419e5c4c41df70dbe00a6ea1faea46484dc8 is the first bad commit > commit f216419e5c4c41df70dbe00a6ea1faea46484dc8 > fatal: you want to use way too much memory > markus@x4 gcc % The issue started with:

[PATCH 2/2] pretty.c: support |() forms

%>|(num), %><|(num) and %<|(num), where num is a positive number, sets a fixed column from the screen's left border. There is no way for us to specifiy a column relative to the right border, which is useful when you want to make use of all terminal space (on big screens). Use negative num for

[PATCH 0/2] Log pretty format alignment improvements

The first patch was from a long time ago. The concern was it may be breaking existing user expectation [1]. I still maintain that it's a good thing to do and should not break anything. Hence the resubmission. The second patch adds negative column specifier to >|() and friends. A positive number

[PATCH 1/2] pretty: pass graph width to pretty formatting for use in '%>|(N)'

From: Josef Kufner Pass graph width to pretty formatting, to make N in '%>|(N)' include columns consumed by graph rendered when --graph option is in use. For example, in the output of git log --all --graph --pretty='format: [%>|(20)%h] %ar%d' this change will make all

Re: final git bisect step leads to: "fatal: you want to use way too much memory"

On 2016.06.16 at 14:53 +0200, Markus Trippelsdorf wrote: > To reproduce the issue, just run: Forget to mention: markus@x4 ~ % git --version git version 2.9.0 git-2.8.4 is fine. -- Markus -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to

final git bisect step leads to: "fatal: you want to use way too much memory"

To reproduce the issue, just run: markus@x4 ~ % git clone git://gcc.gnu.org/git/gcc.git markus@x4 gcc % git checkout -b gcc-6 origin/gcc-6-branch markus@x4 gcc % git bisect bad 23240454adf1 You need to start by "git bisect start" Do you want me to do it for you [Y/n]? y markus@x4 gcc % git

Re: What's cooking in git.git (Jun 2016, #04; Tue, 14)

On Wed, Jun 15, 2016 at 09:35:20AM +0200, Elia Pinto wrote: > > * ep/http-curl-trace (2016-05-24) 2 commits > > - imap-send.c: introduce the GIT_TRACE_CURL enviroment variable > > - http.c: implement the GIT_TRACE_CURL environment variable > > > > HTTP transport gained an option to produce

[PATCH] add--interactive: respect diff.compactionHeuristic

On Wed, Jun 15, 2016 at 08:24:47AM +0200, Alex Prengère wrote: > I see, it makes sense ;-) Indeed it would seem logical to have all > commands showing diffs (diff, add -p, log -p, reset -p, etc..) respect > the diff options. Here's a patch to do so, similar to what we do for diff.algorithm. --

Re: URL rewrite in local config unable to override global config rule

On Thu, Jun 16, 2016 at 03:44:17PM +0530, Saksham Saxena wrote: > Summary : Added a new rule to the local config of a git repo by > issuing ' git config --local url."https://".insteadOf git:// ', but it > wasn't observed by git as it kept using "git://". Hmm. This works in a simple example for

Re: Code review tool recommendations - replacement for crucible?

On Thu, 16 Jun 2016 11:55:56 +, Richard Ipsum wrote: ... > Have you considered Gerrit[1] already? > It would seem to handle the cases you're interested in. Possible, but only after a lot of user education. We don't currently rewrite commits for review comments, and neither can we get (all)

Re: [PATCH] grep: fix grepping for "intent to add" files

On Thu, Jun 16, 2016 at 6:44 PM, Charles Bailey wrote: > On Thu, Jun 16, 2016 at 05:57:18PM +0700, Duy Nguyen wrote: >> >> "git grep --cached" searches file content that will be committed by >> "git commit" (no -a). An i-t-a entry will not be committed (you would >> need

Re: [PATCH] grep: fix grepping for "intent to add" files

On Thu, Jun 16, 2016 at 05:57:18PM +0700, Duy Nguyen wrote: > > "git grep --cached" searches file content that will be committed by > "git commit" (no -a). An i-t-a entry will not be committed (you would > need "git add" first, or do "git commit -a"). So if I say "search > among the

Re: [PATCHv3] gpg-interface: check gpg signature creation status

Jeff King venit, vidit, dixit 16.06.2016 11:25: > On Wed, Jun 15, 2016 at 09:17:54AM +0200, Michael J Gruber wrote: > >> As for the flexibility: >> We do code specifically for gpg, which happens to work for gpg2 also. >> The patch doesn't add any gpg ui requirements that we don't require >>

core.fscache on Windows trashes system

Hello List, We use git in our company and found a problem with the version 2.8.3 (x64 and x86). After installing git, with activated file system caching on Windows 8.1 Enterprise, on the first use of git there a git.exe processes started again and again. Multiple thousands instances are

Re: [PATCH] grep: fix grepping for "intent to add" files

On Thu, Jun 16, 2016 at 4:47 PM, Charles Bailey wrote: > On Thu, Jun 16, 2016 at 02:47:09PM +0700, Duy Nguyen wrote: >> I don't think revert is right. It rather needs a re-fix like below. >> Basically we want grep_file() to run as normal, but grep_sha1() >> (i.e. git grep

Re: Code review tool recommendations - replacement for crucible?

On Thu, Jun 16, 2016 at 11:41:08AM +0200, Andreas Krey wrote: > Hi all, > > I'm looking for pointers to review tools that work with git (obviously), > and can deal sensibly with bigger reviews. Things we need: > > - Ability to split (set of) commits into multiple reviews, > so parts of changes

URL rewrite in local config unable to override global config rule

Hello everyone I came across an anomaly in git recently, and would like to share it here. Please suggest if this is a bug, or if my approach is wrong. Summary : Added a new rule to the local config of a git repo by issuing ' git config --local url."https://".insteadOf git:// ', but it wasn't

Re: Un-paged commit messages in git filter-branch's commit-filter?

On Mon, Jun 13, 2016 at 08:28:18AM +0200, Stefan Tauner wrote: > I am trying to do a major cleanup of the repository in one of my > projects (and switch from git-svn to native git). I have developed a > commit-filter script over the last months that massages partially > dreadful commit messages

Re: [PATCH] gnome-keyring: Don't hard-code pkg-config executable

On Tue, Jun 14, 2016 at 01:27:05PM +0200, Heiko Becker wrote: > Helpful if your pkg-config executable has a prefix based on the > architecture, for example. > > Signed-off-by: Heiko Becker Sounds like a reasonable thing to want to do... > diff --git

Re: [PATCH] grep: fix grepping for "intent to add" files

On Thu, Jun 16, 2016 at 02:47:09PM +0700, Duy Nguyen wrote: > I don't think revert is right. It rather needs a re-fix like below. > Basically we want grep_file() to run as normal, but grep_sha1() > (i.e. git grep --cached) should ignore i-t-a entries, because empty > SHA-1 is not the right content

Re: bug: compactionheuristic config var case issue

On Wed, Jun 15, 2016 at 07:33:31PM +0700, Duy Nguyen wrote: > On Wed, Jun 15, 2016 at 5:39 PM, Brian Lalor wrote: > > I’m very happy to see the new compaction heuristic option; it’s the way I > > always thought diffs should read! > > > > The config option in the documentation

[PATCH 7/7] gpg-interface: check gpg signature creation status

When we create a signature, it may happen that gpg returns with "success" but not with an actual detached signature on stdout. Check for the correct signature creation status to catch these cases better. Really, --status-fd parsing is the only way to check gpg status reliably. We do the same for

Code review tool recommendations - replacement for crucible?

Hi all, I'm looking for pointers to review tools that work with git (obviously), and can deal sensibly with bigger reviews. Things we need: - Ability to split (set of) commits into multiple reviews, so parts of changes can be reviewed by the respective owners (or assign different reviewers

[PATCH 6/7] sign_buffer: use pipe_command

Similar to the prior commit for verify_signed_buffer, the motivation here is both to make the code simpler, and to avoid any possible deadlocks with gpg. In this case we have the same "write to stdin, then read from stdout" that the verify case had. This is unlikely to be a problem in practice,

[PATCH 5/7] verify_signed_buffer: use pipe_command

This is shorter and should make the function easier to follow. But more importantly, it removes the possibility of any deadlocks based on reading or writing to gpg. It's not clear if such a deadlock is possible in practice. We do write the whole payload before reading anything, so we could

[PATCH 4/7] run-command: add pipe_command helper

We already have capture_command(), which captures the stdout of a command in a way that avoids deadlocks. But sometimes we need to do more I/O, like capturing stderr as well, or sending data to stdin. It's easy to write code that deadlocks racily in these situations depending on how fast the

[PATCH 3/7] verify_signed_buffer: use tempfile object

We use git_mkstemp to create a temporary file, and try to clean it up in all exit paths from the function. But that misses any cases where we die by signal, or by calling die() in a sub-function. In addition, we missed one of the exit paths. Let's convert to using a tempfile object, which handles

[PATCH 2/7] verify_signed_buffer: drop pbuf variable

If our caller gave us a non-NULL gpg_status parameter, we write the gpg status into their strbuf. If they didn't, then we write it to a temporary local strbuf (since we still need to look at it). The variable "pbuf" adds an extra layer of indirection so that the rest of the function can just

[PATCH 1/7] gpg-interface: use child_process.args

Our argv allocations are relatively straightforward, but this avoids us having to manually keep the count up to date (or create new to-be-replaced slots in the declaration) when we add new arguments. Signed-off-by: Jeff King --- gpg-interface.c | 19 +-- 1 file

[PATCH 0/7] gpg-interface cleanups

This started off with Michael's patch to sign_buffer, which is at the tip, and then me trying to address the possible deadlocks there and in verify_signed_buffer. While I was in the area, I took the opportunity to do a few cleanups. It's unclear to me whether the deadlocks are possible in

Re: [PATCHv3] gpg-interface: check gpg signature creation status

On Wed, Jun 15, 2016 at 09:17:54AM +0200, Michael J Gruber wrote: > As for the flexibility: > We do code specifically for gpg, which happens to work for gpg2 also. > The patch doesn't add any gpg ui requirements that we don't require > elsewhere already. > More flexibility requires a completely

Re: [PATCH] grep: fix grepping for "intent to add" files

On Thu, Jun 16, 2016 at 07:53:24AM +0100, Charles Bailey wrote: > From: Charles Bailey > > This reverts commit 4d552005323034c1d6311796ac1074e9a4b4b57e. > > This commit caused 'git grep' to no longer find matches in new files in > the working tree where the

Re: I lost my commit signature

On Wed, Jun 15, 2016 at 09:07:16AM +0200, Michael J Gruber wrote: > > Ah, so the problem is probably that you had a signature _initially_, but > > that it did not survive the rebase. Which makes sense, as rebase would > > need to re-sign. It does not by default, but you can tell it to do so > >

Issue with subtree split in git version post 2.7.X on MAC

Hi, I am trying to extract part of larger git repo to create a new smaller repo maintaining al the history of the extracted portion. For this I used git subtree split command. Following are the steps followed: 1. git clone of full repo in 'full_rep' dir 2. Initialised new empty target repo:

Re: [PATCH v8 2/3] bisect: rewrite `check_term_format` shell function in C

On 24 May 2016, at 09:21, Pranit Bauva wrote: > Reimplement the `check_term_format` shell function in C and add > a `--check-term-format` subcommand to `git bisect--helper` to call it > from git-bisect.sh > > Using `--check-term-format` subcommand is a temporary measure

[PATCH] grep: fix grepping for "intent to add" files

From: Charles Bailey This reverts commit 4d552005323034c1d6311796ac1074e9a4b4b57e. This commit caused 'git grep' to no longer find matches in new files in the working tree where the corresponding index entry had the "intent to add" bit set. Add tests to cover this case