Re: [PATCH] make config --add behave correctly for empty and NULL values

Jeff King p...@peff.net writes: I just used #define CONFIG_REGEX_NONE ((void *)1) as my magic sentinel value, both for the string and compiled regex versions. Adding a bit to the store struct is a lot less disgusting and error-prone. So I won't share mine here. :) Actually, I wrote

Issuing warning when hook does not have execution permission

Hi, I saw that if a hook file is present in .git/hooks and it does not have execution permissions it is silently ignored. I thought it might be worthwhile issuing a warning such as Warning: pre-commit hook exists but it cannot be executed due to insufficient permissions. Not sure if this has

Re: make profile issue on Git 2.1.0

On Sun, Aug 17, 2014 at 09:35:29PM -0500, Andrés Sicard-Ramírez wrote: I have the following issue on Git 2.1.0: $ make prefix=/some-directory profile ... make[2]: Entering directory `/home/asr/src/git/git-2.1.0/t/perf' rm -rf test-results ./run === Running 9 tests in this tree ===

Re: [PATCH] make config --add behave correctly for empty and NULL values

On Mon, Aug 18, 2014 at 11:03:51PM -0700, Junio C Hamano wrote: We already have some code paths that use ((void *)1) as a special pointer value, so in that sense I would say it is not the end of the world if you added a new one. No, but if you use it to replace the regexp, you end up having

Re: [PATCH v2 2/2] convert: Stream from fd to required clean filter instead of mmap

On Sun, Aug 17, 2014 at 06:33:54PM +0700, Duy Nguyen wrote: For files 2GB on a 32-bit system (e.g. msysgit), filtering with the previous code always failed. Now it works. I created the patch to change git from 'fundamentally doesn't handle this' to 'works as expected'. I deal with

Re: Issuing warning when hook does not have execution permission

On Tue, Aug 19, 2014 at 04:05:21PM +1000, Babak M wrote: I saw that if a hook file is present in .git/hooks and it does not have execution permissions it is silently ignored. I thought it might be worthwhile issuing a warning such as Warning: pre-commit hook exists but it cannot be executed

Re: Signinig a commit with multiple signatures

On Sun, Aug 17, 2014 at 09:30:47AM -0400, Jason Pyeron wrote: I am working on an open source project right now where we are looking to enforce a N of M audit approval process. It turns out that git supports verifying multiple signatures because gpg supports signature merging. In the scheme

Re: [PATCH v2 2/2] convert: Stream from fd to required clean filter instead of mmap

On Aug 19, 2014, at 9:53 AM, Jeff King p...@peff.net wrote: For files 2GB on a 32-bit system (e.g. msysgit), filtering with the previous code always failed. Now it works. I created the patch to change git from 'fundamentally doesn't handle this' to 'works as expected'. I deal with

Re: [PATCH] Documentation/git-rebase.txt: fix -f description to match actual git behavior.

Junio C Hamano gits...@pobox.com writes: Sergey Organov sorga...@gmail.com writes: A sentence --force has no effect under --preserve-merges mode does not tell the readers very much, either and leaves them wondering if it means --preserve-merges mode always rebases every time it is asked,

Re: [PATCH] Documentation/git-rebase.txt: fix -f description to match actual git behavior.

Junio C Hamano gits...@pobox.com writes: Junio C Hamano gits...@pobox.com writes: [...] How about doing it this way, perhaps? Could you please apply this your suggestion, as we seem not to agree on anything better? -- 8 -- From: Sergey Organov sorga...@gmail.com Date: Tue, 12 Aug 2014

Re: Relative submodule URLs

On Mon, Aug 18, 2014 at 01:55:05PM -0700, Jonathan Nieder wrote: Robert Dailey wrote: The documentation wasn't 100% clear on this, but I'm assuming by remote origin, it says that the relative URL is relative to the actual remote *named* origin (and it is not using origin as just a

Fwd: Shallow clone

Hi, everyone. I'm trying to perform a shallow clone with visibility of all remote branches. git clone REPO --depth 1 --no-single-branch is consistently giving me Cloning into 'REPONAME'... fatal: (null) is unknown object remote: Total 0 (delta 0), reused 0 (delta 0) fatal: recursion detected in

Re: [PATCH/RFC] git-imap-send: use libcurl for implementation

Am 2014-08-17 um 20:42 schrieb Jeff King: [...] I'm not sure I understand this comment. Even if SSL is not in use, wouldn't we be passing a regular pipe to curl, which would break? Yeah, we can't do that, and thus would have to keep the handwritten IMAP implementation just for the tunnel

Re: make profile issue on Git 2.1.0

Maybe we should do this: Looks good to me. As a side note, while testing this I noticed that the make perf run goes a lot faster if you set GIT_PERF_REPEAT_COUNT=1. This is bad for actually measuring things, but probably fine for profile feedback. I don't use the profile builds myself,

Re: Shallow clone

On Tue, Aug 19, 2014 at 6:11 PM, Steven Evergreen i.stevenevergr...@gmail.com wrote: Hi, everyone. I'm trying to perform a shallow clone with visibility of all remote branches. git clone REPO --depth 1 --no-single-branch is consistently giving me Cloning into 'REPONAME'... fatal: (null)

[PATCH] Allow the user to change the temporary file name for mergetool

Using the original filename suffix for the temporary input files to the merge tool confuses IDEs like Eclipse. This patch introduces a configurtion option, mergetool.tmpsuffix, which get appended to the temporary file name. That way the user can choose to use a suffix like .tmp, which does not

Re: [PATCH] Allow the user to change the temporary file name for mergetool

Am 19.08.2014 um 14:22 schrieb Robin Rosenberg: Using the original filename suffix for the temporary input files to the merge tool confuses IDEs like Eclipse. This patch introduces a configurtion option, mergetool.tmpsuffix, which get appended to the temporary file name. That way the user can

RE: Signinig a commit with multiple signatures

-Original Message- From: Jeff King Sent: Tuesday, August 19, 2014 4:05 On Sun, Aug 17, 2014 at 09:30:47AM -0400, Jason Pyeron wrote: I am working on an open source project right now where we are looking to enforce a N of M audit approval process. It turns out that git

[PATCH v2] Allow the user to change the temporary file name for mergetool

Using the original filename suffix for the temporary input files to the merge tool confuses IDEs like Eclipse. This patch introduces a configurtion option, mergetool.tmpsuffix, which get appended to the temporary file name. That way the user can choose to use a suffix like .tmp, which does not

Re: make profile issue on Git 2.1.0

On 19 August 2014 01:12, Jeff King p...@peff.net wrote: This is because v2.1.0 started using make perf to feed the profile builds, but it doesn't work on tarballs. Thanks for the explanation. -- Andrés -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to

Re: Relative submodule URLs

On Mon, Aug 18, 2014 at 3:55 PM, Jonathan Nieder jrnie...@gmail.com wrote: Thanks for reporting. The remote used is the default remote that git fetch without further arguments would use: get_default_remote () { curr_branch=$(git symbolic-ref -q HEAD)

Re: Relative submodule URLs

On Tue, Aug 19, 2014 at 5:24 AM, Heiko Voigt hvo...@hvoigt.net wrote: I think the OP problem stems from him having a branch that does not have a remote configured. Since they do not have 'origin' as a remote and git submodule update --init --recursive path/to/submodule fails. Right?

[PATCH 2/5] refs.c: make add_packed_ref return an error instead of calling die

Change add_packed_ref to return an error instead of calling die(). Update all callers to check the return value of add_packed_ref. We can also skip checking the refname format since this function is now static and only called from the transaction code. If we are updating a ref and the refname is

[PATCH 4/5] refs.c: add an err argument to commit_packed_refs

Signed-off-by: Ronnie Sahlberg sahlb...@google.com --- refs.c | 85 +++--- 1 file changed, 50 insertions(+), 35 deletions(-) diff --git a/refs.c b/refs.c index cfe1292..19e73f3 100644 --- a/refs.c +++ b/refs.c @@ -2232,8 +2232,8 @@

[PATCH 0/5] ref-transactions-req-strbuf-err

List, This is the next patch series in the ref transaction work. This patch series is called ref-transactions-req-strbuf-err and builds ontop of the series called ref-transactions-req-packed-refs which is origin/pu This patch series mainly adds some nice strbuf arguments to some functions to

[PATCH 5/5] refs.c: add an err argument to pack_refs

Signed-off-by: Ronnie Sahlberg sahlb...@google.com --- builtin/pack-refs.c | 8 +++- refs.c | 13 ++--- refs.h | 3 ++- 3 files changed, 15 insertions(+), 9 deletions(-) diff --git a/builtin/pack-refs.c b/builtin/pack-refs.c index b20b1ec..299768e 100644

[PATCH 3/5] refs.c: make lock_packed_refs take an err argument

Signed-off-by: Ronnie Sahlberg sahlb...@google.com --- refs.c | 25 + 1 file changed, 13 insertions(+), 12 deletions(-) diff --git a/refs.c b/refs.c index 0aad8c8..cfe1292 100644 --- a/refs.c +++ b/refs.c @@ -2270,13 +2270,17 @@ static int write_packed_entry_fn(struct

[PATCH 1/5] refs.c: replace the onerr argument in update_ref with a strbuf err

Get rid of the action_on_err enum and replace the action argument to update_ref with a strbuf *err for error reporting. Update all callers to the new api including two callers in transport*.c which used the literal 0 instead of an enum. Signed-off-by: Ronnie Sahlberg sahlb...@google.com ---

[PATCH 0/5] ref-transactions-send-pack

List, This small patch series adds atomic-push support for pushes. By default git will use the old style non-atomic updates for pushes, as not to cause disruption in client scripts that may depend on that behaviour. Command line arguments are introduced to allow the client side to request/

[PATCH 5/5] push.c: add an --atomic-push argument

Signed-off-by: Ronnie Sahlberg sahlb...@google.com --- Documentation/git-push.txt | 7 ++- builtin/push.c | 2 ++ transport.c| 1 + transport.h| 1 + 4 files changed, 10 insertions(+), 1 deletion(-) diff --git a/Documentation/git-push.txt

[PATCH 4/5] receive-pack.c: add receive.atomicpush configuration option

Add a configuration argument to the receive side to force atomic pushes for all pushes to the repo. Signed-off-by: Ronnie Sahlberg sahlb...@google.com --- Documentation/config.txt | 5 + builtin/receive-pack.c | 5 + 2 files changed, 10 insertions(+) diff --git

[PATCH 2/5] send-pack.c: add an --atomic-push command line argument

Signed-off-by: Ronnie Sahlberg sahlb...@google.com --- Documentation/git-send-pack.txt | 7 ++- builtin/send-pack.c | 6 +- send-pack.c | 8 +++- send-pack.h | 1 + 4 files changed, 19 insertions(+), 3 deletions(-) diff --git

[PATCH 3/5] receive-pack.c: use a single transaction when atomic-push is negotiated

Update receive-pack to use an atomic transaction IFF the client negotiated that it wanted atomic-push. This leaves the default behaviour to be the old non-atomic one ref at a time update. This is to cause as little disruption as possible to existing clients. It is unknown if there are client

[PATCH 1/5] receive-pack.c: add protocol support to negotiate atomic-push

Signed-off-by: Ronnie Sahlberg sahlb...@google.com --- builtin/receive-pack.c | 6 +- send-pack.c| 12 +--- 2 files changed, 14 insertions(+), 4 deletions(-) diff --git a/builtin/receive-pack.c b/builtin/receive-pack.c index 0565b94..f6b20cb 100644 ---

[PATCH v3 05/23] refs.c: move delete_ref to the common code

This change moves delete_ref() to the refs.c file since this function does not contain any backend specific code. Signed-off-by: Ronnie Sahlberg sahlb...@google.com --- refs-be-files.c | 19 --- refs.c | 19 +++ 2 files changed, 19 insertions(+), 19

[PATCH v3 15/23] refs.c: move names_conflict to the common code

Move names_conflict to the common code and make it public. We want to use the same name conflict checks across all backends so we guarantee compatibility across backends. Signed-off-by: Ronnie Sahlberg sahlb...@google.com --- refs-be-files.c | 14 -- refs.c | 8

[PATCH v3 04/23] refs.c: move update_ref to refs.c

This change moves update_ref() to the refs.c file since this function does not contain any backend specific code. Signed-off-by: Ronnie Sahlberg sahlb...@google.com --- refs-be-files.c | 23 --- refs.c | 25 + 2 files changed, 25

[PATCH v3 06/23] refs.c: move rename_ref to the common code

This change moves rename_ref() to the refs.c file since this function does not contain any backend specific code. Signed-off-by: Ronnie Sahlberg sahlb...@google.com --- refs-be-files.c | 92 - refs.c | 92

[PATCH v3 08/23] refs.c: move the hidden refs functions to the common code

This change moves the hidden refs functions to the refs.c file since these functions do not contain any backend specific code. Signed-off-by: Ronnie Sahlberg sahlb...@google.com --- refs-be-files.c | 43 --- refs.c | 44

[PATCH v3 20/23] refs-be-files.c: add reflog backend methods

Signed-off-by: Ronnie Sahlberg sahlb...@google.com --- refs-be-files.c | 21 +++-- refs.c | 32 refs.h | 16 3 files changed, 63 insertions(+), 6 deletions(-) diff --git a/refs-be-files.c b/refs-be-files.c index

[PATCH v3 14/23] refs.c: move is_branch to the common code

Signed-off-by: Ronnie Sahlberg sahlb...@google.com --- refs-be-files.c | 5 - refs.c | 5 + 2 files changed, 5 insertions(+), 5 deletions(-) diff --git a/refs-be-files.c b/refs-be-files.c index 55bced9..70c034c 100644 --- a/refs-be-files.c +++ b/refs-be-files.c @@ -2483,11

[PATCH v3 18/23] refs.c: move head_ref_namespaced to the common code

Signed-off-by: Ronnie Sahlberg sahlb...@google.com --- refs-be-files.c | 15 --- refs.c | 15 +++ 2 files changed, 15 insertions(+), 15 deletions(-) diff --git a/refs-be-files.c b/refs-be-files.c index 9aa88ef..e58a7e1 100644 --- a/refs-be-files.c +++

[PATCH v3 19/23] refs-be-files.c: add a backend method structure with transaction functions

Add a ref structure for backend methods. Start by adding method pointers for the transaction functions. Rename the existing transaction functions to files_* and make them static. Add new transaction functions that just pass through to the appropriate methods for the backend. Signed-off-by:

[PATCH v3 07/23] refs.c: move read_ref_at to the common refs file

This change moves read_ref_at() to the refs.c file since this function does not contain any backend specific code. Signed-off-by: Ronnie Sahlberg sahlb...@google.com --- refs-be-files.c | 114 refs.c | 114

[PATCH v3 03/23] refs.c: add a new refs.c file to hold all common refs code

Create a new erfs.c file that will be used to hold all the refs code that is backend agnostic and will be shared across all backends. The reason we renamed everything to refs-be-files.c in the previous patch and now start moving the common code back to the new refs.c file instead of the other way

[PATCH v3 17/23] refs.c: move ref iterators to the common code

Signed-off-by: Ronnie Sahlberg sahlb...@google.com --- refs-be-files.c | 81 - refs.c | 81 + 2 files changed, 81 insertions(+), 81 deletions(-) diff --git a/refs-be-files.c

[PATCH v3 13/23] refs.c: move check_refname_component to the common code

This function does not contain any backend specific code so we can move it to the common code. Signed-off-by: Ronnie Sahlberg sahlb...@google.com --- refs-be-files.c | 110 refs.c | 110

[PATCH v3 22/23] refs-be-files.c: add methods for head_ref*

Signed-off-by: Ronnie Sahlberg sahlb...@google.com --- refs-be-files.c | 7 +-- refs.c | 10 ++ refs.h | 5 + 3 files changed, 20 insertions(+), 2 deletions(-) diff --git a/refs-be-files.c b/refs-be-files.c index b09f0fc..910663b 100644 --- a/refs-be-files.c

[PATCH v3 21/23] refs-be-files.c: add methods for misc ref operations

Add ref backend methods for: resolve_ref_unsafe, is_refname_available, pack_refs, peel_ref, create_symref, resolve_gitlink_ref. Signed-off-by: Ronnie Sahlberg sahlb...@google.com --- refs-be-files.c | 25 ++--- refs.c | 33 + refs.h

[PATCH v3 23/23] refs-be-files.c: add methods for the ref iterators

Signed-off-by: Ronnie Sahlberg sahlb...@google.com --- refs-be-files.c | 21 ++--- refs.c | 36 refs.h | 18 ++ 3 files changed, 68 insertions(+), 7 deletions(-) diff --git a/refs-be-files.c b/refs-be-files.c

[PATCH v3 11/23] refs.c: move read_ref, read_ref_full and ref_exists to the common code

These functions do not depend on the backend implementation so we can move them to the common code. Signed-off-by: Ronnie Sahlberg sahlb...@google.com --- refs-be-files.c | 18 -- refs.c | 18 ++ 2 files changed, 18 insertions(+), 18 deletions(-) diff

[PATCH v3 10/23] refs.c: move warn_if_dangling_symref* to the common code

These functions do not use any backend specific code so we can move them to the common code. Signed-off-by: Ronnie Sahlberg sahlb...@google.com --- refs-be-files.c | 52 refs.c | 52

[PATCH v3 01/23] refs.c: create a public function for is_refname_available

Export a generic is_refname_available() function. We will need this as a public shared function later when we add additional refs backends since we want to keep using the same rules for ref naming across all backends. Signed-off-by: Ronnie Sahlberg sahlb...@google.com --- refs.c | 29

[PATCH v3 09/23] refs.c: move dwim and friend functions to the common refs code

These functions do not contain any backend specific code so we can move them to the common code and share across all backends. Signed-off-by: Ronnie Sahlberg sahlb...@google.com --- refs-be-files.c | 202 refs.c | 202

[PATCH v3 16/23] refs.c: move prettify_refname to the common code

Signed-off-by: Ronnie Sahlberg sahlb...@google.com --- refs-be-files.c | 9 - refs.c | 9 + 2 files changed, 9 insertions(+), 9 deletions(-) diff --git a/refs-be-files.c b/refs-be-files.c index 6542969..fb9c614 100644 --- a/refs-be-files.c +++ b/refs-be-files.c @@

[PATCH v3 12/23] refs.c: move resolve_refdup to common

This function can be shared across all refs backends so move it to the common code. Signed-off-by: Ronnie Sahlberg sahlb...@google.com --- refs-be-files.c | 6 -- refs.c | 6 ++ 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/refs-be-files.c b/refs-be-files.c

Re: Relative submodule URLs

Robert Dailey rcdailey.li...@gmail.com writes: The way I set up my remote tracking branch will be different for each of these commands: - git pull :: If I want convenient pulls (with rebase), I will track my upstream branch. My pushes have to be more explicit as a tradeoff. Keeping 'origin'

Re: Relative submodule URLs

On Tue, Aug 19, 2014 at 11:39 AM, Junio C Hamano gits...@pobox.com wrote: Robert Dailey rcdailey.li...@gmail.com writes: The way I set up my remote tracking branch will be different for each of these commands: - git pull :: If I want convenient pulls (with rebase), I will track my upstream

Re: Issuing warning when hook does not have execution permission

Jeff King p...@peff.net writes: On Tue, Aug 19, 2014 at 04:05:21PM +1000, Babak M wrote: I saw that if a hook file is present in .git/hooks and it does not have execution permissions it is silently ignored. I thought it might be worthwhile issuing a warning such as Warning: pre-commit

Re: [PATCH v2] Allow the user to change the temporary file name for mergetool

Robin Rosenberg robin.rosenb...@dewire.com writes: Using the original filename suffix for the temporary input files to the merge tool confuses IDEs like Eclipse. This patch introduces a configurtion option, mergetool.tmpsuffix, which get appended to the temporary file name. That way the user

Re: [PATCH/RFC] git-imap-send: use libcurl for implementation

Bernhard Reiter ock...@raz.or.at writes: Am 2014-08-17 um 20:42 schrieb Jeff King: [...] I'm not sure I understand this comment. Even if SSL is not in use, wouldn't we be passing a regular pipe to curl, which would break? Yeah, we can't do that, and thus would have to keep the handwritten

[PATCH v3] Allow the user to change the temporary file name for mergetool

Using the original filename suffix for the temporary input files to the merge tool confuses IDEs like Eclipse. This patch introduces a configurtion option, mergetool.tmpsuffix, which get appended to the temporary file name. That way the user can choose to use a suffix like .tmp, which does not

Re: [PATCH/RFC] git-imap-send: use libcurl for implementation

Bernhard Reiter ock...@raz.or.at writes: Use libcurl's high-level API functions to implement git-imap-send instead of the previous low-level OpenSSL-based functions. Since version 7.30.0, libcurl's API has been able to communicate with IMAP servers. Using those high-level functions instead

Re: [PATCH v3] Allow the user to change the temporary file name for mergetool

Robin Rosenberg robin.rosenb...@dewire.com writes: Using the original filename suffix for the temporary input files to the merge tool confuses IDEs like Eclipse. This patch introduces a configurtion option, mergetool.tmpsuffix, which get appended to the temporary file name. That way the user

Re: [PATCH] Push the NATIVE_CRLF Makefile variable to C and added a test for native.

Torsten Bögershausen tbo...@web.de writes: Commit 95f31e9a correctly points out that the NATIVE_CRLF setting is incorrectly set on Mingw git. However, the Makefile variable is not propagated to the C preprocessor and results in no change. This patch pushes the definition to the C code and

[PATCH v2 1/4] run-command: introduce CHILD_PROCESS_INIT

Most struct child_process variables are cleared using memset first after declaration. Provide a macro, CHILD_PROCESS_INIT, that can be used to initialize them statically instead. That's shorter, doesn't require a function call and is slightly more readable (especially given that we already have

[PATCH v2 3/4] run-command: call run_command_v_opt_cd_env() instead of duplicating it

Signed-off-by: Rene Scharfe l@web.de --- run-command.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/run-command.c b/run-command.c index 47ab21b..9196ee0 100644 --- a/run-command.c +++ b/run-command.c @@ -577,9 +577,7 @@ static void prepare_run_command_v_opt(struct

[PATCH v2 4/4] run-command: inline prepare_run_command_v_opt()

Merge prepare_run_command_v_opt() and its only caller. This removes a pointer indirection and allows to initialize the struct child_process using CHILD_PROCESS_INIT. Signed-off-by: Rene Scharfe l@web.de --- run-command.c | 24 1 file changed, 8 insertions(+), 16

Re: Relative submodule URLs

Robert Dailey rcdailey.li...@gmail.com writes: Maybe I'm misunderstanding something here and you can help me out. All the reading I've done (mostly github) says that 'upstream' points to the authoritative repository that you forked from but do not have permissions to write to. 'origin'

Re: Re: Relative submodule URLs

On Tue, Aug 19, 2014 at 11:50:08AM -0500, Robert Dailey wrote: Maybe I'm misunderstanding something here and you can help me out. All the reading I've done (mostly github) says that 'upstream' points to the authoritative repository that you forked from but do not have permissions to write

Re: Transaction patch series overview

List, please see here an overview and ordering of the ref transaction patch series. These series build on each other and needs to be applied in the order listed below. This is an update. rs/ref-transaction-0 --- Early part of the ref transaction topic. *

Re: Relative submodule URLs

On Tue, Aug 19, 2014 at 2:19 PM, Junio C Hamano gits...@pobox.com wrote: I do not know if that is how GitHub teaches people, but I would have to say that these are strange phrasing. I suspect that part of their documentation was written long time ago, back when nobody on the GitHub side were

Re: Re: Relative submodule URLs

On Tue, Aug 19, 2014 at 2:30 PM, Heiko Voigt hvo...@hvoigt.net wrote: Well the remote for the submodule is currently only calculated once, when you do the initial git submodule update --init that clones the submodule. Afterwards the fixed url is configured under the name 'origin' in

Re: [PATCH v3] Allow the user to change the temporary file name for mergetool

Am 19.08.2014 19:15, schrieb Robin Rosenberg: Using the original filename suffix for the temporary input files to the merge tool confuses IDEs like Eclipse. This patch introduces a configurtion option, mergetool.tmpsuffix, which get appended to the temporary file name. That way the user can

Re: Re: Re: Relative submodule URLs

On Tue, Aug 19, 2014 at 03:23:36PM -0500, Robert Dailey wrote: On Tue, Aug 19, 2014 at 2:30 PM, Heiko Voigt hvo...@hvoigt.net wrote: Well the remote for the submodule is currently only calculated once, when you do the initial git submodule update --init that clones the

[PATCH] imap-send.c: imap_folder - imap_server_conf.folder

Rename the imap_folder variable to folder and make it a member of struct imap_server_conf. Signed-off-by: Bernhard Reiter ock...@raz.or.at --- As discussed in http://www.mail-archive.com/git@vger.kernel.org/msg57019.html Bernhard imap-send.c | 10 +- 1 file changed, 5 insertions(+), 5

[PATCH 00/18] Signed push

While signed tags and commits assert that the objects thusly signed came from you, who signed these objects, there is not a good way to assert that you wanted to have a particular object at the tip of a particular branch. My signing v2.0.1 tag only means I want to call the version v2.0.1, and it

[PATCH 01/18] receive-pack: do not overallocate command structure

An update command in the protocol exchange consists of 40-hex old object name, SP, 40-hex new object name, SP, and a refname, but the first instance is further followed by a NUL with feature requests. The command structure, which has a flex-array member that stores the refname at the end, was

[PATCH 03/18] receive-pack: do not reuse old_sha1[] to other things

This piece of code reads object names of shallow boundaries, not old_sha1[]. Signed-off-by: Junio C Hamano gits...@pobox.com --- builtin/receive-pack.c | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/builtin/receive-pack.c b/builtin/receive-pack.c index

[PATCH 02/18] receive-pack: parse feature request a bit earlier

Ideally, we should have also allowed the first shallow to carry the feature request trailer, but that is water under the bridge now. This makes the next step to factor out the queuing of commands easier to review. Signed-off-by: Junio C Hamano gits...@pobox.com --- builtin/receive-pack.c | 24

[PATCH 04/18] receive-pack: factor out queueing of command

Make a helper function to accept a line of a protocol message and queue an update command out of the code from read_head_info(). Signed-off-by: Junio C Hamano gits...@pobox.com --- builtin/receive-pack.c | 50 +- 1 file changed, 29 insertions(+),

[PATCH 05/18] send-pack: move REF_STATUS_REJECT_NODELETE logic a bit higher

20e8b465 (refactor ref status logic for pushing, 2010-01-08) restructured the code to set status for each ref to be pushed, but did not quite go far enough. We inspect the status set earlier by set_refs_status_for_push() and then perform yet another update to the status of a ref with an otherwise

[PATCH 07/18] send-pack: always send capabilities

We tried to avoid sending one extra byte, NUL and nothing behind it to signal there is no protocol capabilities being sent, on the first command packet on the wire, but it just made the code look ugly. Signed-off-by: Junio C Hamano gits...@pobox.com --- send-pack.c | 4 +--- 1 file changed, 1

[PATCH 06/18] send-pack: refactor decision to send update per ref

A new helper function ref_update_to_be_sent() decides for each ref if the update is to be sent based on the status previously set by set_ref_status_for_push() and also if this is a mirrored push. Signed-off-by: Junio C Hamano gits...@pobox.com --- send-pack.c | 36

[PATCH 08/18] send-pack: factor out capability string generation

A run of 'var ? var : ' fed to a long printf string in a deeply nested block was hard to read. Move it outside the loop and format it into a strbuf. As an added bonus, the trick to add agent=agent-name by using two conditionals is replaced by a more readable version. Signed-off-by: Junio C

[PATCH 09/18] send-pack: rename new_refs to need_pack_data

The variable counts how many non-deleting command is being sent, but is only checked with 0-ness to decide if we need to send the pack data. Signed-off-by: Junio C Hamano gits...@pobox.com --- send-pack.c | 7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/send-pack.c

[PATCH 16/18] receive-pack: GPG-validate push certificates

Reusing the GPG signature check helpers we already have, verify the signature in receive-pack and give the results to the hooks via GIT_PUSH_CERT_{SIGNER,KEY,STATUS} environment variables. Policy decisions, such as accepting or rejecting a good signature by a key that is not fully trusted, is

[PATCH 14/18] pack-protocol doc: typofix for PKT-LINE

Everywhere else we use PKT-LINE to denote the pkt-line formatted data, but shallow/deepen messages are described with PKT_LINE(). Fix them. Signed-off-by: Junio C Hamano gits...@pobox.com --- Documentation/technical/pack-protocol.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)

[PATCH 10/18] send-pack: refactor inspecting and resetting status and sending commands

The main loop over remote_refs list inspects the ref status to see if we need to generate pack data (i.e. a delete-only push does not need to send any additional data), resets it to expecting the status report state, and formats the actual update commands to be sent. Split the former two out of

[PATCH 13/18] gpg-interface: move parse_signature() to where it should be

Our signed-tag objects set the standard format used by Git to store GPG-signed payload (i.e. the payload followed by its detached signature), and it made sense to have a helper to find the boundary between the payload and its signature in tag.c back then. Newer code added later to parse other

[PATCH 12/18] gpg-interface: move parse_gpg_output() to where it should be

Earlier, ffb6d7d5 (Move commit GPG signature verification to commit.c, 2013-03-31) moved this helper that used to be in pretty.c (i.e. the output code path) to commit.c for better reusability. It was a good first step in the right direction, but still suffers a myopic view that commits will be

[PATCH 18/18] signed push: final protocol update

With the interim protocol, we used to send the update commands even though we already send a signed copy of the same information when push certificate is in use. Update the send-pack/receive-pack pair not to do so. The notable thing on the receive-pack side is that it makes sure that there is no

[PATCH 11/18] send-pack: clarify that cmds_sent is a boolean

We use it to make sure that the feature request is sent only once on the very first request packet (ignoring the shallow line, which was an unfortunate mistake we cannot retroactively fix with existing receive-pack already deployed in the field) and we set it to true with cmds_sent++, not because

[PATCH 15/18] the beginning of the signed push

While signed tags and commits assert that the objects thusly signed came from you, who signed these objects, there is not a good way to assert that you wanted to have a particular object at the tip of a particular branch. My signing v2.0.1 tag only means I want to call the version v2.0.1, and it

[PATCH 17/18] send-pack: send feature request on push-cert packet

We would want to update the interim protocol so that we do not send the usual update commands when the push certificate feature is in use, as the same information is in the certificate. Once that happens, the push-cert packet may become the only protocol command, but then there is no packet to

Re: [PATCH v3] Allow the user to change the temporary file name for mergetool

Johannes Sixt j...@kdbg.org writes: Am 19.08.2014 19:15, schrieb Robin Rosenberg: Using the original filename suffix for the temporary input files to the merge tool confuses IDEs like Eclipse. This patch introduces a configurtion option, mergetool.tmpsuffix, which get appended to the

Re: Transaction patch series overview

Ronnie Sahlberg sahlb...@google.com writes: List, please see here an overview and ordering of the ref transaction patch series. These series build on each other and needs to be applied in the order listed below. This is an update. rs/ref-transaction-0 ---

Re: [PATCH 02/18] receive-pack: parse feature request a bit earlier

Junio C Hamano gits...@pobox.com writes: Ideally, we should have also allowed the first shallow to carry the feature request trailer, but that is water under the bridge now. This makes the next step to factor out the queuing of commands easier to review. Signed-off-by: Junio C Hamano

Re: [PATCH 03/18] receive-pack: do not reuse old_sha1[] to other things

Junio C Hamano gits...@pobox.com writes: This piece of code reads object names of shallow boundaries, not old_sha1[]. Signed-off-by: Junio C Hamano gits...@pobox.com --- I should double the subject line and say do not reuse ... for other things. -- To unsubscribe from this list: send the

Re: [PATCH 00/18] Signed push

On Wed, Aug 20, 2014 at 5:06 AM, Junio C Hamano gits...@pobox.com wrote: While signed tags and commits assert that the objects thusly signed came from you, who signed these objects, there is not a good way to assert that you wanted to have a particular object at the tip of a particular branch.

  1   2   >