On Mon, Jul 13, 2015 at 2:36 PM, Junio C Hamano wrote:
> Eric Sunshine writes:
>> This series eliminates git-checkout from the picture by instead
>> employing "git reset --hard"[2] to populate the new worktree initially.
>
> A few comments on things I noticed while reading (mostly coming from
> t
Hello
Recently, I have had trouble using git send-email to send a patchset.
After the confirmation to send the email I get the following:
Send this email? ([y]es|[n]o|[q]uit|[a]ll): y
[Net::SMTP::SSL] Connection closed at /usr/lib/git-core/git-send-email
line 1320.
fatal: 'send-email' appears to b
From: "Philip Oakley"
Sent: Friday, June 26, 2015 12:34 AM
From: "Junio C Hamano"
"Philip Oakley" writes:
From: "Junio C Hamano"
I am not sure what this patch is trying to achieve.
I have been able to repeat the issue, more below.
It was probably a bit of 'don't mess with working co
Acked-by: Phillip Sz
>Signed-off-by: Ralf Thielow
>---
> po/de.po | 28 ++--
> 1 file changed, 10 insertions(+), 18 deletions(-)
>
>diff --git a/po/de.po b/po/de.po
>index 64070cd..6ed3509 100644
>--- a/po/de.po
>+++ b/po/de.po
>@@ -10463,14 +10463,12 @@ msgid "print tag
Hi Johannes,
thanks for explaining why re-installing fixed my problem. Although I still
can't wrap my head around why it happened in the first place. It could only be
caused by Windows moving the base address of one, but not the other thus
causing the overlap. Sounds weird. But then again, what
Hi,
I believe there's something wrong with diff-tree's --ignore-space-change option
in conjunction with --quiet. In Git's repo, I get
$ git --version
git version 2.4.5
$ git diff-tree --quiet --ignore-space-change
c925fe23684455735c3bb1903803643a24a58d8f ; echo $?
c925fe23684455735c3bb19038036
On Tue, Jul 14, 2015 at 9:42 AM, wrote:
> From: Beat Bolli
>
> When referencing earlier commits in new commit messages or other text,
> one of the established formats is
>
> commit ("", )
That sounds like I would use it a lot! Thanks :)
>
> Add a "Copy commit summary" command to the conte
On Tue, Jul 14, 2015 at 12:59 AM, Olaf Hering wrote:
> On Tue, Jul 14, John Keeping wrote:
>
>> It was added in an evil merge (f9da455b93f6ba076935b4ef4589f61e529ae046),
That's not an evil merge. That's just a regular merge. One side had
changed the argument to "const":
- 1b9d48f2a579 ("hyper-v
>
>> A few weeks ago we weren’t able to clone and get an error: could not commit
>> /vagrant/.git/config file. Manually we were able to change that file and
>> also the clone command works outside the shared folder.
>
> Why are you trying to commit a file inside the .git dir? Files in that
> dir
Hi,
I don't know if this helps you, but I found two strange things with your
history that I want to point out.
On Tue, Jul 14, 2015 at 05:49:43PM +0200, Peter Hüfner wrote:
> The problem:
> For development we are using virtual box controlled via vagrant with a shared
> folder on windows and mac h
Translate 9 new messages came from git.pot update in a4156d2
(l10n: git.pot: v2.5.0 round 2 (9 new, 5 removed)).
Signed-off-by: Ralf Thielow
---
po/de.po | 28 ++--
1 file changed, 10 insertions(+), 18 deletions(-)
diff --git a/po/de.po b/po/de.po
index 64070cd..6ed3509
Olaf Hering writes:
> On Tue, Jul 14, John Keeping wrote:
>
>> It was added in an evil merge (f9da455b93f6ba076935b4ef4589f61e529ae046),
>> try:
>>
>> git log -p -M --stat --cc -- drivers/hv/channel_mgmt.c
>
> Thanks. Thats rather useless output...
Why do you think this is useless?
> @@@
On Tue, Jul 14, 2015 at 2:34 AM, Paul Tan wrote:
> On Tue, Jul 14, 2015 at 3:05 AM, Stefan Beller wrote:
>> All returns before this point leak the memory of `lock_file`.
>
> Yeah, it's intentional. From Documentation/technical/api-lockfile.txt:
>
> * Allocates a `struct lock_file` either as a sta
From: Beat Bolli
When referencing earlier commits in new commit messages or other text,
one of the established formats is
commit ("", )
Add a "Copy commit summary" command to the context menu that puts this
text for the currently selected commit on the clipboard. This makes it
easy for our
(I haven't been able to do more debugging yet,
but this doesn't fully work on my Mac OS X box:)
Initialized empty Git repository in
/Users/tb/NoBackup/projects/git/tb.150714_Duy_grep_utf8/t/trash
directory.t7812-grep-icase-non-ascii/.git/
# lib-gettext: Found 'is_IS.UTF-8' as an is_IS UTF-8 locale
On Tue, Jul 14, 2015 at 5:53 AM, Michael J Gruber
wrote:
>> Eric Sunshine writes:
>>> This is a follow-on series to [1], which migrated "git checkout --to"
>>> functionality to "git worktree add". That series continued using "git
>>> checkout" for the initial population of the new worktree, which
Dear git-Team,
we recognized a behavior that comes up with a newer git version. Unfortunately
we do not know which version exactly.
The problem:
For development we are using virtual box controlled via vagrant with a shared
folder on windows and mac hosts. The virtual OS ist ubuntu 14.04.2 LTS. I
On Tue, Jul 14, 2015 at 12:05:58AM +0100, Philip Oakley wrote:
> It looks like Git has a healthy truck factor of 8, as reported in
> https://mtov.github.io/Truck-Factor/, which has Git eighth in the list of
> projects it analyzed, with Linux at second place.
>
> The analysis method paper is behin
On Tue, Jul 14, 2015 at 3:19 AM, Junio C Hamano wrote:
>
> * kn/for-each-tag-branch (2015-07-13) 11 commits
> - for-each-ref: add '--contains' option
> - ref-filter: implement '--contains' option
> - parse-options.h: add macros for '--contains' option
> - parse-option: rename parse_opt_with_co
There's another regcomp code block coming in this function. By moving
the error handling code out of this block, we don't have to add the
same error handling code in the new block.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
diffcore-pickaxe.c | 16
1 file changed, 8 insertions(+),
Similar to the "grep -F -i" case, we can't use kws on icase search
outside ascii range, so we quote the string and pass it to regcomp as
a basic regexp and let regex engine deal with case sensitivity.
The new test is put in t7812 instead of t4209-log-pickaxe because
lib-gettext.sh might cause prob
This function returns true if git is running under an UTF-8
locale. pcre in the next patch will need this.
is_encoding_utf8() is used instead of strcmp() to catch both "utf-8"
and "utf8" suffixes.
When built with no gettext support, we peek in several env variables
to detect UTF-8. pcre library m
In the previous change in this function, we add locale support for
single-byte encodings only. It looks like pcre only supports utf-* as
multibyte encodings, the others are left in the cold (which is
fine).
We need to enable PCRE_UTF8 so pcre can find character boundary
correctly. It's needed for
The default tables are usually built with C locale and only suitable
for LANG=C or similar. This should make case insensitive search work
correctly for all single-byte charsets.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
grep.c | 8 ++--
grep.h
When we detect the pattern is just a literal string, we avoid heavy
regex engine and use fast substring search implemented in kwsset.c.
But kws uses git-ctype which is locale-independent so it does not know
how to fold case properly outside ascii range. Let regcomp or pcre
take care of this case in
Similar to the previous commit, we can't use kws on icase search
outside ascii range. But we can't simply pass the pattern to
regcomp/pcre like the previous commit because it may contain regex
special characters, so we need to quote the regex first.
To avoid misquote traps that could lead to undef
Signed-off-by: Nguyễn Thái Ngọc Duy
---
grep.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/grep.c b/grep.c
index b58c7c6..bd32f66 100644
--- a/grep.c
+++ b/grep.c
@@ -403,9 +403,11 @@ static void compile_regexp(struct grep_pat *p, struct
grep_opt *opt)
p->wo
-F means "no regex", not "case sensitive" so it should not override -i
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/grep.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/grep.c b/builtin/grep.c
index d04f440..2d392e9 100644
--- a/builtin/grep.c
+++ b/builtin/grep.
Compared to v2
- fix grep/pcre on utf-8 even in case is sensitive
- peek at $LANG and friends anyway for utf-8 detection even
when gettext support is not built in git
- s/quote we quote/so we quote/ in 9/9
- rename t7813, s/non-ascii/iso/
Nguyễn Thái Ngọc Duy (9):
grep: allow -F -i combi
Signed-off-by: Sunil Kata
---
Documentation/git-merge.txt | 8 +++-
builtin/merge.c | 8 +++-
rerere.h| 2 ++
3 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt
index 273a100..6c60286 10
Signed-off-by: Sunil Kata
---
Documentation/git-merge.txt | 8 +++-
builtin/merge.c | 8 +++-
rerere.h| 2 ++
3 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt
index 273a100..6c60286 10
Signed-off-by: Sunil Kata
---
Documentation/git-merge.txt | 8 +++-
builtin/merge.c | 8 +++-
rerere.h| 2 ++
3 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt
index 273a100..6c60286 10
On Thu, Jul 9, 2015 at 5:17 PM, Erik Faye-Lund wrote:
> On Jun 29, 2015 10:06 PM, "Stefan Beller" wrote:
>>
>> On Sun, Jun 28, 2015 at 7:06 AM, Paul Tan wrote:
>> > The -b/--binary option was initially implemented in 087b674 (git-am:
>> > --binary; document --resume and --binary., 2005-11-16). T
On Tue, Jul 14, 2015 at 4:53 PM, Michael J Gruber
wrote:
> Related to that, I'm interested in "worktree list", and I'm wondering
> how many more worktree commands we foresee, and therefore how much
> refactoring should be done: Currently, the parsing of the contents of
> .../worktrees/ into worktr
On Mon, Jul 13, 2015 at 03:31:37PM -0700, Junio C Hamano wrote:
> A fix is to edit the patch to replace that "flags);" line with full
> "return delete_ref()" line and save it. Then running
>
> $ git am
>
> (no argument) is supposed to read from the corrected patch file and
> continue the appli
Junio C Hamano venit, vidit, dixit 13.07.2015 20:36:
> Eric Sunshine writes:
>
>> This is a follow-on series to [1], which migrated "git checkout --to"
>> functionality to "git worktree add". That series continued using "git
>> checkout" for the initial population of the new worktree, which requi
On Thu, Jul 9, 2015 at 4:44 AM, Johannes Sixt wrote:
> Am 02.07.2015 um 20:16 schrieb Paul Tan:
>> diff --git a/t/t3901-i18n-patch.sh b/t/t3901-i18n-patch.sh
>> index 75cf3ff..b49bdb7 100755
>> --- a/t/t3901-i18n-patch.sh
>> +++ b/t/t3901-i18n-patch.sh
>> @@ -251,4 +251,66 @@ test_expect_success '
On Tue, Jul 14, 2015 at 3:05 AM, Stefan Beller wrote:
> All returns before this point leak the memory of `lock_file`.
Yeah, it's intentional. From Documentation/technical/api-lockfile.txt:
* Allocates a `struct lock_file` either as a static variable or on the
heap, initialized to zeros. Once y
On Wed, Jul 8, 2015 at 4:14 AM, Junio C Hamano wrote:
> Paul Tan writes:
>
>> @@ -82,6 +84,8 @@ struct am_state {
>> /* number of digits in patch filename */
>> int prec;
>>
>> + int threeway;
>> +
>> int quiet;
>>
>> int append_signoff;
>
> These "one line surrounded
Hi Christoph,
On 2015-07-13 14:24, Christoph Murczek wrote:
> Just wanted to let you know: a re-install of git also fixed the problem.
That is probably because your original report (which I do not quote because
that was made too inconvenient by top-posting, sorry) suggests that the culprit
was
A line in the input to "rev-parse --parseopt" describes an option by
listing a short and/or long name, optional flags [*=?!], argument hint,
and then whitespace and help string.
We did not allow any of the [*=?!] characters in the argument hints.
The following input
pair=key=value equals sig
On Tue, Jul 14, John Keeping wrote:
> It was added in an evil merge (f9da455b93f6ba076935b4ef4589f61e529ae046),
> try:
>
> git log -p -M --stat --cc -- drivers/hv/channel_mgmt.c
Thanks. Thats rather useless output...
@@@ -404,7 -365,7 +404,7 @@@ static u32 next_vp
* performance critic
On Tue, Jul 14, 2015 at 09:30:35AM +0200, Olaf Hering wrote:
>
> I wonder why this command fails to show all commits that modify a given
> function:
>
> linux.git $ git log -p -M --stat -- drivers/hv/channel_mgmt.c
>
> With commit 1f656ff3fdddc2f59649cc84b633b799908f1f7b init_vp_index() has
>
I wonder why this command fails to show all commits that modify a given
function:
linux.git $ git log -p -M --stat -- drivers/hv/channel_mgmt.c
With commit 1f656ff3fdddc2f59649cc84b633b799908f1f7b init_vp_index() has
"const uuid_le *type_guid" already. And somewhere between commit
d3ba720dd58
44 matches
Mail list logo
