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 | 19 +--
> refs.h | 2 ++
> 2 files changed, 11 insertions(+), 10 deletions(-)
>
> diff --git a/refs.c b/refs.c
> index 26474cb62a..a252ae43ee 100644
> --- a/refs.c
> +++ b/
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 w
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
contrib/completion/git-completion.bash | 2
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 l
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
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 insertions(+), 16 delet
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
> @@ -1570,19 +1570,1
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 about moving these ha
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. reflog)
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)
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 Jones
builtin/worktree.c | 2 +-
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 traile
+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:
>
> git fetch git://git.kerne
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 scrip
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
>> > "perl -C". Us
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 7b309aef0463340d3ad5449d1f605d1
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
> > j
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 "æ" is counted
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 (e.g
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 f
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 conta
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
> >> want
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
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
>> be either convenient or annoying.
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 the foreground, 2016-05-01) and
>> ef09036cf
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 in
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
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 work
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 his
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 +++
pkt-line.h |
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
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 | 10 --
sub-
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 global (maybe multi-lev
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 +++--
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 d15b10a3c5..cfae45aeee 10064
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| 1 +
convert.c
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 usi
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.
>>
>> There was concern at
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
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 spec
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 d4b6bfe076..bfdb177b34 100644
--- a/p
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:
>>>
>>> http://public-inbox.org/git/20170330210354.20018-1-chrisc...@tuxfamily.org/
>>
>> Yea
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 initially
>> added.
>>
>> There was concern at
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
---
Æ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 f
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
> 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
> plumbing messages
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 @@ s
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 same result.
> Unless
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 topic branches, I
> have anoth
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 complete all local bra
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
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 Couder
>>> wrote:
On Thu, Apr 20, 2017 at 11:24 PM, Thomas Gummerer
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 Gummerer
>>> wrote:
On 04/20, Christian Couder wrote:
>
> Coul
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 *mode)
>> {
>> FILE *fh = fo
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:
Could you try with the following patch:
http://public-inbox.o
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. Perhaps it is trying to read
>> > an
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'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.
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 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
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 | 12
1 file cha
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
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
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
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
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 reason, but it came with a few ser
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:
>>>
>>> http://public-inbox.org/git/20170330210354.20018-1-chrisc...@tuxfamily.org/
>>
>> Yea
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
> >> - run-command: handle dup2 and close er
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 functions entirely.
>>
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 va
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 instance, my clone of gi
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 same result.
> Unless
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 been in the stalled state for
> quite some time
75 matches
Mail list logo
