[PATCH] Document the 'svn propset' command.

Add example usage to the git-svn documentation. Reported-by: Joseph Pecoraro Signed-off-by: Alfred Perlstein --- Junio, Pranit, + all, A week ago I was requested to provide documentation for the 'svn propset' command. I have attached a diff off of the

Re: I lost my commit signature

On Wed, Jun 15, 2016 at 12:27:15PM +0800, ZhenTian wrote: > I got two more lines from gpg -v during commit with -S: > ``` > gpg: writing to stdout > gpg: RSA/SHA1 signature from: "2EF2AD6E Tian Zhen " > ``` > > after I commit, I push it to remote, but someone had pushed

Re: I lost my commit signature

Hi Michael and Peff, I got two more lines from gpg -v during commit with -S: ``` gpg: writing to stdout gpg: RSA/SHA1 signature from: "2EF2AD6E Tian Zhen " ``` after I commit, I push it to remote, but someone had pushed before to master branch, so I pull on master

Re: [PATCH] fetch: document that pruning happens before fetching

On Tue, Jun 14, 2016 at 05:36:35PM +0700, Duy Nguyen wrote: > > or what would happen if the packfile > > fetch failed (we'd already have deleted the old refs, but wouldn't fetch > > the new ones). > > Off topic, but this sounds like a bug to me. We could have kept ref > update more consistent

Re: [PATCH v2] Refactor recv_sideband()

On Tue, Jun 14, 2016 at 02:25:42PM -0700, Junio C Hamano wrote: > > Also, reorganize the overall control flow, remove some superfluous > > variables and replace a custom implementation of strpbrk() with a call > > to the standard C library function. > > I find that calling the loop "a custom

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

On Tue, Jun 14, 2016 at 06:26:33PM -0400, Jeff King wrote: > > > > bottom = signature->len; > > > > - len = strbuf_read(signature, gpg.out, 1024); > > > > + strbuf_read(signature, gpg.out, 1024); > > > > + strbuf_read(, gpg.err, 0); > > > > > > H, isn't this asking

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

On Tue, Jun 14, 2016 at 03:08:04PM -0700, Junio C Hamano wrote: > 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

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

On Tue, Jun 14, 2016 at 04:47:35PM -0700, Junio C Hamano wrote: > Jeff King writes: > > > I'm still undecided on whether it is a better approach than making > > sure the stdout we got looks sane. In particular I'd worry that it > > would make things harder for somebody trying to

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

Jeff King writes: > I'm still undecided on whether it is a better approach than making > sure the stdout we got looks sane. In particular I'd worry that it > would make things harder for somebody trying to plug in something > gpg-like (e.g., if you wanted to do something exotic

Re: [PATCH v4 6/6] send-email: add option --cite to quote the message body

On 06/09/2016 01:49 PM, Matthieu Moy wrote: Samuel GROOT writes: If used with `in-reply-to=`, cite the message body of the given email file. Otherwise, do nothing. It should at least warn when --in-reply-to= is not given (either no --in-reply-to or

Re: [PATCH v4 5/6] send-email: --in-reply-to= populate header fields

On 06/09/2016 11:45 AM, Matthieu Moy wrote: Samuel GROOT writes: diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt index edbba3a..21776f0 100644 --- a/Documentation/git-send-email.txt +++ b/Documentation/git-send-email.txt @@

Re: [PATCH v4 5/6] send-email: --in-reply-to= populate header fields

On 06/08/2016 08:23 PM, Junio C Hamano wrote: Samuel GROOT writes: +if ($initial_reply_to && -f $initial_reply_to) { + my $error = validate_patch($initial_reply_to); This call is wrong, isn't it? You are not going to send out the message you are

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

On Tue, Jun 14, 2016 at 05:50:19PM -0400, Jeff King wrote: > On Tue, Jun 14, 2016 at 11:13:54AM -0700, Junio C Hamano wrote: > > > Michael J Gruber writes: > > > > > bottom = signature->len; > > > - len = strbuf_read(signature, gpg.out, 1024); > > > +

Re: [PATCH v4 4/6] send-email: create email parser subroutine

On 06/14/2016 12:47 AM, Eric Wong wrote: Samuel GROOT wrote: On 06/09/2016 02:21 AM, Eric Wong wrote: Samuel GROOT wrote: Email::Simple library uses qr/\x0a\x0d|\x0d\x0a|\x0a|\x0d/ [1]. Should we handle \n\r at end of line as

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

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. Git 2.9 has been tagged. Let's

Re: [ANNOUNCE] Sharness v1.0.0

Jeff King writes: > Yeah, I don't think it has kept up with our work. My statement above was > "I don't think we'd _ever_ want to consider sharness the upstream, even > if it were up to date", but obviously there would be a lot of work to > even get it there. I actually was a lot

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

On Tue, Jun 14, 2016 at 11:13:54AM -0700, Junio C Hamano wrote: > Michael J Gruber writes: > > > bottom = signature->len; > > - len = strbuf_read(signature, gpg.out, 1024); > > + strbuf_read(signature, gpg.out, 1024); > > + strbuf_read(, gpg.err, 0); > >

Re: [ANNOUNCE] Sharness v1.0.0

On Tue, Jun 14, 2016 at 02:43:19PM -0700, Junio C Hamano wrote: > Jeff King writes: > > > I don't think the Git project would ever want to say "sharness is the > > upstream, and we are now just a user of it". But I wonder if we could > > break down test-lib.sh to keep the

Re: compactionHeuristic=true is not used by interactive staging

Jeff King writes: > Nobody noticed so far because originally the compaction heuristic was on > by default, and so just worked everywhere. But we backed off on that at > the last minute after finding a few cases where the diff looks worse. Yup, and that is why this is called

Re: [ANNOUNCE] Sharness v1.0.0

Jeff King writes: > I don't think the Git project would ever want to say "sharness is the > upstream, and we are now just a user of it". But I wonder if we could > break down test-lib.sh to keep the Git-specific parts separate, which > would make it easier for sharness to pull the

Re: compactionHeuristic=true is not used by interactive staging

On Tue, Jun 14, 2016 at 04:22:54PM +0200, Alex Prengère wrote: > Hello, > I just did a fresh clone of git from Github and installed the version > 2.9.0 on Fedora 22. > > I tried the new compactionHeuristic = true, which is awesome. > The only thing that struck me was that this option was not

Re: 'untracked working tree files would be overwritten by merge' on ignored files?

On Tue, 14 Jun 2016 10:06:16 +, Junio C Hamano wrote: ... > > IIRC, untracked files are kept during merge and across checking out > another branch. Files that are deliberately marked as ignored by > listing them to .gitignore mechanism are considered expendable, and > they will be removed as

Re: [ANNOUNCE] Sharness v1.0.0

On Tue, Jun 14, 2016 at 09:34:17PM +0200, Christian Couder wrote: > Version 1.0.0 of Sharness [1] -- the test harness library derived from > Git's test lib -- is released. Cool. Git's test harness is something I really miss having in other projects. I'm glad this project exists. :) > This

Re: [PATCH v2] Refactor recv_sideband()

Lukas Fleischer writes: Lukas Fleischer writes: > Improve the readability of recv_sideband() significantly by replacing s/significantly //; "making it readable" is already a subjective goodness criterion, and you do not have to make it sound even more

Re: [PATCH] do not loop around deref_tag()

On Tue, Jun 14, 2016 at 01:28:39PM -0700, Junio C Hamano wrote: > These callers appear to expect that deref_tag() is to peel one layer > of a tag, but the function does not work that way; it has its own > loop to unwrap tags until an object that is not a tag appears. Looks obviously correct.

Re: [ANNOUNCE] Sharness v1.0.0

On Tue, Jun 14, 2016 at 9:48 PM, Stefan Beller wrote: > On Tue, Jun 14, 2016 at 12:34 PM, Christian Couder > wrote: >> >> Sharness was first announced on this list in July 2012 [4]. It was >> created from Git's test lib in April 2011 by Mathias

Re: [PATCH v2] Refactor recv_sideband()

On Tue, 14 Jun 2016 at 23:00:38, Lukas Fleischer wrote: > Improve the readability of recv_sideband() significantly by replacing > fragile buffer manipulations with string buffers and more sophisticated > format strings. Note that each line is printed using a single write() > syscall to avoid

[PATCH v2] Refactor recv_sideband()

Improve the readability of recv_sideband() significantly by replacing fragile buffer manipulations with string buffers and more sophisticated format strings. Note that each line is printed using a single write() syscall to avoid garbled output when multiple processes write to stderr in parallel,

[PATCH] do not loop around deref_tag()

These callers appear to expect that deref_tag() is to peel one layer of a tag, but the function does not work that way; it has its own loop to unwrap tags until an object that is not a tag appears. Signed-off-by: Junio C Hamano --- builtin/blame.c | 6 ++ line-log.c

Re: [PATCH] Refactor recv_sideband()

On Tue, 14 Jun 2016, Lukas Fleischer wrote: > On Tue, 14 Jun 2016 at 19:55:06, Nicolas Pitre wrote: > > It is not buffered as it writes to stderr. And some C libs do separate > > calls to write() for every string format specifier. So "%s%s%c" may end > > up calling write() 3 times depending on

Re: [ANNOUNCE] Sharness v1.0.0

On Tue, Jun 14, 2016 at 12:34 PM, Christian Couder wrote: > Hi, > > Version 1.0.0 of Sharness [1] -- the test harness library derived from > Git's test lib -- is released. > > This release contains many upstream fixes and improvements from Git > and a lot of specific

[ANNOUNCE] Sharness v1.0.0

Hi, Version 1.0.0 of Sharness [1] -- the test harness library derived from Git's test lib -- is released. This release contains many upstream fixes and improvements from Git and a lot of specific user contributed features [2]. It's the first release since v0.3.0 in April 2013 [3]. Sharness was

Re: [PATCH] Refactor recv_sideband()

Lukas Fleischer writes: > One possible solution is using strbuf and constructing the message as we > did before. However, that still relies on fprintf() only calling write() > once per format specifier. While that is probably true for all existing > implementations, I don't

Re: [PATCH] Refactor recv_sideband()

On Tue, 14 Jun 2016 at 20:11:12, Junio C Hamano wrote: > Nicolas Pitre writes: > > > It is not buffered as it writes to stderr. And some C libs do separate > > calls to write() for every string format specifier. So "%s%s%c" may end > > up calling write() 3 times depending on

Re: [PATCH v2 1/1] Don't free remote->name after fetch

Keith McGuigan writes: > Yeah that was the only place I found where it was doing the strdup > already (and in that situation, it has to). All the other places just > grabbed remote->name. > > Yes, sorry, I can sign off on this. Do you want me to resend with the >

Re: [PATCH v2 1/1] Don't free remote->name after fetch

Yeah that was the only place I found where it was doing the strdup already (and in that situation, it has to). All the other places just grabbed remote->name. Yes, sorry, I can sign off on this. Do you want me to resend with the header in place, or is this confirmation good enough? -- - Keith

Re: [PATCH v2 1/1] Don't free remote->name after fetch

kmcgui...@twopensource.com writes: > From: Keith McGuigan > > Make fetch's string_list of remote names owns all of its string items > (strdup'ing when necessary) so that it can deallocate them safely when > clearing. > > --- OK. When I pointed out the call to

[PATCH] blame: dwim "blame --reverse OLD" as "blame --reverse OLD.."

Instead of always requiring both ends of a range, we could DWIM "OLD", which could be a misspelt "OLD..", to be a range that ends at the current commit. Signed-off-by: Junio C Hamano --- * I am not convinced that this is a good change, though. It is true that there is no

[PATCH v2 1/1] Don't free remote->name after fetch

From: Keith McGuigan Make fetch's string_list of remote names owns all of its string items (strdup'ing when necessary) so that it can deallocate them safely when clearing. --- builtin/fetch.c | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git

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

Michael J Gruber writes: > bottom = signature->len; > - len = strbuf_read(signature, gpg.out, 1024); > + strbuf_read(signature, gpg.out, 1024); > + strbuf_read(, gpg.err, 0); H, isn't this asking for a deadlock? When GPG spews more than what

Re: [PATCH] Refactor recv_sideband()

Nicolas Pitre writes: > It is not buffered as it writes to stderr. And some C libs do separate > calls to write() for every string format specifier. So "%s%s%c" may end > up calling write() 3 times depending on the implementation. The example > I gave in commit ed1902ef5c

Re: [PATCH] Refactor recv_sideband()

On Tue, 14 Jun 2016, Lukas Fleischer wrote: > Hi Nicolas, > > On Tue, 14 Jun 2016 at 19:09:15, Nicolas Pitre wrote: > > I just looked again at all the contraptions _I_ wrote (not Junio's) for > > a reason why I went to such extremes in making this code co complicated. > > > > One aspect that

Re: [PATCH 1/1] Don't free remote->name after fetch

Keith McGuigan writes: > As an alternative, I could xstrdup each instance where remote->name is > appended, > which would make the string_list a homogenous dup'd list, which we > could then free. Yeah, I think that is the right way to fix it, even though I agree

Re: [PATCH v7 02/40] builtin/apply: make apply_patch() return -1 instead of die()ing

Christian Couder writes: >> Before this patch, the program said "fatal: $message" and exited >> with status = 128. All these changes in this step modifies the >> external behaviour and make it say "error: $message" and exit with >> status = 1 (at least the caller in

[PATCH v2] blame: improve diagnosis for "--reverse NEW"

"git blame --reverse OLD..NEW -- PATH" tells us to start from the contents in PATH at OLD and observe how each line is changed while the history developers up to NEW, and report for each line the latest commit up to which the line survives in the original form. If you say "git blame --reverse NEW

[PATCH] blame: improve diagnosis for "--reverse NEW"

"git blame --reverse OLD..NEW -- PATH" tells us to start from the contents in PATH at OLD and observe how each line is changed while the history developers up to NEW, and report for each line the latest commit up to which the line survives in the original form. If you say "git blame --reverse NEW

Re: problems installing GIT on my MAC OS X 10.11.5

On Tue, 14 Jun 2016 17:49:50 +0100 Maria Jose Fernandez wrote: > I am very sorry but I am not understanding what you are saying. > I will try with homebrew and see if it works that way. Torstean means: 1. Using the Finder, locate the Terminal application and run

Re: [PATCH] Refactor recv_sideband()

On Mon, 13 Jun 2016, Nicolas Pitre wrote: > On Mon, 13 Jun 2016, Lukas Fleischer wrote: > > > Improve the readability of recv_sideband() significantly by replacing > > fragile buffer manipulations with more sophisticated format strings. > > Also, reorganize the overall control flow, remove some

Re: 'untracked working tree files would be overwritten by merge' on ignored files?

Andreas Krey writes: > when I have an ignored file in my workspace, is git > then also assumed not to remove it in the course > of a merge? IIRC, untracked files are kept during merge and across checking out another branch. Files that are deliberately marked as ignored by

Re: problems installing GIT on my MAC OS X 10.11.5

I am very sorry but I am not understanding what you are saying. I will try with homebrew and see if it works that way. > On 14 Jun 2016, at 17:48, Torsten Bögershausen wrote: > > On 14.06.16 18:45, Maria Jose Fernandez wrote: >> From http://git-scm.com/download/mac I clicked to

Re: problems installing GIT on my MAC OS X 10.11.5

On 14.06.16 18:45, Maria Jose Fernandez wrote: > From http://git-scm.com/download/mac I clicked to download manually. > Then it goes to > https://sourceforge.net/projects/git-osx-installer/files/git-2.8.1-intel-universal-mavericks.dmg/download?use_mirror=autoselect > I found the git -

Re: [PATCH] Refactor recv_sideband()

On Tue, 14 Jun 2016, Johannes Schindelin wrote: > Hi Nico, > > On Tue, 14 Jun 2016, Nicolas Pitre wrote: > > > On Tue, 14 Jun 2016, Johannes Schindelin wrote: > > > > > On Mon, 13 Jun 2016, Nicolas Pitre wrote: > > > > > > > On Mon, 13 Jun 2016, Lukas Fleischer wrote: > > > > > > > > >

'untracked working tree files would be overwritten by merge' on ignored files?

Hi all, when I have an ignored file in my workspace, is git then also assumed not to remove it in the course of a merge? Shouldn't it then say that the file is ignored, as it does not show up in the untracked section of git status? Regards, Andreas PS: Test script (will remove anything named

Re: problems installing GIT on my MAC OS X 10.11.5

On 14.06.16 18:06, Konstantin Khomoutov wrote: > On Tue, 14 Jun 2016 16:56:15 +0100 > Maria Jose Fernandez wrote: > >> I am doing a data science course and need to download GIT but for >> some reason I can’t installed it. I called Apple but they couldn’t >> help and

Re: problems installing GIT on my MAC OS X 10.11.5

On Tue, 14 Jun 2016 16:56:15 +0100 Maria Jose Fernandez wrote: > I am doing a data science course and need to download GIT but for > some reason I can’t installed it. I called Apple but they couldn’t > help and suggested me to contact you guys. So you proceeded to

problems installing GIT on my MAC OS X 10.11.5

Hello, I am doing a data science course and need to download GIT but for some reason I can’t installed it. I called Apple but they couldn’t help and suggested me to contact you guys. I hope you can help me. Thank you very much, Maria Jose Freeman-- To unsubscribe from this list: send the

Re: [PATCH] Refactor recv_sideband()

Hi Nico, On Tue, 14 Jun 2016, Nicolas Pitre wrote: > On Tue, 14 Jun 2016, Johannes Schindelin wrote: > > > On Mon, 13 Jun 2016, Nicolas Pitre wrote: > > > > > On Mon, 13 Jun 2016, Lukas Fleischer wrote: > > > > > > > Improve the readability of recv_sideband() significantly by > > > >

Re: [PATCH] Refactor recv_sideband()

On Tue, 14 Jun 2016, Johannes Schindelin wrote: > Hi, > > On Mon, 13 Jun 2016, Nicolas Pitre wrote: > > > On Mon, 13 Jun 2016, Lukas Fleischer wrote: > > > > > Improve the readability of recv_sideband() significantly by replacing > > > fragile buffer manipulations with more sophisticated

[PATCHv3] 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

[PATCH 1/2] Make send_sideband() return void

The send_sideband() function uses write_or_die() for writing data which immediately terminates the process on errors. If no such error occurred, send_sideband() always returned the value that was passed as fourth parameter prior to this commit. This value is already known to the caller in any

[PATCH 2/2] Make send_client_data() return void

The send_client_data() function uses write_or_die() for writing data which immediately terminates the process on errors. If no such error occurred, send_client_data() always returned the value that was passed as third parameter prior to this commit. This value is already known to the caller in any

compactionHeuristic=true is not used by interactive staging

Hello, I just did a fresh clone of git from Github and installed the version 2.9.0 on Fedora 22. I tried the new compactionHeuristic = true, which is awesome. The only thing that struck me was that this option was not used when doing an interactive staging, meaning `git diff` and `git add -p`

Re: [PATCH] Refactor recv_sideband()

Hi, On Mon, 13 Jun 2016, Nicolas Pitre wrote: > On Mon, 13 Jun 2016, Lukas Fleischer wrote: > > > Improve the readability of recv_sideband() significantly by replacing > > fragile buffer manipulations with more sophisticated format strings. > > Also, reorganize the overall control flow, remove

[PATCHv2] gpg-interface: check gpg signature for correct header

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 header to catch these cases better. We use the same parse_signature function for that that we use otherwise, so that gpg specifics are localised

Re: [PATCH] gpg-interface: check gpg signature for correct header

Michael J Gruber venit, vidit, dixit 14.06.2016 13:34: > Jeff King venit, vidit, dixit 14.06.2016 13:20: >> On Tue, Jun 14, 2016 at 01:11:19PM +0200, Michael J Gruber wrote: >> >>> When we create a signature, it may happen that gpg returns with >>> "success" but not with an actual detached

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

Helpful if your pkg-config executable has a prefix based on the architecture, for example. Signed-off-by: Heiko Becker --- contrib/credential/gnome-keyring/Makefile | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git

Re: [PATCH] gpg-interface: check gpg signature for correct header

Jeff King venit, vidit, dixit 14.06.2016 13:20: > On Tue, Jun 14, 2016 at 01:11:19PM +0200, Michael J Gruber wrote: > >> 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 header to catch

Re: [PATCH] gpg-interface: check gpg signature for correct header

On Tue, Jun 14, 2016 at 01:11:19PM +0200, Michael J Gruber wrote: > 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 header to catch these cases better. Seems like a reasonable idea. I do

[ANNOUNCE] Git for Windows 2.9.0

Dear Git users, It is my pleasure to announce that Git for Windows 2.9.0 is available from: https://git-for-windows.github.io/ Changes since Git for Windows v2.8.4 (June 7th 2016) Bug Fixes ??? When running git gc --aggressive or git repack -ald in the presence of multiple pack

[PATCH] gpg-interface: check gpg signature for correct header

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 header to catch these cases better. Signed-off-by: Michael J Gruber --- This catches at least my echo example. We

Re: [PATCH v7 01/40] apply: move 'struct apply_state' to apply.h

On Tue, Jun 14, 2016 at 12:49 AM, Junio C Hamano wrote: > Christian Couder writes: > >> To libify `git apply` functionality we must make 'struct apply_state' >> usable outside "builtin/apply.c". >> >> Let's do that by creating a new "apply.h" and

Re: [PATCH v7 02/40] builtin/apply: make apply_patch() return -1 instead of die()ing

On Tue, Jun 14, 2016 at 12:55 AM, Junio C Hamano wrote: > Christian Couder writes: > >> +/* >> + * Try to apply a patch. >> + * >> + * Returns: >> + * -1 if an error happened >> + * 0 if the patch applied >> + * 1 if the patch did not apply >>

Re: [PATCH] fetch: document that pruning happens before fetching

On Tue, Jun 14, 2016 at 5:22 PM, Jeff King wrote: > I think the documentation should be updated either way. This is not > about the ordering in the status table, but rather about the order of > the real operations. The user may care about that ordering if they want > to know what

Re: I lost my commit signature

On Tue, Jun 14, 2016 at 04:39:38PM +0800, ZhenTian wrote: > I want to set gpg -v to pgp.program, but if I set it, it can't call gpg: > ``` > error: cannot run gpg -v: No such file or directory > error: could not run gpg. > fatal: failed to write commit object > ``` > > I have tried set

Re: [PATCH] fetch: document that pruning happens before fetching

On Tue, Jun 14, 2016 at 6:58 AM, Jeff King wrote: > This was changed in 10a6cc8 (fetch --prune: Run prune before > fetching, 2014-01-02), but it seems that nobody in that > discussion realized we were advertising the "after" > explicitly. Ah... ok. Good to know it's moved up top

Re: [PATCH 00/27] nd/shallow-deepen updates

On Tue, Jun 14, 2016 at 12:10 AM, Junio C Hamano wrote: > Eric Sunshine writes: > >> I agree with Junio that moving the sigchain_pop() into the error >> handling code-path, if possible, would be a nice improvement. > > Yeah, "if possible" is really

Re: I lost my commit signature

Hi Peff, I want to set gpg -v to pgp.program, but if I set it, it can't call gpg: ``` error: cannot run gpg -v: No such file or directory error: could not run gpg. fatal: failed to write commit object ``` I have tried set gpg.program value to `gpg|/tmp/log`, `/usr/bin/gpg -v`, `gpg -v`,

[TIG PATCH] test: make diff/log work with git 2.9

git 2.9.0 switches the default for diff.renames to true. Set this to false in config so that the test suite runs unmodified for old and new git. Signed-off-by: Michael J Gruber --- test/tools/libgit.sh | 1 + 1 file changed, 1 insertion(+) diff --git

Re: I lost my commit signature

On Tue, Jun 14, 2016 at 04:09:52PM +0800, ZhenTian wrote: > I have tested sign my work in another project, it works fine, I have > committed five times, all commits are signed. > > I can't find encoded signature block in the output of "git cat-file > commit HEAD", only these: > ``` > tree

Re: I lost my commit signature

Hi Peff, I commit via this command: gcs -nm "feat: mobile support free freight hint, closed #1417" gcs is an alias in zsh, which is: git commit -S I have tested sign my work in another project, it works fine, I have committed five times, all commits are signed. I can't find encoded signature

Re: I lost my commit signature

On Tue, Jun 14, 2016 at 03:50:43PM +0800, ZhenTian wrote: > I commit with -S argument, and I got some output like this: > > You need a passphrase to unlock the secret key for > user: "Tian Zhen " > 4096-bit RSA key, ID 2EF2AD6E, created 2016-05-21 > > [master d107770]

Re: [PATCH 1/1] Don't free remote->name after fetch

On Mon, Jun 13, 2016 at 08:14:43PM -0400, Keith McGuigan wrote: > Right. The string_list ends up getting (potentially) populated with a > mix of dup'd and borrowed values. I figured it was safer to leak here > (especially as we're on the way out anyway), than free memory that > shouldn't be

I lost my commit signature

Hi git developers, I commit with -S argument, and I got some output like this: You need a passphrase to unlock the secret key for user: "Tian Zhen " 4096-bit RSA key, ID 2EF2AD6E, created 2016-05-21 [master d107770] feat: mobile support free freight hint, closed #1417

Re: [PATCH] fetch: document that pruning happens before fetching

On Mon, Jun 13, 2016 at 11:17 PM, Jeff King wrote: > On Mon, Jun 13, 2016 at 11:14:36PM -0700, Jacob Keller wrote: > >> On Mon, Jun 13, 2016 at 4:58 PM, Jeff King wrote: >> > This was changed in 10a6cc8 (fetch --prune: Run prune before >> > fetching, 2014-01-02),

Re: [PATCH] fetch: document that pruning happens before fetching

On Mon, Jun 13, 2016 at 11:14:36PM -0700, Jacob Keller wrote: > On Mon, Jun 13, 2016 at 4:58 PM, Jeff King wrote: > > This was changed in 10a6cc8 (fetch --prune: Run prune before > > fetching, 2014-01-02), but it seems that nobody in that > > discussion realized we were

[PATCH v2] strbuf: describe the return value of strbuf_read_file

Mentored-by: Lars Schneider Mentored-by: Christian Couder Signed-off-by: Pranit Bauva --- strbuf.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/strbuf.h b/strbuf.h index 7987405..83c5c98 100644 --- a/strbuf.h

Re: [PATCH] fetch: document that pruning happens before fetching

On Mon, Jun 13, 2016 at 4:58 PM, Jeff King wrote: > This was changed in 10a6cc8 (fetch --prune: Run prune before > fetching, 2014-01-02), but it seems that nobody in that > discussion realized we were advertising the "after" > explicitly. > > Signed-off-by: Jeff King