On Tue, Sep 06, 2016 at 04:30:24PM -0700, Jonathan Tan wrote:
> On 09/06/2016 03:08 PM, Jonathan Tan wrote:
> > On 09/02/2016 07:23 PM, Junio C Hamano wrote:
> > > A slightly related tangent. An unconditionally good change you
> > > could make is to allow folding of in-body headers. I.e. you can
The process spawned in the hook uses the test's trash directory as CWD.
As long as it is alive, the directory cannot be removed on Windows.
Although the test succeeds, the 'test_done' that follows produces an
error message and leaves the trash directory around. Kill the process
before the test case
On 09/06/2016 04:25 PM, Jakub Narębski wrote:
> W dniu 04.09.2016 o 18:08, Michael Haggerty pisze:
>
>> +/*
>> + * Check whether an attempt to rename old_refname to new_refname would
>> + * cause a D/F conflict with any existing reference (other than
>> + * possibly old_refname). If there would be
Josh Triplett wrote:
> On Tue, Aug 16, 2016 at 09:27:04PM +, Eric Wong wrote:
> > As for other projects, I'm not aware of anybody else using it,
> > yet. I have some small projects using it, but most of those are
> > one-off throwaways and I'm not comfortable promoting those along
> > with pu
On 09/06/2016 03:08 PM, Jonathan Tan wrote:
On 09/02/2016 07:23 PM, Junio C Hamano wrote:
A slightly related tangent. An unconditionally good change you
could make is to allow folding of in-body headers. I.e. you can
have e.g.
-- >8 --
Subject: [PATCH] sequencer: support in-body heade
On 09/02/2016 07:23 PM, Junio C Hamano wrote:
Jonathan Tan writes:
Sample-field: multiple-line field body
that causes a blank line below
I am not sure this is unconditionally good, or may cause problems to
those with workflows you did not consider when you wrote this patch.
Not being too l
larsxschnei...@gmail.com wrote:
> static int ce_compare_data(const struct cache_entry *ce, struct stat *st)
> {
> int match = -1;
> - int fd = open(ce->name, O_RDONLY);
> + int fd = open(ce->name, O_RDONLY | O_CLOEXEC);
>
> if (fd >= 0) {
> unsigned char sha1[2
On 9/6/16, Torsten Bögershausen wrote:
> On 06.09.16 19:47, john smith wrote:
>> I am looking for a way to force smudge filter to run by simulating a
>> real life checkout. Let's say I just created a new branch and did not
>> modify any files but want to test my new smudge filter. According to
>>
Johannes,
You know what, lets end it.
You are right and I am sorry.
Have a great life.
--
-Best
Idan
On Tue, Sep 6, 2016 at 3:00 PM, Stefan Beller wrote:
> On Fri, Sep 2, 2016 at 12:22 PM, Dakota Hawkins
> wrote:
>> Below is a simple reproduction of the issue.
>>
>> The _real_ problem is that this is how our pull request merges work,
>
> So your workflow is the problem or is the actual bug just
On 06.09.16 19:47, john smith wrote:
> I am looking for a way to force smudge filter to run by simulating a
> real life checkout. Let's say I just created a new branch and did not
> modify any files but want to test my new smudge filter. According to
> some answers such as
> https://stackoverflow.c
Hi,
Quoting Jeff King :
On Tue, Sep 06, 2016 at 03:07:59AM +0200, SZEDER Gábor wrote:
So that seems wrong. Even weirder, if I set _only_ "-beta", I get:
$ git tag -l --sort=version:refname | grep -v ^2.6.0
2.6.0-beta-2
2.6.0-beta-3
2.6.0-beta-4
2.6.0
2.6.0-RC1
2.6.0-RC2
2.6.0-beta-
The highlight binary can detect language by shebang when we can't tell
the syntax type by the name of the file. To use highlight's shebang
detection, add highlight to the pipeline whenever highlight is enabled.
Document the shebang detection and add a test which exercises it in
t/t9500-gitweb-stan
From: "Johannes Schindelin"
Hi Philip,
On Sun, 4 Sep 2016, Philip Oakley wrote:
From: "Johannes Schindelin"
> The point is that fixup! messages are really special, and are always
> intended to be squashed into the referenced commit *before* the latter
> hits `master`.
I think it's here tha
On Fri, Sep 2, 2016 at 12:22 PM, Dakota Hawkins wrote:
> Below is a simple reproduction of the issue.
>
> The _real_ problem is that this is how our pull request merges work,
So your workflow is the problem or is the actual bug just exposed in
your workflow?
> they're not allowed to do fast-forw
If we found bad instruction lines in the instruction sheet
of interactive rebase, we give the user advice on how to
fix it. However, we don't tell the user what to do afterwards.
Give the user advice to run 'git rebase --continue' after
the fix.
Signed-off-by: Ralf Thielow
---
Changes in v2:
- a
On Sun, Sep 4, 2016 at 1:17 PM, Christian Couder
wrote:
> Goal
>
>
> This is a patch series about libifying `git apply` functionality, and
> using this libified functionality in `git am`, so that no 'git apply'
> process is spawn anymore. This makes `git am` significantly faster, so
> `git re
2016-09-06 20:08 GMT+02:00 Ralf Thielow :
> - warn "$(gettext "You can fix this with 'git rebase
> --edit-todo'.")"
> + warn "$(gettext "You can fix this with 'git rebase
> --edit-todo' and then run 'git rebase --continue'.")"
> die "$(gettext "Or you c
On Mon, Sep 05, 2016 at 05:45:02PM +0200, Johannes Schindelin wrote:
> Typically, on Linux the test passes. On Windows, it fails virtually
> every time due to an access violation (that's a segmentation fault for
> you Unix-y people out there). And Windows would be correct: the
> regexec() call wan
On Tue, Sep 06, 2016 at 06:02:59PM +0200, Johannes Schindelin wrote:
> It will still be quite tricky, because we have to touch a function that is
> rather at the bottom of the food chain: diff_populate_filespec() is called
> from fill_textconv(), which in turn is called from pickaxe_match(), and
>
Is there any additional information I could provide that would be helpful?
Dakota
On Fri, Sep 2, 2016 at 3:22 PM, Dakota Hawkins wrote:
> Below is a simple reproduction of the issue.
>
> The _real_ problem is that this is how our pull request merges work,
> they're not allowed to do fast-forward
On Tue, Sep 06, 2016 at 04:06:32PM +0200, Johannes Schindelin wrote:
> > I think re_search() the correct replacement function but it's been a
> > while since I've looked into it.
>
> The segfault I investigated happened in a call to strlen(). I see many
> calls to strlen() in compat/regex/... The
On Sun, Sep 4, 2016 at 1:18 PM, Christian Couder
wrote:
> As most of the apply code in builtin/apply.c has been libified by a number of
> previous commits, it can now be moved to apply.{c,h}, so that more code can
> use it.
>
> Helped-by: Nguyễn Thái Ngọc Duy
> Helped-by: Ramsay Jones
> Signed-o
If we found bad instruction lines in the instruction sheet
of interactive rebase, we give the user advice on how to
fix it. However, we don't tell the user what to do afterwards.
Give the user advice to run 'git rebase --continue' after
the fix.
Signed-off-by: Ralf Thielow
---
git-rebase--inter
Hi,
today I accidentally triggered a "fatal" using interactive rebase.
If you edit the instruction sheet after 'rebase -i' and add an unknown
command, Git stops because it doesn't know the command.
That's fine, however, now we are in a state where 'git status' fails with
interactive rebase in pr
Folks,
I have recently been enlisted by folks at the Linux Foundation to
help run a Miniconference on Git at the Plumbers Conference [*]
this fall.
We currently have both Junio Hamano and Josh Triplett signed
up to do talks. Hopefully, though not confirmed yet, Junio
will give us a brief "State
On Fri, Sep 2, 2016 at 8:16 PM, Stefan Beller wrote:
> Signed-off-by: Stefan Beller
> ---
> xdiff/xemit.c | 9 -
> 1 file changed, 9 deletions(-)
Despite the moved coloring patch moving into a different direction, I
think this is still
an improvement to the code.
Thanks,
Stefan
>
> di
W dniu 06.09.2016 o 19:03, Stefan Beller pisze:
> On Tue, Sep 6, 2016 at 7:05 AM, Jakub Narębski wrote:
>> If not for `color.moved`, I would have thought that instead of adding
>> new command line option `--color-moved` (and the fact that it is on
>> by default), we could simply reuse duplication
I am looking for a way to force smudge filter to run by simulating a
real life checkout. Let's say I just created a new branch and did not
modify any files but want to test my new smudge filter. According to
some answers such as
https://stackoverflow.com/questions/22909620/git-smudge-clean-filter-b
On Tue, Sep 6, 2016 at 7:05 AM, Jakub Narębski wrote:
> W dniu 06.09.2016 o 09:01, Stefan Beller pisze:
>
>> ---
>>
>> * moved new data structures into struct diff_options
>> * color.moved=bool as well as --[no-]color-moved to {dis,en}able the new
>> feature
>> * color.diff.movedfrom and color
On Tue, Sep 6, 2016 at 5:44 AM, Junio C Hamano wrote:
> By the way, not running xdiff twice would also remove another worry
> I have about correctness, in that the approach depends on xdiff
> machinery to produce byte-for-byte identical result given the same
> pair of input.
As we use different p
Hi Michael,
okay, final mail on this issue today:
On Tue, 6 Sep 2016, Johannes Schindelin wrote:
> Your original issue seemed to be that the gpg command could succeed, but
> still no signature be seen. There *must* be a way to test whether the
> called program added a signature, simply by testin
Hi Michael,
On Tue, 6 Sep 2016, Michael J Gruber wrote:
> Johannes Schindelin venit, vidit, dixit 06.09.2016 10:01:
> > With the recent update in efee955 (gpg-interface: check gpg signature
> > creation status, 2016-06-17), we ask GPG to send all status updates to
> > stderr, and then catch the s
Hi Michael,
On Tue, 6 Sep 2016, Johannes Schindelin wrote:
> On Tue, 6 Sep 2016, Michael J Gruber wrote:
>
> > A full blown approach would use --status-fd=4 or such rather than hijacking
> > stderr.
> > This would require an extension of pipe_command() etc. to handle yet
> > another fd.
For t
Hi Jaakko,
On Tue, 6 Sep 2016, Jaakko Pääkkönen wrote:
> I am using beyond compare, but it does not really matter which one
> because even I create a dummy script as a external diff program, it
> will not get called ever. Only internal diff is started.
Any chance you can come up with an MCVE [*1
Hi Michael,
On Tue, 6 Sep 2016, Michael J Gruber wrote:
> efee955 ("gpg-interface: check gpg signature creation status",
> 2016-06-17) used stderr to capture gpg's status output, which is the
> only reliable way for status checks. As a side effect, stderr was not
> shown to the user any more.
>
Hi Idan,
please only write public mails when discussing Open Source.
On Tue, 6 Sep 2016, Idan Shimoni wrote:
> "This" top-posting is auto generated when hitting on the magic button
> called "Reply", and it is the generic way that the industry works. How
> do you expect me to know that this is c
Signed-off-by: Satoshi Yasushima
---
po/ja.po | 77 +---
1 file changed, 35 insertions(+), 42 deletions(-)
diff --git a/po/ja.po b/po/ja.po
index 23974cc..deaf8e3 100644
--- a/po/ja.po
+++ b/po/ja.po
@@ -102,6 +102,8 @@ msgstr "準備完了"
m
Signed-off-by: Satoshi Yasushima
---
po/ja.po | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/po/ja.po b/po/ja.po
index 8a2c16f..b692b5c 100644
--- a/po/ja.po
+++ b/po/ja.po
@@ -598,7 +598,7 @@ msgstr "文脈を見せる"
#: lib/blame.tcl:291
msgid "Blame Parent Commit"
-msgstr "親
Signed-off-by: Satoshi Yasushima
---
po/ja.po | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/po/ja.po b/po/ja.po
index deaf8e3..208651c 100644
--- a/po/ja.po
+++ b/po/ja.po
@@ -1,15 +1,17 @@
# Translation of git-gui to Japanese
# Copyright (C) 2007 Shawn Pearce
# Thi
Signed-off-by: Satoshi Yasushima
---
po/ja.po | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/po/ja.po b/po/ja.po
index b140e8b..23974cc 100644
--- a/po/ja.po
+++ b/po/ja.po
@@ -11,7 +11,7 @@ msgstr ""
"PO-Revision-Date: 2010-02-02 19:03+0900\n"
"Last-Translator: しらいし ななこ \n
Hi Peff,
On Tue, 6 Sep 2016, Jeff King wrote:
> On Mon, Sep 05, 2016 at 05:45:09PM +0200, Johannes Schindelin wrote:
>
> > Before calling regexec() on the file contents, we better be certain that
> > the strings fulfill the contract of C strings assumed by said function.
>
> If you have a buffe
Signed-off-by: Satoshi Yasushima
---
po/ja.po | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/po/ja.po b/po/ja.po
index 9aff249..8a2c16f 100644
--- a/po/ja.po
+++ b/po/ja.po
@@ -765,7 +765,8 @@ msgstr "トラッキング・ブランチを選択して下さい。"
#: lib/branch_create.tcl:140
#, tcl-format
Hi Peff,
On Tue, 6 Sep 2016, Jeff King wrote:
> On Mon, Sep 05, 2016 at 05:45:06PM +0200, Johannes Schindelin wrote:
>
> > It is true that many code paths populate the mmfile_t structure
> > silently appending a NUL, e.g. when running textconv on a temporary
> > file and reading the results back
Hi
I am using beyond compare, but it does not really matter which one
because even I create a dummy script as a external diff program, it
will not get called ever. Only internal diff is started.
Re-installing git will not remove the problem. I am using the latest git
Any hints how I can debug gi
Am 04.09.2016 um 09:49 schrieb Johannes Schindelin:
Hi René,
On Sat, 3 Sep 2016, René Scharfe wrote:
Add and use a helper function that decodes the char value of two
hexadecimal digits. It returns a negative number on error, avoids
running over the end of the given string and doesn't shift ne
Am 04.09.2016 um 09:46 schrieb Johannes Schindelin:
Hi René,
I imagine you Cc:ed me because the nedmalloc stuff came in via the Windows
port, contributed by Marius (who is no longer active on the Git project
because it works well enough for him)?
Kind of; it's also a follow-up to the recent di
Sent from my iPhone
W dniu 04.09.2016 o 18:08, Michael Haggerty pisze:
> +/*
> + * Check whether an attempt to rename old_refname to new_refname would
> + * cause a D/F conflict with any existing reference (other than
> + * possibly old_refname). If there would be a conflict, emit an error
> + * message and return fa
Hi Peff,
On Tue, 6 Sep 2016, Jeff King wrote:
> On Mon, Sep 05, 2016 at 05:44:57PM +0200, Johannes Schindelin wrote:
>
> > The problem with that: mmap()ed memory is *not* NUL-terminated, yet
> > the pickaxe code calls regexec() on it just the same.
> >
> > This problem has been reported by my c
Hi Peff & Junio,
On Tue, 6 Sep 2016, Jeff King wrote:
> On Mon, Sep 05, 2016 at 12:10:11PM -0700, Junio C Hamano wrote:
>
> > * We could use variant of regexp engine as you proposed,
> >which I think is a preferrable solution. Do people know of a
> >widely accepted implementation that
W dniu 06.09.2016 o 09:01, Stefan Beller pisze:
> ---
>
> * moved new data structures into struct diff_options
> * color.moved=bool as well as --[no-]color-moved to {dis,en}able the new
> feature
> * color.diff.movedfrom and color.diff.movedto to control the colors
> * added a test
[...]
>
On 06/09/16 08:01, Stefan Beller wrote:
[snip]
> This patch was motivated by e.g. reviewing 3b0c4200 ("apply: move
> libified code from builtin/apply.c to apply.{c,h}", 2016-08-08)
>
> Signed-off-by: Stefan Beller
> ---
>
> * moved new data structures into struct diff_options
> * color.moved
Hi Junio,
On Mon, 5 Sep 2016, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > This patch series addresses a problem where `git diff` is called using
> > `-G` or `-S --pickaxe-regex` on new-born files that are configured
> > without user diff drivers, and that hence get mmap()ed into m
efee955 ("gpg-interface: check gpg signature creation status",
2016-06-17) used stderr to capture gpg's status output, which is the
only reliable way for status checks. As a side effect, stderr was not
shown to the user any more.
In case of a gpg error, reflect the whole captured buffer to stderr.
Stefan Beller writes:
> This new coloring is linear to the size of the patch, i.e. O(number of
> added/removed lines) in memory and for computational efforts I'd
> think it is O(n log n) as inserting into the hashmap is an amortized
> log n.
In addition to that O(n log n) overhead for book-keepi
Johannes Schindelin venit, vidit, dixit 06.09.2016 10:01:
> With the recent update in efee955 (gpg-interface: check gpg signature
> creation status, 2016-06-17), we ask GPG to send all status updates to
> stderr, and then catch the stderr in an strbuf.
>
> But GPG might fail, and send error messag
Hi Idan,
On Tue, 6 Sep 2016, Idan Shimoni wrote:
> ???
Please understand that you continue to annoy Stefan, who is only trying to
help you, by adding your replies *above* the quoted email. This is called
top-posting and considered very, very rude on this mailing list.
Also, your replies are ver
Hi Lars,
On Mon, 5 Sep 2016, larsxschnei...@gmail.com wrote:
> [... commit message ...]
Makes sense.
> diff --git a/read-cache.c b/read-cache.c
> index 491e52d..02f74d3 100644
> --- a/read-cache.c
> +++ b/read-cache.c
> @@ -156,7 +156,7 @@ void fill_stat_cache_info(struct cache_entry *ce, struc
Hi Eric & Lars,
On Mon, 5 Sep 2016, Eric Wong wrote:
> larsxschnei...@gmail.com wrote:
> > All processes that the Git main process spawns inherit the open file
> > descriptors of the main process. These leaked file descriptors can
> > cause problems.
>
>
> > -int git_open_noatime(const char *na
W dniu 06.09.2016 o 00:27, Eric Wong pisze:
> larsxschnei...@gmail.com wrote:
>> -int git_open_noatime(const char *name)
>> +int git_open_noatime_cloexec(const char *name)
[...]
>
> I question the need for the "_cloexec" suffixing in the
> function name since the old function is going away entire
Did you get my message?
???
On Tue, Sep 6, 2016 at 11:20 AM, wrote:
> (and s/he did it againhitting "reply all" seems really complicated)
>
> Am 06.09.2016 um 10:07 schrieb Idan Shimoni:
>> it is part of git cheetah plugin not tortoise.
>> But it was part of the git installer for windows, I did not installed
>> any
(and s/he did it againhitting "reply all" seems really complicated)
Am 06.09.2016 um 10:07 schrieb Idan Shimoni:
> it is part of git cheetah plugin not tortoise.
> But it was part of the git installer for windows, I did not installed
> anything else before.
>
> On Tue, Sep 6, 2016 at 10:54 AM
With the recent update in efee955 (gpg-interface: check gpg signature
creation status, 2016-06-17), we ask GPG to send all status updates to
stderr, and then catch the stderr in an strbuf.
But GPG might fail, and send error messages to stderr. And we simply
do not show them to the user.
Even wors
(Please, please, please, use "reply all" in your mail reader i.e. make sure you
don't
remove 'git@vger.kernel.org' from the "To:" or "CC:" field. Thank you!)
Am 06.09.2016 um 09:47 schrieb Idan Shimoni:
> On Tue, Sep 6, 2016 at 10:33 AM, wrote:
>> (Please don't top post and do "reply all")
>>
>
(Please don't top post and do "reply all")
Am 06.09.2016 um 09:28 schrieb Idan Shimoni:
>
> On Tue, Sep 6, 2016 at 10:23 AM, wrote:
>> Am 06.09.2016 um 09:12 schrieb Idan Shimoni:
>>> Hi,
>>>
>>> The last install removed the old good context menu I used to work with.
>>>
>>> Is that on purpose
On Mon, Sep 05, 2016 at 09:03:48PM +0200, Johannes Sixt wrote:
> The process spawned in the hook uses the test's trash directory as CWD.
> As long as it is alive, the directory cannot be removed on Windows.
> Although the test succeeds, the 'test_done' that follows produces an
> error message and
Hi Hannes,
On Mon, 5 Sep 2016, Johannes Sixt wrote:
> The process spawned in the hook uses the test's trash directory as CWD.
> As long as it is alive, the directory cannot be removed on Windows.
> Although the test succeeds, the 'test_done' that follows produces an
> error message and leaves the
Am 06.09.2016 um 09:12 schrieb Idan Shimoni:
> Hi,
>
> The last install removed the old good context menu I used to work with.
>
> Is that on purpose or is it a bug? is there any way to get it back?
>
You're working on a Cray system using git 1.3.2, right ?
SCNR
--
---
On Mon, Sep 05, 2016 at 09:00:47PM +0200, Johannes Sixt wrote:
> We might wonder why our && chain check does not catch this case:
> The && chain check uses a strange exit code with the expectation that
> the second or later part of a broken && chain would not exit with this
> particular code.
>
>
On Mon, Sep 05, 2016 at 12:10:11PM -0700, Junio C Hamano wrote:
> * We could use variant of regexp engine as you proposed,
>which I think is a preferrable solution. Do people know of a
>widely accepted implementation that we can throw into compat/ as
>fallback that is compatible wit
On 06.09.2016 04:07, SZEDER Gábor wrote:
[versionsort]
prereleasesuffix = beta
prereleasesuffix = -beta
prereleasesuffix = RC
prereleasesuffix = -RC
Best,
Gábor
Yes, yes you are the best. Workaround works, tyvm. I was heading in that
direction, too, but never
Hi,
The last install removed the old good context menu I used to work with.
Is that on purpose or is it a bug? is there any way to get it back?
--
-Best
Idan
On Mon, Sep 05, 2016 at 05:45:09PM +0200, Johannes Schindelin wrote:
> Before calling regexec() on the file contents, we better be certain that
> the strings fulfill the contract of C strings assumed by said function.
If you have a buffer that is exactly "size" bytes and you are worried
about reg
On Mon, Sep 05, 2016 at 05:45:06PM +0200, Johannes Schindelin wrote:
> It is true that many code paths populate the mmfile_t structure silently
> appending a NUL, e.g. when running textconv on a temporary file and
> reading the results back into an strbuf.
>
> The assumption is most definitely wr
When we color the diff, we'll mark moved lines with a different color.
This is achieved by doing a two passes over the diff. The first pass
will inspect each line of the diff and store the removed lines and the
added lines in its own hash map.
The second pass will check for each added line if that
77 matches
Mail list logo
