On Wed, 4 Oct 2017, Junio C Hamano wrote:
> Rats indeed. Let's go incremental as promised, perhaps like this
> (but please supply a better description if you have one).
I think you'll also want the following squashed into 5c8cdcfd8 and
def437671:
-- >8 --
>From 445d45027bb5b7823338cf111910d2884a
Jeff King writes:
> More seriously, is there any interest in marking it as deprecated in the
> release notes and issuing a warning when it's used for a few cycles?
No objection from me.
I do not object with such a well designed deprecation plan for any
other features, if there are other "favour
Thanks. All of my review comments from the previous round seem to
have been addressed, so this is Reviewed-by: me ;-)
Derrick Stolee writes:
> diff --git a/sha1_name.c b/sha1_name.c
> index f2a1ebe49..5081aeb71 100644
> --- a/sha1_name.c
> +++ b/sha1_name.c
> @@ -480,13 +480,23 @@ struct min_abbrev_data {
> char *hex;
> };
>
> +static inline char get_hex_char_from_oid(const struct object_id *oid,
> +
Derrick Stolee writes:
> 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
>>> foll
Derrick Stolee writes:
> -int find_unique_abbrev_r(char *hex, const unsigned char *sha1, int len)
> +struct min_abbrev_data {
> + unsigned int init_len;
> + unsigned int cur_len;
> + char *hex;
> +};
> +
> +static int extend_abbrev_len(const struct object_id *oid, void *cb_data)
> {
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 subprocess_start(struct hashmap *ha
On Wed, Oct 04, 2017 at 01:59:31PM +0900, Junio C Hamano wrote:
> > Perhaps this should become
> >
> > argv_array_push(&process->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 wh
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 st
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
> >>> completely (or at least prov
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 == '.' && path[1] == '/') {
> >>>
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 really like that, too. It has been
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 maintain and has
> been ver
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
>> subprocess_entry
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 lot of pain
> whe
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 passing in 'len' or sw
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 From:
header of
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 the logic to diagnose extra argum
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 original 28/29
> patch series; in pa
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 (GitHub is totally a differe
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
>> ...
>
> I prefer your "section.var" proposal above. I think people wh
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 think those sh
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]: test-terminal: set TERM=vt1
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 si
+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
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 only bug! (I have probably fo
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 strbuf *);
>
> I th
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 you have one).
-- >8 -
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 we ended up with
Jonathan Nieder writes:
> +Alternatives considered
> +---
> +Upgrading everyone working on a particular project on a flag day
> +
> ...
> +Using hash functions in parallel
> +
> ...
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
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
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
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 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
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
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 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
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 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
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 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
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 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
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
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
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
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,
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
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
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-
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
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
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,
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
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
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
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
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, 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
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
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 +
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
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.
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
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
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
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
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/
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 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 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 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 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 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"
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 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
> @@ -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
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"
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
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
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 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
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
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
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,
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
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
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
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
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
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
1 - 100 of 129 matches
Mail list logo