Stefan Beller writes:
> diff --git a/list-objects.c b/list-objects.c
> index bf46f80dff..5e114c9a8a 100644
> --- a/list-objects.c
> +++ b/list-objects.c
> @@ -237,6 +237,8 @@ void traverse_commit_list(struct rev_info *revs,
> if (commit->tree)
> add_pending_tre
Stefan Beller writes:
> diff --git a/Documentation/git-describe.txt b/Documentation/git-describe.txt
> index c924c945ba..3d618b2445 100644
> --- a/Documentation/git-describe.txt
> +++ b/Documentation/git-describe.txt
> @@ -3,7 +3,7 @@ git-describe(1)
>
> NAME
>
> -git-describe - Describe
Stefan Beller writes:
> With traverse_trees_and_blobs factored out of the main traverse function,
> the next patch can introduce an in-order revision walking with ease.
>
> The variable holding the base path is only used in the newly factored out
> function `traverse_trees_and_blobs`, however we
Jonathan Nieder writes:
>> This feature was introduced as an experimental feature into Git for
>> Windows v2.11.0(2) and has been tested ever since. I feel it is
>> well-tested enough that it can be integrated into core Git.
>
> Can this rationale go in the commit messages?
>
> Actually I wouldn'
Carlos Martín Nieto writes:
> This heuristic has been the default since 2.14 so we should not confuse our
> users by saying that it's experimental and off by default.
>
> Signed-off-by: Carlos Martín Nieto
> ---
Good eyes. Nobody raised noises since this happened at 2.14 until
now, so this cou
Alex Vandiver writes:
> diff --git a/fsmonitor.c b/fsmonitor.c
> index 4ea44dcc6..417759224 100644
> --- a/fsmonitor.c
> +++ b/fsmonitor.c
> @@ -49,20 +49,7 @@ int read_fsmonitor_extension(struct index_state *istate,
> const void *data,
> ewah_free(fsmonitor_dirty);
>
Antoine Beaupré writes:
> On 2017-10-30 11:29:55, Matthieu Moy wrote:
>>> It should also be mentioned that this contrib isn't very active: I'm not
>>> part of the GitHub organization, yet I'm probably the one that's been
>>> the most active with patches in the last year (and I wasn't very active
That is more in line with the design decision made in the previous
step to pass struct by reference.
We may want to squash this into the previous patch eventually.
Signed-off-by: Junio C Hamano
---
* I am OK either way as long as things are consistent; as you took
time to change the code to
Change the meaning of the bit to "the user explicitly set the
allow-textconv bit to true from the command line".
The "touched" mechanism in the old code meant to express "the user
explicitly set the allow-textconv bit to something from the command
line" and recorded that fact upon "--no-textconv",
Brandon Williams writes:
> diff --git a/builtin/log.c b/builtin/log.c
> index dc28d43eb..82131751d 100644
> --- a/builtin/log.c
> +++ b/builtin/log.c
> @@ -485,7 +485,7 @@ static int show_blob_object(const struct object_id *oid,
> struct rev_info *rev, c
> unsigned long size;
>
> f
Brandon Williams writes:
> + if (flags)
> + rev.diffopt.flags = diff_flags_or(&rev.diffopt.flags, flags);
If we are avoiding from passing a struct (even if it is a small one)
by value, then returning a struct as value defeats the point of the
exercise, I would think. If that wil
Yubin Ruan writes:
> diff --git a/path/somefile b/path/somefile
> index f8886b4..a1c96df 100644
> --- a/path/somefile
> +++ b/path/somefile
>
>
> This is output by a `git diff` between two adjacent commits but they are
> not any commit hash. I grep through the whole $(git log) but still cannot
>
Hi,
Can anyone tell me what does the "f8886b4..a1c96df" mean in a git diff output,
as below?
diff --git a/path/somefile b/path/somefile
index f8886b4..a1c96df 100644
--- a/path/somefile
+++ b/path/somefile
This is output by a `git diff` between two adjacent commits but they are
not any commit h
jameson.mille...@gmail.com writes:
> Only difference from previous version is to update the commit author
> email to match corporate email address.
Will replace; thanks.
Junio C Hamano writes:
> Junio C Hamano writes:
>
>> I still haven't brought myself to like the structure being passed by
>> value and the singleton diff_flags_cleared thing, but I suspect that
>> we may get used to them once we start using these. I dunno.
>
> Just bikeshedding, but I just had
Stefan Beller writes:
> (I note this as you regard your patches as a lunch time hack
> in the cooking email; I am serious about these patches though.)
We do not want to touch borrowed code unnecessarily. Are these
lines and bits hampering further progress we are actively trying to
make right no
Jeff Hostetler writes:
> I've been assuming that the jt/partial-clone-lazy-fetch is a
> placeholder for our next combined patch series.
Yes, that, together with the expectation that I will hear from both
you and JTan once the result of combined effort becomes ready to
replace this placeholder, m
Johannes Schindelin writes:
> Hi Junio,
>
> On Mon, 30 Oct 2017, Junio C Hamano wrote:
>
>> * jc/branch-name-sanity (2017-10-14) 3 commits
>> (merged to 'next' on 2017-10-16 at 174646d1c3)
>> + branch: forbid refs/heads/HEAD
>> + branch: split validate_new_branchname() into two
>> + branch:
Junio C Hamano writes:
> That holds true for the code before or after this patch equally. In
> other words, that sounds like a justification for rejecting this
> patch (i.e. explanation of why this change is not needed).
>
> If we are worried about another thread calling these functions after
>
On 2017-10-31 10:37:29, Junio C Hamano wrote:
>> There's also a hybrid solution used by git-multimail: have a copy of the
>> code in git.git, but do the development separately. I'm not sure it'd be
>> a good idea for Git-Mediawiki, but I'm mentionning it for completeness.
>
> I think the plan was t
Ben Peart writes:
> Any updates or thoughts on this one? While the patch has become quite
> trivial, it does results in a savings of 5%-15% in index load time.
>
> I thought the compromise of having this test only run when DEBUG is
> defined should limit it to developer builds (hopefully everyon
Andrey Okoshkin writes:
> Get 'GIT_MERGE_VERBOSITY' environment variable only once in
> init_merge_options() and store the pointer to its value for the further check.
OK, that is "what this thing does" description.
> No intervening calls to getenv(), putenv(), setenv() or unsetenv() are done
>
Matthieu Moy writes:
> So, my conclusion is that a simpler submission mechanism (GitHub's
> pull-requests) and a less picky code review would help Git-Mediawiki.
>
> From previous discussions, I think Junio will agree with that: he's
> reluctant to keeping too much stuff in contrib/ and usally pr
On Mon, Oct 30, 2017 at 01:28:05PM +0900, Junio C Hamano wrote:
> "brian m. carlson" writes:
>
> Thanks. I personally prefer the plain-text original, but I do
> understand the need to have a version with ids that you can tell
> others to visit in their browsers. Assuming that this goes in the
>
In the next patch we'll learn how to describe more than just commits,
so factor out describing commits into its own function. That will make
the next patches easy as we still need to describe a commit as part of
describing blobs.
While factoring out the functionality to describe_commit, make sure
The functionality to list tree objects in the order they were seen
while traversing the commits will be used in the next commit,
where we teach `git describe` to describe not only commits, but
trees and blobs, too.
Helped-by: Johannes Schindelin
Signed-off-by: Stefan Beller
---
list-objects.c
The function `describe` has already a variable named `oid` declared at
the beginning of the function for an object id. Do now shadow that
variable with a pointer to an object id.
Signed-off-by: Stefan Beller
---
builtin/describe.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
d
With traverse_trees_and_blobs factored out of the main traverse function,
the next patch can introduce an in-order revision walking with ease.
The variable holding the base path is only used in the newly factored out
function `traverse_trees_and_blobs`, however we keep its scope to
`traverse_commi
Sometimes users are given a hash of an object and they want to
identify it further (ex.: Use verify-pack to find the largest blobs,
but what are these? or [1])
"This is an interesting endeavor, because describing things is hard."
-- me, upon writing this patch.
When describing commits, we try t
This is not an RFC any more, but a serious series.
Occasionally a user is given an object hash from a blob as an error message
or other output (e.g. [1]).
It would be useful to get a further description of such a blob, such as
the (commit, path) tuple where this blob was introduced.
This impleme
For debuggers aid we'd want to print debug statements early, so
introduce a new line in the debug output that describes the whole
function, and the change the next debug output to describe why we need
to search. Conveniently drop the arg from the second line; which will
be useful in a follow up com
On Mon, 30 Oct 2017, Jeff King wrote:
> On Mon, Oct 30, 2017 at 08:48:48AM -0400, Ben Peart wrote:
>
> > Any updates or thoughts on this one? While the patch has become quite
> > trivial, it does results in a savings of 5%-15% in index load time.
>
> I like the general direction of avoiding the
Signed-off-by: Stefan Beller
---
t/t6120-describe.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/t/t6120-describe.sh b/t/t6120-describe.sh
index 3be01316e8..fd329f173a 100755
--- a/t/t6120-describe.sh
+++ b/t/t6120-describe.sh
@@ -304,7 +304,7 @@ test_expect_success 'descr
On 10/28, brian m. carlson wrote:
> Since in the future we want to support an additional hash algorithm, add
> a structure that represents a hash algorithm and all the data that must
> go along with it. Add a constant to allow easy enumeration of hash
> algorithms. Implement function typedefs to
On Mon, Oct 30, 2017 at 01:35:19PM +0100, Johannes Schindelin wrote:
> If you want to go into the direction of the web, AsciiDoc is actually the
> wrong choice IMO, and Markdown would be the right choice. Basically
> everybody on the web is either supporting Markdown or being asked by users
> to do
Those patches implements a new --quote-email= option.
Typical use case: the user receives a bug report by email and replies with a
patch.
Before this patch, to make a proper reply, the user had to perform
several steps manually using "git send-email":
* Add --in-reply-to= to the command-line for
From: Tom Russello
---
Documentation/git-send-email.txt | 4 +-
git-send-email.perl | 80 ++--
t/t9001-send-email.sh| 19 +-
3 files changed, 97 insertions(+), 6 deletions(-)
diff --git a/Documentation/git-send-email.txt b/Do
From: Tom Russello
---
Documentation/git-send-email.txt | 3 +
git-send-email.perl | 70 ++-
t/t9001-send-email.sh| 117 +--
3 files changed, 147 insertions(+), 43 deletions(-)
diff --git a/Documentation/git-sen
Hi,
Jonathan Tan wrote:
> As for how this patch set (excluding the partialclone patch) interacts
> with my fsck series, they are relatively independent, as far as I can
> tell. I'll rebase my fsck, gc, and lazy object fetch patches (but not
> the fetch and clone parts, which we plan to instead ad
Remove the `DIFF_OPT_SET` macro and instead set the flags directly.
This conversion is done using the following semantic patch:
@@
expression E;
identifier fld;
@@
- DIFF_OPT_CLR(&E, fld)
+ E.flags.fld = 0
@@
type T;
T *ptr;
Remove the `DIFF_OPT_SET` macro and instead set the flags directly.
This conversion is done using the following semantic patch:
@@
expression E;
identifier fld;
@@
- DIFF_OPT_SET(&E, fld)
+ E.flags.fld = 1
@@
type T;
T *ptr;
Remove the `DIFF_OPT_TST` macro and instead access the flags directly.
This conversion is done using the following semantic patch:
@@
expression E;
identifier fld;
@@
- DIFF_OPT_TST(&E, fld)
+ E.flags.fld
@@
type T;
T *ptr;
Now that the flags stored in struct diff_flags are being accessed
directly and not through macros, change all struct members from being
uppercase to lowercase.
This conversion is done using the following semantic patch:
@@
expression E;
@@
- E.RECURSIVE
+ E.
Hi,
Johannes Schindelin wrote:
> Particularly when calling Git from applications, such as Visual Studio,
> it is important that stdin/stdout/stderr are closed properly. However,
> when spawning processes on Windows, those handles must be marked as
> inheritable if we want to use them, but that fl
On 10/30, Brandon Williams wrote:
> On 10/30, Stefan Beller wrote:
> > On Mon, Oct 30, 2017 at 12:46 PM, Brandon Williams
> > wrote:
> > > git-show is unique in that it wants to use textconv by default except
> > > for when it is showing blobs. When asked to show a blob, show doesn't
> > > want
On 10/30, Stefan Beller wrote:
> On Mon, Oct 30, 2017 at 12:46 PM, Brandon Williams wrote:
> > git-show is unique in that it wants to use textconv by default except
> > for when it is showing blobs. When asked to show a blob, show doesn't
> > want to use textconv unless the user explicitly reques
On Mon, Oct 30, 2017 at 12:46 PM, Brandon Williams wrote:
> git-show is unique in that it wants to use textconv by default except
> for when it is showing blobs. When asked to show a blob, show doesn't
> want to use textconv unless the user explicitly requested that it be
> used by providing the
On 10/30/2017 1:31 PM, Johannes Schindelin wrote:
Hi Junio,
On Mon, 30 Oct 2017, Junio C Hamano wrote:
* jt/partial-clone-lazy-fetch (2017-10-02) 18 commits
- fetch-pack: restore save_commit_buffer after use
- unpack-trees: batch fetching of missing blobs
- clone: configure blobmaxbyte
git-show is unique in that it wants to use textconv by default except
for when it is showing blobs. When asked to show a blob, show doesn't
want to use textconv unless the user explicitly requested that it be
used by providing the command line flag '--textconv'.
Currently this is done by using a
Now that the set of parallel touched flags are no longer being used,
remove them.
Signed-off-by: Brandon Williams
---
builtin/log.c | 2 --
diff.h| 6 ++
2 files changed, 2 insertions(+), 6 deletions(-)
diff --git a/builtin/log.c b/builtin/log.c
index 82131751d..9c0815270 100644
---
We cannot add many more flags to the diff machinery due to the
limitations of the number of flags that can be stored in a single
unsigned int. In order to allow for more flags to be added to the diff
machinery in the future this patch converts the flags to be stored in
bitfields in 'struct diff_fl
Changes in v2:
* removed the diff_flags_cleared singleton
* eliminated the 'touched' parallel flags
* pass structs by reference instead of by value
Now that the 'touched' flags have been removed it may be valuable to go ahead
and remove the macros all together (including making the flags lower
Instead of explicitly setting the 'DIFF_OPT_OVERRIDE_SUBMODULE_CONFIG'
flag, use the 'DIFF_OPT_SET' macro.
Signed-off-by: Brandon Williams
---
builtin/add.c | 2 +-
builtin/reset.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/builtin/add.c b/builtin/add.c
index a648cf
On 10/30, Junio C Hamano wrote:
> Junio C Hamano writes:
>
> > I still haven't brought myself to like the structure being passed by
> > value and the singleton diff_flags_cleared thing, but I suspect that
> > we may get used to them once we start using these. I dunno.
>
> Just bikeshedding, but
On Mon, Oct 30, 2017 at 10:59:41AM -0700, Jeff King wrote:
> > There's also https://www.strchr.com/hash_functions, which lists DJB2
> > as Bernstein. Both functions rank somewhere in the middle of that list.
>
> FWIW, I did some experiments with Murmur3 and SipHash a while back, but
> I don't th
On Mon, Oct 30, 2017 at 1:10 PM, Johannes Schindelin
wrote:
> This feature is still highly experimental and has not even been
> contributed to the Git mailing list yet: the feature still needs to be
> battle-tested more.
>
> Signed-off-by: Johannes Schindelin
> ---
> +`GIT_REDIRECT_STDIN`::
> +`G
On Mon, Oct 30, 2017 at 11:08 AM, Jeff King wrote:
> On Mon, Oct 23, 2017 at 01:26:41PM +0100, Philip Oakley wrote:
>
>> > Totally offtopic, but is it only me who finds these "section
>> > headers" in cover letters from some people irritating and/or
>> > jarring?
>>
>> Personally I find that, for
On Mon, Oct 30, 2017 at 06:20:12PM +0100, Johannes Schindelin wrote:
> Subject: Re: [PATCH 1/2] t0302: check helper can handle empty credentials
I guess we really care about t0303 here (which tests external helpers).
This patch adds the test to lib-credential, so it hits the "cache" and
"store" h
On Mon, Oct 23, 2017 at 01:26:41PM +0100, Philip Oakley wrote:
> > Totally offtopic, but is it only me who finds these "section
> > headers" in cover letters from some people irritating and/or
> > jarring?
>
> Personally I find that, for significant patch series, that clearly breaking
> out these
On 10/29, Junio C Hamano wrote:
> Brandon Williams writes:
>
> > Instead of explicitly setting the 'DIFF_OPT_OVERRIDE_SUBMODULE_CONFIG'
> > flag, use the 'DIFF_OPT_SET' macro.
> >
> > Signed-off-by: Brandon Williams
> > ---
>
> Looks good. It's not like one of 1/3 and 2/3 could be a good idea
On Mon, Oct 30, 2017 at 08:48:48AM -0400, Ben Peart wrote:
> Any updates or thoughts on this one? While the patch has become quite
> trivial, it does results in a savings of 5%-15% in index load time.
I like the general direction of avoiding the check during each read.
But...
> I thought the co
On Thu, Oct 26, 2017 at 07:43:19PM +0200, René Scharfe wrote:
> Am 25.10.2017 um 20:49 schrieb Stefan Beller:
> > The implementations in diff.c to detect moved lines needs to compare
> > strings and hash strings, which is implemented in that file, as well
> > as in the xdiff library.
> >
> > Remo
On 10/29, Junio C Hamano wrote:
> Brandon Williams writes:
>
> > We have have reached the limit of the number of flags that can be stored
>
> s/have have/have/; but bit #9 is unused.
>
> "We cannot add many more flags even if we wanted to" would be more
> flexible and does not take this chang
Hey Martin,
On Sat, Oct 28, 2017 at 1:34 AM, Martin Ågren wrote:
> On 27 October 2017 at 17:06, Pranit Bauva wrote:
>> + for (i = 0; i < argc; i++) {
>> + if (!strcmp(argv[i], "--term-good"))
>> + printf(_("%s\n"), terms->term_good);
>> + e
Hey Martin,
On Fri, Oct 27, 2017 at 11:05 PM, Martin Ågren wrote:
> On 27 October 2017 at 17:06, Pranit Bauva wrote:
>> + /*
>> +* have bad (or new) but not good (or old). We could bisect
>> +* although this is less optimum.
>> +*/
>>
On Mon, Oct 30, 2017 at 1:35 PM, Johannes Schindelin
wrote:
> Hi,
>
> On Mon, 30 Oct 2017, Junio C Hamano wrote:
>
>> "brian m. carlson" writes:
>>
>> Thanks. I personally prefer the plain-text original, but I do
>> understand the need to have a version with ids that you can tell
>> others to vi
On Sun, Oct 29, 2017 at 8:12 AM, Carlos Martín Nieto wrote:
> This heuristic has been the default since 2.14 so we should not confuse our
> users by saying that it's experimental and off by default.
>
> Signed-off-by: Carlos Martín Nieto
Looks good to me,
Thanks,
Stefan
On Thu, Oct 26, 2017 at 10:18:53AM +0200, Michael Haggerty wrote:
> Add a test balloon to see if we get complaints from anybody who is
> using a shell that doesn't support the "local" keyword. If so, this
> test can be reverted. If not, we might want to consider using "local"
> in shell code throu
Hey Junio,
On Fri, Oct 27, 2017 at 11:49 PM, Junio C Hamano wrote:
> Pranit Bauva writes:
>
>> - bisect_write "$state" "$rev"
>> + git bisect--helper --bisect-write "$state" "$rev" "$TERM_GOOD"
>> "$TERM_BAD" || exit
>
> I can see why two extra "terms" parameters need to
Hey Martin,
On Fri, Oct 27, 2017 at 10:58 PM, Martin Ågren wrote:
> On 27 October 2017 at 17:06, Pranit Bauva wrote:
>> +static void free_terms(struct bisect_terms *terms)
>> +{
>> + if (!terms->term_good)
>> + free((void *) terms->term_good);
>> + if (!terms->term_bad)
Hi Junio,
On Mon, 30 Oct 2017, Junio C Hamano wrote:
> * jt/partial-clone-lazy-fetch (2017-10-02) 18 commits
> - fetch-pack: restore save_commit_buffer after use
> - unpack-trees: batch fetching of missing blobs
> - clone: configure blobmaxbytes in created repos
> - clone: support excluding l
Hey Stephan,
On Mon, Oct 30, 2017 at 10:04 PM, Stephan Beyer wrote:
> On 10/27/2017 05:06 PM, Pranit Bauva wrote:
>> diff --git a/builtin/bisect--helper.c b/builtin/bisect--helper.c
>> index 0f9c3e63821b8..ab0580ce0089a 100644
>> --- a/builtin/bisect--helper.c
>> +++ b/builtin/bisect--helper.c
>
Hi Junio,
On Mon, 30 Oct 2017, Junio C Hamano wrote:
> * jc/branch-name-sanity (2017-10-14) 3 commits
> (merged to 'next' on 2017-10-16 at 174646d1c3)
> + branch: forbid refs/heads/HEAD
> + branch: split validate_new_branchname() into two
> + branch: streamline "attr_only" handling in valida
Hey Stephan,
On Mon, Oct 30, 2017 at 10:21 PM, Stephan Beyer wrote:
> Hi,
>
>> + return error(_("unrecognised option: '%s'"), arg);
>
> Please write "unrecogni_z_ed".
>
> Since the string for translation changed from
> "unrecognised option: '$arg'"
> to
> "unre
Hey Stephan,
On Mon, Oct 30, 2017 at 6:52 PM, Stephan Beyer wrote:
> Hi Pranit,
>> +static int bisect_reset(const char *commit)
>> +{
>> + struct strbuf branch = STRBUF_INIT;
>> +
>> + if (!commit) {
>> + if (strbuf_read_file(&branch, git_path_bisect_start(), 0) < 1)
>> +
Hey Junio,
On Fri, Oct 27, 2017 at 11:10 PM, Junio C Hamano wrote:
> Pranit Bauva writes:
>
>> +static int bisect_reset(const char *commit)
>> +{
>> + struct strbuf branch = STRBUF_INIT;
>> +
>> + if (!commit) {
>> + if (strbuf_read_file(&branch, git_path_bisect_start(), 0) <
Hi Junio,
On Mon, 30 Oct 2017, Junio C Hamano wrote:
> * cc/git-packet-pm (2017-10-30) 7 commits
> - fixup! Git/Packet.pm: extract parts of t0021/rot13-filter.pl for reuse
I am really terribly sorry for the breakage I introduced here. Junio,
would you mind amending this commit by deleting the "
From: Jameson Miller
Signed-off-by: Jameson Miller
---
Documentation/git-status.txt | 21 +-
Documentation/technical/api-directory-listing.txt | 27 +++
2 files changed, 43 insertions(+), 5 deletions(-)
diff --git a/Documentation/git-sta
From: Jameson Miller
Teach the status command more flexibility in how ignored files are
reported. Currently, the reporting of ignored files and untracked
files are linked. You cannot control how ignored files are reported
independently of how untracked files are reported (i.e. `all` vs
`normal`).
From: Jameson Miller
Add tests around status reporting ignord files that match an exclude
pattern for both --untracked-files=normal and --untracked-files=all.
Signed-off-by: Jameson Miller
---
t/t7521-ignored-mode.sh | 233
1 file changed, 233 i
From: Jameson Miller
Teach status command to handle `--ignored=matching` with
`--untracked-files=normal`
Signed-off-by: Jameson Miller
---
dir.c | 20 ++--
1 file changed, 18 insertions(+), 2 deletions(-)
diff --git a/dir.c b/dir.c
index b9af87eca9..20457724c0 100644
--- a/dir
From: Jameson Miller
Previous patch series can be found:
https://public-inbox.org/git/20171023170534.157740-1-jam...@microsoft.com/
Only difference from previous version is to update the commit author
email to match corporate email address.
Jameson Miller (4):
status: add option to show ignor
From: =?UTF-8?q?Jakub=20Bere=C5=BCa=C5=84ski?=
Empty (length 0) usernames and/or passwords, when saved in the Windows
Credential Manager, come back as null when reading the credential.
One use case for such empty credentials is with NTLM authentication, where
empty username and password instruct
On Fri, Oct 27, 2017 at 10:07 AM, Stefan Beller wrote:
>> Let's do this bit-shuffling as a preliminary clean-up.
>
> These 2 patches can go on top of that as well.
Actually these textually do not conflict with your patch,
and they can be picked independently, e.g. they could
go on top of sb/diff-
From: =?UTF-8?q?Jakub=20Bere=C5=BCa=C5=84ski?=
Make sure the helper does not crash when blank username and password is
provided. If the helper can save such credentials, it should be able to
read them back.
Signed-off-by: Jakub Bereżański
---
t/lib-credential.sh | 19 +++
1 fil
As we learned some time ago, NTLM authentication happens by passing
"empty credentials", i.e. 0-length usernames and passwords.
However, when saved in the Windows Credential Manager, such usernames
and passwords come back as null when reading the credential. Let's
handle this.
This patch series i
This fixes https://github.com/git-for-windows/git/issues/723
Signed-off-by: Johannes Schindelin
---
This patch has been carried in Git for Windows in this form since
Git for Windows v2.11.0(2). It seems to be ready for prime time.
I could just imagine *one* change: to us
This feature is still highly experimental and has not even been
contributed to the Git mailing list yet: the feature still needs to be
battle-tested more.
Signed-off-by: Johannes Schindelin
---
Documentation/git.txt | 17 +
1 file changed, 17 insertions(+)
diff --git a/Documenta
The "2>&1" notation in POSIX shells implies that stderr is redirected to
stdout. Let's special-case this value for the environment variable
GIT_REDIRECT_STDERR to allow writing to the same destination as stdout.
The functionality was suggested by Jeff Hostetler.
Signed-off-by: Johannes Schindelin
On Windows, file handles need to be marked inheritable when they need to
be used as standard input/output/error handles for a newly spawned
process. The problem with that, of course, is that the "inheritable" flag
is global and therefore can wreak havoc with highly multi-threaded
applications: othe
Particularly when calling Git from applications, such as Visual Studio,
it is important that stdin/stdout/stderr are closed properly. However,
when spawning processes on Windows, those handles must be marked as
inheritable if we want to use them, but that flag is a global flag and
may very well be
Hi Andreas,
El vie, 27-10-2017 a las 14:33 +0200, Andreas Schwab escribió:
> On Okt 27 2017, Alvaro del Castillo wrote:
>
> >
> > We're wondering why "fetch-pack" (when is running from the command
> > line) doesn't handle "https://"; protocol. It only works with
> > "git://".
> >
> > For insta
Hi,
> + return error(_("unrecognised option: '%s'"), arg);
Please write "unrecogni_z_ed".
Since the string for translation changed from
"unrecognised option: '$arg'"
to
"unrecognised option: '%s'"
anyway, it does not result in further work for the translators
On Sat, Oct 28, 2017 at 11:12 AM, brian m. carlson
wrote:
> This is a series proposing a basic abstraction for hash functions.
>
> As we get closer to converting the remainder of the codebase to use
> struct object_id, we should think about the design we want our hash
> function abstraction to tak
Hi team,
On Mon, 30 Oct 2017, Johannes Schindelin wrote:
> It is my pleasure to announce that Git for Windows 2.15.0 is available from:
>
> https://git-for-windows.github.io/
By the way, to everybody who tested the RC2: thank you so much. You caught
three bugs. Three bugs that did not ent
On 10/27/2017 05:06 PM, Pranit Bauva wrote:
> diff --git a/builtin/bisect--helper.c b/builtin/bisect--helper.c
> index 0f9c3e63821b8..ab0580ce0089a 100644
> --- a/builtin/bisect--helper.c
> +++ b/builtin/bisect--helper.c
[...]
> +static int bisect_terms(struct bisect_terms *terms, const char **argv
From: Torsten Bögershausen
Make it safer to normalize the line endings in a repository:
Files that had been commited with CRLF will be commited with LF.
The old way to normalize a repo was like this:
# Make sure that there are not untracked files
$ echo "* text=auto" >.gitattributes
$ git rea
On Sat, Oct 28, 2017 at 11:12 AM, brian m. carlson
wrote:
>
> Include repository.h in cache.h since we now need to have access to
> these struct and variable definitions.
Let's see how that works out. I remember having include issues
in the repository struct series.
> };
> extern const struct
On 10/30/2017 02:38 PM, Stephan Beyer wrote:
> This last change is not necessary. You never use "res".
Whoops, ignore this!
I compared old and new diff and mixed something up, it seems.
Sorry,
Stephan
On Sat, Oct 28, 2017 at 11:12 AM, brian m. carlson
wrote:
> Since in the future we want to support an additional hash algorithm, add
> a structure that represents a hash algorithm and all the data that must
> go along with it. Add a constant to allow easy enumeration of hash
> algorithms. Implem
1 - 100 of 125 matches
Mail list logo
