This is in preparation to turn test-regex into some generic regex
testing command.
Helped-by: Eric Sunshine
Helped-by: Ramsay Jones
Signed-off-by: Nguyễn Thái Ngọc Duy
Signed-off-by: Junio C Hamano
---
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
Signed-off-by: Nguyễn Thái Ngọc Duy
Signed-off-by: Junio C Hamano
---
grep.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/grep.c b/grep.c
index 3d63612..92587a8 100644
--- a/grep.c
+++ b/grep.c
@@ -438,10 +438,7 @@ static void
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
Signed-off-by: Junio C Hamano
---
grep.c
"!icase || ascii_only" is repeated twice in this if/else chain as this
series evolves. Rewrite it (and basically revert the first if
condition back to before the "grep: break down an "if" stmt..." commit).
Helped-by: Junio C Hamano
Signed-off-by: Nguyễn Thái Ngọc Duy
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
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
Signed-off-by: Nguyễn Thái Ngọc Duy
Signed-off-by: Junio C Hamano
---
test-regex.c | 51 +--
1 file changed, 49 insertions(+), 2 deletions(-)
diff --git a/test-regex.c b/test-regex.c
index 67a1a65..eff26f5
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
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
There's another regcomp code block coming in this function that needs
the same error handling. This function can help avoid duplicating
error handling code.
Helped-by: Jeff King
Signed-off-by: Nguyễn Thái Ngọc Duy
---
diffcore-pickaxe.c | 22
v2 fixes Junio's and Jeff's comments (both good). The sharing "!icase
|| ascii_only" is made a separate commit (6/12) because I think it
takes some seconds to realize that the conversion is correct and it's
technically not needed in 5/12 (and it's sort of the opposite of 1/12)
Interdiff
diff
Signed-off-by: Nguyễn Thái Ngọc Duy
Signed-off-by: Junio C Hamano
---
grep.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/grep.c b/grep.c
index 7b2b96a..f430d7e 100644
--- a/grep.c
+++ b/grep.c
@@ -403,7 +403,9 @@ static void
Add the --name parameter to git worktree add that allows the user to set
the name of the created worktree directory. A worktree must not already
exist with the current name or creation will fail.
Signed-off-by: Barret Rennie
---
Documentation/git-worktree.txt | 6 +-
Jeff King wrote:
> On Sat, Jun 25, 2016 at 01:14:50AM +, Eric Wong wrote:
>
> > I'm not sure if this is the best approach, or if changing
> > too_many_packs can be done without causing problems for
> > hosts of big repos.
> >
> > ---8<-
> > Subject: [PATCH] gc:
On Sat, Jun 25, 2016 at 01:14:50AM +, Eric Wong wrote:
> I'm not sure if this is the best approach, or if changing
> too_many_packs can be done without causing problems for
> hosts of big repos.
>
> ---8<-
> Subject: [PATCH] gc: correct gc.autoPackLimit documentation
>
> I want to
I'm not sure if this is the best approach, or if changing
too_many_packs can be done without causing problems for
hosts of big repos.
---8<-
Subject: [PATCH] gc: correct gc.autoPackLimit documentation
I want to ensure there is only one pack in my repo to take
advantage of pack bitmaps.
On Fri, Jun 24, 2016 at 05:29:18PM -0700, Junio C Hamano wrote:
> "brian m. carlson" writes:
>
>
> > @@
> > struct diff_filespec o;
> > @@
> > - o.sha1_valid
> > + o.oid_valid
> >
> > @@
> > struct diff_filespec *p;
> > @@
> > - p->sha1_valid
> > + p->oid_valid
>
"brian m. carlson" writes:
> @@
> struct diff_filespec o;
> @@
> - o.sha1_valid
> + o.oid_valid
>
> @@
> struct diff_filespec *p;
> @@
> - p->sha1_valid
> + p->oid_valid
Totally offtopic (from Git's point of view), but why does Coccinelle
need both of these? I
On Fri, Jun 24, 2016 at 03:41:47PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > The difference in time between the two is measurable on my system, but
> > it's only a few milliseconds (for 4096 bytes). So maybe it's not worth
> > worrying about (though as a general
Convert the anonymous struct within struct stage_data to use struct
object_id. The following Coccinelle semantic patch was used to
implement this, followed by the transformations in object_id.cocci:
@@
struct stage_data o;
expression E1;
@@
- o.stages[E1].sha
+ o.stages[E1].oid.hash
@@
struct
Convert struct diff_filespec's sha1 member to use a struct object_id
called "oid" instead. The following Coccinelle semantic patch was used
to implement this, followed by the transformations in object_id.cocci:
@@
struct diff_filespec o;
@@
- o.sha1
+ o.oid.hash
@@
struct diff_filespec *p;
@@
-
Convert this function and the git merge-recursive subcommand to use
struct object_id.
Signed-off-by: brian m. carlson
Signed-off-by: Junio C Hamano
---
builtin/merge-recursive.c | 20 ++--
merge-recursive.c | 14
Convert struct merge_file_info to use struct object_id. The following
Coccinelle semantic patch was used to implement this, followed by the
transformations in object_id.cocci:
@@
struct merge_file_info o;
@@
- o.sha
+ o.oid.hash
@@
struct merge_file_info *p;
@@
- p->sha
+ p->oid.hash
All of the callers of this function use struct object_id, so convert it
to use struct object_id in its arguments and internally.
Signed-off-by: brian m. carlson
---
diff.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/diff.c b/diff.c
Convert all but two of the static functions in this file to use struct
object_id.
Signed-off-by: brian m. carlson
Signed-off-by: Junio C Hamano
---
merge-recursive.c | 236 +++---
1 file changed,
Apply the set of semantic patches from contrib/coccinelle to convert
some leftover places using struct object_id's hash member to instead
use the wrapper functions that take struct object_id natively.
Signed-off-by: brian m. carlson
Signed-off-by: Junio C Hamano
Now that this struct's sha1 member is called "oid", update the comment
and the sha1_valid member to be called "oid_valid" instead. The
following Coccinelle semantic patch was used to implement this, followed
by the transformations in object_id.cocci:
@@
struct diff_filespec o;
@@
- o.sha1_valid
Coccinelle (http://coccinelle.lip6.fr/) is a program which performs
mechanical transformations on C programs using semantic patches. These
semantic patches can be used to implement automatic refactoring and
maintenance tasks.
Add a set of basic semantic patches to convert common patterns related
This series is part 4 in a series of conversions to replace instances of
unsigned char [20] with struct object_id. Most of this series touches
the merge-recursive code.
New in this series is the use of Coccinelle (http://coccinelle.lip6.fr/)
semantic patches. These semantic patches can make
hashcpy with null_sha1 as the source is equivalent to hashclr. In
addition to being simpler, using hashclr may give the compiler a chance
to optimize better. Convert instances of hashcpy with the source
argument of null_sha1 to hashclr.
This transformation was implemented using the following
This function works just like sha1_to_hex_r, except that it takes a
pointer to struct object_id instead of a pointer to unsigned char.
Signed-off-by: brian m. carlson
---
cache.h | 1 +
hex.c | 5 +
2 files changed, 6 insertions(+)
diff --git a/cache.h
Citando Junio C Hamano :
Vasco Almeida writes:
The only downside I can tell about this is translator are going to have
to update those strings on their translations, but that is a normal
thing to do on an active project like Git.
A larger issue is
Jeff King writes:
> The difference in time between the two is measurable on my system, but
> it's only a few milliseconds (for 4096 bytes). So maybe it's not worth
> worrying about (though as a general technique, it does make me worry
> that it's easy to get wrong in a way that
Hi,
when run on a 32 bit system (Linux system, don't know about other
systems),
mkdir test && cd test && git init && touch someFile && git add someFile
&& git commit -m "Initial commit." && dd if=/dev/urandom
of=bigBinaryFile bs=1MB count=4294 && git add bigBinaryFile && git
commit -m
Vasco Almeida writes:
> The only downside I can tell about this is translator are going to have
> to update those strings on their translations, but that is a normal
> thing to do on an active project like Git.
A larger issue is this fails to update tests that check these
Johannes Schindelin writes:
> It is highly unlikely that any user would want to see ANSI color
> sequences in a file. So let's stop doing that by default.
>
> This is a backwards-incompatible change.
>
> The reason this was not caught earlier is most likely that
Johannes Schindelin writes:
> Earlier, we freopen()ed stdout in order to write patches to files.
> That forced us to duplicate stdout (naming it "realstdout") because we
> *still* wanted to be able to report the file names.
>
> As we do not abuse stdout that way
Johannes Schindelin writes:
> We rely on the auto-detection ("is stdout a terminal?") to determine
> whether to use color in the output of format-patch or not. That happens
> to work because we freopen() stdout when redirecting the output to files.
>
> However, we are
Am 24.06.2016 um 23:05 schrieb Jeff King:
On Fri, Jun 24, 2016 at 10:52:32PM +0200, Johannes Sixt wrote:
The Windows behavior is most closely described as having signal(SIGPIPE,
SIG_IGN) at the very beginning of the program.
Right, but then we would get EPIPE. So what does git do in such
On Fri, Jun 24, 2016 at 04:58:58PM -0400, Eric Sunshine wrote:
> On Fri, Jun 24, 2016 at 3:07 PM, Jeff King wrote:
> > On Fri, Jun 24, 2016 at 11:56:19AM -0700, Junio C Hamano wrote:
> >> Jeff King writes:
> >> > +tar_info () {
> >> > + "$TAR" tvf "$1" | awk
On Fri, Jun 24, 2016 at 10:52:32PM +0200, Johannes Sixt wrote:
> Am 24.06.2016 um 21:43 schrieb Jeff King:
> > In POSIX shells, a program which exits due to a signal
> > generally has an exit code of 128 plus the signal number.
> > However, some platforms do other things. ksh uses 256 plus
> >
Johannes Schindelin writes:
> We are about to teach the log-tree machinery to reuse the diffopt.file
> field to output to a file stream other than stdout, in line with the
> diff machinery already writing to diffopt.file.
>
> However, we might want to write something
Am 24.06.2016 um 21:43 schrieb Jeff King:
In POSIX shells, a program which exits due to a signal
generally has an exit code of 128 plus the signal number.
However, some platforms do other things. ksh uses 256 plus
the signal number, and on Windows, all signals are just "3".
That's not true,
On Fri, Jun 24, 2016 at 03:07:44PM -0400, Jeff King wrote:
> > "dd bs=1 count=4096" is hopefully more portable.
>
> Hmm. I always wonder whether dd is actually very portable, but we do use
> it already, at least.
>
> Perhaps the perl monstrosity in t9300 could be replaced with that, too.
Hrm.
On Fri, Jun 24, 2016 at 3:07 PM, Jeff King wrote:
> On Fri, Jun 24, 2016 at 11:56:19AM -0700, Junio C Hamano wrote:
>> Jeff King writes:
>> > +tar_info () {
>> > + "$TAR" tvf "$1" | awk '{print $3 " " $4}' | cut -d- -f1
>> > +}
>
>> Seeing an awk piped into cut
Commit 6d41edc6 ("refs: add methods for reflog", 24-02-2016), moved the
reflog handling into the ref-storage backend. In particular, the
files_reflog_iterator_begin() API was removed from internal refs API
header, resulting in sparse warnings.
Signed-off-by: Ramsay Jones
Sir,
I am a retired banker, currently working as a consultant.
By virtue of my past working experience, I have contacts to high net worth
Individuals and Investment firms in need to place funds into different projects
to generate profits. The funding would be provided as a soft loan at 3%
On vr, 2016-06-24 at 14:14 -0400, Jeff King wrote:
> On Fri, Jun 24, 2016 at 07:45:04PM +0200, Johannes Schindelin wrote:
>> Do we *actually* send color via the sideband, like, ever?
> We don't, but remember that we forward arbitrary output from hooks.
> If the consensus is "nah, it is probably
Please don't drop Cc:, re-adding git@vger and Christian
Jacob Godserv wrote:
> > Christian (Cc-ed) also noticed the problem a few weeks ago
> > and took a more drastic approach by having git-svn die
> > instead of warning:
> >
On Fri, Jun 24, 2016 at 03:39:24PM -0400, Jeff King wrote:
> Anyway. Here's a series that I think makes things better, and it is not
> too painful to do.
>
> [1/4]: tests: factor portable signal check out of t0005
> [2/4]: t0005: use test_match_signal as appropriate
> [3/4]:
Matthieu Moy writes:
> Junio C Hamano writes:
>
>> On Wed, Jun 22, 2016 at 12:00 PM, Eric Wong wrote:
>>>
>>> Just wondering, who updates
>>> https://kernel.org/pub/software/scm/git/docs/
>>> and why hasn't it been updated in a
On Fri, Jun 24, 2016 at 12:45:05PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > So if anything, I would put a comment here, explaining that ustar cannot
> > handle anything larger than this, and POSIX mandates it (but I didn't
> > because the commit message already goes
Jeff King writes:
> So if anything, I would put a comment here, explaining that ustar cannot
> handle anything larger than this, and POSIX mandates it (but I didn't
> because the commit message already goes into much more detail).
That sounds like a good thing to do. Not
When git-daemon exits, we expect it to be with the SIGTERM
we just sent it. If we see anything else, we'll complain.
But our check against exit code "143" is not portable. For
example:
$ ksh93 t5570-git-daemon.sh
[...]
error: git daemon exited with status: 271
We can fix this by using
In 8bf4bec (add "ok=sigpipe" to test_must_fail and use it to
fix flaky tests, 2015-11-27), test_must_fail learned to
recognize "141" as a sigpipe failure. However, testing for
a signal is more complicated than that; we should use
test_match_signal to implement more portable checking.
The first test already uses this more portable construct
(that was where it was factored from initially), but the
later tests do a raw comparison against 141 to look for
SIGPIPE, which can fail on some shells and platforms.
Signed-off-by: Jeff King
---
Again, I couldn't test
Jeff King writes:
>> > +# When parsing, we'll pull out only the year from the date; that
>> > +# avoids any question of timezones impacting the result.
>>
>> ... as long as the month-day part is not close to the year boundary.
>> So this explanation is insuffucient to convince
In POSIX shells, a program which exits due to a signal
generally has an exit code of 128 plus the signal number.
However, some platforms do other things. ksh uses 256 plus
the signal number, and on Windows, all signals are just "3".
We've accounted for that in t0005, but not in other tests.
Let's
On Fri, Jun 24, 2016 at 07:05:14PM +0200, Johannes Sixt wrote:
> Am 24.06.2016 um 18:46 schrieb Jeff King:
> > On Fri, Jun 24, 2016 at 06:38:55PM +0200, Johannes Sixt wrote:
> > > It's going to be 269 with ksh, and who-knows-what on Windows (due to lack
> > > of
> > > SIGPIPE - I haven't tested
Jacob Godserv wrote:
> On Tue, Sep 22, 2015 at 2:48 PM, Jacob Godserv wrote:
> > I found a specific case in which git-svn improperly aborts:
> >
> > 1. I created a git-svn repository, named "git-svn repo", by cloned an
> > svn repository via the
On Fri, Jun 24, 2016 at 12:06:59PM -0700, Junio C Hamano wrote:
> > + if (args->time > 0777UL) {
> > + strbuf_append_ext_header_uint(_header, "mtime",
> > + args->time);
> > + args->time = 0777UL;
> > + }
> > +
> > +
On Fri, Jun 24, 2016 at 12:01:16PM -0700, Junio C Hamano wrote:
> > @@ -267,7 +281,13 @@ static int write_tar_entry(struct archiver_args *args,
> > memcpy(header.linkname, buffer, size);
> > }
> >
> > - prepare_header(args, , mode, size);
> > + size_in_header = size;
Jeff King writes:
> On Fri, Jun 24, 2016 at 01:49:24PM +0200, Remi Galan Alfonso wrote:
>
>> Hi Peff,
>>
>> Jeff King writes:
>> > @@ -413,7 +411,7 @@ static int write_tar_archive(const struct archiver *ar,
>> > {
>> > int err = 0;
>> >
>> > -
On Fri, Jun 24, 2016 at 11:56:19AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > The ustar format only has room for 11 (or 12, depending on
> > some implementations) octal digits for the size and mtime of
> > each file. After this, we have to add pax extended headers
> >
Jeff King writes:
> There's a slight bit of trickiness there. We may already be
> ...
> After writing the extended header, we munge the timestamp in
> the ustar headers to the maximum-allowable size. This is
> wrong, but it's the least-wrong thing we can provide to a
> tar
Jeff King writes:
> If the size was 64GB or greater, then we actually overflowed
> digits into the mtime field, meaning our value was was
was was
> effectively right-shifted by those lost octal digits. And
> this patch is again a strict improvement over that.
> diff --git
Jeff King writes:
> The ustar format only has room for 11 (or 12, depending on
> some implementations) octal digits for the size and mtime of
> each file. After this, we have to add pax extended headers
> to specify the real data, and git does not yet know how to
> do so.
I am
On Fri, Jun 24, 2016 at 11:14 AM, Jeff King wrote:
>
> I do wonder about the ANSI_SUFFIX thing, though.
compat/winansi.c seems to have a provision for 'K' (and obviously 'm'
for colors).
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
I suppose I got ahead of myself there. :-) Thanks for the
clarification on the process.
On Thu, Jun 23, 2016 at 2:17 AM, Junio C Hamano wrote:
> Emily Xie writes:
>
>> Awesome. Thanks, Junio---this is exciting!
>
> No, thank _you_.
>
>> As for step 2: do
On Sat, Jun 18, 2016 at 03:10:27AM +0100, Leo Gaspard wrote:
> First, sorry for not having this message threaded: I'm not subscribed to
> the list and haven't found a way to get a Message-Id from gmane.
Sorry it's taken so long to get back to this. I've been at a
conference.
> So, my questions
On Fri, Jun 24, 2016 at 07:45:04PM +0200, Johannes Schindelin wrote:
> > $ git grep -A2 IMPORTANT color.h
> > color.h: * IMPORTANT: Due to the way these color codes are emulated on
> > Windows,
> > color.h- * write them only using printf(), fprintf(), and fputs(). In
> > particular,
> >
Signed-off-by: Ralf Thielow
---
po/de.po | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/po/de.po b/po/de.po
index d50cb1b..fdf4d92 100644
--- a/po/de.po
+++ b/po/de.po
@@ -12408,7 +12408,7 @@ msgstr ""
#: git-rebase.sh:168
msgid "Applied
Hi Peff,
On Fri, 24 Jun 2016, Jeff King wrote:
> On Tue, Jun 14, 2016 at 11:00:38PM +0200, Lukas Fleischer wrote:
>
> > Improve the readability of recv_sideband() significantly by replacing
> > fragile buffer manipulations with string buffers and more sophisticated
> > format strings. Note that
On Fri, Jun 24, 2016 at 09:54:21AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > ... It's
> > not a flag day for either, of course; we'll build in all of the usual
> > backwards-compatibility flags. But it's convenient for users to remember
> > that "3.0" is the minimum
On Thu, Jun 02, 2016 at 01:11:56PM +0200, Michael Haggerty wrote:
> On 06/01/2016 11:07 PM, Jeff King wrote:
> > On Wed, Jun 01, 2016 at 03:42:18AM -0400, Jeff King wrote:
> >
> >> I have no idea if those ideas would work. But I wouldn't want to start
> >> looking into either of them without
Am 24.06.2016 um 18:46 schrieb Jeff King:
On Fri, Jun 24, 2016 at 06:38:55PM +0200, Johannes Sixt wrote:
It's going to be 269 with ksh, and who-knows-what on Windows (due to lack of
SIGPIPE - I haven't tested this, yet).
Thanks, I meant to ask about that. We do a workaround in t0005, but we
Jeff King writes:
> ... It's
> not a flag day for either, of course; we'll build in all of the usual
> backwards-compatibility flags. But it's convenient for users to remember
> that "3.0" is the minimum to support a new slate of
> backwards-incompatible features.
>
> So my
On Fri, Jun 24, 2016 at 06:38:55PM +0200, Johannes Sixt wrote:
> Am 24.06.2016 um 01:20 schrieb Jeff King:
> > +# We expect git to die with SIGPIPE here (otherwise we
> > +# would generate the whole 64GB).
> > +test_expect_failure BUNZIP 'generate tar with huge size' '
> > + {
> > +
Jeff King writes:
> On Wed, Jun 22, 2016 at 08:25:59AM +0100, Philip Oakley wrote:
>
>> Is there a common name for the A..B range format (two dots) that would
>> complement the A...B (three dots) symmetric range format's name?
>>
>> I was looking at the --left-right distinctions
Am 24.06.2016 um 01:20 schrieb Jeff King:
+# We expect git to die with SIGPIPE here (otherwise we
+# would generate the whole 64GB).
+test_expect_failure BUNZIP 'generate tar with huge size' '
+ {
+ git archive HEAD
+ echo $? >exit-code
+ } | head -c 4096
On Wed, Jun 22, 2016 at 08:25:59AM +0100, Philip Oakley wrote:
> Is there a common name for the A..B range format (two dots) that would
> complement the A...B (three dots) symmetric range format's name?
>
> I was looking at the --left-right distinctions and noticed that the trail
> back to the
On Sun, Jun 19, 2016 at 03:52:04PM -0700, Junio C Hamano wrote:
> Here are the list of topics that are in the "private edition" I use
> for every day work, grouped by where they sit in the the near-term
> plan of merging them up to 'next' and then to 'master'.
By the way, I wondered if you had
On Sun, Jun 19, 2016 at 04:20:14PM +0100, Philip Oakley wrote:
> From: "Ovatta Bianca"
> > I read in every comparison of git vs other version control systems,
> > that git does not record differences but takes "snapshots"
> > I was wondering what a "snapshot" is ? Does
On Tue, Jun 14, 2016 at 11:00:38PM +0200, Lukas Fleischer wrote:
> Improve the readability of recv_sideband() significantly by replacing
> fragile buffer manipulations with string buffers and more sophisticated
> format strings. Note that each line is printed using a single write()
> syscall to
On Tue, Jun 21, 2016 at 03:22:04PM -0700, Junio C Hamano wrote:
> "brian m. carlson" writes:
>
> I was trying to make sure there is no misconversion, but some lines
> that got wrapped were distracting. For example:
>
> > @@ -2721,7 +2722,8 @@ static int
On Tue, Sep 22, 2015 at 2:48 PM, Jacob Godserv wrote:
> I found a specific case in which git-svn improperly aborts:
>
> 1. I created a git-svn repository, named "git-svn repo", by cloned an
> svn repository via the git-svn tool.
> 2. I created a normal git repository,
Subsequent patches will want to reuse the 'signed' branch that the
'log --graph --show-signature' test creates and uses.
Split the set-up part into a test of its own, and make the existing
test into a separate one that only inspects the history on the 'signed'
branch. This way, it becomes clearer
Hi,
On Thu, 23 Jun 2016, UberBooster wrote:
> [...] and I also installed MS Office 360. AFTER installing this
> software, Git-Bash was AMAZINGLY fast.
I suspect you mean Office 365.
In any case, it is next to impossible to diagnose slowness after it
dissipated.
For the record, we do have a
On Fri, Jun 24, 2016 at 01:49:24PM +0200, Remi Galan Alfonso wrote:
> Hi Peff,
>
> Jeff King writes:
> > @@ -413,7 +411,7 @@ static int write_tar_archive(const struct archiver *ar,
> > {
> > int err = 0;
> >
> > -err = write_global_extended_header(args);
> > +
您好,我们是能够帮您:
1、一天搜索上万家行业内匹配客人邮箱,帮您开发到B2B、展会上遇不到的优质客户。
2、高效邮件营销,帮您获得更多一对一高质量优质客户询盘。
3、让您的潜在客户主动找您洽谈订单!
请加+QQ 3246075707 联系 在线演示主动开发全球客户,欢迎验证是否真实有效
也可加微信号:sunsesoftsam
您是选择主动出击,从源头开发优质客户,还是苦苦等待客户来联系你呢
如有不需要此信息,请回复“不需要”,我们将会将您的邮箱进行屏蔽,不再给您发信的。
On Fri, Jun 24, 2016 at 5:21 AM, Mehul Jain wrote:
> On Thu, Jun 23, 2016 at 12:02 PM, Junio C Hamano wrote:
>> Mehul Jain writes:
>>> In patch 2/3 and 3/3, there are many tests which requires a branch
>>> similar to that of
Às 05:31 de 24-06-2016, Alex Henrie escreveu:
> Signed-off-by: Alex Henrie
> ---
> unpack-trees.c | 18 +-
> 1 file changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/unpack-trees.c b/unpack-trees.c
> index 6bc9512..11c37fb 100644
> ---
Hi Peff,
Jeff King writes:
> @@ -413,7 +411,7 @@ static int write_tar_archive(const struct archiver *ar,
> {
> int err = 0;
>
> -err = write_global_extended_header(args);
> +write_global_extended_header(args);
> if (!err)
> err
https://s3-eu-west-1.amazonaws.com/profff/mergeinfo.zip
even ordinary merge may take up to 20-30 minutes. I'll try to trace in future
23.06.2016, 01:58, "Eric Wong" :
> Александр Овчинников wrote:
>> Unfortunately this is not open source repository. I agree
Alex Henrie writes:
> Signed-off-by: Alex Henrie
> ---
> unpack-trees.c | 18 +-
> 1 file changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/unpack-trees.c b/unpack-trees.c
> index 6bc9512..11c37fb 100644
> ---
On Thu, Jun 23, 2016 at 12:02 PM, Junio C Hamano wrote:
> Mehul Jain writes:
>
>> In patch 2/3 and 3/3, there are many tests which requires a branch
>> similar to that of "signed" branch, i.e. a branch with a commit having
>> GPG signature. So
97 matches
Mail list logo