Re: [PATCH v2 4/8] Specify explicitly where we parse timestamps

[] --- a/git-compat-util.h +++ b/git-compat-util.h @@ -319,6 +319,8 @@ extern char *gitdirname(char *); #define PRIo32 "o" #endif +#define parse_timestamp strtoul + Would #define parse_timestamp(a,b,c) strtoul((a),(b),(c)) be more strict ?

Re: [PATCH v2 1/8] ref-filter: avoid using `unsigned long` for catch-all data type

On 02/04/17 21:06, Johannes Schindelin wrote: 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

chmod: changing permissions of `blib/arch/auto/Git': Operation not permitted

This is kind of unusual. I'm seeing it under Debian 7 on a ci20 mipsel dev-board when building/installing Git 2.12.2: ... 317 translated messages. GEN gitk-wish 307 translated messages. SUBDIR perl chmod: changing permissions of `blib/lib': Operation not permitted chmod: changing

Re: [PATCH v7 5/5] remove_subtree(): reimplement using iterators

On 04/02/2017 10:03 PM, Daniel Ferreira wrote: > From: Daniel Ferreira > > Use dir_iterator to traverse through remove_subtree()'s directory tree, > avoiding the need for recursive calls to readdir(). Simplify > remove_subtree()'s code. > > A conversion similar in

Re: [PATCH v7 4/5] dir_iterator: refactor state machine model

On 04/02/2017 10:03 PM, Daniel Ferreira wrote: > Perform major refactor of dir_iterator_advance(). dir_iterator has > ceased to rely on a convoluted state machine mechanism of two loops and > two state variables (level.initialized and level.dir_state). This serves > to ease comprehension of the

Bug? git submodule update --reference doesn't use the referenced repository

Hi there, I have been trying to use the --reference option to clone a big repository using a local copy, but I can't manage to make it work using sub-module update. I believe this is a bug, unless I missed something. I am on Windows, Git 2.12.0 So the problem is as follow: - I have got a

[PATCH] Fix 'git am' in-body header continuations

From: Linus Torvalds Date: Sat, 1 Apr 2017 12:14:39 -0700 Subject: [PATCH] Fix 'git am' in-body header continuations An empty line should stop any pending in-body headers, and start the actual body parsing. This also modifies the original test for the in-body

Re: [GSoC] Proposal: turn git-add--interactive.perl into a builtin

On Sun, Apr 2, 2017 at 4:43 PM, Johannes Schindelin wrote: > We ask to accomplish a microproject before evaluating the proposals for > one reason: to have a good understanding how well the students would > interact with the project if they were accepted. As such, the >

[PATCH v7 5/5] remove_subtree(): reimplement using iterators

From: Daniel Ferreira Use dir_iterator to traverse through remove_subtree()'s directory tree, avoiding the need for recursive calls to readdir(). Simplify remove_subtree()'s code. A conversion similar in purpose was previously done at 46d092a ("for_each_reflog():

[PATCH v7 4/5] dir_iterator: refactor state machine model

Perform major refactor of dir_iterator_advance(). dir_iterator has ceased to rely on a convoluted state machine mechanism of two loops and two state variables (level.initialized and level.dir_state). This serves to ease comprehension of the iterator mechanism and ease addition of new features to

[PATCH v7 3/5] dir_iterator: add helpers to dir_iterator_advance

Create inline helpers to dir_iterator_advance(). Make dir_iterator_advance()'s code more legible and allow some behavior to be reusable. Signed-off-by: Daniel Ferreira --- dir-iterator.c | 65 +- 1 file changed, 42

[PATCH v7 1/5] dir_iterator: add tests for dir_iterator API

Create t/helper/test-dir-iterator.c, which prints relevant information about a directory tree iterated over with dir_iterator. Create t/t0065-dir-iterator.sh, which tests that dir_iterator does iterate through a whole directory tree. Signed-off-by: Daniel Ferreira ---

[PATCH v7 2/5] remove_subtree(): test removing nested directories

Test removing a nested directory when an attempt is made to restore the index to a state where it does not exist. A similar test could be found previously in t/t2000-checkout-cache-clash.sh, but it did not check for nested directories, which could allow a faulty implementation of remove_subtree()

[PATCH v7 0/5] [GSoC] remove_subtree(): reimplement using iterators

This is the seventh version of a patch series that implements the GSoC microproject of converting a recursive call to readdir() to use dir_iterator. v1: https://public-inbox.org/git/CAGZ79kZwT-9mHTiOJ5CEjk2wDFkn6+NcogjX0=vjhsah16a...@mail.gmail.com/T/#t v2:

Re: [GSoC] Proposal: turn git-add--interactive.perl into a builtin

Hi Daniel, On Fri, 31 Mar 2017, Daniel Ferreira (theiostream) wrote: > Question: do you suggest any pending bugfix to git-add--interactive or > to something related that might give some useful knowledge in advance? > (for the pre-code period). My microproject involves playing with the >

[PATCH v2 8/8] 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 v2 7/8] 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 v2 6/8] 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 v2 5/8] 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 v2 0/8] 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 v2 4/8] 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 v2 3/8] 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 v2 1/8] 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),

[PATCH v2 2/8] 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.

Re: Bug in "git am" when the body starts with spaces

Linus Torvalds writes: > On Fri, Mar 31, 2017 at 5:52 PM, Linus Torvalds > wrote: >> >> The continuation logic is oddly complex, and I can't follow the logic. >> But it is completely broken in how it thinks empty lines are somehow >>

Re: [PATCH 2/2] [GSOC] show_bisect_vars(): Use unsigned int instead of signed int for flags

Robert Stanca writes: > The question is : If the flags field of the structure is used in > function calls should i update flags that deep?(there are other > cases where the field is used in nested calls ) [administrivia: please don't top-post around here]. There won't

Re: [PATCH] contrib/git-resurrect.sh: do not write \t for HT in sed scripts

Jakub Narębski writes: > W dniu 01.04.2017 o 06:14, Junio C Hamano pisze: > >> Just like we did in 0d1d6e50 ("t/t7003: replace \t with literal tab >> in sed expression", 2010-08-12), avoid writing "\t" for HT in sed >> scripts, which is not portable. > > I guess it is not

Re: [PATCH v2 00/20] Separate `ref_cache` into a separate module

Ramsay Jones writes: >> In that sense, Michael's series and Duy's later two series are >> "tangled" (i.e. shares some common commits that are still not in >> 'master'). If nd/files-backend-git-dir that is shared among them is >> ever rebased, all of them need to be

Re: [PATCH v2 00/20] Separate `ref_cache` into a separate module

On 02/04/17 04:38, Junio C Hamano wrote: > Ramsay Jones writes: > >>> I am getting the impression that the files-backend thing as well as >>> this topic are ready for 'next'. Please stop me if I missed something >>> in these topics (especially the other one) that

Re: [PATCH 2/2] [GSOC] show_bisect_vars(): Use unsigned int instead of signed int for flags

One more quesestion regarding flags used in structures : for example: update_callback_data has a flags field (type int) , in function void update_callback() the field flags of that structure is used as param for add_file_to_index(..., data->flags) and this function is define as: int

Re: [BUG?] iconv used as textconv, and spurious ^M on added lines on Windows

W dniu 02.04.2017 o 09:45, Jeff King pisze: > On Sat, Apr 01, 2017 at 08:31:27PM +0200, Jakub Narębski wrote: > >> W dniu 01.04.2017 o 08:08, Jeff King pisze: >>> On Fri, Mar 31, 2017 at 03:24:48PM +0200, Jakub Narębski wrote: >>> > I suspect in the normal case that git is doing line-ending

Re: [PATCH] contrib/git-resurrect.sh: do not write \t for HT in sed scripts

W dniu 01.04.2017 o 06:14, Junio C Hamano pisze: > Just like we did in 0d1d6e50 ("t/t7003: replace \t with literal tab > in sed expression", 2010-08-12), avoid writing "\t" for HT in sed > scripts, which is not portable. I guess it is not possible to use HT variable (similar to LF that we have

Re: Bug: 'git config --local user.email=' fails silently?

On Sun, 2017-04-02 at 03:38 -0400, Jeff King wrote: > On Sun, Apr 02, 2017 at 07:47:23AM +0200, Knut Omang wrote: > > > From the documentation I would have expected  > >  > > git config --local user.email=alt.email@alt.domain > >  > > to create a section  > >  > > [user] > > 

Re: [BUG?] iconv used as textconv, and spurious ^M on added lines on Windows

On Sat, Apr 01, 2017 at 08:31:27PM +0200, Jakub Narębski wrote: > W dniu 01.04.2017 o 08:08, Jeff King pisze: > > On Fri, Mar 31, 2017 at 03:24:48PM +0200, Jakub Narębski wrote: > > > >>> I suspect in the normal case that git is doing line-ending conversion, > >>> but it's suppressed when

Re: Bug: 'git config --local user.email=' fails silently?

On Sun, Apr 02, 2017 at 07:47:23AM +0200, Knut Omang wrote: > From the documentation I would have expected  > > git config --local user.email=alt.email@alt.domain > > to create a section  > > [user] > email=alt.email@alt.domain > > in the local .git/config. When it sees one argument,