Junio C Hamano gitster at pobox.com writes:
Junio C Hamano gitster at pobox.com writes:
I would suspect that this may be fine.
rev-parse --verify makes sure the named object exists, but in this
case at {u} does not even name any object, does it?
Hmph, but rev-parse --verify
On 29.07.2014 16:43, Patrick Reynolds wrote:
Remotes are stored as an array, so looking one up or adding one without
duplication is an O(n) operation. Reading an entire config file full of
remotes is O(n^2) in the number of remotes. For a repository with tens of
thousands of remotes, the
I've re-ordered things in this round. Hopefully the first 3 patches are
uncontroversial, Junio has expressed reservations about the 4th. I
haven't looked at moving the changes into mailsplit yet or I could try
and update gitk to use something other than diff-tree or I could write
some external
In check_patch_format we feed $1 to a block that attempts to determine
the patch format. Since we've already redirected $1 to stdin there is no
need to redirect it again when we invoke tr. This prevents the following
errors when invoking git am
$ git am patch.patch
tr: write error: Broken
Patches created using gitk's write commit to file functionality (which
uses 'git diff-tree -p --pretty' under the hood) need some massaging in
order to apply cleanly. This consists of dropping the 'commit' line
automatically determining the subject and removing leading whitespace.
Signed-off-by:
This adds a tests which exercise the detection of the stgit format.
There is a current know breakage in that the code that deals with stgit
in split_patches can't handle reading from stdin.
Signed-off-by: Chris Packham judge.pack...@gmail.com
---
t/t4150-am.sh | 27 +++
1
This adds a tests which exercise the detection of the hg format. As
with stgit there is a current know breakage in where split_patches can't
handle reading from stdin with these patch formats.
Cc: Giuseppe Bilotta giuseppe.bilo...@gmail.com
Signed-off-by: Chris Packham judge.pack...@gmail.com
Hello,
Caveat: this is somewhat long, sorry.
Recently I've run into yet another rather tricky trouble with
pull/rebase. No, neither of my troubles is in the usual rewriting
published history group.
(The first trouble I ran earlier was caused by the fact that git pull
breaks local merges when
On Fri, Sep 5, 2014 at 10:26 AM, Scott Schmit i.g...@comcast.net wrote:
Each linked working tree has a private sub-directory in the repository's
$GIT_DIR/worktrees directory. The private sub-directory's name is usually
the base name of the linked working tree's path, possibly appended with a
On Fri, Sep 05, 2014 at 11:55:06AM +0200, Stefan Beller wrote:
struct remote {
+ struct hashmap_entry ent; /* must be first */
+
I stumbled about this comment /* must be first */
when reading the changelog.
Why does it need to be first?
Is it a common reason I'm just not aware
I'm not going to say what you *should* have done, since it's not clear
whether anything close to what you were doing is a supported workflow.
But I can tell you what I *do* myself. Personally, I vastly distrust
git pull --rebase.
So in general, my pulls are all the equivalent of git pull
Signed-off-by: Ralf Thielow ralf.thie...@gmail.com
---
po/TEAMS | 1 +
1 file changed, 1 insertion(+)
diff --git a/po/TEAMS b/po/TEAMS
index 461cc14..a33a38e 100644
--- a/po/TEAMS
+++ b/po/TEAMS
@@ -17,6 +17,7 @@ Members: Thomas Rast t...@thomasrast.ch
Christian Stimming
Chris Packham judge.pack...@gmail.com writes:
So teaching git mailinfo to do s/^// (either when asked to or
using some heuristic) would be a better approach? I also think we
should accept Author: as an acceptable fallback if From: is not
present.
Not as a fallback in the sense that
Here is a pair of commit which allow messages from git to be translated when
running an ambiguous checkout such as when a branch name and a tag name are the
same.
Sandy Carter (2):
i18n: ambiguous refname message is not translated
i18n translate builtin warning, error, usage, fatal messages
Allow warnings, errors, usage and fatal messages to be translated to user
when checking out a ambiguous refname for example
Signed-off-by: Sandy Carter sandy.car...@savoirfairelinux.com
---
usage.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/usage.c b/usage.c
Allow warning message about ambuiguous refname to be exported to .pot files
when checking out a refname which is the name of a tag and of a branch for
example.
Signed-off-by: Sandy Carter sandy.car...@savoirfairelinux.com
---
sha1_name.c | 6 +++---
1 file changed, 3 insertions(+), 3
Sandy Carter sandy.car...@savoirfairelinux.com writes:
Allow warnings, errors, usage and fatal messages to be translated to user
when checking out a ambiguous refname for example
Signed-off-by: Sandy Carter sandy.car...@savoirfairelinux.com
---
H. Doesn't this break the plumbing
Am 05.09.2014 12:06, schrieb Chris Packham:
In check_patch_format we feed $1 to a block that attempts to determine
the patch format. Since we've already redirected $1 to stdin there is no
need to redirect it again when we invoke tr. This prevents the following
errors when invoking git am
The first round is found at $gmane/255520.
The second round is found at $gmane/255701.
The third round is found at $gmane/256464.
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
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
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
---
builtin/receive-pack.c | 8 +---
1 file changed, 5 insertions(+), 3
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(+),
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
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
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
---
send-pack.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/send-pack.c
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
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
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
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
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
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
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
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 | 26
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
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
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
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 receiving end uses an HMAC
hash of the path to the
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
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(-)
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
Hi Johan,
Johan Herland writes:
A colleague of mine noticed that cherry-pick does not accept the
--no-verify option to skip running the pre-commit/commit-msg hooks.
neither git-cherry-pick nor git-revert execute the pre-commit or
commit-msg hooks at the moment. The underlying rationale can be
On Sat, Sep 6, 2014 at 8:26 AM, Johannes Sixt j...@kdbg.org wrote:
Am 05.09.2014 12:06, schrieb Chris Packham:
In check_patch_format we feed $1 to a block that attempts to determine
the patch format. Since we've already redirected $1 to stdin there is no
need to redirect it again when we
On Sat, Sep 6, 2014 at 6:29 AM, Junio C Hamano gits...@pobox.com wrote:
Chris Packham judge.pack...@gmail.com writes:
So teaching git mailinfo to do s/^// (either when asked to or
using some heuristic) would be a better approach? I also think we
should accept Author: as an acceptable
Chris Packham judge.pack...@gmail.com writes:
On Sat, Sep 6, 2014 at 8:26 AM, Johannes Sixt j...@kdbg.org wrote:
Am 05.09.2014 12:06, schrieb Chris Packham:
In check_patch_format we feed $1 to a block that attempts to determine
the patch format. Since we've already redirected $1 to stdin
Junio C Hamano gits...@pobox.com writes:
Also,
- tr -d '\015' $1 |
sed -n -e '/^$/q' -e '/^[ ]/d' -e p |
sane_egrep -v '^[!-9;-~]+:' /dev/null ||
patch_format=mbox
as the tr is at an upsteam of
On Fri, Sep 05, 2014 at 02:28:46PM +0400, Sergey Organov wrote:
...
# Then I realize I need more changes and it gets complex enough to
# warrant a topic branch. I create the 'topic' branch that will track
# 'master' branch and reset 'master' back to its origin (remote
# origin/master in
Junio C Hamano gits...@pobox.com writes:
Redoing what e3f67d30 (am: fix patch format detection for
Thunderbird Save As emails, 2010-01-25) tried to do without
wasting a fork and a pipe may be a workable improvement.
I see Stephen who wrote the original Thunderbird save-as is
already on the
(replying from webmail interface)
On Fri, Sep 5, 2014 at 3:25 PM, Junio C Hamano gits...@pobox.com wrote:
Junio C Hamano gits...@pobox.com writes:
Redoing what e3f67d30 (am: fix patch format detection for
Thunderbird Save As emails, 2010-01-25) tried to do without
wasting a fork and a pipe
49 matches
Mail list logo
