Jeff King writes:
> I'd prefer not to revert. I think setting any of the color config to
> "always" in an on-disk file is basically a broken config. It was
> exacerbated by 4c7f1819b, but it was already broken for scripts that
> call "git log" or "git diff", or even just something as simple as pi
On Tue, Oct 03, 2017 at 04:10:12PM +0900, Junio C Hamano wrote:
> Jeff King writes:
>
> > I'd prefer not to revert. I think setting any of the color config to
> > "always" in an on-disk file is basically a broken config. It was
> > exacerbated by 4c7f1819b, but it was already broken for scripts
Jeff King writes:
> I agree it's not quite the same thing, and I agree the problem was made
> much worse by 4c7f1819b. But I still think color.ui=always is
> inherently a foot-gun, and in either case it is the user that sets it
> that is harmed (and they are the ones who have the power to fix it
On Tue, Oct 03, 2017 at 05:34:40PM +0900, Junio C Hamano wrote:
> Jeff King writes:
>
> > I agree it's not quite the same thing, and I agree the problem was made
> > much worse by 4c7f1819b. But I still think color.ui=always is
> > inherently a foot-gun, and in either case it is the user that s
Christian Couder writes:
> Could you give a bit more details about the use cases this is designed for?
> It seems that when people review my work they want a lot of details
> about the use cases, so I guess they would also be interesting in
> getting this kind of information for your work too.
>
Jeff King writes:
> Note that I'm arguing that it's a foot-gun even without scripts in the
> picture at all. Forget about plumbing versus porcelain. If you set
> color.ui to "always", you're going to get unexpected and confusing
> results from time to time.
Really?
I would think you would cons
On Tue, Oct 03, 2017 at 05:56:53PM +0900, Junio C Hamano wrote:
> Jeff King writes:
>
> > Note that I'm arguing that it's a foot-gun even without scripts in the
> > picture at all. Forget about plumbing versus porcelain. If you set
> > color.ui to "always", you're going to get unexpected and con
I also don't remember why I set it, and as such I removed it.
A helpful hint as to a bad config option would've been great.
Something along the lines of "The use of color.ui = always is not
recommended", with a flag allowing you to disable said warning.
Thanks,
Tsvi
Tsvi Mostovicz
ttm...@gmail.c
On Tue, Oct 03, 2017 at 02:15:15AM -0400, Jeff King wrote:
> The two reasonable paths forward to me are:
>
> 1. Do nothing. Putting "color.ui = always" in your on-disk config is a
> bad idea, and the right fix is to stop doing it.
>
> 2. Make "always" a synonym for "auto". This has the
On Fri, Sep 29, 2017 at 10:36 PM, Jonathan Tan wrote:
> On Wed, 27 Sep 2017 18:46:30 +0200
> Christian Couder wrote:
>> I don't think single-shot processes would be a huge burden, because
>> the code is simpler, and because for example for filters we already
>> have single shot and long-running
On Mon, Oct 02, 2017 at 12:37:53PM +0300, Оля Тележная wrote:
> >> Simplify mru.[ch] and related code by reusing the double-linked list
> >> implementation from list.h instead of a custom one.
> >> This commit is an intermediate step. Our final goal is to get rid of
> >> mru.[ch] at all and inline
There is a need to pass predefined push-option during "git push"
without need to specify it explicitly.
In another words we need to have a new "git config" variable to
specify string that will be automatically passed as "--push-option"
when pushing to remote.
Something like the following:
git co
> lookup_blob() etc. can return NULL if the referenced object isn't of the
> expected type. In theory it's wrong to reference the object member in
> that case. In practice it's OK because it's located at offset 0 for all
> types, so the pointer arithmetic (NULL + 0) is optimized out by the
> comp
(i suppose that if i'm going to continue whining about stuff, i might
as well clone the git source and start submitting patches.)
in "man git-config":
-l
--list
List all variables set in config file, along with their values.
Jeff King writes:
> On Tue, Oct 03, 2017 at 05:56:53PM +0900, Junio C Hamano wrote:
>
>> Jeff King writes:
>>
>> > Note that I'm arguing that it's a foot-gun even without scripts in the
>> > picture at all. Forget about plumbing versus porcelain. If you set
>> > color.ui to "always", you're goi
Derrick Stolee writes:
> p0008.1: find_unique_abbrev() for existing objects
> --
>
> For 10 repeated tests, each checking 100,000 known objects, we find the
> following results when running in a Linux VM:
>
> | | Pack | Packed | Loose | Bas
---
Documentation/config.txt | 2 ++
advice.c | 2 ++
advice.h | 1 +
contrib/completion/git-completion.bash | 1 +
run-command.c | 4
5 files changed, 10 insertions(+)
diff --git a/Documentati
Hi,
On Tue, Oct 3, 2017 at 1:45 AM, Jonathan Nieder wrote:
> Proposed fix: because of case (1), I would like a way to tell Git to
> stop trusting any files in .git. That is:
>
> 1. Introduce a (configurable) list of "safe" configuration items that
> can be set in .git/config and don't resp
On 10/3/2017 6:49 AM, Junio C Hamano wrote:
Derrick Stolee writes:
p0008.1: find_unique_abbrev() for existing objects
--
For 10 repeated tests, each checking 100,000 known objects, we find the
following results when running in a Linux VM:
|
"Junio C Hamano" writes:
> Jonathan Nieder writes:
>
>>> what's with that "git config bla ~/"? is this some config keyword
>>> or something?
>> ...
>>
>> I agree with you that it is less clear than it could be. Ideas for
>> clarifying it?
>
> Yeah, if it were
>
> git config section.var
On Mon, Oct 02, 2017 at 04:45:17PM -0700, Jonathan Nieder wrote:
> This topic has been mentioned on this mailing list before but I had
> trouble finding a relevant reference. Links welcome.
There were discussions long ago related to the upload-pack hook. One of
the proposed fixes was checking th
Am 03.10.2017 um 12:22 schrieb SZEDER Gábor:
>> lookup_blob() etc. can return NULL if the referenced object isn't of the
>> expected type. In theory it's wrong to reference the object member in
>> that case. In practice it's OK because it's located at offset 0 for all
>> types, so the pointer ari
On Tue, Oct 03, 2017 at 02:40:26PM +0900, Junio C Hamano wrote:
> Jonathan Nieder writes:
...
> > +Meaning of signatures
> > +~
> > +The signed payload for signed commits and tags does not explicitly
> > +name the hash used to identify objects. If some day Git adopts a new
> >
Dear Friend,
Good Day. I know this message might meet you in utmost surprise;
however, it's just my urgent need for a foreign partner that made me
to contact you for this mutual benefiting business when searching for
a good and reliable and trust worthy person. I got your contact email
address fro
t4015 contains many color-related tests which need to
override the "is stdout a tty" check. They do so by setting
the color.diff config, but we can accomplish the same with
the --color option. Besides being shorter to type, switching
will prepare us for upcoming changes to "always" when see it
in c
The tests for --color-moved write their output to a file,
but doing so suppresses color output under "auto". Right now
this is solved by running the whole script under
"color.diff=always". In preparation for the behavior of
"always" changing, let's explicitly enable color.
Signed-off-by: Jeff King
On Tue, Oct 03, 2017 at 07:38:24PM +0900, Junio C Hamano wrote:
> That's an argument to say color.ui=always is not a useful thing to
> use and Git is wrong to offer such a nonsense option. I agree with
> both of them.
>
> But it is a different matter that plumbing commands are now doing
> the "c
The point of the test-terminal script is to simulate in the
test scripts an environment where output is going to a real
terminal.
But since test-lib.sh also sets TERM=dumb, the simulation
isn't very realistic. The color code will skip auto-coloring
for TERM=dumb, leading to us liberally sprinkling
To check that "status -v" respects diff config, we set
"color.diff" and look at the output of "status". We could
equally well use any diff config. Since color output depends
on a lot of other factors (like whether stdout is a tty, and
how we interpret "always"), let's use a more mundane option.
Si
This script tests the output of status with various formats
when color is enabled. It uses the "always" setting so that
the output is valid even though we capture it in a file.
Using test_terminal gives us a more realistic environment,
and prepares us for the behavior of "always" changing.
Arguabl
When testing whether "add -p" can generate colors, we set
color.ui to "always". This isn't a very good test, as in the
real-world a user typically has "auto" coupled with stdout
going to a terminal (and it's plausible that this could mask
a real bug in add--interactive if we depend on plumbing's
is
In preparation for the behavior of "always" changing to
match "auto", we can simply drop this test. We already check
other forms (like "--color") independently.
Signed-off-by: Jeff King
---
t/t3203-branch-output.sh | 6 --
1 file changed, 6 deletions(-)
diff --git a/t/t3203-branch-output.sh
We test the %C() format placeholders with a variety of
color-inducing options, including "--color" and
"-c color.ui=always". In preparation for the behavior of
"always" changing, we need to do something with those
"always" tests.
We can drop ones that expect "always" to turn on color even
to a fil
This test wants to confirm that "clean -i" shows color
output. Using test_terminal gives us a more realistic
environment than "color.ui=always", and prepares us for the
behavior of "always" changing in a future patch.
Signed-off-by: Jeff King
---
t/t7301-clean-interactive.sh | 5 +++--
1 file ch
To test the color output, we must convince "git branch" to
write colors to a non-terminal. We do that now by setting
the color config to "always". In preparation for the
behavior of "always" changing, let's switch to using the
"--color" command-line option, which is more direct.
Signed-off-by: Je
When ref-filter learned about want_color() in 11b087adfd
(ref-filter: consult want_color() before emitting colors,
2017-07-13), it became useful to be able to turn colors off
and on for specific commands. For git-branch, you can do so
with --color/--no-color.
But for git-for-each-ref and git-tag,
It can be handy to use `--color=always` (or it's synonym
`--color`) on the command-line to convince a command to
produce color even if it's stdout isn't going to the
terminal or a pager.
What's less clear is whether it makes sense to set config
variables like color.ui to `always`. For a one-shot l
Am 03.10.2017 um 14:51 schrieb René Scharfe:
> Am 03.10.2017 um 12:22 schrieb SZEDER Gábor:
>> Furthermore, fsck.c:fsck_walk_tree() does the same "immediately
>> reference the object member in lookup_blob()'s and lookup_tree()'s
>> return value" thing. I think those should receive the same treatme
On Tue, Oct 03, 2017 at 06:34:34AM -0400, rpj...@crashcourse.ca wrote:
> (i suppose that if i'm going to continue whining about stuff, i might
> as well clone the git source and start submitting patches.)
Yes, please. :)
> in "man git-config":
>
> -l
> --list
> List all va
Check if the strbuf containing data to sort is empty before attempting
to trim a trailing newline character.
Signed-off-by: Rene Scharfe
---
t/helper/test-string-list.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/t/helper/test-string-list.c b/t/helper/test-string-list.c
i
On 10/3/2017 4:50 AM, Junio C Hamano wrote:
Christian Couder writes:
Could you give a bit more details about the use cases this is designed for?
It seems that when people review my work they want a lot of details
about the use cases, so I guess they would also be interesting in
getting this
I'm on Windows using Git for Windows v2.13.1. Following github's
recommended process for fixing line endings after adding a
`.gitattributes` file[1], I run the following:
$ rm .git/index && git reset
Once I run `git status`, I see that no files have changed. Note that I
know for a fact in my repo
So once upon a time we compared Gits security model with a
web browser. A web browser lets you execute 3rd party code
(e.g. javascript) and it is supposedly safe to look at malicious sites.
Currently Git only promises to have the clone/fetch operation safe,
not the "here is a zip of my whole repo"
> @@ -505,6 +506,65 @@ static int extend_abbrev_len(const struct object_id
> *oid, void *cb_data)
> return 0;
> }
>
> +static void find_abbrev_len_for_pack(struct packed_git *p,
> +struct min_abbrev_data *mad)
> +{
> + int match = 0;
> + uin
On 2017-10-03 17:00, Robert Dailey wrote:
> I'm on Windows using Git for Windows v2.13.1. Following github's
> recommended process for fixing line endings after adding a
> `.gitattributes` file[1], I run the following:
>
> $ rm .git/index && git reset
>
> Once I run `git status`, I see that no fi
With this patch, it is possible to work on remote filesystems which
were made accessible by tramp.
For example, 'M-x git-status /remote-host:/repository' will show the
status of /repository on 'remote-host' and usual operations like add
or commit are supported there.
First part of the is patch is
On Tue, Oct 3, 2017 at 3:15 AM, Marius Paliga wrote:
> There is a need to pass predefined push-option during "git push"
> without need to specify it explicitly.
>
> In another words we need to have a new "git config" variable to
> specify string that will be automatically passed as "--push-option"
On 10/3/2017 11:55 AM, Stefan Beller wrote:
@@ -505,6 +506,65 @@ static int extend_abbrev_len(const struct object_id *oid,
void *cb_data)
return 0;
}
+static void find_abbrev_len_for_pack(struct packed_git *p,
+struct min_abbrev_data *mad)
+{
+
On Tue, Oct 3, 2017 at 11:26 AM, Torsten Bögershausen wrote:
> The short version is, that the instructions on Github are outdated.
> This is the official procedure (since 2016, Git v2.12 or so)
> But it should work even with older version of Git.
>
> $ echo "* text=auto" >.gitattributes
> $ git re
On Tue, 2017-10-03 at 09:21 +0900, Junio C Hamano wrote:
> Kaartic Sivaraam writes:
>
> I do not even recall what the patches did and if I thought what they
> wanted to do made sense,
I thought you did or may be I misinterpreted the following statement,
On Thursday 17 August 2017 12:58 AM, J
On 2017-10-03 19:23, Robert Dailey wrote:
> On Tue, Oct 3, 2017 at 11:26 AM, Torsten Bögershausen wrote:
>> The short version is, that the instructions on Github are outdated.
>> This is the official procedure (since 2016, Git v2.12 or so)
>> But it should work even with older version of Git.
>>
>
On Mon, Oct 02, 2017 at 01:38:17PM +0300, Tsvi Mostovicz wrote:
> Hi,
>
> When setting "color.ui = always" in the last few versions (not sure
> exactly when this started, but definitely exists in 2.14.1 and
> 2.14.2), git add -p stops working as expected. Instead of prompting
> the user, it skips
On 10/1/2017 4:24 AM, Junio C Hamano wrote:
Ben Peart writes:
I had accumulated the same set of changes with one addition of removing
a duplicate "the" from a comment in the fsmonitor.h file:
diff --git a/fsmonitor.h b/fsmonitor.h
index 8eb6163455..0de644e01a 100644
--- a/fsmonitor.h
+++ b/
I recently tried to run the git test suite with --valgrind.
Unfortunately it didn't come back completely clean. This patch series
fixes a bunch of these errors, although unfortunately not quite all of
them yet.
The remaining failures are in
t0021.15 - This one is not actually valgrind complainin
In cleanup_path we're passing in a char array, run a memcmp on it, and
run through it without ever checking if something is in the array in the
first place. This can lead us to access uninitialized memory, for
example in t5541-http-push-smart.sh test 7, when run under valgrind:
==4423== Condition
The get_oid_hex_from_objpath takes care of creating a oid from a
pathname. It does this by memcpy'ing the first two bytes of the path to
the "hex" string, then skipping the '/', and then copying the rest of the
path to the "hex" string. Currently it fails to increase the pointer to
the hex string
Currently the argv is only allocated on the stack, and then assigned to
process->argv. When the start_subprocess function goes out of scope,
the local argv variable is eliminated from the stack, but the pointer is
still kept around in process->argv.
Much later when we try to access the same proce
Create protocol.{c,h} and provide functions which future servers and
clients can use to determine which protocol to use or is being used.
Also introduce the 'GIT_PROTOCOL' environment variable which will be
used to communicate a colon separated list of keys with optional values
to a server. Unkno
Changes in v3:
* added a new ssh variant 'simple' and update documentation to better reflect
the command-line parameters passed to the ssh command.
* updated various commit messages based on feedback.
* tighten the wording for 'GIT_PROTOCOL' to indicate that both unknown keys
and values mu
A normal request to git-daemon is structured as
"command path/to/repo\0host=..\0" and due to a bug introduced in
49ba83fb6 (Add virtualization support to git-daemon, 2006-09-19) we
aren't able to place any extra arguments (separated by NULs) besides the
host otherwise the parsing of those arguments
From: Jonathan Tan
Currently, get_remote_heads() parses the ref advertisement in one loop,
allowing refs and shallow lines to intersperse, despite this not being
allowed by the specification. Refactor get_remote_heads() to use two
loops instead, enforcing that refs come first, and then shallows.
Teach upload-pack and receive-pack to understand and respond using
protocol version 1, if requested.
Protocol version 1 is simply the original and current protocol (what I'm
calling version 0) with the addition of a single packet line, which
precedes the ref advertisement, indicating the protocol
Signed-off-by: Brandon Williams
---
t/interop/i5700-protocol-transition.sh | 68 ++
1 file changed, 68 insertions(+)
create mode 100755 t/interop/i5700-protocol-transition.sh
diff --git a/t/interop/i5700-protocol-transition.sh
b/t/interop/i5700-protocol-transiti
Add a function which can be used to write the contents of an arbitrary
buffer. This makes it easy to build up data in a buffer before writing
the packet instead of formatting the entire contents of the packet using
'packet_write_fmt()'.
Signed-off-by: Brandon Williams
---
pkt-line.c | 6 ++
Tell a server that protocol v1 can be used by sending the http header
'Git-Protocol' indicating this.
Also teach the apache http server to pass through the 'Git-Protocol'
header as an environment variable 'GIT_PROTOCOL'.
Signed-off-by: Brandon Williams
---
cache.h | 2 ++
http.
When using the 'ssh' transport, the '-o' option is used to specify an
environment variable which should be set on the remote end. This allows
git to send additional information when contacting the server,
requesting the use of a different protocol version via the
'GIT_PROTOCOL' environment variabl
Teach the connection logic to tell a serve that it understands protocol
v1. This is done in 2 different ways for the builtin transports.
1. git://
A normal request to git-daemon is structured as
"command path/to/repo\0host=..\0" and due to a bug introduced in
49ba83fb6 (Add virtualizatio
Teach a client to recognize that a server understands protocol v1 by
looking at the first pkt-line the server sends in response. This is
done by looking for the response "version 1" send by upload-pack or
receive-pack.
Signed-off-by: Brandon Williams
---
connect.c | 30 +
Am 03.10.2017 um 21:57 schrieb Thomas Gummerer:
diff --git a/sub-process.c b/sub-process.c
index 6dde5062be..4680af8193 100644
--- a/sub-process.c
+++ b/sub-process.c
@@ -77,7 +77,9 @@ int subprocess_start(struct hashmap *hashmap, struct
subprocess_entry *entry, co
{
int err;
s
On Tue, Oct 3, 2017 at 12:57 PM, Thomas Gummerer wrote:
> Currently the argv is only allocated on the stack, and then assigned to
> process->argv. When the start_subprocess function goes out of scope,
> the local argv variable is eliminated from the stack, but the pointer is
> still kept around i
Dear sir,
I am Barrister Joseph Taylor, a legal Solicitor. I was the Personal
Attorney and legal adviser to Mr. John ALBIN, a national of your country,
who was an expatriate engineer to British Petroleum oil Company. My
client, his wife, and their three children were involved in the ill fated
Keny
On Tue, 3 Oct 2017, Jeff King wrote:
> On Tue, Oct 03, 2017 at 06:34:34AM -0400, rpj...@crashcourse.ca wrote:
>
> > (i suppose that if i'm going to continue whining about stuff, i might
> > as well clone the git source and start submitting patches.)
>
> Yes, please. :)
>
> > in "man git-config
Our documentation advises to not re-use a strbuf, after strbuf_release
has been called on it. Use the proper reset instead.
Signed-off-by: Stefan Beller
---
Maybe one of the #leftoverbits is to remove the re-init call in release
and see what breaks? (And then fixing up more of such cases as pres
Hello everybody,
I played around with my gitconfig and I think I found a bug while doing
so. I set the following lines in my gitconfig:
[color]
ui = always
When I try to use `git add -p ` I don't see the 'Stage
this hunk'-dialog anymore. First I thought it's some other configuration
but now I
Hi,
Brandon Williams wrote:
> When using the 'ssh' transport, the '-o' option is used to specify an
> environment variable which should be set on the remote end. This allows
> git to send additional information when contacting the server,
> requesting the use of a different protocol version via
Hi,
Stefan Beller wrote:
> Our documentation advises to not re-use a strbuf, after strbuf_release
> has been called on it. Use the proper reset instead.
I'm super surprised at this documentation. strbuf_release maintains
the invariant that a strbuf is always usable (i.e., that we do not have
to
Hi Christian,
Christian Rebischke wrote:
> I played around with my gitconfig and I think I found a bug while doing
> so. I set the following lines in my gitconfig:
>
> [color]
> ui = always
>
> When I try to use `git add -p ` I don't see the 'Stage
> this hunk'-dialog anymore. First I thought
I intend to give you a portion of my wealth as a free-will financial donation
to you, Respond to partake.contact my email (wang.jian...@yandex.com)
Wang Jianlin
Wanda Group
Signed-off-by: Ramsay Jones
---
Hi Derrick,
If you need to re-roll your 'ds/find-unique-abbrev-optim' branch,
could you please squash this into the relevant patch (commit 3792c78ba0,
"test-list-objects: list a subset of object ids", 01-10-2017).
Thanks!
ATB,
Ramsay Jones
t/helper/test-list-
Our documentation advises to not re-use a strbuf, after strbuf_release
has been called on it. Use the proper reset instead.
Currently 'strbuf_release' releases and re-initializes the strbuf, so it
is safe, but slow. 'strbuf_reset' only resets the internal length variable,
such that this could also
Hi,
Stefan Beller wrote:
> Our documentation advises to not re-use a strbuf, after strbuf_release
> has been called on it. Use the proper reset instead.
>
> Reviewed-by: Jonathan Nieder
This is indeed
Reviewed-by: Jonathan Nieder
Thank you.
> Signed-off-by: Stefan Beller
> ---
> builtin/br
Hi,
Thomas Gummerer wrote:
> In cleanup_path we're passing in a char array, run a memcmp on it, and
> run through it without ever checking if something is in the array in the
> first place. This can lead us to access uninitialized memory, for
> example in t5541-http-push-smart.sh test 7, when ru
Hi,
Thomas Gummerer wrote:
> The get_oid_hex_from_objpath takes care of creating a oid from a
> pathname. It does this by memcpy'ing the first two bytes of the path to
> the "hex" string, then skipping the '/', and then copying the rest of the
> path to the "hex" string. Currently it fails to i
Kindly find attached today's cash payments statement of account. 10/3/2017
Reems Exchange Company
SOA-03-10-2017.pdf
Description: SOA-03-10-2017.pdf
René Scharfe wrote:
> Check if the strbuf containing data to sort is empty before attempting
> to trim a trailing newline character.
>
> Signed-off-by: Rene Scharfe
> ---
> t/helper/test-string-list.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Thanks for fixing it.
Reviewed-by: Jon
On Tue, Oct 03, 2017 at 04:54:32PM -0400, Robert P. J. Day wrote:
> > It does that by default, or it lists the contents of a specific file
> > if given (either by --file, or with --system, --global, or --local).
> >
> > So I agree it's not quite accurate, but you probably want some
> > phrasing th
On Tue, Oct 03, 2017 at 03:45:01PM -0700, Jonathan Nieder wrote:
> When I first read the above, I thought it was going to be about a
> NUL-terminated string that was missing a NUL. But in fact, the issue
> is that strlen(path) can be < 2.
>
> In other words, an alternative fix would be
>
>
On Tue, Oct 03, 2017 at 03:53:15PM -0700, Jonathan Nieder wrote:
> Thomas Gummerer wrote:
>
> > The get_oid_hex_from_objpath takes care of creating a oid from a
> > pathname. It does this by memcpy'ing the first two bytes of the path to
> > the "hex" string, then skipping the '/', and then copyi
Jeff King wrote:
> On Tue, Oct 03, 2017 at 03:45:01PM -0700, Jonathan Nieder wrote:
>> In other words, an alternative fix would be
>>
>> if (*path == '.' && path[1] == '/') {
>> ...
>> }
>>
>> which would not require passing in 'len' or switching to index-based
>> arithmet
On Tue, Oct 3, 2017 at 7:39 AM, Jeff Hostetler wrote:
>
> As I see it there are the following major parts to partial clone:
> 1. How to let git-clone (and later git-fetch) specify the desired
>subset of objects that it wants? (A ref-relative request.)
> 2. How to let the server and git-pack-o
On Tue, Oct 03, 2017 at 08:57:10PM +0100, Thomas Gummerer wrote:
> I recently tried to run the git test suite with --valgrind.
> Unfortunately it didn't come back completely clean. This patch series
> fixes a bunch of these errors, although unfortunately not quite all of
> them yet.
Thanks for t
On Tue, Oct 03, 2017 at 03:24:14PM -0700, Jonathan Nieder wrote:
> Here's a patch to address the surprising strbuf.h advice.
>
> -- >8 --
> Subject: strbuf: do not encourage init-after-release
>
> strbuf_release already leaves the strbuf in a valid, initialized
> state, so there is not need to c
Jeff King wrote:
> I think using SANITIZE=memory would catch these, but it needs some
> suppressions tuning. The weird "zlib reads uninitialized memory" error
> is a problem (valgrind sees this, too, but we have suppressions).
What version of zlib do you use? I've heard some good things about
v1
On Tue, Oct 03, 2017 at 02:47:48PM -0700, Jonathan Nieder wrote:
> Hi Christian,
>
> Christian Rebischke wrote:
>
> > I played around with my gitconfig and I think I found a bug while doing
> > so. I set the following lines in my gitconfig:
> >
> > [color]
> > ui = always
> >
> > When I try
On Tue, Oct 03, 2017 at 04:50:58PM -0700, Jonathan Nieder wrote:
> > I think using SANITIZE=memory would catch these, but it needs some
> > suppressions tuning. The weird "zlib reads uninitialized memory" error
> > is a problem (valgrind sees this, too, but we have suppressions).
>
> What version
Dearest,
I am Mrs. Asana Hajraf and I am married to Mr. Hassan Hajraf from kuwait for 19
years without a child and my husband died in 2014. I am contacting you to let
you know my desire to donate the sum of $4.5 million to charities in your
country which I inherited from my late husband. Due t
On Tue, Oct 3, 2017 at 2:45 AM, Christian Couder
wrote:
> Yeah, some people need the faster solution, but my opinion is that
> many other people would prefer the single shot protocol.
> If all you want to do is a simple resumable clone using bundles for
> example, then the long running process sol
On Mon, Oct 2, 2017 at 11:31 PM, Jeff King wrote:
> Right, I kind of wonder if this has fallen into an uncanny value where
> we have this almost-hashmap infrastructure, but the end result is not
> significantly easier to use than a plain-old hashmap.
>
> I.e., it looks like you still have to decla
compat/mingw.c assigns the Windows file creation time [1] to Git's ctime
fields at line 591 and at line 705:
buf->st_ctime = filetime_to_time_t(&(fdata.ftCreationTime));
ftCreationTime > ftLastWriteTime is actually possible after copying a
file, so it makes sense to include this timestamp some
Jonathan Nieder writes:
> +Alternatives considered
> +---
> +Upgrading everyone working on a particular project on a flag day
> +
> ...
> +Using hash functions in parallel
> +
> ...
1 - 100 of 129 matches
Mail list logo
