Re: [PATCH 3/3] sub-process: allocate argv on the heap

Am 04.10.2017 um 06:59 schrieb Junio C Hamano: Johannes Sixt writes: 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

Re: [PATCH 3/3] sub-process: allocate argv on the heap

On Wed, Oct 04, 2017 at 01:59:31PM +0900, Junio C Hamano wrote: > > Perhaps this should become > > > > argv_array_push(>args, cmd); > > > > so that there is no new memory leak? > > Sounds like a good idea (if I am not grossly mistaken as to what is > being suggested). > > Here is what I am

Re: [PATCH v2] strbuf doc: reuse after strbuf_release is fine

On Tue, Oct 03, 2017 at 07:39:54PM -0700, Jonathan Nieder wrote: > > I think it's actually OK to use the string buffer after this function. > > It's just an empty string. > > > > Perhaps we should be more explicit: this releases any resources and > > resets to a pristine, empty state. I suspect

Re: [PATCH 2/3] http-push: fix construction of hex value from path

On Wed, Oct 04, 2017 at 02:20:05PM +0900, Junio C Hamano wrote: > Junio C Hamano writes: > > > Jeff King writes: > > > >>> Moreover, this is in the webdav-based "dumb http" push code path, > >>> which I do not trust much at all. I wonder if we could retire it

Re: [PATCH 1/3] path.c: fix uninitialized memory access

On Wed, Oct 04, 2017 at 01:47:29PM +0900, Junio C Hamano wrote: > Jonathan Nieder writes: > > > 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 == '.' &&

Re: [PATCH 2/3] http-push: fix construction of hex value from path

Junio C Hamano writes: > Jeff King writes: > >>> Moreover, this is in the webdav-based "dumb http" push code path, >>> which I do not trust much at all. I wonder if we could retire it >>> completely (or at least provide an option to turn it off). >> >> I would

Re: [PATCH v2] strbuf doc: reuse after strbuf_release is fine

Jonathan Nieder writes: > strbuf_release leaves the strbuf in a valid, initialized state, so > there is no need to call strbuf_init after it. > > Moreover, this is not likely to change in the future: strbuf_release > leaving the strbuf in a valid state has been easy to

Re: [PATCH 3/3] sub-process: allocate argv on the heap

Johannes Sixt writes: > 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 >>

Re: [PATCH 2/3] http-push: fix construction of hex value from path

Jeff King writes: >> Moreover, this is in the webdav-based "dumb http" push code path, >> which I do not trust much at all. I wonder if we could retire it >> completely (or at least provide an option to turn it off). > > I would really like that, too. It has been the cause of a

Re: [PATCH 1/3] path.c: fix uninitialized memory access

Jonathan Nieder writes: > 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

Re: [PATCH] run-command.c: add hint when hook is not executable

Damien writes: > --- Please explain why this change makes sense to those who find this commit in "git log" output six months down the line, without having read the original thread that motivated you to add this feature above this line with three dashes. Use your full name on the

Re: [PATCH v2] branch: change the error messages to be more meaningful

Kaartic Sivaraam writes: > I interpreted the "not .. too bad" as a "it makes little sense". So, > pinged the thread. Thanks. I think what the patch does (sort of) makes sense. It is a bit dissapointing that we do not need to touch tests, as it indicates that

Re: [PATCH v16 1/6] bisect--helper: use OPT_CMDMODE instead of OPT_BOOL

Ramsay Jones writes: > On 03/10/17 04:51, Junio C Hamano wrote: >> >> It seems that Pranit needs a bit more work to take known fixes from >> your efforts and we should wait for the series to be rerolled? > > This series is just the first few patches from the

Re: new contributors presentation

Nathan PAYRE writes: > Hi all, > me and my two other partner (Daniel and Timothee) have make the choice > to contribute to gitHub for a university project supervised by Mattieu > Moy. First things first. I suspect that you are trying to contribute to the Git project

Re: What means "git config bla ~/"?

Matthieu Moy writes: > "Junio C Hamano" writes: > >> Jonathan Nieder writes: >> what's with that "git config bla ~/"? is this some config keyword or something? >>> ... >> git config section.var ~/some/thing >> ... > >

Re: [PATCH] fsck: check results of lookup_blob() and lookup_tree() for NULL

René Scharfe writes: > 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

Re: Updated to v2.14.2 on macOS; git add --patch broken

Jeff King writes: > Here's what I came up with on the "color.ui=always is nonsense that we > should not offer" front. The number of patches may be a little daunting, > but most of them are just removing cases of "git -c color.ui=always" > from the tests. > > [01/12]:

[PATCH v2] strbuf doc: reuse after strbuf_release is fine

strbuf_release leaves the strbuf in a valid, initialized state, so there is no need to call strbuf_init after it. Moreover, this is not likely to change in the future: strbuf_release leaving the strbuf in a valid state has been easy to maintain and has been very helpful for Git's robustness and

Re: Git for Windows: mingw.c's strange usage of creation time as ctime?

+git-for-windows Hi Marc, Marc Strapetz wrote: > 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

Re: [PATCH v16 1/6] bisect--helper: use OPT_CMDMODE instead of OPT_BOOL

On 03/10/17 04:51, Junio C Hamano wrote: > Ramsay Jones writes: > >> On 02/10/17 14:44, Pranit Bauva wrote: >> [snip] >>> ... >> Yes, I also meant to tidy that up by removing some, now >> redundant, initialisation later in that function. >> >> Note, that wasn't the

Re: [PATCH] branch: reset instead of release a strbuf

Jeff King writes: >> /** >> * Release a string buffer and the memory it used. You should not use the >> - * string buffer after using this function, unless you initialize it again. >> + * string buffer after using this function. >> */ >> extern void strbuf_release(struct

Re: [PATCH v8 00/12] Fast git status via a file system watcher

Ben Peart writes: > Well, rats. I found one more issue that applies to two of the > commits. Can you squash this in as well or do you want it in some > other form? Rats indeed. Let's go incremental as promised, perhaps like this (but please supply a better description if

Re: Line ending normalization doesn't work as expected

Torsten Bögershausen writes: >> $ git rm -r --cached . && git add . > > (Both should work) > > To be honest, from the documentation, I can't figure out the difference > between > $ git read-tree --empty > and > $ git rm -r --cached . > > Does anybody remember the discussion, why

Re: [PATCH v4] technical doc: add a design doc for hash function transition

Jonathan Nieder writes: > +Alternatives considered > +--- > +Upgrading everyone working on a particular project on a flag day > + > ... > +Using hash functions in parallel >

Git for Windows: mingw.c's strange usage of creation time as ctime?

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

Re: [PATCH v2] oidmap: map with OID as key

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

Re: [PATCH v6 09/40] Add initial external odb support

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

Dearest

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

Re: [PATCH 0/3] fixes for running the test suite with --valgrind

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

Re: [bug] git version 2.4.12 color.ui = always breaks git add -p

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

Re: [PATCH 0/3] fixes for running the test suite with --valgrind

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

Re: [PATCH] branch: reset instead of release a strbuf

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

Re: [PATCH 0/3] fixes for running the test suite with --valgrind

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

Re: [PATCH 00/18] Partial clone (from clone to lazy fetch in 18 patches)

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

Re: [PATCH 1/3] path.c: fix uninitialized memory access

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 >>

Re: [PATCH 2/3] http-push: fix construction of hex value from path

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

Re: [PATCH 1/3] path.c: fix uninitialized memory access

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 > >

Re: "man git-config", "--list" option misleadingly refers to "config file" (singular)

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

Re: [PATCH] test-stringlist: avoid buffer underrun when sorting nothing

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.

Cash Statement of Account 10/03/2017

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

Re: [PATCH 2/3] http-push: fix construction of hex value from path

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

Re: [PATCH 1/3] path.c: fix uninitialized memory access

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

Re: [PATCH] branch: reset instead of release a strbuf

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. >

[PATCH] branch: reset instead of release a strbuf

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

[PATCH] test-list-objects: mark file-local symbols as static

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,

contact my email (wang.jian...@yandex.com)

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

Re: [bug] git version 2.4.12 color.ui = always breaks git add -p

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

Re: [PATCH] branch: reset instead of release a strbuf

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

Re: [PATCH v3 10/10] ssh: introduce a 'simple' ssh variant

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

[bug] git version 2.4.12 color.ui = always breaks git add -p

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

[PATCH] branch: reset instead of release a strbuf

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

Re: "man git-config", "--list" option misleadingly refers to "config file" (singular)

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

Project Proposal

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

Re: [PATCH 3/3] sub-process: allocate argv on the heap

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

Re: [PATCH 3/3] sub-process: allocate argv on the heap

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;

[PATCH v3 06/10] connect: teach client to recognize v1 server response

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

[PATCH v3 10/10] ssh: introduce a 'simple' ssh variant

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

[PATCH v3 07/10] connect: tell server that the client understands v1

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

[PATCH v3 08/10] http: tell server that the client understands v1

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

[PATCH v3 02/10] pkt-line: add packet_write function

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 ---

[PATCH v3 01/10] connect: in ref advertisement, shallows are last

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

[PATCH v3 05/10] upload-pack, receive-pack: introduce protocol version 1

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

[PATCH v3 09/10] i5700: add interop test for protocol transition

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

[PATCH v3 04/10] daemon: recognize hidden request arguments

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

[PATCH v3 03/10] protocol: introduce protocol extention mechanisms

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.

[PATCH v3 00/10] protocol transition

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

[PATCH 3/3] sub-process: allocate argv on the heap

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

[PATCH 0/3] fixes for running the test suite with --valgrind

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

[PATCH 1/3] path.c: fix uninitialized memory access

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==

[PATCH 2/3] http-push: fix construction of hex value from path

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

Re: [PATCH v8 00/12] Fast git status via a file system watcher

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

Re: git add -p stops working when setting color.ui = always

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

Re: Line ending normalization doesn't work as expected

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

Re: [PATCH v2] branch: change the error messages to be more meaningful

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

Re: Line ending normalization doesn't work as expected

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"

Re: [PATCH v3 5/5] sha1_name: Minimize OID comparisons during disambiguation

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) +{ +

Re: Enhancement request: git-push: Allow (configurable) default push-option

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

[PATCH] emacs: work with remote filesystems

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

Re: Line ending normalization doesn't work as expected

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

Re: [PATCH v3 5/5] sha1_name: Minimize OID comparisons during disambiguation

> @@ -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; > +

Re: Security of .git/config and .git/hooks

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

Line ending normalization doesn't work as expected

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

Re: [PATCH 00/18] Partial clone (from clone to lazy fetch in 18 patches)

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

[PATCH] test-stringlist: avoid buffer underrun when sorting nothing

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

Re: "man git-config", "--list" option misleadingly refers to "config file" (singular)

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

[PATCH] fsck: check results of lookup_blob() and lookup_tree() for NULL

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

[PATCH 12/12] color: make "always" the same as "auto" in config

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

[PATCH 11/12] provide --color option for all ref-filter users

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,

[PATCH 10/12] t3205: use --color instead of color.branch=always

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:

[PATCH 09/12] t7301: use test_terminal to check color

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

[PATCH 07/12] t6006: drop "always" color config tests

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

[PATCH 08/12] t3203: drop "always" color test

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

[PATCH 04/12] t3701: use test-terminal to collect color output

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

[PATCH 05/12] t7508: use test_terminal for color output

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.

[PATCH 06/12] t7502: use diff.noprefix for --verbose test

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.

[PATCH 01/12] test-terminal: set TERM=vt100

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

Re: Updated to v2.14.2 on macOS; git add --patch broken

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

[PATCH 03/12] t4015: use --color with --color-moved

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

[PATCH 02/12] t4015: prefer --color to -c color.diff=always

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

I am waiting for your Reply

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

  1   2   >