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, gi
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 textcon
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]
> > email=alt.email@al
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 in
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 co
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 add_file_to_in
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 needs updating
>>> before that
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 rebased on top of it
>> consis
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 possible to use HT varia
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 be any fast and clear rule
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
>> "continuations".
>
> The attached patch seems to work for me.
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.
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),
th
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()` instead
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
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
64
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 i
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
fo
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` sho
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 Schindel
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
> dir_itera
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:
https://public-inbox.org/git/cacsjy8dx
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
---
Makefile
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() p
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 insertions(+), 23 deletio
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 th
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(): reimplement using iterators", 20
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
> microprojects really are abo
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 headers to actually
have a real com
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 repo
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 ite
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 purpose was previously done at
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 permissio
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
[]
--- 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 ?
Junio,
thanks for explaining! So if there are at least two commits, blame is fast, but
with only one commit blame tries hard to find another commit that might have
contributed to the one file?
I verified that without those "-C" options the result is very quick.
In the other case (for the user bo
36 matches
Mail list logo
