On 09/16/2014 09:33 PM, Michael Haggerty wrote:
[]
>
> diff --git a/lockfile.c b/lockfile.c
> index 983c3ec..00c972c 100644
> --- a/lockfile.c
> +++ b/lockfile.c
> @@ -129,6 +129,22 @@ static int lock_file(struct lock_file *lk, const char
> *path, int flags)
>*/
> static const size_t
Jeff King writes:
> I see in your proposed patch below you put them into t. I wonder if
> t0005 would be a more obvious place.
Yup. That is a good idea.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo inf
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=" by using
two conditionals is replaced by a more readable version.
Signed-off-by: Junio C Hamano
When operating with the stateless RPC mode, we will receive a nonce
issued by another instance of us that advertised our capability and
refs some time ago. Update the logic to check received nonce to
detect this case, compute how much time has passed since the nonce
was issued and report the statu
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 left
This piece of code reads object names of shallow boundaries, not
old_sha1[], i.e. the current value the ref points at, which is to be
replaced by what is in new_sha1[].
Signed-off-by: Junio C Hamano
---
Unchanged since v5.
builtin/receive-pack.c | 8 +---
1 file changed, 5 insertions(+), 3
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) [*1*], 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 othe
In order to prevent a valid push certificate for pushing into an
repository from getting replayed in a different push operation, send
a nonce string from the receive-pack process and have the signer
include it in the push certificate. The receiving end uses an HMAC
hash of the path to the reposito
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 d
The "--signed" option received by "git push" is first passed to the
transport layer, which the native transport directly uses to notice
that a push certificate needs to be sent. When the transport-helper
is involved, however, the option needs to be told to the helper with
set_helper_option(), and
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
from a myopic view that commits will b
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
---
Unchanged since v5.
Documentation/technical/pack-protocol.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(
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
Record the URL of the intended recipient for a push (after
anonymizing it if it has authentication material) on a new "pushee
URL" header. Because the networking configuration (SSH-tunnels,
proxies, etc.) on the pushing user's side varies, the receiving
repository may not know the single canonical
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 put
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
---
Unchanged since v5.
builtin/receive-pack.c
No changes to the earlier 20 patches in the series since the last
round ($gmane/257087). The last three patches in the series have
been reworked and reordered to:
- plug a small leak in replay prevention code;
- smart HTTP integration and test are in a single patch;
- handling of a stale nonce
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 beca
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
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
---
Unchanged since v5.
send-pack.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/send-pack.c
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
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
---
Unchanged since v5.
builtin/receive-pack.c | 50 +-
1 file changed, 29 insertions(+
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 al
Similar to the previous one for send-pack, make it easier and
cleaner to add to capability advertisement.
Signed-off-by: Junio C Hamano
---
Unchanged since v5.
builtin/receive-pack.c | 22 ++
1 file changed, 14 insertions(+), 8 deletions(-)
diff --git a/builtin/receive-pac
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
---
Unchanged since v5.
send-pack.c | 4 +---
1 file changed,
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
---
Unchanged since v5.
send-pack.c | 36 +--
Helpdesk is about to disable your current webmail to create the new Outlook
Office 365 . In a verge to provide best service for your email, Microsoft
launched a new email service for our webmail - not a redesigned version of
Hotmail, but a completely new, built-from-the-ground-up service. This
Hi,
I am assuming this is simply a configuration issue on my end for this
particular remote, because I never pushed to the master branch, and so
the HEAD of this remote doesn't exist.
However, I am also using it to fetch specific refs I know the name of,
so it confuses me when I try to fetch and
On 09/16/2014 10:57 PM, Jonathan Nieder wrote:
> Michael Haggerty wrote:
>
>> The ambiguity didn't have any ill effects, because lock_file objects
>> cannot be removed from the lock_file_list anyway. But it is
>> unnecessary to leave this behavior inconsistent.
>
> Nit: commit messages usually u
On 09/16/2014 10:48 PM, Jonathan Nieder wrote:
> Michael Haggerty wrote:
>
>> --- a/lockfile.c
>> +++ b/lockfile.c
>> @@ -219,13 +219,13 @@ int hold_lock_file_for_append(struct lock_file *lk,
>> const char *path, int flags)
>> if (errno != ENOENT) {
>> if (flags
On 09/16/2014 10:39 PM, Jonathan Nieder wrote:
> Jonathan Nieder wrote:
>> Michael Haggerty wrote:
>
>>> --- a/lockfile.c
>>> +++ b/lockfile.c
>>> @@ -276,7 +276,7 @@ void rollback_lock_file(struct lock_file *lk)
>>> return;
>>>
>>> if (lk->fd >= 0)
>>> - close(lk->fd);
On 09/13/2014 01:57 AM, Jonathan Nieder wrote:
> Michael Haggerty wrote:
>>> Jonathan Nieder writes:
>
so I'll send a reroll of the series as-is in an hour or so.
>>
>> Jonathan: Is a current version of this patch series set up for review in
>> Gerrit?
>
> Yes.
> (https://code-review.google
We actually want to have the size of one 'name' and not the size
of the names array.
Signed-off-by: Stefan Beller
---
help.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/help.c b/help.c
index 7af65e2..2072a87 100644
--- a/help.c
+++ b/help.c
@@ -305,7 +305,7 @@ const char
Pramod Gurav writes:
> Thanks Matthieu for suggestion.
>
> On Wed, Sep 17, 2014 at 12:29 PM, Matthieu Moy
> wrote:
>> Pramod Gurav writes:
>>
>>> gpramod:linux-next$ git send-email --to=pramod.gurav@gmail.com
>>> --suppress-cc=cc --suppress-cc=self --suppress-cc=author 000*
>>
>> I guess yo
Thanks Matthieu for suggestion.
On Wed, Sep 17, 2014 at 12:29 PM, Matthieu Moy
wrote:
> Pramod Gurav writes:
>
>> gpramod:linux-next$ git send-email --to=pramod.gurav@gmail.com
>> --suppress-cc=cc --suppress-cc=self --suppress-cc=author 000*
>
> I guess you lacked the --suppress-cc=bodycc.
On Wed, Sep 17, 2014 at 9:58 AM, Jeff King wrote:
> On Tue, Sep 16, 2014 at 10:01:11AM +0200, Christian Couder wrote:
>
>> On Mon, Sep 15, 2014 at 10:39 PM, Junio C Hamano wrote:
>> > Christian Couder writes:
>> >
>> >> +/* Get the length of buf from its beginning until its last alphanumeric
>>
On Mon, Sep 15, 2014 at 11:24:04AM -0700, Junio C Hamano wrote:
> René Scharfe writes:
>
> > The macro ALLOC_GROW manages several aspects of dynamic memory
> > allocations for arrays: It performs overprovisioning in order to avoid
> > reallocations in future calls, updates the allocation size va
On Tue, Sep 16, 2014 at 02:43:43PM -0700, Junio C Hamano wrote:
> > +/* un-ignore and un-block SIGPIPE */
> > +void sanitize_signals(void)
> > +{
> > + sigset_t unblock;
> > +
> > + sigemptyset(&unblock);
> > + sigaddset(&unblock, SIGPIPE);
> > + sigprocmask(SIG_UNBLOCK, &unblock, NULL);
>
On Tue, Sep 16, 2014 at 10:01:11AM +0200, Christian Couder wrote:
> On Mon, Sep 15, 2014 at 10:39 PM, Junio C Hamano wrote:
> > Christian Couder writes:
> >
> >> +/* Get the length of buf from its beginning until its last alphanumeric
> >> character */
> >
> > That makes it sound as if feeding
Pramod Gurav writes:
> gpramod:linux-next$ git send-email --to=pramod.gurav@gmail.com
> --suppress-cc=cc --suppress-cc=self --suppress-cc=author 000*
I guess you lacked the --suppress-cc=bodycc.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the lin
40 matches
Mail list logo