On Wed, Sep 3, 2014 at 6:42 PM, Max Kirillov m...@max630.net wrote:
When gitfile is used, git sets GIT_DIR environment variable for
subsequent commands, and that commands start working in mode GIT_DIR
set, workdir current, which is incorrect for the case when git runs
from subdirectory 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
---
send-pack.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/send-pack.c
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
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
---
builtin/receive-pack.c | 22 ++
1 file changed, 14 insertions(+), 8 deletions(-)
diff --git a/builtin/receive-pack.c
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
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
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
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
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
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
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
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
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(-)
In order to prevent a valid push certificate for pushing into an
repository from getting replayed to push to an unrelated one, send a
nonce string from the receive-pack process and have the signer
include it in the push certificate. The original nonce is exported
as GIT_PUSH_CERT_NONCE for the
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
I see, tnx for the pointer.
Would inclusion of this patch be viable option then?
Patch below, it is possible to look at it here to:
Patch:
https://github.com/teonsystems/git/commit/27449825ff4d7bb3eecb5a3e32692aaf1ab1a026
Branch:
On Thu, Sep 4, 2014 at 1:04 PM, Junio C Hamano gits...@pobox.com wrote:
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
Hi,
I just wanted to ask if the --in-reply-to flag of git format-patch is
supposed to write the given string unmodified into the email or whether
it ought to perform some check against header injection.
For example, if you pass --in-reply-to=msgid\nTo: ot...@example.com
(notice lack of trailing
When gitfile is used, git sets GIT_DIR environment variable for
subsequent commands, and that commands start working in mode GIT_DIR
set, workdir current, which is incorrect for the case when git runs
from subdirectory of repository. This can be observed at least for
running aliases - git fails
Niklas Hambüchen m...@nh2.me writes:
For example, if you pass --in-reply-to=msgid\nTo: ot...@example.com
(notice lack of trailing ``), then the generated email will actually
contain a
To: ot...@example.com
header.
While I do not think of a reason to specify such a string to the
Tanay Abhra tanay...@gmail.com writes:
GSoC Experience
---
...
Conclusion
--
So a great summer comes to an end. Hopefully I would still be part of
Git's community
and will continue working on it to improve it. I like to thank my
mentors for being patient
with me and
On 04/09/14 23:36, Junio C Hamano wrote:
While I do not think of a reason to specify such a string to the
in-reply-to option (I'd rather edit the output in the editor if I
wanted to do anything fancy [*1*]), I do not think there is a reason
why you want to add a code to forbid such use,
Sorry, I just realized that when the hunks are across file boundaries,
it won't go back to it. I think this is a bit misleading, it would be
great to see it go back to the ACTUAL previous hunk, regardless of
which file it came from.
On Thu, Sep 4, 2014 at 4:54 PM, Robert Dailey
Hi Junio,
On Fri, Sep 5, 2014 at 5:21 AM, Junio C Hamano gits...@pobox.com wrote:
Chris Packham judge.pack...@gmail.com writes:
Another thing that I've since realised is that this 'gitk' format is
also what you've get from git show or git log -p. So this is actually
allowing (for better or
Shawn Pearce spea...@spearce.org writes:
As you know, the stateless HTTP thing doesn't allow the nonce on the
server to be carried from the initial ref advertisement into the final
receive-pack. We would either need to write the nonce to disk and load
it back up later (ick), or use some sort
Niklas Hambüchen m...@nh2.me writes:
On 04/09/14 23:36, Junio C Hamano wrote:
While I do not think of a reason to specify such a string to the
in-reply-to option (I'd rather edit the output in the editor if I
wanted to do anything fancy [*1*]), I do not think there is a reason
why you want
On Thu, Sep 4, 2014 at 11:51 PM, Junio C Hamano gits...@pobox.com wrote:
Duy Nguyen pclo...@gmail.com writes:
On Wed, Sep 3, 2014 at 5:06 AM, Junio C Hamano gits...@pobox.com wrote:
* nd/multiple-work-trees (2014-07-29) 39 commits
Reroll posted, but haven't picked up yet. How would this
On Fri, Sep 5, 2014 at 12:14 AM, Junio C Hamano gits...@pobox.com wrote:
Junio C Hamano gits...@pobox.com writes:
Duy Nguyen pclo...@gmail.com writes:
On Wed, Sep 3, 2014 at 5:06 AM, Junio C Hamano gits...@pobox.com wrote:
* nd/multiple-work-trees (2014-07-29) 39 commits
Reroll posted,
(added back git ml because I accidentally dropped the Cc when replying
to Junio).
On Fri, Sep 5, 2014 at 10:57 AM, Junio C Hamano gits...@pobox.com wrote:
I doubt that a patchset that does
not update mailinfo and mailsplit to extract information and to undo
the indentation could be a right
On Thu, Sep 4, 2014 at 4:57 PM, Junio C Hamano gits...@pobox.com wrote:
Shawn Pearce spea...@spearce.org writes:
As you know, the stateless HTTP thing doesn't allow the nonce on the
server to be carried from the initial ref advertisement into the final
receive-pack. We would either need to
On Tue, Sep 02, 2014 at 10:51:47AM -0400, Marc Branchaud wrote:
MULTIPLE WORKING TREES
--
A git repository can support multiple working trees, allowing you to check
out more than one branch at a time. With `git checkout --to` a new working
tree is associated with the
Git no longer seems to use these flags or their associated config keys;
when they are present, git-svn outputs a message indicating that they
are being ignored.
Signed-off-by: Lawrence Velázquez v...@larryv.me
---
Documentation/git-svn.txt | 15 ---
1 file changed, 15 deletions(-)
32 matches
Mail list logo
