Hi,
I was trying to send a patchset to self just to test by suppressing
everyone in CC list of patch header. But it failed and the patch was
send to people in CC.
Is there anything wrong that I have done? My git verions is:
gpramod:git$ git --version
git version 1.7.9.5
Below is the command I
Pramod Gurav pramod.gurav@gmail.com 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
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 gits...@pobox.com wrote:
Christian Couder chrisc...@tuxfamily.org writes:
+/* Get the length of buf from its beginning until its last alphanumeric
character */
That
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 Mon, Sep 15, 2014 at 11:24:04AM -0700, Junio C Hamano wrote:
René Scharfe l@web.de 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
On Wed, Sep 17, 2014 at 9:58 AM, Jeff King p...@peff.net 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 gits...@pobox.com wrote:
Christian Couder chrisc...@tuxfamily.org writes:
+/* Get the length of buf from its
Thanks Matthieu for suggestion.
On Wed, Sep 17, 2014 at 12:29 PM, Matthieu Moy
matthieu@grenoble-inp.fr wrote:
Pramod Gurav pramod.gurav@gmail.com writes:
gpramod:linux-next$ git send-email --to=pramod.gurav@gmail.com
--suppress-cc=cc --suppress-cc=self --suppress-cc=author 000*
Pramod Gurav pramod.gurav@gmail.com writes:
Thanks Matthieu for suggestion.
On Wed, Sep 17, 2014 at 12:29 PM, Matthieu Moy
matthieu@grenoble-inp.fr wrote:
Pramod Gurav pramod.gurav@gmail.com writes:
gpramod:linux-next$ git send-email --to=pramod.gurav@gmail.com
We actually want to have the size of one 'name' and not the size
of the names array.
Signed-off-by: Stefan Beller stefanbel...@gmail.com
---
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
@@
On 09/13/2014 01:57 AM, Jonathan Nieder wrote:
Michael Haggerty wrote:
Jonathan Nieder jrnie...@gmail.com 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.
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/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: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 use
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
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.
Similar to the previous one for send-pack, make it easier and
cleaner to add to capability advertisement.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
Unchanged since v5.
builtin/receive-pack.c | 22 ++
1 file changed, 14 insertions(+), 8 deletions(-)
diff --git
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
---
Unchanged since v5.
send-pack.c | 4 +---
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
---
Unchanged since v5.
send-pack.c | 36
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
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
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 gits...@pobox.com
---
Unchanged since v5.
send-pack.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff
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
---
Unchanged since v5.
builtin/receive-pack.c | 50 +-
1 file
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
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
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
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
---
Unchanged since v5.
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
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
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
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 gits...@pobox.com
---
Unchanged since v5.
builtin/receive-pack.c | 8 +---
1 file changed,
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
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
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
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 the
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
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
---
Unchanged since v5.
Documentation/technical/pack-protocol.txt | 4 ++--
1 file changed, 2
Jeff King p...@peff.net 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
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
41 matches
Mail list logo
