Re: [PATCH v3 09/12] revision.c: --all adds HEAD from all worktrees

On 04/19/2017 01:01 PM, Nguyễn Thái Ngọc Duy wrote: > Unless single_worktree is set, --all now adds HEAD from all worktrees. > > Since reachable.c code does not use setup_revisions(), we need to call > other_head_refs_submodule() explicitly there to have the same effect on > "git prune", so that

[PATCH v2] status: add color config slots for branch info in "--short --branch"

Add color config slots to be used in the status short-format when displaying local and remote tracking branch information. Signed-off-by: Stephen Kent --- Documentation/config.txt | 5 - builtin/commit.c | 4

Re: [PATCH] Add color slots for branch names in "git status --short --branch"

Hi Peff and Junio, I've updated the commit message and updated one of the existing unit tests for this feature. Patch version 2 will follow shortly after this email. Responses to both of your comments: I wondered if this "short-format" was accurate. But indeed, we do not seem to color the

Re: [PATCH v3 08/12] refs: remove dead for_each_*_submodule()

On 04/19/2017 01:01 PM, Nguyễn Thái Ngọc Duy wrote: > These are used in revision.c. After the last patch they are replaced > with the refs_ version. Delete them (except for_each_remote_ref_submodule > which is still used by submodule.c) ❤❤ I love the way this is going. Michael

Re: [PATCH v3 05/12] refs: move submodule slash stripping code to get_submodule_ref_store

On 04/19/2017 01:01 PM, Nguyễn Thái Ngọc Duy wrote: > This is a better place that will benefit all submodule callers instead > of just resolve_gitlink_ref() > > Signed-off-by: Nguyễn Thái Ngọc Duy > --- > refs.c | 33 + > 1 file changed, 17

Re: [PATCH v3 04/12] refs.c: refactor get_submodule_ref_store(), share common free block

On 04/19/2017 01:01 PM, Nguyễn Thái Ngọc Duy wrote: > Signed-off-by: Nguyễn Thái Ngọc Duy > --- > refs.c | 12 +--- > 1 file changed, 5 insertions(+), 7 deletions(-) > > diff --git a/refs.c b/refs.c > index 5d31fb6bcf..5902a3d9e5 100644 > --- a/refs.c > +++ b/refs.c >

Re: [PATCH v4 0/5] Kill manual ref parsing code in worktree.c

On 04/14/2017 03:40 AM, Junio C Hamano wrote: > Nguyễn Thái Ngọc Duy writes: > >> v4 adds a new patch, 2/5, which makes the hashmap related functions in >> refs.c generic, so I could add a new map for worktree ref stores and >> not abuse submodule hashmap. >> >> I mentioned

Re: [PATCH v4 3/5] refs: introduce get_worktree_ref_store()

On 04/04/2017 12:21 PM, Nguyễn Thái Ngọc Duy wrote: > files-backend at this point is still aware of the per-repo/worktree > separation in refs, so it can handle a linked worktree. > > Some refs operations are known not working when current files-backend is > used in a linked worktree (e.g.

[PATCH] git_fopen: fix a sparse 'not declared' warning

Commit 8f4f6e53d2 ("config.mak.uname: set FREAD_READS_DIRECTORIES for Linux and FreeBSD", 20-04-2017) caused sparse to issue a 'not declared, should it be static?' warning on Linux. This is a result of the method employed by 'compat/fopen.c' to suppress the (possible) redefinition of the (system)

[PATCH] worktree: fix an 'Using integer as a NULL pointer' warning

Signed-off-by: Ramsay Jones --- Hi Duy, If you need to re-roll your 'nd/worktree-move' branch could you please squash this into the relevant patch (commit 8a1dc92e91 ("worktree move: refuse to move worktrees with submodules", 20-04-2017)). Thanks! ATB, Ramsay

Re: [GIT 2.12.2 REGRESSION] git cherry-pick -x

On Fri, Apr 21, 2017 at 03:10:03PM -0700, Stefan Beller wrote: > +Jonathan, who worked on trailers > [...] > > I haven't tried bisecting precisely, but somewhere along the way git > > cherry-pick -x regressed between 2.9.3 and 2.12.2. Yeah, it bisects to 967dfd4d5 (sequencer: use trailer's

Re: [GIT 2.12.2 REGRESSION] git cherry-pick -x

+Jonathan, who worked on trailers On Fri, Apr 21, 2017 at 3:01 PM, Brian Norris wrote: > Hi all, > > I haven't tried bisecting precisely, but somewhere along the way git > cherry-pick -x regressed between 2.9.3 and 2.12.2. > > Looking at upstream linux.git, I can do:

Re: [PATCH] t/perf: correctly align non-ASCII descriptions in output

On Sat, Apr 22, 2017 at 12:02:02AM +0200, Ævar Arnfjörð Bjarmason wrote: > > Yeah, I know "use utf8" doesn't work for that, but I was thinking there > > was some other trick. Digging...ah, here it is: > > > > use open ':encoding(utf8)' > > > > No clue how portable that is. For such a small

Re: [PATCH] t/perf: correctly align non-ASCII descriptions in output

On Fri, Apr 21, 2017 at 11:35 PM, Jeff King wrote: > On Fri, Apr 21, 2017 at 11:28:42PM +0200, Ævar Arnfjörð Bjarmason wrote: > >> > I thought there was some "use" flag we could set to just make all of our >> > handles utf8. But all I could come up with was stuff like PERLIO and >>

[GIT 2.12.2 REGRESSION] git cherry-pick -x

Hi all, I haven't tried bisecting precisely, but somewhere along the way git cherry-pick -x regressed between 2.9.3 and 2.12.2. Looking at upstream linux.git, I can do: git fetch git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git next git cherry-pick -x

Re: [PATCH] t/perf: correctly align non-ASCII descriptions in output

On Fri, Apr 21, 2017 at 11:28:42PM +0200, Ævar Arnfjörð Bjarmason wrote: > > I thought there was some "use" flag we could set to just make all of our > > handles utf8. But all I could come up with was stuff like PERLIO and > > "perl -C". Using binmode isn't too bad, though (I think you could > >

Re: [PATCH] t/perf: correctly align non-ASCII descriptions in output

On Fri, Apr 21, 2017 at 10:41 PM, Jeff King wrote: > On Fri, Apr 21, 2017 at 07:44:28PM +, Ævar Arnfjörð Bjarmason wrote: > >> Change the test descriptions from being treated as binary blobs by >> perl to being treated as UTF-8. This ensures that e.g. a test >> description like

Git archive doesn't fully support zip64

Dear git, git archive, when writing a zip file, has a silent 4GB file size limit (on the inputs as well as the output), as it doesn’t fully support zip64. Although a zip archive written by git which is larger than 4GB can be often still be unzipped, it won’t be fully useable and some tools

Re: [PATCH] t/perf: correctly align non-ASCII descriptions in output

On Fri, Apr 21, 2017 at 07:44:28PM +, Ævar Arnfjörð Bjarmason wrote: > Change the test descriptions from being treated as binary blobs by > perl to being treated as UTF-8. This ensures that e.g. a test > description like "æ" is counted as 1 character, not 2. > > I have WIP performance tests

[PATCH v2] completion: optionally disable checkout DWIM

When we complete branch names for "git checkout", we also complete remote branch names that could trigger the DWIM behavior. Depending on your workflow and project, this can be either convenient or annoying. For instance, my clone of gitster.git contains 74 local "jk/*" branches, but origin

Re: [PATCH] completion: optionally disable checkout DWIM

On Fri, Apr 21, 2017 at 10:14:48PM +0200, SZEDER Gábor wrote: > >> This is flexible enough for me, but it's possible somebody would want > >> this on a per-repo basis. I don't know that we want to read from `git > >> config`, though, because it's relatively expensive to do so. People who > >>

Re: [PATCH] test-lib: abort when can't remove trash directory

On Thu, Apr 20, 2017 at 06:52:30PM +0200, SZEDER Gábor wrote: > diff --git a/t/test-lib.sh b/t/test-lib.sh > index 13b569682..e9e6f677d 100644 > --- a/t/test-lib.sh > +++ b/t/test-lib.sh > @@ -761,9 +761,12 @@ test_done () { > say "1..$test_count$skip_all" > fi

Re: [PATCH] completion: optionally disable checkout DWIM

On Fri, Apr 21, 2017 at 7:01 AM, Junio C Hamano wrote: > Jeff King writes: > >> When we complete branch names for "git checkout", we also >> complete remote branch names that could trigger the DWIM >> behavior. Depending on your workflow and project, this can >>

Re: [PATCH] test-lib: abort when can't remove trash directory

On Fri, Apr 21, 2017 at 2:48 AM, Junio C Hamano wrote: > SZEDER Gábor writes: > >> We had two similar bugs in the tests sporadically triggering error >> messages during the removal of the trash directory, see commits >> bb05510e5 (t5510: run auto-gc in

Re: [BUG] test suite broken with GIT_TEST_SPLIT_INDEX

On Fri, Apr 21, 2017 at 05:23:51PM +0200, Christian Couder wrote: > > I just tried on "pu" and only the first test > > (t7009-filter-branch-null-sha1.sh) fails there. > > I bisected this test's failure (when using > GIT_TEST_SPLIT_INDEX=YesPlease) to e6a1dd77e1 (read-cache: regenerate > shared

[PATCH] t/perf: correctly align non-ASCII descriptions in output

Change the test descriptions from being treated as binary blobs by perl to being treated as UTF-8. This ensures that e.g. a test description like "æ" is counted as 1 character, not 2. I have WIP performance tests for non-ASCII grep patterns on another topic that are affected by this. Now instead

Re: [BUG] test suite broken with GIT_TEST_SPLIT_INDEX

On Fri, Apr 21, 2017 at 07:25:21PM +0700, Duy Nguyen wrote: > >> Yeah, you are right. > >> It looks like we have GIT_TEST_OPTS to pass options like --debug, > >> --valgrind, --verbose, but we don't have an environment variable to > >> set config options. > > > > Or maybe GIT_CONFIG_PARAMETERS

[PATCH] cache-tree: reject entries with null sha1

We generally disallow null sha1s from entering the index, due to 4337b5856 (do not write null sha1s to on-disk index, 2012-07-28). However, we loosened that in 83bd7437c (write_index: optionally allow broken null sha1s, 2013-08-27) so that tools like filter-branch could be used to repair broken

[PATCH v6 2/8] convert: move packet_write_list() into pkt-line as packet_writel()

Add packet_writel() which writes multiple lines in a single call and then calls packet_flush_gently(). Update convert.c to use the new packet_writel() function from pkt-line. Signed-off-by: Ben Peart --- convert.c | 23 ++- pkt-line.c | 19

[PATCH] tests: fix tests broken under GETTEXT_POISON=YesPlease

The GETTEXT_POISON=YesPlease compile-time testing option added in my bb946bba76 ("i18n: add GETTEXT_POISON to simulate unfriendly translator", 2011-02-22) has been slowly bitrotting as strings have been marked for translation, and new tests have been added without running it. I brought this up on

[PATCH v6 8/8] convert: Update subprocess_read_status to not die on EOF

Enable sub-processes to gracefully handle when the process dies by updating subprocess_read_status to return an error on EOF instead of dying. Update apply_multi_file_filter to take advantage of the revised subprocess_read_status. Signed-off-by: Ben Peart --- convert.c

Re: [PATCH 00/15] Handle fopen() errors

On Fri, Apr 21, 2017 at 07:27:20PM +0700, Duy Nguyen wrote: > On Fri, Apr 21, 2017 at 6:52 PM, Junio C Hamano wrote: > > Yes, but (1) we'd need to be careful about --quiet > > Yeah. It's a real pain point for making changes like this. At some > point we should just have a

[PATCH v6 5/8] convert: Update generic functions to only use generic data structures

Update all functions that are going to be moved into a reusable module so that they only work with the reusable data structures. Move code that is specific to the filter out into the filter specific functions. Signed-off-by: Ben Peart --- convert.c | 41

[PATCH v6 6/8] convert: rename reusable sub-process functions

Do a mechanical rename of the functions that will become the reusable sub-process module. Signed-off-by: Ben Peart --- convert.c | 40 1 file changed, 20 insertions(+), 20 deletions(-) diff --git a/convert.c b/convert.c index

[PATCH v6 7/8] sub-process: move sub-process functions into separate files

Move the sub-proces functions into sub-process.h/c. Add documentation for the new module in Documentation/technical/api-sub-process.txt Signed-off-by: Ben Peart --- Documentation/technical/api-sub-process.txt | 59 Makefile

[PATCH v6 0/8] refactor the filter process code into a reusable module

Refactor the filter..process code into a separate sub-process module that can be used to reduce the cost of starting up a sub-process for multiple commands. It does this by keeping the external process running and processing all commands by communicating over standard input and standard output

Re: [BUG] test suite broken with GETTEXT_POISON=YesPlease

On Fri, Apr 21, 2017 at 4:47 PM, Michael J Gruber wrote: > Ævar Arnfjörð Bjarmason venit, vidit, dixit 20.04.2017 23:58: >> As a refresh of everyone's memory (because mine needed it). This is a >> feature I added back in 2011 when the i18n support was initially >> added. >> >>

[PATCH v6 4/8] convert: Separate generic structures and variables from the filter specific ones

To enable future reuse of the filter..process infrastructure, split the cmd2process structure into two separate parts. subprocess_entry will now contain the generic data required to manage the creation and tracking of the child process in a hashmap. Also move all knowledge of the hashmap into the

[PATCH v6 3/8] convert: Split start_multi_file_filter into two separate functions

To enable future reuse of the filter..process infrastructure, split start_multi_file_filter into two separate parts. start_multi_file_filter will now only contain the generic logic to manage the creation and tracking of the child process in a hashmap. start_multi_file_filter_fn is a protocol

[PATCH v6 1/8] pkt-line: add packet_read_line_gently()

Add packet_read_line_gently() to enable reading a line without dying on EOF. Signed-off-by: Ben Peart --- pkt-line.c | 14 +- pkt-line.h | 10 ++ 2 files changed, 23 insertions(+), 1 deletion(-) diff --git a/pkt-line.c b/pkt-line.c index

Re: [BUG] test suite broken with GIT_TEST_SPLIT_INDEX

On Fri, Apr 21, 2017 at 4:25 PM, Christian Couder wrote: > On Thu, Apr 20, 2017 at 11:24 PM, Thomas Gummerer > wrote: >> On 04/20, Christian Couder wrote: >>> >>> Could you try with the following patch: >>> >>>

Re: [BUG] test suite broken with GETTEXT_POISON=YesPlease

On Fri, Apr 21, 2017 at 4:54 PM, Lars Schneider wrote: > >> Am 20.04.2017 um 23:58 schrieb Ævar Arnfjörð Bjarmason : >> >> As a refresh of everyone's memory (because mine needed it). This is a >> feature I added back in 2011 when the i18n support was

[PATCHv3 4/4] builtin/reset: add --recurse-submodules switch

git-reset is yet another working tree manipulator, which should be taught about submodules. When a user uses git-reset and requests to recurse into submodules, this will reset the submodules to the object name as recorded in the superproject, detaching the HEADs. Signed-off-by: Stefan Beller

Re: [BUG] test suite broken with GETTEXT_POISON=YesPlease

Ævar Arnfjörð Bjarmason venit, vidit, dixit 20.04.2017 23:58: > As a refresh of everyone's memory (because mine needed it). This is a > feature I added back in 2011 when the i18n support was initially > added. > > There was concern at the time that we would inadvertently mark > plumbing messages

RE: Proposal for "fetch-any-blob Git protocol" and server design

Hi Jonathan, Sorry for the delayed response - other work got in the way, unfortunately! Kevin -Original Message- From: Jonathan Tan [mailto:jonathanta...@google.com] Sent: Thursday, April 13, 2017 4:13 PM >> I know we're considering server behavior here, but how large do you generally

Re: [BUG] test suite broken with GETTEXT_POISON=YesPlease

> Am 20.04.2017 um 23:58 schrieb Ævar Arnfjörð Bjarmason : > > As a refresh of everyone's memory (because mine needed it). This is a > feature I added back in 2011 when the i18n support was initially > added. > > There was concern at the time that we would inadvertently mark >

Re: [PATCH 0/6] nd/worktree-move update

On Thu, Apr 20, 2017 at 05:10:18PM +0700, Nguyễn Thái Ngọc Duy wrote: > - fixes the compile problem on latest master (because prefix_filename >takes one argument less) It also now returns an allocated buffer. So: > --- a/builtin/worktree.c > +++ b/builtin/worktree.c > @@ -561,9 +561,7 @@

Re: [BUG] test suite broken with GIT_TEST_SPLIT_INDEX

On Thu, Apr 20, 2017 at 11:24 PM, Thomas Gummerer wrote: > On 04/20, Christian Couder wrote: >> >> Could you try with the following patch: >> >> http://public-inbox.org/git/20170330210354.20018-1-chrisc...@tuxfamily.org/ > > Yeah, I tried with and without that patch with the

Re: What's cooking in git.git (Apr 2017, #04; Wed, 19)

On Fri, Apr 21, 2017 at 11:50 AM, Johannes Schindelin wrote: > > Since that "let's aggregate everything and only push out the final result > at the end of the day" approach does not really allow the Continuous > Testing to identify problems associated with individual

Re: [PATCH] completion: expand "push --delete " for refs on that

On Tue, Apr 18, 2017 at 3:31 PM, Ævar Arnfjörð Bjarmason wrote: > Change the completion of "push --delete " to complete > refs on that , not all refs. Good. > Before this e.g. cloning git.git > and doing "git push --delete origin p" will complete nothing, Well, it will

Re: [PATCH 00/15] Handle fopen() errors

On Fri, Apr 21, 2017 at 6:52 PM, Junio C Hamano wrote: > Yes, but (1) we'd need to be careful about --quiet Yeah. It's a real pain point for making changes like this. At some point we should just have a global (maybe multi-level) quiet flag. -- Duy

Re: [BUG] test suite broken with GIT_TEST_SPLIT_INDEX

On Fri, Apr 21, 2017 at 6:57 PM, Christian Couder wrote: > On Fri, Apr 21, 2017 at 1:46 PM, Christian Couder > wrote: >> On Fri, Apr 21, 2017 at 11:53 AM, Duy Nguyen wrote: >>> On Fri, Apr 21, 2017 at 2:10 PM, Christian

Re: [BUG] test suite broken with GIT_TEST_SPLIT_INDEX

On Fri, Apr 21, 2017 at 1:46 PM, Christian Couder wrote: > On Fri, Apr 21, 2017 at 11:53 AM, Duy Nguyen wrote: >> On Fri, Apr 21, 2017 at 2:10 PM, Christian Couder >> wrote: >>> On Thu, Apr 20, 2017 at 11:24 PM, Thomas

Re: [PATCH 00/15] Handle fopen() errors

On Fri, Apr 21, 2017 at 8:04 PM, Duy Nguyen wrote: > On Fri, Apr 21, 2017 at 1:29 PM, Jeff King wrote: >> >> I had a similar thought while reading through it. I think it would be >> shorter still with: >> >> FILE *fopen_or_warn(const char *path, const char

Re: [BUG] test suite broken with GIT_TEST_SPLIT_INDEX

On Fri, Apr 21, 2017 at 11:53 AM, Duy Nguyen wrote: > On Fri, Apr 21, 2017 at 2:10 PM, Christian Couder > wrote: >> On Thu, Apr 20, 2017 at 11:24 PM, Thomas Gummerer >> wrote: >>> On 04/20, Christian Couder wrote:

Re: [PATCH 00/15] Handle fopen() errors

On Fri, Apr 21, 2017 at 1:29 PM, Jeff King wrote: > On Thu, Apr 20, 2017 at 08:41:32PM -0700, Junio C Hamano wrote: > >> Junio C Hamano writes: >> >> > I wonder if it is OK to only special case ENOENT for !fp cases, >> > where existing code silently returns.

[PATCH v4 3/9] t0006 & t5000: skip "far in the future" test when time_t is too limited

Git's source code refers to timestamps as unsigned long, which is ill-defined, as there is no guarantee about the number of bits that data type has. In preparation of switching to another data type that is large enough to hold "far in the future" dates, we need to prepare the t0006-date.sh script

[PATCH v4 2/9] t0006 & t5000: prepare for 64-bit timestamps

Git's source code refers to timestamps as unsigned longs. On 32-bit platforms, as well as on Windows, unsigned long is not large enough to capture dates that are "absurdly far in the future". It is perfectly valid by the C standard, of course, for the `long` data type to refer to 32-bit integers.

[PATCH v4 4/9] Specify explicitly where we parse timestamps

Currently, Git's source code represents all timestamps as `unsigned long`. In preparation for using a more appropriate data type, let's introduce a symbol `parse_timestamp` (currently being defined to `strtoul`) where appropriate, so that we can later easily switch to, say, use `strtoull()`

[PATCH v4 6/9] Introduce a new data type for timestamps

Git's source code assumes that unsigned long is at least as precise as time_t. Which is incorrect, and causes a lot of problems, in particular where unsigned long is only 32-bit (notably on Windows, even in 64-bit versions). So let's just use a more appropriate data type instead. In preparation

[PATCH v4 9/9] show_date_ident(): defer date overflow check

Now that we use uintmax_t for timestamps, we can represent timestamps that would not fit inside the time_t data type. As long as we do not have to use the system functions, we can even display them, e.g. as Unix epoch. Signed-off-by: Johannes Schindelin --- pretty.c

[PATCH v4 5/9] Introduce a new "printf format" for timestamps

Currently, Git's source code treats all timestamps as if they were unsigned longs. Therefore, it is okay to write "%lu" when printing them. There is a substantial problem with that, though: at least on Windows, time_t is *larger* than unsigned long, and hence we will want to switch away from the

[PATCH v4 7/9] Abort if the system time cannot handle one of our timestamps

We are about to switch to a new data type for time stamps that is definitely not smaller or equal, but larger or equal to time_t. So before using the system functions to process or format timestamps, let's make extra certain that they can handle what we feed them. Signed-off-by: Johannes

[PATCH v4 8/9] Use uintmax_t for timestamps

Previously, we used `unsigned long` for timestamps. This was only a good choice on Linux, where we know implicitly that `unsigned long` is what is used for `time_t`. However, we want to use a different data type for timestamps for two reasons: - there is nothing that says that `unsigned long`

[PATCH v4 0/9] Introduce timestamp_t for timestamps

Git v2.9.2 was released in a hurry to accomodate for platforms like Windows, where the `unsigned long` data type is 32-bit even for 64-bit setups. The quick fix was to simply disable all the testing with "absurd" future dates. However, we can do much better than that, as we already make use of

[PATCH v4 1/9] ref-filter: avoid using `unsigned long` for catch-all data type

In its `atom_value` struct, the ref-filter source code wants to store different values in a field called `ul` (for `unsigned long`), e.g. timestamps. However, as we are about to switch the data type of timestamps away from `unsigned long` (because it may be 32-bit even when `time_t` is 64-bit),

Re: [PATCH v3 0/8] Introduce timestamp_t for timestamps

Hi Junio, On Thu, 20 Apr 2017, Junio C Hamano wrote: > Johannes Schindelin writes: > > > Note: while the `time_t` data type exists and is meant to be used for > > timestamps, on 32-bit Linux it is *still* 32-bit. An earlier iteration > > used `time_t` for that

Re: [BUG] test suite broken with GIT_TEST_SPLIT_INDEX

On Fri, Apr 21, 2017 at 2:10 PM, Christian Couder wrote: > On Thu, Apr 20, 2017 at 11:24 PM, Thomas Gummerer > wrote: >> On 04/20, Christian Couder wrote: >>> >>> Could you try with the following patch: >>> >>>

Re: What's cooking in git.git (Apr 2017, #04; Wed, 19)

Hi Junio, On Thu, 20 Apr 2017, Junio C Hamano wrote: > Lars Schneider writes: > > >> * bw/forking-and-threading (2017-04-19) 11 commits > >> - run-command: block signals between fork and execve > >> - run-command: add note about forking and threading > >> -

Re: [PATCH] refs.h: rename submodule arguments to submodule_path

On Fri, Apr 21, 2017 at 1:42 PM, Michael Haggerty wrote: > On 04/21/2017 08:32 AM, Michael Haggerty wrote: >> [...] >> I've CCed Duy because I don't know whether he has more plans regarding >> submodule references [...] get rid of the >> `for_each_ref_submodule()` family of

RE: [PATCH] Increase core.packedGitLimit

Hi Dave, On Thu, 20 Apr 2017, David Turner wrote: > > We might want to think about replacing git_config_ulong with > git_config_size_t in nearly all cases. "long" has ceased to be > useful. More modern versions of C prefer uint64_t, but I > think that we'll usually want size_t because these

Re: [PATCH] completion: optionally disable checkout DWIM

On Thu, Apr 20, 2017 at 1:12 PM, Jeff King wrote: > When we complete branch names for "git checkout", we also > complete remote branch names that could trigger the DWIM > behavior. Depending on your workflow and project, this can > be either convenient or annoying. > > For

Re: [BUG] test suite broken with GIT_TEST_SPLIT_INDEX

On Thu, Apr 20, 2017 at 11:24 PM, Thomas Gummerer wrote: > On 04/20, Christian Couder wrote: >> >> Could you try with the following patch: >> >> http://public-inbox.org/git/20170330210354.20018-1-chrisc...@tuxfamily.org/ > > Yeah, I tried with and without that patch with the

Re: [BUG] test suite broken with GIT_TEST_SPLIT_INDEX

On Fri, Apr 21, 2017 at 6:01 AM, Junio C Hamano wrote: > Christian Couder writes: > >> Could you try with the following patch: >> >> http://public-inbox.org/git/20170330210354.20018-1-chrisc...@tuxfamily.org/ > > Ah, this reminds me. The patch has

Re: [PATCH] refs.h: rename submodule arguments to submodule_path

On 04/21/2017 08:32 AM, Michael Haggerty wrote: > [...] > I've CCed Duy because I don't know whether he has more plans regarding > submodule references [...] get rid of the > `for_each_ref_submodule()` family of functions entirely. > > So perhaps the code that this patch touches won't be around

Re: [PATCH] refs.h: rename submodule arguments to submodule_path

On 04/21/2017 03:12 AM, Junio C Hamano wrote: > Stefan Beller writes: > >> + Junio > > Just like Michael, I do not have strong enough opinion for or > against this patch to comment on it. > > I do agree with you that it would be a good longer-term direction to > use

Re: [PATCH 05/15] log: report errno on failure to fopen() a file

On Thu, Apr 20, 2017 at 06:25:59PM +0700, Nguyễn Thái Ngọc Duy wrote: > Signed-off-by: Nguyễn Thái Ngọc Duy > --- > builtin/log.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/builtin/log.c b/builtin/log.c > index b3b10cc1ed..26d6a3cf14 100644 >

Re: [PATCH 00/15] Handle fopen() errors

On Thu, Apr 20, 2017 at 08:41:32PM -0700, Junio C Hamano wrote: > Junio C Hamano writes: > > > I wonder if it is OK to only special case ENOENT for !fp cases, > > where existing code silently returns. Perhaps it is trying to read > > an optional file, and it returns silently

Re: [PATCH v3 0/8] Introduce timestamp_t for timestamps

Johannes Schindelin writes: > Note: while the `time_t` data type exists and is meant to be used for > timestamps, on 32-bit Linux it is *still* 32-bit. An earlier iteration > used `time_t` for that reason, but it came with a few serious downsides: > as `time_t` can be