Hello,
My name is Mateusz Maciołek, I am a mobile developer and I am using
yours tool in my all projects. Last days I found special case. A
changed packages name (all letter to lowercase). After merge with
other branch there were still uppercase letters.All the rest code is
after refactoring.
Is
(replying from webmail interface)
On Fri, Sep 5, 2014 at 3:25 PM, Junio C Hamano wrote:
> Junio C Hamano 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 improvem
Junio C Hamano 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 Cc list.
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 ori
Junio C Hamano 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
Chris Packham writes:
> On Sat, Sep 6, 2014 at 8:26 AM, Johannes Sixt 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
On Sat, Sep 6, 2014 at 6:29 AM, Junio C Hamano wrote:
> Chris Packham 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
>> prese
On Sat, Sep 6, 2014 at 8:26 AM, Johannes Sixt 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 invoke tr. T
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
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
---
Documentation/technical/pack-protocol.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Docum
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
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 repository
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
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
---
send-pack.c | 36 +---
1 file chan
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
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
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
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 statu
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
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
---
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 b
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 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
---
send-pack.c | 4 +---
1 file changed, 1 insertion(+), 3 dele
Similar to the previous one for send-pack, make it easier and
cleaner to add to capability advertisement.
Signed-off-by: Junio C Hamano
---
builtin/receive-pack.c | 22 ++
1 file changed, 14 insertions(+), 8 deletions(-)
diff --git a/builtin/receive-pack.c b/builtin/receive-
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
---
send-pack.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/send-pack.c b/send-pack.c
index 0c
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
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
---
builtin/receive-pack.c | 8 +---
1 file changed, 5 insertions(+), 3 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
---
builtin/receive-pack.c | 50 +-
1 file changed, 29 insertions(+), 21 deletions(-)
di
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 a
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
>
Sandy Carter 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
> ---
H. Doesn't this break the plumbing commands whose messages are
meant to be matched and interpreted by s
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
---
sha1_name.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/sha1_name.c b/sha1
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
---
usage.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/usage.c b/usage.c
index ed14645..24a450e 100644
--- a/us
Chris Packham 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 "Author:" should no
Signed-off-by: Ralf Thielow
---
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
Christian Stimming
Phillip Szelat
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
--ff-on
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 ju
On Fri, Sep 5, 2014 at 10:26 AM, Scott Schmit 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
>> number to m
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
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
Signed-off-by: Chris Packham
---
Note. I don't have access to a mercurial reposit
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
---
t/t4150-am.sh | 27 +++
1 file changed, 27 insert
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:
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 filt
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 pipe
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
Junio C Hamano pobox.com> writes:
>
> Junio C Hamano pobox.com> writes:
>
> > I would suspect that this may be fine.
> >
> > "rev-parse --verify" makes sure the named object exists, but in this
> > case {u} does not even name any object, does it?
>
> Hmph, but "rev-parse --verify no-such-br
50 matches
Mail list logo
