Hi,
On Wed, 7 Sep 2016, Junio C Hamano wrote:
> René Scharfe writes:
>
> > Well, OK. I think the missing point is that the original nedmalloc
> > doesn't come with strdup() and doesn't need it. Only _users_ of
> > nedmalloc need it. Marius added it in nedmalloc.c, but strdup.c is a
> > bette
Hi Junio,
On Wed, 7 Sep 2016, Junio C Hamano wrote:
> Pat, we haven't heard from you for a long time.
Indeed. There are a couple of git-gui patches in Git for Windows that have
been contributed a long time ago and not been picked up.
Maybe it is time to just accept git-gui patches directly into
Hi Alex,
On Wed, 7 Sep 2016, Alex Henrie wrote:
> diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
> index 7e558b0..6fd6d4e 100644
> --- a/git-rebase--interactive.sh
> +++ b/git-rebase--interactive.sh
> @@ -1082,7 +1082,7 @@ If they are meant to go into a new commit, run:
>
On Thu, Sep 08, 2016 at 01:51:05AM +0100, Ramsay Jones wrote:
>
>
> On 07/09/16 23:04, Jeff King wrote:
> > All of our errors come from diff_get_patch_id(), which has
> > exactly three error conditions. The first is an internal
> > assertion, which should be a die("BUG") in the first place.
> >
Hi Peff,
sorry for the late answer, I was really busy trying to come up with a new
and improved version of the patch series, and while hunting a bug I
introduced got bogged down with other tasks.
The good news is that I made up my mind about releasing a Git for Windows
v2.10.0(2): originally, I h
On Wed, Sep 07, 2016 at 03:51:04PM -0700, Josh Triplett wrote:
> > This is still marked RFC, because there are really two approaches here,
> > and I'm not sure which one is better for "format-patch --base". I'd like
> > to get input from Xiaolong Ye (who worked on --base), and Josh Triplett
> > (w
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 memory.
The problem with that: mmap()ed memory is *not* NUL-terminated, yet the
pickaxe code calls r
We just introduced a test that demonstrates that our sloppy use of
regexec() on a mmap()ed area can result in incorrect results or even
hard crashes.
So what we need to fix this is a function that calls regexec() on a
length-delimited, rather than a NUL-terminated, string.
Happily, there is an ex
The new regexec_buf() function operates on buffers with an explicitly
specified length, rather than NUL-terminated strings.
We need to use this function whenever the buffer we want to pass to
regexec() may have been mmap()ed (and is hence not NUL-terminated).
Note: the original motivation for thi
When our pickaxe code feeds file contents to regexec(), it implicitly
assumes that the file contents are read into implicitly NUL-terminated
buffers (i.e. that we overallocate by 1, appending a single '\0').
This is not so.
In particular when the file contents are simply mmap()ed, we can be
virtu
Hi,
On Thu, 8 Sep 2016, Johannes Schindelin wrote:
> We solve this by introducing a helper, regexec_buf(), that takes a
> pointer and a length instead of a NUL-terminated string.
BTW I should have clarified why I decided on another name than regexecn()
(I had considered this even before reading
Hi Peff,
On Tue, 6 Sep 2016, Jeff King wrote:
> 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_textc
Hi Junio,
On Wed, 7 Sep 2016, Junio C Hamano wrote:
> Jeff King writes:
>
> > What happens to those poor souls on systems without REG_STARTEND? Do
> > they get to keep segfaulting?
> >
> > I think the solution is to push them into setting NO_REGEX. So looking
> > at this versus a "regexecn", it
Hi Peff,
On Tue, 6 Sep 2016, Jeff King wrote:
> 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 ther
Hi,
On Thu, 8 Sep 2016, Johannes Schindelin wrote:
> The new regexec_buf() function operates on buffers with an explicitly
> specified length, rather than NUL-terminated strings.
>
> We need to use this function whenever the buffer we want to pass to
> regexec() may have been mmap()ed (and is he
When our pickaxe code feeds file contents to regexec(), it implicitly
assumes that the file contents are read into implicitly NUL-terminated
buffers (i.e. that we overallocate by 1, appending a single '\0').
This is not so.
In particular when the file contents are simply mmap()ed, we can be
virtu
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 memory.
The problem with that: mmap()ed memory is *not* NUL-terminated, yet the
pickaxe code calls r
We just introduced a test that demonstrates that our sloppy use of
regexec() on a mmap()ed area can result in incorrect results or even
hard crashes.
So what we need to fix this is a function that calls regexec() on a
length-delimited, rather than a NUL-terminated, string.
Happily, there is an ex
The new regexec_buf() function operates on buffers with an explicitly
specified length, rather than NUL-terminated strings.
We need to use this function whenever the buffer we want to pass to
regexec() may have been mmap()ed (and is hence not NUL-terminated).
Note: the original motivation for thi
On Thu, Sep 08, 2016 at 09:29:58AM +0200, Johannes Schindelin wrote:
> sorry for the late answer, I was really busy trying to come up with a new
> and improved version of the patch series, and while hunting a bug I
> introduced got bogged down with other tasks.
No problem. I am not in a hurry.
>
On Thu, Sep 08, 2016 at 09:31:11AM +0200, Johannes Schindelin wrote:
> diff --git a/git-compat-util.h b/git-compat-util.h
> index db89ba7..19128b3 100644
> --- a/git-compat-util.h
> +++ b/git-compat-util.h
> @@ -965,6 +965,27 @@ void git_qsort(void *base, size_t nmemb, size_t size,
> #define qsor
Hi Peff & Junio,
On Wed, 7 Sep 2016, Jeff King wrote:
> On Wed, Sep 07, 2016 at 11:39:57AM -0700, Junio C Hamano wrote:
>
> > > Can we do some signaling with fifos to tell the hook when it is safe to
> > > exit? Then we would just need to `wait` for its parent process.
> >
> > Is fifo safe on W
On Thu, Sep 08, 2016 at 09:54:51AM +0200, Johannes Schindelin wrote:
> > diff.c | 3 ++-
> > diffcore-pickaxe.c | 18 --
> > xdiff-interface.c | 13 -
> > 3 files changed, 14 insertions(+), 20 deletions(-)
>
> I just realized that this should switch the
On Thu, Sep 08, 2016 at 09:33:29AM +0200, Johannes Schindelin wrote:
> On Thu, 8 Sep 2016, Johannes Schindelin wrote:
>
> > We solve this by introducing a helper, regexec_buf(), that takes a
> > pointer and a length instead of a NUL-terminated string.
>
> BTW I should have clarified why I decide
On Thu, Sep 08, 2016 at 04:10:24AM -0400, Jeff King wrote:
> On Thu, Sep 08, 2016 at 09:54:51AM +0200, Johannes Schindelin wrote:
>
> > > diff.c | 3 ++-
> > > diffcore-pickaxe.c | 18 --
> > > xdiff-interface.c | 13 -
> > > 3 files changed, 14 insertio
On Thu, Sep 08, 2016 at 09:49:38AM +0200, Johannes Schindelin wrote:
> > > diff --git a/diff.c b/diff.c
> > > index 534c12e..2c5a360 100644
> > > --- a/diff.c
> > > +++ b/diff.c
> > > @@ -951,7 +951,13 @@ static int find_word_boundaries(mmfile_t *buffer,
> > > regex_t *word_regex,
> > > {
> > >
On Thu, Sep 08, 2016 at 10:05:58AM +0200, Johannes Schindelin wrote:
> > > Is fifo safe on Windows, though?
> >
> > No clue. We seem to use mkfifo unconditionally in lib-daemon, but
> > perhaps people do not run that test on Windows. Other invocations seem
> > to be protected by the PIPE prerequi
On Thu, Sep 08, 2016 at 04:14:46AM -0400, Jeff King wrote:
> On Thu, Sep 08, 2016 at 04:10:24AM -0400, Jeff King wrote:
>
> > On Thu, Sep 08, 2016 at 09:54:51AM +0200, Johannes Schindelin wrote:
> >
> > > > diff.c | 3 ++-
> > > > diffcore-pickaxe.c | 18 --
> > > >
Am 03.09.2016 um 15:17 schrieb Johannes Schindelin:
> Dear Git users,
>
> It is my pleasure to announce that Git for Windows 2.10.0 is available.
> This time, I even blogged about it, primarily because I am so excited
> about the speed improvements of rebase -i:
>
> https://blogs.msdn.microsoft.c
I am Jacobs Steven $ 2 Million Has Been Donated To You this is Real,For More
Info Contact Mr James Stocklas with this Email ; >> jamesstocklas...@gmail.com
Send Your Response To >> jamesstocklas...@gmail.com
__
This emai
On Thu, Sep 8, 2016 at 8:25 AM, Jeff King wrote:
> On Thu, Sep 08, 2016 at 07:49:12AM +0700, Duy Nguyen wrote:
>
>> I got the message in the subject when pushing to github today. Yes I
>> know it's github, not git. But according to stackoveflow [1] it's a
>> local problem. Which makes me think, if
On Wed, 07 Sep 2016 10:35:22 -0700 Junio C Hamano wrote:
Since I received the patch directly bypassing vger, I queued it on
gitgui-0.20.0 from Pat and tentatively merged it to my 'pu'.
wow, thanks so much.
W dniu 06.09.2016 o 23:01, john smith pisze:
> I'd prefer smudge/clean filters instead of `make' scripts etc. to
> convert template dotfiles into something usable and back because
> filters:
>
> 1. could be run automatically
>
> 2. do not modify files as shown by `git show HEAD:' and
> therefore
git-init somehow reads '.git/config' at current directory and sets
log_all_ref_updates based on this file. Because log_all_ref_updates is
not unspecified (-1) any more. It will not be written to the new repo's
config file (see create_default_files() function).
This will affect our tests in the nex
My ASAP is not so ASAP. Sorry about that but I think I have fixed it.
Side note about 2/3. I've known this problem (in general) for years
(accidentally reading .git config file before .git is searched) and
could not do anything about it. And because test_expect_failure should
only be there if some
When 'git init' is called from a linked worktree, '.git' dir as the main
'.git' (i.e. $GIT_COMMON_DIR) and populate the whole repository skeleton
in there. It does not harm anything (*) but it is still wrong.
Since 'git init' calls set_git_dir() at preparation time, which
indirectly calls get_comm
When "git init" is called with GIT_WORK_TREE environment set, we want to
keep this worktree's location in core.worktree so the user does not have
to set the environment again and again. See ef6f0af (git-init: set
core.worktree if GIT_WORK_TREE is specified - 2007-07-04)
We detect that by this logi
Jonathan Nieder writes:
> I think we can make this stricter. The capabilities^{} line is supposed
> to be the first advertised ref, before any 'shallow' lines or .have
> extra refs.
"The first", or "the first and only"? I thought that it would be
the latter.
On Wed, Sep 7, 2016 at 6:45 PM, Jonathan Nieder wrote:
> (+cc: Heiko)
> Jonathan Nieder wrote:
>
>> 'die_initial_contact' uses got_at_least_one_head to determine whether
>> it was on the first line but code paths added later that use
>> 'continue' don't populate it properly (see b06dcd7d, 40c155ff
Jonathan Nieder writes:
> Jonathan Nieder wrote:
>
>> Subject: connect: tighten check for unexpected early hang up
> [...]
>> @@ -131,7 +131,7 @@ struct ref **get_remote_heads(int in, char *src_buf,
>> size_t src_len,
>>PACKET_READ_GENTLE_ON_EOF |
>>
Johannes Schindelin writes:
> On Wed, 7 Sep 2016, Junio C Hamano wrote:
>
>> Pat, we haven't heard from you for a long time.
>
> Indeed. There are a couple of git-gui patches in Git for Windows that have
> been contributed a long time ago and not been picked up.
>
> Maybe it is time to just accep
Jeff King writes:
> Between the two options for regexec_buf(), I think you have convinced me
> that REG_STARTEND is better than just using compat/regex everywhere. I
> do think the fallback for platforms like musl should be "use
> compat/regex" and not doing an expensive copy (which in most cases
Johannes Schindelin writes:
> We just introduced a test that demonstrates that our sloppy use of
> regexec() on a mmap()ed area can result in incorrect results or even
> hard crashes.
>
> So what we need to fix this is a function that calls regexec() on a
> length-delimited, rather than a NUL-ter
Johannes Schindelin writes:
> @@ -33,11 +32,8 @@ static void diffgrep_consume(void *priv, char *line,
> unsigned long len)
>* caller early.
>*/
> return;
> - /* Yuck -- line ought to be "const char *"! */
> - hold = line[len];
> - line[le
Lars Schneider writes:
>>> We probably should be using O_NOATIME for all O_RDONLY cases
>>> to get the last bit of performance out (especially since
>>> non-modern-Linux systems probably still lack relatime).
>>
>> No, please do not go there.
>>
>> The user can read from a file in a working tre
SZEDER Gábor writes:
> - * Note that we don't have to deal with the situation when both p1 and
> - * p2 start with the same suffix because the common part is already
> + * Note that we don't have to deal with the situation when both s1 and
> + * s2 contain the same suffix because the common part
Hi Stefan,
On Thu, 8 Sep 2016, stefan.na...@atlas-elektronik.com wrote:
> Am 03.09.2016 um 15:17 schrieb Johannes Schindelin:
>
> > New Features
> >
> > • Comes with Git v2.10.0.
> > • The git rebase -i command was made faster by reimplementing large
> > parts in C.
>
> I finally had t
Jeff King writes:
> On Wed, Sep 07, 2016 at 10:27:34AM +0200, Michael J Gruber wrote:
>
>> Now, I can't reproduce C on Linux[*], so there is more involved. It
>> could be that my patch just exposes a problem in our start_command()
>> etc.: run-command.c contains a lot of ifdefing, so possibly qui
From: Lars Schneider
set_packet_header() converts an integer to a 4 byte hex string. Make
this function locally available so that other pkt-line functions can
use it.
Signed-off-by: Lars Schneider
---
pkt-line.c | 19 +--
1 file changed, 13 insertions(+), 6 deletions(-)
diff -
From: Lars Schneider
packet_write() should be called packet_write_fmt() as the string
parameter can be formatted.
Suggested-by: Junio C Hamano
Signed-off-by: Lars Schneider
---
builtin/archive.c| 4 ++--
builtin/receive-pack.c | 4 ++--
builtin/remote-ext.c | 4 ++--
builtin/
From: Lars Schneider
packet_write_fmt() would die in case of a write error even though for
some callers an error would be acceptable. Add packet_write_fmt_gently()
which writes a formatted pkt-line and returns `0` for success and `-1`
for an error.
Signed-off-by: Lars Schneider
---
pkt-line.c
From: Lars Schneider
The goal of this series is to avoid launching a new clean/smudge filter
process for each file that is filtered.
A short summary about v1 to v5 can be found here:
https://git.github.io/rev_news/2016/08/17/edition-18/
This series is also published on web:
https://github.com/l
From: Lars Schneider
packet_write_fmt_gently() uses format_packet() which lets the caller
only send string data via "%s". That means it cannot be used for
arbitrary data that may contain NULs.
Add packet_write_gently() which writes arbitrary data and returns `0`
for success and `-1` for an error
From: Lars Schneider
Use `test_config` to set the config, check that files are empty with
`test_must_be_empty`, compare files with `test_cmp`, and remove spaces
after ">" and "<".
Please note that the "rot13" filter configured in "setup" keeps using
`git config` instead of `test_config` because
From: Lars Schneider
Git filter driver commands with spaces (e.g. `filter.sh foo`) are hard to
read in error messages. Quote them to improve the readability.
Signed-off-by: Lars Schneider
---
convert.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/convert.c b
From: Lars Schneider
write_packetized_from_fd() and write_packetized_from_buf() write a
stream of packets. All content packets use the maximal packet size
except for the last one. After the last content packet a `flush` control
packet is written.
read_packetized_to_buf() reads arbitrary sized pa
From: Lars Schneider
apply_filter() returns a boolean that tells the caller if it
"did convert or did not convert". The variable `ret` was used throughout
the function to track errors whereas `1` denoted success and `0`
failure. This is unusual for the Git source where `0` denotes success.
Renam
From: Lars Schneider
packet_flush() would die in case of a write error even though for some
callers an error would be acceptable. Add packet_flush_gently() which
writes a pkt-line flush packet and returns `0` for success and `-1` for
failure.
Signed-off-by: Lars Schneider
---
pkt-line.c | 9 ++
Hi Peff & Junio,
On Thu, 8 Sep 2016, Junio C Hamano wrote:
> Jeff King writes:
>
> > Between the two options for regexec_buf(), I think you have convinced me
> > that REG_STARTEND is better than just using compat/regex everywhere. I
> > do think the fallback for platforms like musl should be "u
From: Lars Schneider
Git's clean/smudge mechanism invokes an external filter process for
every single blob that is affected by a filter. If Git filters a lot of
blobs then the startup time of the external filter processes can become
a significant part of the overall Git execution time.
In a prel
Josh Triplett writes:
> Any text below the "-- " for the email signature gets treated as part of
> the signature, and many mail clients will trim it from the quoted text
> for a reply. Move it above the signature, so people can reply to it
> more easily.
>
> Add tests for the exact format of the
On Thu, Sep 08, 2016 at 06:03:33PM +0700, Duy Nguyen wrote:
> > So this is really an internal failure at the ref-update stage. There
> > _should_ be a reasonable error message, but I think "fatal error in
> > commit_refs" is the generic last-ditch fallback. I'll pass this along to
> > people in ch
On Thu, Sep 08, 2016 at 09:57:43AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > Between the two options for regexec_buf(), I think you have convinced me
> > that REG_STARTEND is better than just using compat/regex everywhere. I
> > do think the fallback for platforms like musl should b
On Thu, Sep 08, 2016 at 11:34:15AM -0700, Junio C Hamano wrote:
> Josh Triplett writes:
>
> > Any text below the "-- " for the email signature gets treated as part of
> > the signature, and many mail clients will trim it from the quoted text
> > for a reply. Move it above the signature, so peopl
On 08/09/16 09:35, Jeff King wrote:
> On Thu, Sep 08, 2016 at 04:14:46AM -0400, Jeff King wrote:
>
>> On Thu, Sep 08, 2016 at 04:10:24AM -0400, Jeff King wrote:
>>
>>> On Thu, Sep 08, 2016 at 09:54:51AM +0200, Johannes Schindelin wrote:
>>>
> diff.c | 3 ++-
> diffcore-pick
Josh Triplett writes:
> If any other change ends up being necessary, I'll split the patch in v2.
Thanks. I do not see anything else offhand myself, but other people
watching the topic from the sideline may spot something we missed.
Nguyễn Thái Ngọc Duy writes:
> When 'git init' is called from a linked worktree, '.git' dir as the main
> '.git' (i.e. $GIT_COMMON_DIR) and populate the whole repository skeleton
> in there. It does not harm anything (*) but it is still wrong.
-ECANNOTPARSE. Did you mean "... worktree, we trea
Nguyễn Thái Ngọc Duy writes:
> git-init somehow reads '.git/config' at current directory and sets
> log_all_ref_updates based on this file. Because log_all_ref_updates is
> not unspecified (-1) any more. It will not be written to the new repo's
> config file (see create_default_files() function)
On Thu, Sep 08, 2016 at 08:06:35PM +0100, Ramsay Jones wrote:
> > Actually, I take it back again. Your test case doesn't have an embedded
> > NUL in it (so we check that git finds it, but aside from the lack of
> > segfault, stock git would already find it).
>
> This reminds me ... despite the na
Nguyễn Thái Ngọc Duy writes:
> +/*
> + * Return the first ".git" that we have encountered.
> + * FIXME this function for not entirely correct because
> + * setup_git_directory() and enter_repo() do not update first_git_dir
> + * when they follow .git files. The function in its current state is
>
On Thu, Sep 08, 2016 at 08:47:18PM +0700, Nguyễn Thái Ngọc Duy wrote:
> git-init somehow reads '.git/config' at current directory and sets
> log_all_ref_updates based on this file. Because log_all_ref_updates is
> not unspecified (-1) any more. It will not be written to the new repo's
> config fil
Nguyễn Thái Ngọc Duy writes:
> Normally we err on the safe side: if something can be seen as both an
> SHA1 and a pathspec, we stop and scream. In checkout, there is one
> exception added in 859fdab (git-checkout: improve error messages, detect
> ambiguities. - 2008-07-23), to allow the common c
On Thu, Sep 08, 2016 at 11:20:09AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > On Wed, Sep 07, 2016 at 10:27:34AM +0200, Michael J Gruber wrote:
> >
> >> Now, I can't reproduce C on Linux[*], so there is more involved. It
> >> could be that my patch just exposes a problem in our start
Nguyễn Thái Ngọc Duy writes:
> The two functions in parse_branchname_arg(), verify_non_filename and
> check_filename, need correct prefix in order to reconstruct the paths
> and check for their existence. With NULL prefix, they just check paths
> at top dir instead.
Good eyes. Will queue.
>
>
On Thu, Sep 08, 2016 at 11:54:08AM -0700, Josh Triplett wrote:
> > your problem description
> > looks perfect. I am still not sure if the code does a reasonable
> > thing in MIME case, though.
>
> It *looks* correct to me.
Hmm. It looks correct to me, too; we stick it just after the patch, so
w
Johannes Schindelin writes:
> On Thu, 1 Sep 2016, Junio C Hamano wrote:
>
>> Hopefully that [patch removing the - suffix] would help making
>> Dscho's "what are the failed tests?" logic simpler.
>
> Of course.
>
> It also makes sure that those 2 hours I spent on writing and perfecting
> the sed m
Quoting Junio C Hamano :
SZEDER Gábor writes:
- * Note that we don't have to deal with the situation when both p1 and
- * p2 start with the same suffix because the common part is already
+ * Note that we don't have to deal with the situation when both s1 and
+ * s2 contain the same suffix be
Teach git to avoid unnecessary merge during trivial checkout. When
running 'git checkout -b foo' git follows a common code path through
the expensive merge_working_tree even when it is unnecessary. As a
result, 95% of the time is spent in merge_working_tree doing the 2-way
merge between the new a
Thanks.
I'll skip 01-03/13 and queue the remainder for now, as I'd want to
see Christian's "split builtin/apply.c into two, moving bulk to
apply.c at the top-level to be reused" merged to 'next' sooner and
to 'master' hopefully during this cycle.
Stefan Beller writes:
> diff --git a/diff.c b/diff.c
> index 4a6501c..79ad91d 100644
> --- a/diff.c
> +++ b/diff.c
> @@ -354,7 +354,6 @@ struct emit_callback {
> const char **label_path;
> struct diff_words_data *diff_words;
> struct diff_options *opt;
> - int *found_changes
Stefan Beller writes:
> When `len < 1`, len has to be 0 or negative, emit_line will then remove the
> first character and by then `len` would be negative. As this doesn't
> happen, it is safe to assume it is dead code.
>
> This continues to simplify the code, which was started in b8d9c1a66b
> (20
On Thu, Sep 8, 2016 at 11:21 AM, wrote:
> +static int packet_write_fmt_1(int fd, int gently,
> + const char *fmt, va_list args)
> +{
> + struct strbuf buf = STRBUF_INIT;
> + size_t count;
> +
> + format_packet(&buf, fmt, args);
> + count = wri
Ben Peart writes:
> Teach git to avoid unnecessary merge during trivial checkout. When
> running 'git checkout -b foo' git follows a common code path through
> the expensive merge_working_tree even when it is unnecessary.
I would be lying if I said I am not sympathetic to the cause, but...
> +
Jeff King writes:
> On Thu, Sep 08, 2016 at 11:54:08AM -0700, Josh Triplett wrote:
>
>> > your problem description
>> > looks perfect. I am still not sure if the code does a reasonable
>> > thing in MIME case, though.
>>
>> It *looks* correct to me.
>
> Hmm. It looks correct to me, too; ...
>
On Thu, Sep 8, 2016 at 11:21 AM, wrote:
> From: Lars Schneider
>
> packet_write_fmt_gently() uses format_packet() which lets the caller
> only send string data via "%s". That means it cannot be used for
> arbitrary data that may contain NULs.
Makes sense.
>
> Add packet_write_gently() which wr
Jeff King writes:
>> commit f96e5673 ("grep: use REG_STARTEND for all matching if available",
>> 22-05-2010) introduced this test and expects ".. NUL characters themselves
>> are not matched in any way". With the native library on cygwin they are
>> matched, with the compat/regex they are not. In
SZEDER Gábor writes:
> I'm not sure about the relevancy of this pararaph, or the relevancy of
> the original version for that matter. I mean, there is a different
> character for sure, so it's really rather obvious that it can't
> possibly be the same suffix in both, isn't it? So I don't think
Jeff King writes:
>> Even though this patch is fixing only one of the two issues, I am
>> tempted to say that we should queue it for now, as it does so
>> without breaking a bigger gain made by the original, i.e. we learn
>> the status of verification in a way the authors of GPG wants us to,
>> w
On Thu, Sep 08, 2016 at 02:22:16PM -0700, Junio C Hamano wrote:
> > + /*
> > +* Optimize the performance of checkout when the current and
> > +* new branch have the same OID and avoid the trivial merge.
> > +* For example, a "git checkout -b foo" just needs to create
> > +* the n
Reproduction Steps:
1. Have a git repo cloned from a perforce repo using multiple depot paths (e.g.
//depot/foo and //depot/bar).
2. Submit a single change to the perforce repo that makes changes in both
//depot/foo and //depot/bar.
3. Run "git p4 sync" to sync the change from #2.
Expected Beh
Other than the duplicated sign-offs, this series looks good to me
("Don't act surprised, you guys, cuz I wrote 'em").
Kind of a funny place to cut it off, but I guess it makes sense.
On Sun, 2016-09-04 at 18:08 +0200, Michael Haggerty wrote:
> From: David Turner
>
> Alternate refs backends migh
On Thu, Sep 8, 2016 at 11:21 AM, wrote:
> From: Lars Schneider
>
> write_packetized_from_fd() and write_packetized_from_buf() write a
> stream of packets. All content packets use the maximal packet size
> except for the last one. After the last content packet a `flush` control
> packet is writte
On Thu, Sep 8, 2016 at 11:21 AM, wrote:
> From: Lars Schneider
>
> Use `test_config` to set the config, check that files are empty with
> `test_must_be_empty`, compare files with `test_cmp`, and remove spaces
> after ">" and "<".
>
> Please note that the "rot13" filter configured in "setup" keep
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 ones marked with '.' do not appear in any of
the integration branches, but I am still holding onto them.
There are a few more topics in fli
Instead of referencing "stash@{n}" explicitly, it can simply be
referenced as "n". Most users only reference stashes by their position
in the stash stask (what I refer to as the "index"). The syntax for the
typical stash (stash@{n}) is slightly annoying and easy to forget, and
sometimes difficult
I have a fresh git installation on my windows 10 machine, but I am
unable to use the Git Bash or the Git GUI because the program freezes
just after opening.
The only difference I have made on my machine was to update Windows 10
Pro to it's latest version (build 14393.105) and change the default
Doc
96 matches
Mail list logo
