On Fri, Mar 03, 2017 at 06:31:55PM +0100, Johannes Schindelin wrote:
> Interdiff vs v2:
> [...]
> + * When we are not about to create a repository ourselves (init or
> + * clone) and when no .git/ directory was set up yet (in which case
> + * git_config_with_options() would already
On Sat, Mar 04, 2017 at 06:55:48AM +, Eric Wong wrote:
> Jeff King wrote:
> > The warning itself:
> >
> > > + warning("alternate disabled by http.followRedirects!=true: %s",
> >
> > feels like it could use some whitespace around the "!=", but maybe
> > that's just me.
>
> Yeah, I k
Jeff King wrote:
> The warning itself:
>
> > + warning("alternate disabled by http.followRedirects!=true: %s",
>
> feels like it could use some whitespace around the "!=", but maybe
> that's just me.
Yeah, I kinda wanted to emulate the command-line syntax.
Maybe rewording it a bit an
On 2017-03-03 18:47, Junio C Hamano wrote:
> Torsten Bögershausen writes:
>
>> Understood, thanks for the explanation.
>>
>> quiet is not quite any more..
>>
>> Does the following fix help ?
>>
>> --- a/diff.c
>> +++ b/diff.c
>> @@ -2826,6 +2826,8 @@ int diff_populate_filespec(struct diff_filespe
On Fri, Mar 3, 2017 at 4:03 PM, Junio C Hamano wrote:
>
> I only recently started looking at Travis logs, so I cannot tell if
> it is just a usual flake (e.g. some builds a few days ago seems to
> have failed due to not being able to check out the tree being
> tested, which I do not think is our f
On Fri, Mar 03, 2017 at 10:13:14PM -0500, Jeff King wrote:
> > - if (http_follow_config != HTTP_FOLLOW_ALWAYS)
> > - return;
> > -
>
> I was surprised from the description to see not just the addition of a
> warning, but a movement of the enforcement code.
>
> I think it's necessary
On Sat, Mar 04, 2017 at 01:50:16AM +, Eric Wong wrote:
> This likely has no real-world impact on memory usage,
> but it is cleaner for future readers.
Yep, this looks good.
-Peff
On Sat, Mar 04, 2017 at 01:35:04AM +, Eric Wong wrote:
> It is disconcerting for users to not notice the behavior
> change in handling alternates from commit cb4d2d35c4622ec2
> ("http: treat http-alternates like redirects")
>
> Give the user a hint about the config option so they can
> see th
This likely has no real-world impact on memory usage,
but it is cleaner for future readers.
Fixes: abcbdc03895f ("http: respect protocol.*.allow=user for http-alternates")
Signed-off-by: Eric Wong
---
http-walker.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/http-walker.c b/http-walker
Hi,
This past week we came up with this idea for what a transition to a new
hash function for Git would look like. I'd be interested in your
thoughts (especially if you can make them as comments on the document,
which makes it easier to address them and update the document).
This document is sti
It is disconcerting for users to not notice the behavior
change in handling alternates from commit cb4d2d35c4622ec2
("http: treat http-alternates like redirects")
Give the user a hint about the config option so they can
see the URL and decide whether or not they want to enable
http.followRedirects
From: Junio C Hamano [mailto:gits...@pobox.com]
> As you and Marc seemed to be still working on speeding up, such a
> customization work to fully adjust your code to our codebase was premature,
> so I tentatively queued what we saw on the list as-is on our 'pu' branch so
> that people can have
"Philip Oakley" writes:
> Bikeshedding: If the given boundary is a tag, it could be tagging a
> blob or tree rather than a commit. Would that be a scenario that
> reaches this part of the code?
I do not think it is relevant.
Bisection is an operation over a "bisectable" commit DAG, where
commit
Junio C Hamano writes:
> I see he did v2 which you Acked in a different thread. Will replace
> what's been on 'pu' and running with Travis the past few days with
> it. Let's wait for one or more Travis cycles and then merge it to
> 'next'.
https://travis-ci.org/git/git/jobs/207517043 is an out
Hello,
I’m having some issues with using server-side hooks when pushing to a non-bare
repository. In my git config, I have `receive.denyCurrentBranch` set to
`updateInstead`, which behaves as expected, and updates the current working
tree when the current branch is pushed to. However, attemptin
Jeff King writes:
> Heh. I had no idea we had FREAD_READS_DIRECTORIES. I think Duy and I
> reinvented it in another thread. ;)
You two were not alone. I was planning to reinvent it before I went
to bed last night and then found it already was there this morning ;-)
> I agree that may be worth
From: "Junio C Hamano"
Ever since "bisect--helper" was introduced in 1bf072e366
("bisect--helper: implement "git bisect--helper"", 2009-03-26),
after setting up the "rev-list $bad --not $good_ones" machinery, the
code somehow prepared to mark the trees and blobs at the good boundary
as uninteres
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'. The ones marked with '.' do not appear in any of
the integration branches, but I am still holding onto them.
You can find the changes described
On Fri, Mar 3, 2017 at 5:16 PM, Junio C Hamano wrote:
> Ever since "bisect--helper" was introduced in 1bf072e366
> ("bisect--helper: implement "git bisect--helper"", 2009-03-26),
> after setting up the "rev-list $bad --not $good_ones" machinery, the
> code somehow prepared to mark the trees and bl
On Fri, Mar 03, 2017 at 10:51:57AM -0800, Junio C Hamano wrote:
> Jeff King writes:
>
> > Thanks, this is obviously the right thing to do, and the mistake is mine
> > from ea97002fc (t/perf: time rev-list with UNINTERESTING commits,
> > 2014-01-20). This is not the first time I've been confused
On Fri, Mar 03, 2017 at 10:24:05AM -0800, Junio C Hamano wrote:
> Jeff King writes:
>
> > For those following on the mailing list, there is some discussion at:
> >
> > https://github.com/git/git/commit/484f78e46d00c6d35f20058671a8c76bb924fb33
> >
> > I think that is mostly focused around anoth
On Fri, Mar 03, 2017 at 11:05:20AM -0800, Junio C Hamano wrote:
> I am not sure about "obviousness", but I agree that we do not know
> that "conditional include" would be the only thing we want for the
> second level for "include.path" directive. "include-if..path"
> is better for that reason.
>
On Fri, Mar 03, 2017 at 02:54:56PM +, Ian Jackson wrote:
> > What _does_ get rewritten is what's in your ref files, your pack .idx,
> > etc. Those are all sha256 (or whatever), and work as sha1's do now.
>
> This all sounds very similar to my proposal.
Yeah, sorry I haven't reviewed that mor
On Thu, Mar 2, 2017 at 11:55 AM, Linus Torvalds
wrote:
>
> So: What do you think about the concept?
>
>Linus
One of the things I like about working on Git is its pretty
high standard of testing. So we would need to come up with
good methods of testing this, e.g. when
GIT_TEST_WITH
Johannes Schindelin writes:
> Notable notes:
>
> - In contrast to earlier versions, I no longer special-case init and
> clone. Peff pointed out that this adds technical debt, and that we can
> actually argue (for consistency's sake) that early config reads the
> current repository config (i
Hi René,
Am 02.03.2017 um 21:04 schrieb René Scharfe:
When I use ulimit -v with lower and lower numbers I can provoke mmap failures on
bigger pack files, but not the realloc failures that you're seeing. And your
packs should be only up to 20MB anyway (you can check that with "ls -l
.git/objects
On Fri, Mar 03, 2017 at 04:46:36PM +0100, Johannes Schindelin wrote:
> Hi Denton (or should I address you as Liu?),
Denton is fine, thanks.
>
> On Fri, 3 Mar 2017, Denton Liu wrote:
>
> > When difftool was rewritten in C, it removed the capability to read
> > fallback configs from mergetool. This
On Fri, Mar 03, 2017 at 11:39:30AM -0800, Junio C Hamano wrote:
> Denton Liu writes:
>
> > In these tests, there are many situations where
> > 'echo "" | git mergetool' is used. This replaces all of those
> > occurrences with 'git mergetool -y' for simplicity and readability.
>
> "-y where _poss
Hi Duy,
Am 2017-03-02 um 10:31 schrieb Duy Nguyen:
You could also try "git fast-export --anonymize" (read the doc first).
Eventually this was not needed, but thanks for letting me know about it!
I've not been aware of this feature beforehand, learned something.
Best regards,
Carsten
Duy Nguyen writes:
> On Fri, Mar 03, 2017 at 01:33:29AM -0500, Jeff King wrote:
>> For those following on the mailing list, there is some discussion at:
>>
>> https://github.com/git/git/commit/484f78e46d00c6d35f20058671a8c76bb924fb33
>>
>> I think that is mostly focused around another failing
Jeff King writes:
>a. actually check ferror() after getting EOF and report the read
> error. That catches EISDIR, along with any other unexpected
> errors.
That is the most sensible, I would think (assuming that we really
get EISDIR instead of silent EOF).
>b.
Jeff King writes:
> The change to filter-branch itself looks obviously correct. The only
> objectionable thing I noticed in the test additions is that the early
> ones should be marked test_expect_failure until the fix from 3/4 flips
> them to "success". Otherwise it breaks bisectability.
I'll s
On Fri, Mar 03, 2017 at 02:56:05AM -0500, Jeff King wrote:
> On Thu, Feb 23, 2017 at 02:27:36AM -0600, Devin J. Pohly wrote:
>
> > +test_perf 'noop prune-empty' '
> > + git checkout --detach tip &&
> > + git filter-branch -f --prune-empty base..HEAD
> > +'
>
> I don't mind adding this, but of
On Fri, Mar 03, 2017 at 02:55:35AM -0500, Jeff King wrote:
> The only objectionable thing I noticed in the test additions is that
> the early ones should be marked test_expect_failure until the fix from
> 3/4 flips them to "success". Otherwise it breaks bisectability.
>
> -Peff
Good point. Will
On 03/03/17 09:42, Nguyễn Thái Ngọc Duy wrote:
> If a directory is given as a config file by accident, we keep open it
> as a file. The behavior of fopen() in this case seems to be
> undefined.
>
> On Linux, we open a directory as a file ok, then get error (which we
> consider eof) on the first
On Fri, Mar 3, 2017 at 8:10 PM, Junio C Hamano wrote:
>> Just a niggle: This change moves the warning message from stderr to stdout.
>
> Right. Here is what I'll queue.
Indeed, thanks for the note, and also Junio for fixing while queuing.
--
Sebastian Schuberth
On Thu, Mar 02, 2017 at 11:55:45AM -0800, Linus Torvalds wrote:
> Anyway, I do have a suggestion for what the "object version" would be,
> but I'm not even going to mention it, because I want people to first
> think about the _concept_ and not the implementation.
>
> So: What do you think about t
Denton Liu writes:
> In these tests, there are many situations where
> 'echo "" | git mergetool' is used. This replaces all of those
> occurrences with 'git mergetool -y' for simplicity and readability.
"-y where _possible_" is not necessarily a good thing to do in
tests. We do want to make sur
Marc Branchaud writes:
> On 2017-03-03 05:57 AM, Sebastian Schuberth wrote:
>> It does not make sense for these placeholder scripts to depend on Python
>> just because the real scripts do. At the example of Git for Windows, we
>> would not even be able to see those warnings as it does not ship wi
Johannes Schindelin writes:
> Hi Denton (or should I address you as Liu?),
>
> On Fri, 3 Mar 2017, Denton Liu wrote:
>
>> When difftool was rewritten in C, it removed the capability to read
>> fallback configs from mergetool. This changes the documentation to
>> reflect this.
>
> Thanks for point
When difftool was rewritten in C, it removed the capability to read
fallback configs from mergetool. This changes the documentation to
reflect this.
Signed-off-by: Denton Liu
---
Documentation/git-difftool.txt | 3 ---
1 file changed, 3 deletions(-)
diff --git a/Documentation/git-difftool.txt b
Allan Xavier writes:
> The existing implementation of range_set_union does not correctly
> reallocate memory, leading to a heap overflow when it attempts to union
> more than 24 separate line ranges.
> ...
I'll add "Reviewed-by: Jeff King " and queue, as I
know we already reviewed the change.
T
Duy Nguyen writes:
> The patch to fix it is this
>
> diff --git a/t/t1305-config-include.sh b/t/t1305-config-include.sh
> index f0cd2056ba..e833939320 100755
> --- a/t/t1305-config-include.sh
> +++ b/t/t1305-config-include.sh
> @@ -102,7 +102,7 @@ test_expect_success 'config modification does not
Jeff King writes:
> That was how I had originally envisioned the namespace working when I
> introduced include.path long ago. And I think Duy's v1 used that, but
> the feedback was that it was not sufficiently obvious that the
> subsection was a conditional.
I am not sure about "obviousness", bu
Jeff King writes:
> On Fri, Mar 03, 2017 at 10:57:46AM +, Sebastian Schuberth wrote:
>
>> It does not make sense for these placeholder scripts to depend on Python
>> just because the real scripts do. At the example of Git for Windows, we
>> would not even be able to see those warnings as it d
Johannes Schindelin writes:
> On Thu, 2 Mar 2017, Junio C Hamano wrote:
>
>> Another question is which v3 people mean in the discussion, when you
>> and Dscho work on improvements at the same time and each post the
>> "next" version marked as "v3", and they comment on one of them?
>
> But then, L
Signed-off-by: Denton Liu
---
This patch isn't strictly necessary since 'git rev-list' isn't a porcelain
command. However, it might be nice to include in case users interactively call
'git rev-list' anyway.
---
contrib/completion/git-completion.bash | 30 ++
1 file cha
Jeff King writes:
> Thanks, this is obviously the right thing to do, and the mistake is mine
> from ea97002fc (t/perf: time rev-list with UNINTERESTING commits,
> 2014-01-20). This is not the first time I've been confused by missing
> variables in t/perf scripts, since it behaves differently than
Am 03.03.2017 um 17:07 schrieb Junio C Hamano:
> Jeff King writes:
>
>> On Thu, Mar 02, 2017 at 05:36:17PM -0800, Junio C Hamano wrote:
>> ...
Is that on purpose?
>>>
>>> No, it's a mere oversight (as I do not think I never even thought
>>> about special casing binary
>>> files from day one,
Jeff King writes:
> For those following on the mailing list, there is some discussion at:
>
> https://github.com/git/git/commit/484f78e46d00c6d35f20058671a8c76bb924fb33
>
> I think that is mostly focused around another failing in the
> error-handling of the config code, and that does not need t
Robert Dailey writes:
> Sometimes I run into a situation where I need to find out which
> release of the product a submodule change was introduced in. This is
> nontrivial, since there are no tags in the submodule itself.
Does your superproject rewind the commit in the submodule project as
it go
Hi,
Denton Liu writes:
> [...]
>
> +test_expect_success 'gui mergetool' '
> + test_when_finished "git reset --hard" &&
> + test_when_finished "git config merge.tool mytool" &&
> + test_when_finished "git config --unset merge.guitool" &&
> + git config merge.tool badtool &&
> + git config me
Torsten Bögershausen writes:
> Understood, thanks for the explanation.
>
> quiet is not quite any more..
>
> Does the following fix help ?
>
> --- a/diff.c
> +++ b/diff.c
> @@ -2826,6 +2826,8 @@ int diff_populate_filespec(struct diff_filespec *s,
> unsigned int flags)
> enum safe_crlf crl
On Fri, Mar 3, 2017 at 7:40 AM, Robert Dailey wrote:
> I have a repository with a single submodule in it. Since the parent
> repository represents the code base for an actual product, I tag
> release versions in the parent repository. I do not put tags in the
> submodule since multiple other produ
Understood, thanks for the explanation.
quiet is not quite any more..
Does the following fix help ?
--- a/diff.c
+++ b/diff.c
@@ -2826,6 +2826,8 @@ int diff_populate_filespec(struct diff_filespec *s,
unsigned int flags)
enum safe_crlf crlf_warn = (safe_crlf == SAFE_CRLF_FAIL
So far, we only look whether the startup_info claims to have seen a
git_dir.
However, do_git_config_sequence() (and consequently the
git_config_with_options() call used by read_early_config() asks the
have_git_dir() function whether we have a .git/ directory, which in turn
also looks at git_dir an
The setup_git_directory_gently_1() function we modified earlier still
needs to return both the path to the .git/ directory as well as the
"cd-up" path to allow setup_git_directory() to retain its previous
behavior as if it changed the current working directory on its quest for
the .git/ directory.
For historical reasons, Git searches for the .git/ directory (or the
.git file) by changing the working directory successively to the parent
directory of the current directory, until either anything was found or
until a ceiling or a mount point is hit.
Further global state may be changed in case a
It is okay in practice to test for forward slashes in the output of
getcwd(), because we go out of our way to convert backslashes to forward
slashes in getcwd()'s output on Windows.
Still, the correct way to test for a dir separator is by using the
helper function we introduced for that very purpo
So far, we had no explicit tests of that function.
Signed-off-by: Johannes Schindelin
---
t/helper/test-config.c | 15 +++
t/t1309-early-config.sh | 50 +
2 files changed, 65 insertions(+)
create mode 100755 t/t1309-early-config.sh
d
Earlier, we punted and simply assumed that we are in the top-level
directory of the project, and that there is no .git file but a .git/
directory so that we can read directly from .git/config.
However, that is not necessarily true. We may be in a subdirectory. Or
.git may be a gitfile. Or the envi
The pager configuration needs to be read early, possibly before
discovering any .git/ directory.
Let's not hide this function in pager.c, but make it available to other
callers.
Signed-off-by: Johannes Schindelin
---
cache.h | 1 +
config.c | 31 +++
pager.c | 31
Currently, the offset parameter (indicating what part of the cwd
parameter corresponds to the current directory after discovering the
.git/ directory) is set to 0 when we are running in the root directory.
However, in the next patches we will avoid changing the current working
directory while sear
The idea of the test case "git -p - core.pager is not used from
subdirectory" was to verify that the setup_git_directory() function had
not been called just to obtain the core.pager setting.
However, we are about to fix the early config machinery so that it
*does* work, without messing up the glob
These patches are an attempt to make Git's startup sequence a bit less
surprising.
The idea here is to discover the .git/ directory gently (i.e. without
changing the current working directory, or global variables), and to use
it to read the .git/config file early, before we actually called
setup_g
On 02/22/2017 03:04 PM, Nguyễn Thái Ngọc Duy wrote:
> Signed-off-by: Nguyễn Thái Ngọc Duy
> ---
> t/t1406-submodule-ref-store.sh (new +x) | 95
> +
> 1 file changed, 95 insertions(+)
> create mode 100755 t/t1406-submodule-ref-store.sh
I wonder if you could reduc
Hi Torsten,
Your patch has been superseded, but I thought I ought to answer your
questions rather than leave them hanging.
On Thursday 02 March 2017 at 19:17:00 +0100, Torsten Bögershausen wrote:
> On 2017-03-01 22:25, Mike Crowe wrote:
> > On Wednesday 01 March 2017 at 18:04:44 +0100, tbo...@web
Hi Peff,
On Fri, 3 Mar 2017, Jeff King wrote:
> I think the "dirty hack..." comment in read_early_config() can be
> condensed (or go away) now.
Yes, I made that change in response to a comment you made about an earlier
patch in this series.
> I think we _could_ do away with read_early_config()
On 02/22/2017 03:04 PM, Nguyễn Thái Ngọc Duy wrote:
> v5 goes a bit longer than v4, basically:
I've reviewed all of the patches and left a bunch of comments, mostly
superficial. I'm very happy about the way it's going, and especially
want to say how much I appreciate that you've done so much legwo
On 02/22/2017 03:04 PM, Nguyễn Thái Ngọc Duy wrote:
> Signed-off-by: Nguyễn Thái Ngọc Duy
> ---
> t/t1405-main-ref-store.sh (new +x) | 123
> +
> 1 file changed, 123 insertions(+)
> create mode 100755 t/t1405-main-ref-store.sh
>
> diff --git a/t/t1405-main-r
Hi all,
This will be a bit long, sorry in advance.
I've hit a problem with how rebase works since the introduction of the
--fork-point option. I initially thought it was a bug until the kind
folks over at git-for-windows patiently told me otherwise.
Consider the following:
---8<---
# On
Ever since "bisect--helper" was introduced in 1bf072e366
("bisect--helper: implement "git bisect--helper"", 2009-03-26),
after setting up the "rev-list $bad --not $good_ones" machinery, the
code somehow prepared to mark the trees and blobs at the good boundary
as uninteresting, only when --objects
Jeff King writes:
> On Thu, Mar 02, 2017 at 05:36:17PM -0800, Junio C Hamano wrote:
> ...
>> > Is that on purpose?
>>
>> No, it's a mere oversight (as I do not think I never even thought
>> about special casing binary
>> files from day one, it is unlikely that you would find _any_ old
>> version
On 02/22/2017 03:04 PM, Nguyễn Thái Ngọc Duy wrote:
> A small step towards making files-backend works as a non-main ref store
> using the newly added store-aware API.
>
> For the record, `join` and `nm` on refs.o and files-backend.o tell me
> that files-backend no longer uses functions that defaul
Hi Denton (or should I address you as Liu?),
On Fri, 3 Mar 2017, Denton Liu wrote:
> When difftool was rewritten in C, it removed the capability to read
> fallback configs from mergetool. This changes the documentation to
> reflect this.
Thanks for pointing that out. But that is probably an over
On 02/22/2017 03:04 PM, Nguyễn Thái Ngọc Duy wrote:
> The transaction struct now takes a ref store at creation and will
> operate on that ref store alone.
>
> Signed-off-by: Nguyễn Thái Ngọc Duy
> ---
> refs.c | 54
>
> refs.h
Hi Lars,
On Fri, 3 Mar 2017, Lars Schneider wrote:
> From: Johannes Schindelin
>
> When Git v2.9.1 was released, it had a bug that showed only on Windows
> and on 32-bit systems: our assumption that `unsigned long` can hold
> 64-bit values turned out to be wrong.
>
> This could have been caugh
On 2017-03-03 05:57 AM, Sebastian Schuberth wrote:
It does not make sense for these placeholder scripts to depend on Python
just because the real scripts do. At the example of Git for Windows, we
would not even be able to see those warnings as it does not ship with
Python. So just use plain shell
I have a repository with a single submodule in it. Since the parent
repository represents the code base for an actual product, I tag
release versions in the parent repository. I do not put tags in the
submodule since multiple other products may be using it there and I
wanted to avoid ambiguous tags
Hi Peff,
On Fri, 3 Mar 2017, Jeff King wrote:
> On Fri, Mar 03, 2017 at 12:16:31PM +0100, Johannes Schindelin wrote:
>
> > > What is "dir"? I'm guessing this patch got reordered and it should
> > > stay as cwd.buf?
> >
> > Oh drats. Usually I do a final `git rebase -x "make test"
> > upstream/m
Hi Peff,
On Fri, 3 Mar 2017, Jeff King wrote:
> On Fri, Mar 03, 2017 at 03:03:56AM +0100, Johannes Schindelin wrote:
>
> > These patches are an attempt to make Git's startup sequence a bit less
> > surprising.
> >
> > The idea here is to discover the .git/ directory gently (i.e. without
> > cha
Hi Peff,
On Fri, 3 Mar 2017, Jeff King wrote:
> On Fri, Mar 03, 2017 at 03:04:36AM +0100, Johannes Schindelin wrote:
>
> > So far, we had no explicit tests of that function.
>
> Makes sense. The pager tests fixed in an earlier commit were effectively
> checking those, but I don't mind making it
Jeff King writes ("Re: SHA1 collisions found"):
> I think you've read more into my "conversion" than I intended. The old
> history won't get rewritten. It will just be grafted onto the bottom of
> the commit history you've got, and the new trees will all be written
> with the new hash.
>
> So you
Hi Peff,
On Thu, 2 Mar 2017, Jeff King wrote:
> On Fri, Mar 03, 2017 at 03:04:24AM +0100, Johannes Schindelin wrote:
>
> > When the command we are about to execute wants to create a repository
> > (i.e. the command is `init` or `clone`), we *must not* look for a
> > repository config.
>
> Hmm.
On 02/22/2017 03:04 PM, Nguyễn Thái Ngọc Duy wrote:
> files-backend.c is unlearning submodules. Instead of having a specific
> check for submodules to see what operation is allowed, files backend
> now takes a set of flags at init. Each operation will check if the
> required flags is present before
Hi Peff,
On Thu, 2 Mar 2017, Jeff King wrote:
> On Fri, Mar 03, 2017 at 03:04:15AM +0100, Johannes Schindelin wrote:
>
> > diff --git a/cache.h b/cache.h
> > index 80b6372cf76..a104b76c02e 100644
> > --- a/cache.h
> > +++ b/cache.h
> > @@ -518,6 +518,7 @@ extern void set_git_work_tree(const char
Signed-off-by: Denton Liu
---
contrib/completion/git-completion.bash | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index 41ee52991..c94e38a3a 100644
--- a/contrib/completion/git-completion
On 02/22/2017 03:04 PM, Nguyễn Thái Ngọc Duy wrote:
> files-backend is now initialized with a $GIT_DIR. Converting a submodule
> path to where real submodule gitdir is located is done in get_ref_store().
>
> This gives a slight performance improvement for submodules since we
> don't convert submod
Hi Peff,
On Thu, 2 Mar 2017, Jeff King wrote:
> On Fri, Mar 03, 2017 at 03:04:20AM +0100, Johannes Schindelin wrote:
>
> > The pager configuration needs to be read early, possibly before
> > discovering any .git/ directory.
> >
> > Let's not hide this function in pager.c, but make it available
Hi Peff,
On Thu, 2 Mar 2017, Jeff King wrote:
> On Fri, Mar 03, 2017 at 03:04:11AM +0100, Johannes Schindelin wrote:
>
> > For historical reasons, Git searches for the .git/ directory (or the
> > .git file) by changing the working directory successively to the
> > parent directory of the current
This fixes the discrepancy between difftool and mergetool where the
former has the --gui flag and the latter does not by adding the
functionality to mergetool.
Signed-off-by: Denton Liu
---
Documentation/git-mergetool.txt | 8 +++-
git-mergetool.sh| 5 -
t/t7610-mergeto
In these tests, there are many situations where
'echo "" | git mergetool' is used. This replaces all of those
occurrences with 'git mergetool -y' for simplicity and readability.
Signed-off-by: Denton Liu
---
t/t7610-mergetool.sh | 62 ++--
1 file c
Prior to this, the test cases would use 'test_expect_failure' to detect
a merge conflict. This changes the test case to use 'test_expect_code 1'
which is more specific.
Signed-off-by: Denton Liu
---
t/t7610-mergetool.sh | 76 ++--
1 file changed, 3
On Fri, Mar 03, 2017 at 03:57:38AM -0800, Denton Liu wrote:
> This fixes the discrepancy between difftool and mergetool where the
> former has the --gui flag and the latter does not by adding the
> functionality to mergetool.
>
> Signed-off-by: Denton Liu
> ---
> Documentation/git-mergetool.txt
Signed-off-by: Denton Liu
---
If the last patch (PATCH 1/2) is not included, we can remove the call to
__git_complete_rev_list_command.
---
contrib/completion/git-completion.bash | 17 +
1 file changed, 17 insertions(+)
diff --git a/contrib/completion/git-completion.bash
b/contr
On Fri, Mar 03, 2017 at 10:57:46AM +, Sebastian Schuberth wrote:
> It does not make sense for these placeholder scripts to depend on Python
> just because the real scripts do. At the example of Git for Windows, we
> would not even be able to see those warnings as it does not ship with
> Python
Hi Peff,
On Thu, 2 Mar 2017, Jeff King wrote:
> On Fri, Mar 03, 2017 at 03:04:02AM +0100, Johannes Schindelin wrote:
>
> > The intention of that test case, however, was to verify that the
> > setup_git_directory() function has not run, because it changes global
> > state such as the current work
When difftool was rewritten in C, it removed the capability to read
fallback configs from mergetool. This changes the documentation to
reflect this.
Signed-off-by: Denton Liu
---
Documentation/git-difftool.txt | 3 ---
1 file changed, 3 deletions(-)
diff --git a/Documentation/git-difftool.txt b
Signed-off-by: Denton Liu
---
contrib/completion/git-completion.bash | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index d5f3b9aeb..c94e38a3a 100644
--- a/contrib/completion/git-completion.bas
1 - 100 of 125 matches
Mail list logo