> I timed this one versus the existing diff-highlight. It's about 7%
> slower. That's not great, but is acceptable to me. The String::Multibyte
> version was a lot faster, which was nice (but I'm still unclear on
> _why_).
I think the reason is here:
> sub split_line {
>local $_ = shift;
>
On Apr 2, 2015, at 18:24, Jeff King wrote:
On Thu, Apr 02, 2015 at 05:49:24PM -0700, Kyle J. McKay wrote:
Subject: [PATCH v2] diff-highlight: do not split multibyte characters
When the input is UTF-8 and Perl is operating on bytes instead
of characters, a diff that changes one multibyte chara
On Fri, Apr 03, 2015 at 02:02:15AM +0200, Torsten Bögershausen wrote:
> But not this one:
> ./git fetch-pack --diag-url
> ssh://git.kernel.org:/pub/scm/linux/kernel/git/mchehab/v4l-dvb.git
> Diag: url=ssh://git.kernel.org:/pub/scm/linux/kernel/git/mchehab/v4l-dvb.git
> Diag: protocol=ssh
> Diag
On Thu, Apr 02, 2015 at 05:49:24PM -0700, Kyle J. McKay wrote:
> Subject: [PATCH v2] diff-highlight: do not split multibyte characters
>
> When the input is UTF-8 and Perl is operating on bytes instead
> of characters, a diff that changes one multibyte character to
> another that shares an initia
Hi,
Today after I merged pull request from Ralf, I found there is one new
l10n update from Git 2.4.0-rc1. I also checked the 4 potential feature
branches ("Will merge to master") documented in whats-cooking.txt,
and I guess this is the last round for 2.4.0 l10n.
The new "git.pot" is generated in
On Apr 2, 2015, at 15:09, Junio C Hamano wrote:
* jc/show-branch (2014-03-24) 5 commits
- show-branch: use commit slab to represent bitflags of arbitrary
width
- show-branch.c: remove "all_mask"
- show-branch.c: abstract out "flags" operation
- show-branch.c: lift all_mask/all_revs to a globa
On Mar 30, 2015, at 15:16, Jeff King wrote:
> Yeah, I agree the current output is not ideal, and this should address
> the problem. I was worried that multi-byte splitting would make things
> slower, but in my tests, it actually speeds things up!
[...]
> Unfortunately, String::Multibyte is not a
On 2015-04-02 21.35, Jeff King wrote:
> On Thu, Apr 02, 2015 at 12:31:14PM -0700, Reid Woodbury Jr. wrote:
>
>> Ah, understand. Here's my project URL for 'remote "origin"' with a
>> more meaningful representation of their internal FQDN:
>>
>> url = ssh://rwoodbury@systemname.groupname.online:
Junio –
I see you changed my commit message a bit, but some mistakes seem to
have slipped in:
> checkout: call a single commit “it” instead of “th
“them” was cut off, including the trailing quotation mark.
[…]
> them ..."” even for only one commit.
Two quotation marks?
I always use the “right” qu
After looking at $gmane/264000 again, maybe the client should talk first
stating all the relevant information it wants to get, though I realize this
is not part of capabilities so maybe it could even before, such as:
Client: All I want to do is an ls-remote, so only Phase 2, no
transmission of blo
On Thu, Apr 2, 2015 at 3:18 PM, Martin Fick wrote:
>> The current protocol has the following problems that limit
>> us:
>>
>> - It is not easy to make it resumable, because we
>> recompute every time. This is especially problematic for
>> the initial fetch aka "clone" as we will be talking about
Martin Fick writes:
>> The current protocol has the following problems that limit
>> us:
>>
>> - It is not easy to make it resumable, because we
>> recompute every time. This is especially problematic for
>> the initial fetch aka "clone" as we will be talking about
>> a large transfer. Redirec
> The current protocol has the following problems that limit
> us:
>
> - It is not easy to make it resumable, because we
> recompute every time. This is especially problematic for
> the initial fetch aka "clone" as we will be talking about
> a large transfer. Redirection to a bundle hosted on CD
On Thu, Apr 02, 2015 at 03:09:15PM -0700, Junio C Hamano wrote:
> + if (isalnum(ch) ||
> + ch == '-' || ch == '.' ||
> + ch == '/' || ch == '+' ||
> + ch == '=' || ch == '_')
> + continue;
I think this looks good. Ear
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
The first release candidate 2.4-rc1 has been tagged. I'll still
take small and trivial fixes and documentation updates but let's
really shift o
Instead of blindly trusting the receiving side to give us a sensible
nonce to sign, limit the length (max 256 bytes) and the alphabet
(alnum and a few selected punctuations, enough to encode in base64)
that can be used in nonce.
Noticed-by: Jann Horn
Signed-off-by: Junio C Hamano
---
send-pack.
A release candidate Git v2.4.0-rc1 is now available for testing at
the usual places. The changes since the early preview 2.4.0-rc0 is
minimum. Please give it a good testing.
The tarballs are found at:
https://www.kernel.org/pub/software/scm/git/testing/
The following public repositories al
Dr Harry Thomas
Brondesbury, North West
Londyn Anglia
Drogi Przyjacielu.
Jestem dr Harry Thomas z Brondesbury, North West London, tutaj w Anglii.
Pracuję dla UBS Investment Bank Londyn. Piszę wam o propozycji biznesowych,
które będą z ogromną korzyścią dla nas obu. W moim departamencie, jak
Alex Henrie writes:
> This is a follow-up to commit 9c9b4f2f8b7f27f3984e80d053106d5d41cbb03b.
>
> Signed-off-by: Alex Henrie
> ---
Thanks, but please no more _("string") changes for the rest of the
cycle, as that would impact i18n folks who will be starting from
tagged -rc releases.
Please hol
On Thu, Apr 02, 2015 at 02:42:30PM +0200, Carl Mäsak wrote:
> In the following session, a 'git merge' command shows some output even
> with the '--quiet' flag supplied.
>
> ~/tmp $ git init example
> Initialized empty Git repository in /tmp/example/.git/
> ~/tmp $ cd example/
> ~/
Signed-off-by: Alex Henrie
---
builtin/branch.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/branch.c b/builtin/branch.c
index 1d15037..c0b4bae 100644
--- a/builtin/branch.c
+++ b/builtin/branch.c
@@ -972,7 +972,7 @@ int cmd_branch(int argc, const char **argv, const
This is a follow-up to commit 9c9b4f2f8b7f27f3984e80d053106d5d41cbb03b.
Signed-off-by: Alex Henrie
---
builtin/blame.c | 2 +-
builtin/log.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/builtin/blame.c b/builtin/blame.c
index 06484c2..0b2f4ed 100644
--- a/builtin/blam
Luke Diamand writes:
> (+Pete for interest).
>
> On 31 March 2015 at 22:54, Holloway, Blair
> wrote:
>> If a Perforce server is configured to automatically set +l (exclusive lock)
>> on
>> add of certain file types, git p4 submit will fail during getP4OpenedType, as
>> the regex doesn't expect
On Thu, Apr 02, 2015 at 11:34:09PM +0300, Max Kirillov wrote:
> For diff --cc, paths fitering used to select only paths which have
> changed in all parents, while diffing itself output hunks which are
> changed in as few as 2 parents.
I'm confused about "used to" here. Is this a regression due to
This partially reverts commit 8d849957d81fc0480a52570d66cc3c2a688ecb1b.
This change makes the string "OK" translatable and the string "mc" not
translatable. It will take effect the next time `make update-po` is run.
Signed-off-by: Alex Henrie
---
gitk | 4 ++--
1 file changed, 2 insertions(+),
Signed-off-by: Alex Henrie
---
gitk | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gitk b/gitk
index 9a2daf3..30fcd30 100755
--- a/gitk
+++ b/gitk
@@ -4066,7 +4066,7 @@ set known_view_options {
{committer t15 . "--committer=*" {mc "Committer:"}}
{loginfo t15 .
Max Kirillov writes:
Again, just surface nitpicks.
[side: Kirill Smelkov removed from CC, as the
ddress just bounced for me]
> +static int changed_parents(struct combine_diff_path *p, int n)
> +{
> + int parent_idx;
> + int result = 0;
> +
> + for (parent_idx = 0; parent_idx < n; +
Max Kirillov writes:
> If a hunk has been changed in both branches and conflict resolution
> fully takes one of branches, discarding all changes that are in the
> other, then the merge is not shown in 3-way diff which git uses by
> default.
>
> The advice is to use flag --cc and and explicitly ad
When merged to 'pu', this seems to break at least 5309 and 5300
tests (there might be others, but I didn't check).
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.ht
For diff --cc, paths fitering used to select only paths which have
changed in all parents, while diffing itself output hunks which are
changed in as few as 2 parents.
Fix intersect_paths() to add paths which have at least 2 changed
parents.
Intersects with branch 'bc/object-id' which is not yet i
If a hunk has been changed in both branches and conflict resolution
fully takes one of branches, discarding all changes that are in the
other, then the merge is not shown in 3-way diff which git uses by
default.
The advice is to use flag --cc and and explicitly add the mergebase was
given in $gman
For diff --cc, paths fitering used to select only paths which have
changed in all parents, while diffing itself output hunks which are
changed in as few as 2 parents.
Fix intersect_paths() to add paths which have at least 2 changed
parents. In this new functionality does not require special treatm
Signed-off-by: Max Kirillov
---
combine-diff.c | 43 ---
1 file changed, 24 insertions(+), 19 deletions(-)
diff --git a/combine-diff.c b/combine-diff.c
index 8eb7278..a236bb5 100644
--- a/combine-diff.c
+++ b/combine-diff.c
@@ -22,6 +22,28 @@ static int co
Looks like there is no exact specification what `diff -c` and
`diff --cc` should output. Considering this it is not reasonable to
hardcode any specific output in test. Rather, it should verify that file
selection behaves the same as hunk selection.
Rewrite test so that it makes sure that a "short"
2015-04-02 22:06 GMT+02:00 Reid Woodbury Jr. :
> I'm sure I've seen it other places but I can't remember right now.
What you mean is the scp-like syntax: user@host:path/relative/to/home
– but if you write user@host:/path/to/something, it’s relative to /.
You can also achieve paths relative to the h
Yup, removing the colon works in both 2.3.3 and 2.3.4. And I see that the
manual doesn't use the colon! (eg. $ git clone ssh://user@server/project.git).
The usage of the colon looks normal to my eyes because, for instance, SFTP uses
it to set the path on login so this wasn't something I would ha
(+Pete for interest).
On 31 March 2015 at 22:54, Holloway, Blair
wrote:
> If a Perforce server is configured to automatically set +l (exclusive lock) on
> add of certain file types, git p4 submit will fail during getP4OpenedType, as
> the regex doesn't expect the trailing '*exclusive*' from p4 op
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I can't seem to get gitk to show notes, even when I give it --notes.
Does it just not handle notes?
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (MingW32)
iQEcBAEBAgAGBQJVHZm5AAoJENRVrw2cjl5RT0wIAJVfE2cDQODUCoOsIwhVDiMf
CNeTKy1VxCgwVy8KDoYxY2
On Thu, Apr 02, 2015 at 12:31:14PM -0700, Reid Woodbury Jr. wrote:
> Ah, understand. Here's my project URL for 'remote "origin"' with a
> more meaningful representation of their internal FQDN:
>
> url = ssh://rwoodbury@systemname.groupname.online:/opt/git/inventory.git
>
> The "online" is
Ah, understand. Here's my project URL for 'remote "origin"' with a more
meaningful representation of their internal FQDN:
url = ssh://rwoodbury@systemname.groupname.online:/opt/git/inventory.git
The "online" is their literal internal TLD.
Reid
> On Apr 2, 2015, at 12:24 PM, Junio C Ham
Jeff King writes:
> but this does not:
>
> $ git push ssh://does-not-exist:/repo.git
> ssh: Could not resolve hostname does-not-exist:: No address associated with
> hostname
>
> (note the doubled colon). v2.3.3 did strip off that extra colon, but I
> am not sure the URL above (i.e., a colon
On Thu, Apr 02, 2015 at 11:58:13AM -0700, Reid Woodbury Jr. wrote:
> The colons were part of the output. The '' replaces the domain in
> the response.
OK, if the double colons are correct, then that is almost certainly the
problem:
$ ssh does-not-exist
ssh: Could not resolve hostname doe
Karthik Nayak writes:
> +static int unpack_sha1_header_to_strbuf(git_zstream *stream, unsigned char
> *map,
> + unsigned long mapsize,
> + struct strbuf *header)
> +{
> + unsigned char buffer[32], *cp;
> + unsigned l
Karthik Nayak writes:
> Currently 'git cat-file' throws an error while trying to
> print the type or size of a broken/corrupt object which is
> created using 'git hash-object --literally'. This is
> because these objects are usually of unknown types.
>
> Teach git cat-file a '--literally' option
Peff
The colons were part of the output. The '' replaces the domain in the
response. The domain is an internal one that my client would rather keep
private. But this got me to think that this might be an important detail: I am
using GIT from a remote node on a Cisco AnyConnect VPN with DNS s
Jeff King wrote:
> OK, dropped. Here's the re-roll.
Thanks.
> -- >8 --
> Subject: [PATCH] init: don't set core.worktree when initializing /.git
[...]
> No tests, as we would need to be able to write to "/" to do
> so.
This is confusing in the light of t1509-root-worktree.sh existing, but
anyone
On Tue, Mar 31, 2015 at 12:14:20PM -0700, Jonathan Nieder wrote:
> > No tests, as we would need to be able to write to "/" to do
> > so.
>
> t1509-root-worktree.sh is supposed to test the repository-at-/ case.
> But I wouldn't be surprised if it's bitrotted, since people don't set
> up a throwawa
On Thu, Apr 02, 2015 at 10:18:33AM -0700, Reid Woodbury Jr. wrote:
> After upgrading from GIT 2.3.3 to 2.3.4 (on Mac OS X 10.10.2,
> installed with MacPorts) I received this error message when doing a
> push:
>
> $ git push
> ssh: Could not resolve hostname :: nodename nor servname provided,
Ralf Thielow writes:
> If --signed is not supported, the error message names the remote
> "receiving end". If --atomic is not supported, the error message
> names the remote "server". Unify the naming to "receiving end"
> as we're in the context of "push".
>
> Signed-off-by: Ralf Thielow
> ---
If --signed is not supported, the error message names the remote
"receiving end". If --atomic is not supported, the error message
names the remote "server". Unify the naming to "receiving end"
as we're in the context of "push".
Signed-off-by: Ralf Thielow
---
send-pack.c | 2 +-
1 file changed,
On Thu, Apr 2, 2015 at 12:15 PM, Shawn Landden wrote:
> [RFC 2] systemd socket activation support
Rephrase this as:
[PATCH/RFC v2] daemon: add systemd support
> systemd support git-daemon's --inetd mode as well.
Unable to make sense of this sentence (fragment). A better commit
message woul
Dear Sirs
After upgrading from GIT 2.3.3 to 2.3.4 (on Mac OS X 10.10.2, installed with
MacPorts) I received this error message when doing a push:
$ git push
ssh: Could not resolve hostname :: nodename nor servname provided, or not
known
fatal: Could not read from remote repository.
It was
Junio C Hamano venit, vidit, dixit 30.03.2015 23:12:
> Jonathon Mah writes:
>
>> During a few years of discussing git operations with colleagues, I’ve
>> found the “git rebase --onto” operation particularly ambiguous. The
>> reason is that I always describe a rebase operation as “onto”
>> somethi
On Thu, Apr 2, 2015 at 8:47 AM, Junio C Hamano wrote:
> Eric Sunshine writes:
>
>> On Wed, Apr 1, 2015 at 9:23 PM, Shawn Landden wrote:
>>> From: Shawn Landden
>>>
>>> [PATCH] systemd socket activation support
>>
>> This patch feels like an RFC rather than a properly fleshed-out
>> submission.
systemd support git-daemon's --inetd mode as well.
v2: actually test...
Signed-off-by: Shawn Landden
---
Documentation/git-daemon.txt | 25 +++
Makefile | 1 +
daemon.c | 35 --
sd-daemon.c | 152 ++
On 04/02/2015 06:59 PM, Junio C Hamano wrote:
Mikko Perttunen writes:
Of course this is probably rather hard to fix on the applying end; but
perhaps format-patch could check for ambiguous chunks and either warn
the user or increase the context size automatically, or apply could
warn about the
Mikko Perttunen writes:
> Of course this is probably rather hard to fix on the applying end; but
> perhaps format-patch could check for ambiguous chunks and either warn
> the user or increase the context size automatically, or apply could
> warn about the chunk being ambiguous?
Interesting thoug
Eric Sunshine writes:
> On Wed, Apr 1, 2015 at 9:23 PM, Shawn Landden wrote:
>> From: Shawn Landden
>>
>> [PATCH] systemd socket activation support
>
> This patch feels like an RFC rather than a properly fleshed-out
> submission. If so, indicate such in the subject. Also, mention the
> area you
Hello everyone,
we recently ran into a kernel bug caused by git misapplying this patch:
https://lkml.org/lkml/2014/7/3/896 .
The chunk '@@ -653,6 +655,7 @@' in tegra124.dtsi (the second file in the
patch) has ambiguous context (there are several almost identical PHY
nodes in the file). Git a
Duy Nguyen writes:
> On Wed, Apr 1, 2015 at 2:58 AM, Junio C Hamano wrote:
>> This is a follow-up on $gmane/264553, which is a continuation of
>> $gmane/264000, but instead of giving two required readings to
>> readers, I'll start with reproduction of the two, and add a few more
>> things the cu
In the following session, a 'git merge' command shows some output even
with the '--quiet' flag supplied.
~/tmp $ git init example
Initialized empty Git repository in /tmp/example/.git/
~/tmp $ cd example/
~/tmp/example $ git commit --allow-empty -m'initial commit'
[master (root
On Wed, Apr 1, 2015 at 2:58 AM, Junio C Hamano wrote:
> This is a follow-up on $gmane/264553, which is a continuation of
> $gmane/264000, but instead of giving two required readings to
> readers, I'll start with reproduction of the two, and add a few more
> things the current protocol lacks that I
Signed-off-by: Karthik Nayak
---
t/t1006-cat-file.sh | 27 +++
1 file changed, 27 insertions(+)
diff --git a/t/t1006-cat-file.sh b/t/t1006-cat-file.sh
index a72e700..3015062 100755
--- a/t/t1006-cat-file.sh
+++ b/t/t1006-cat-file.sh
@@ -47,6 +47,18 @@ $content"
te
Signed-off-by: Karthik Nayak
---
Documentation/git-cat-file.txt | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/Documentation/git-cat-file.txt b/Documentation/git-cat-file.txt
index f6a16f4..8bac7bd 100644
--- a/Documentation/git-cat-file.txt
+++ b/Documentation/git-cat-f
Currently 'git cat-file' throws an error while trying to
print the type or size of a broken/corrupt object which is
created using 'git hash-object --literally'. This is
because these objects are usually of unknown types.
Teach git cat-file a '--literally' option where it prints
the type or size of
Update sha1_loose_object_info() to optionally allow it to read
from a loose object file of unknown/bogus type; as the function
usually returns the type of the object it read in the form of enum
for known types, add an optional "typename" field to receive the
name of the type in textual form and a f
The changes made in this version are :
* unpack_sha1_header_to_strbuf() now checks for Z_STREAM_END and also
the return is not changed to status (as per Junios suggestion) as this
breaks the check done in sha1_loose_object_info() as the return is
sometimes Z_BUF_ERROR (-5).
* In sha1_loose_o
Junio C Hamano writes:
> Sergey Organov writes:
>
>> Nope. It seems like cherry-pick takes care of that:
>> ...
>> What do I miss?
>
> The fact that cherry-pick did not flag it as a potential conflict
> situation where a manual verification is required
> (the cherry-pick process can be fooled by
68 matches
Mail list logo
