Re: [PATCH v3 0/9] Fix the early config

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

Re: [PATCH] http: inform about alternates-as-redirects behavior

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

Re: [PATCH] http: inform about alternates-as-redirects behavior

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

Re: [PATCH v1 1/1] git diff --quiet exits with 1 on clean tree with CRLF conversions

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

Re: [PATCH v1] Travis: also test on 32-bit Linux

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

Re: [PATCH] http: inform about alternates-as-redirects behavior

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

Re: [PATCH] http: release strbuf on disabled alternates

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

Re: [PATCH] http: inform about alternates-as-redirects behavior

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

[PATCH] http: release strbuf on disabled alternates

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

RFC: Another proposed hash function transition plan

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

[PATCH] http: inform about alternates-as-redirects behavior

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

RE: [PATCH] Put sha1dc on a diet

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

Re: bisect-helper: we do not bisect --objects

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

Re: [PATCH v1] Travis: also test on 32-bit Linux

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

Server-side hooks on non-bare repository

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,

Re: [PATCH v7 0/3] Conditional config include

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

Re: bisect-helper: we do not bisect --objects

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

What's cooking in git.git (Mar 2017, #02; Fri, 3)

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

Re: bisect-helper: we do not bisect --objects

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

Re: [PATCH] t/perf: export variable used in other blocks

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

Re: [PATCH v7 0/3] Conditional config include

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

Re: [PATCH v7 3/3] config: add conditional include

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

Re: SHA1 collisions found

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

Re: SHA1 collisions found

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

Re: [PATCH v3 0/9] Fix the early config

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 >

Re: git status --> Out of memory, realloc failed

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

Re: [PATCH 3/3] Remove outdated info in difftool manpage

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.

Re: [PATCH v2 2/5] Use -y where possible in test t7610-mergetool

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

Re: git status --> Out of memory, realloc failed

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

Re: [PATCH v7 0/3] Conditional config include

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

Re: [PATCH 1/2] config: check if config path is a file before parsing it

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

Re: [PATCH 3/4] filter-branch: fix --prune-empty on parentless commits

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

Re: [PATCH 4/4] p7000: add test for filter-branch with --prune-empty

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

Re: [PATCH 3/4] filter-branch: fix --prune-empty on parentless commits

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

Re: [PATCH 1/2] config: check if config path is a file before parsing it

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

Re: [PATCH] Do not require Python for the git-remote-{bzr,hg} placeholder scripts

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

Re: SHA1 collisions found

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

Re: [PATCH v2 2/5] Use -y where possible in test t7610-mergetool

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.

Re: [PATCH] Do not require Python for the git-remote-{bzr,hg} placeholder scripts

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

Re: [PATCH 3/3] Remove outdated info in difftool manpage

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

[PATCH v2 5/5] Remove outdated info in difftool manpage

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

Re: [PATCH] line-log.c: prevent crash during union of too many ranges

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,

Re: [PATCH v7 0/3] Conditional config include

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

Re: [PATCH v7 3/3] config: add conditional include

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

Re: [PATCH] Do not require Python for the git-remote-{bzr,hg} placeholder scripts

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

Re: [PATCH v1] Travis: also test on 32-bit Linux

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

[RFC PATCH 1/2] completion: add bash completion for 'git rev-list'

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

Re: [PATCH] t/perf: export variable used in other blocks

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

Hello, i am Lindsey , How's everything with you, I picked interest on you after going through your profile I really want to have a good friendship with you.Beside i have something very vital to tell y

Re: log -S/-G (aka pickaxe) searches binary files by default

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

Re: [PATCH v7 0/3] Conditional config include

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

Re: Finding a tag that introduced a submodule change

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

Re: [PATCH 1/3] Add --gui option to mergetool

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

Re: [PATCH v1 1/1] git diff --quiet exits with 1 on clean tree with CRLF conversions

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

Re: Finding a tag that introduced a submodule change

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

Re: [PATCH v1 1/1] git diff --quiet exits with 1 on clean tree with CRLF conversions

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

[PATCH v3 7/9] read_early_config(): avoid .git/config hack when unneeded

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

[PATCH v3 5/9] Export the discover_git_directory() function

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.

[PATCH v3 4/9] setup_git_directory_1(): avoid changing global state

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

[PATCH v3 2/9] setup_git_directory(): use is_dir_sep() helper

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

[PATCH v3 9/9] Test read_early_config()

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

[PATCH v3 8/9] read_early_config(): really discover .git/

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

[PATCH v3 6/9] Make read_early_config() reusable

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

[PATCH v3 3/9] Prepare setup_discovered_git_directory() the root directory

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

[PATCH v3 1/9] t7006: replace dubious test

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

[PATCH v3 0/9] Fix the early config

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

Re: [PATCH v5 24/24] t1406: new tests for submodule ref store

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

Re: [PATCH v1 1/1] git diff --quiet exits with 1 on clean tree with CRLF conversions

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,

Re: [PATCH v2 8/9] read_early_config(): really discover .git/

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

Re: [PATCH v5 00/24] Remove submodule from files-backend.c

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

Re: [PATCH v5 23/24] t1405: some basic tests on main ref store

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

rebase: confusing behaviour since --fork-point

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

bisect-helper: we do not bisect --objects

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

Re: log -S/-G (aka pickaxe) searches binary files by default

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

Re: [PATCH v5 20/24] files-backend: avoid ref api targetting main ref store

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

Re: [PATCH 3/3] Remove outdated info in difftool manpage

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

Re: [PATCH v5 19/24] refs: new transaction related ref-store api

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 >

Re: [PATCH v2] Travis: also test on 32-bit Linux

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

Re: [PATCH] Do not require Python for the git-remote-{bzr,hg} placeholder scripts

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

Finding a tag that introduced a submodule change

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

Re: [PATCH v2 2/9] setup_git_directory(): use is_dir_sep() helper

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

Re: [PATCH v2 0/9] Fix the early config

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

Re: [PATCH v2 9/9] Test read_early_config()

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

Re: SHA1 collisions found

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

Re: [PATCH v2 6/9] read_early_config(): special-case builtins that create a repository

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.

Re: [PATCH v5 16/24] files-backend: replace submodule_allowed check in files_downcast()

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

Re: [PATCH v2 4/9] Export the discover_git_directory() function

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

[PATCH v2 4/5] Add guitool completions for diff and mergetools

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

Re: [PATCH v5 15/24] refs: move submodule code out of files-backend.c

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

Re: [PATCH v2 5/9] Make read_early_config() reusable

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

Re: [PATCH v2 3/9] setup_git_directory(): avoid changing global state during discovery

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

[PATCH v2 3/5] Add --gui option to mergetool

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

[PATCH v2 2/5] Use -y where possible in test t7610-mergetool

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

[PATCH v2 1/5] Detect merges specifically in test t7610-mergetool

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

Re: [PATCH 1/3] Add --gui option to mergetool

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

[RFC PATCH 2/2] completion: add bash completion for 'filter-branch'

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

Re: [PATCH] Do not require Python for the git-remote-{bzr,hg} placeholder scripts

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 >

Re: [PATCH v2 1/9] t7006: replace dubious test

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

[PATCH 3/3] Remove outdated info in difftool manpage

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

[PATCH 2/3] Add gui completions for difftool

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

  1   2   >