On Mon, Sep 23, 2019 at 10:00:37AM -0400, Derrick Stolee wrote:
> > builtin/pack-objects.c
> > 7c59828b 2694) (reuse_packfile_bitmap &&
> > 7c59828b 2695) bitmap_walk_contains(bitmap_git, reuse_packfile_bitmap,
> > oid));
>
> This change to obj_is_packed(oid) is a small change in a
> really big
We've never had a formally written Code of Conduct document. Though it
has been discussed off and on over the years, for the most part the
behavior on the mailing list has been good enough that nobody felt the
need to push one forward.
However, even if there aren't specific problems now, it's a go
Am 23.09.19 um 12:04 schrieb Alexandr Miloslavskiy via GitGitGadget:
> From: Alexandr Miloslavskiy
>
> After I discovered that UTF-16-LE-BOM test was bugged and still
> succeeded, I decided that better tests are required. Possibly the best
> option here is to compare git results against hardcoded
On Mon, Sep 23, 2019 at 03:04:19AM -0700, Alexandr Miloslavskiy via
GitGitGadget wrote:
> From: Alexandr Miloslavskiy
Thanks for the tests, some nit-picks inline.
>
> After I discovered that UTF-16-LE-BOM test was bugged and still
> succeeded...
My interpretation is that the \000\000 must be h
On Mon, Sep 23, 2019 at 03:04:19AM -0700, Alexandr Miloslavskiy via
GitGitGadget wrote:
> From: Alexandr Miloslavskiy
>
> According to its name, the test is designed for UTF-16-LE-BOM.
> However, possibly due to copy&paste oversight, it was using UTF-32 file.
>
> While the test succeeds (probably
Hello,
I think I have found a bug in the implementation of `git checkout
—recurse-submodules $branch` in the case of nested submodules. When I add a
submodule that has submodules in a feature branch of the main project, checkout
the master branch and then checkout my feature branch again, the s
This is less error-prone than "const void *" as the compiler
now detects invalid types being passed.
Signed-off-by: Eric Wong
---
diff.c | 5 +++--
diffcore-rename.c | 2 +-
hashmap.c | 5 +++--
hashmap.h | 3 ++-
name-hash.c | 2 +-
And add *_entry variants to perform container_of as necessary
to simplify most callers.
Signed-off-by: Eric Wong
---
hashmap.c | 6 --
hashmap.h | 13 +++--
range-diff.c| 4 +++-
remote.c| 3 ++-
submodule-config.c | 4
This is less error-prone than "void *" as the compiler now
detects invalid types being passed.
Signed-off-by: Eric Wong
---
builtin/fast-export.c | 2 +-
hashmap.c | 2 +-
hashmap.h | 2 +-
merge-recursive.c | 4 ++--
oidmap.c| 2 +-
refs.c
This is less error-prone than "void *" as the compiler now
detects invalid types being passed.
Signed-off-by: Eric Wong
---
attr.c | 2 +-
blame.c | 2 +-
builtin/describe.c | 2 +-
builtin/difftool.c | 6 +++---
builtin/fetch.c | 2 +-
config.c
This is less error-prone than "const void *" as the compiler
now detects invalid types being passed.
Signed-off-by: Eric Wong
---
attr.c| 2 +-
blame.c | 6 +++---
builtin/difftool.c| 5 +++--
builtin/fast-export.c | 2 +-
config.c | 2 +-
diff.c
`hashmap_free_entries' behaves like `container_of' and passes
the offset of the hashmap_entry struct to the internal
`hashmap_free_' function, allowing the function to free any
struct pointer regardless of where the hashmap_entry field
is located.
`hashmap_free' no longer takes any arguments aside
This macro is popular within the Linux kernel for supporting
intrusive data structures such as linked lists, red-black trees,
and chained hash tables while allowing the compiler to do
type checking.
I intend to use this to remove the limitation of "hashmap_entry"
being location-dependent and to al
While we cannot rely on a `__typeof__' operator being portable
to use with `offsetof'; we can calculate the pointer offset
using an existing pointer and the address of a member using
pointer arithmetic.
This allows us to simplify usage of hashmap iterator macros
by not having to specify a type whe
This is less error-prone than "const void *" as the compiler
now detects invalid types being passed.
Signed-off-by: Eric Wong
---
blame.c| 2 +-
hashmap.c | 3 ++-
hashmap.h | 2 +-
merge-recursive.c | 2 +-
name-hash.c| 4 ++--
packfile.c | 2 +-
r
This is a step towards removing the requirement for
hashmap_entry being the first field of a struct.
Signed-off-by: Eric Wong
---
diff.c | 19 ---
diffcore-rename.c | 11 +++
hashmap.c | 2 +-
hashmap.h | 12
Update callers to use hashmap_get_entry, hashmap_get_entry_from_hash
or container_of as appropriate.
This is another step towards eliminating the requirement of
hashmap_entry being the first field in a struct.
Signed-off-by: Eric Wong
---
attr.c| 2 +-
blame.c | 1
Since these macros already take a `keyvar' pointer of a known type,
we can rely on OFFSETOF_VAR to get the correct offset without
relying on non-portable `__typeof__' and `offsetof'.
Argument order is also rearranged, so `keyvar' and `member' are
sequential as they are used as: `keyvar->member'
S
C compilers do type checking to make life easier for us. So
rely on that and update all hashmap_entry_init callers to take
"struct hashmap_entry *" to avoid future bugs while improving
safety and readability.
Signed-off-by: Eric Wong
---
attr.c | 4 ++--
blame.c
Inspired by list_for_each_entry in the Linux kernel.
Once again, these are somewhat compromised usability-wise
by compilers lacking __typeof__ support.
Signed-off-by: Eric Wong
---
attr.c | 5 +++--
blame.c | 10 ++
builtin/descri
Another step in eliminating the requirement of hashmap_entry
being the first member of a struct.
Signed-off-by: Eric Wong
---
attr.c | 10 ++
builtin/describe.c | 10 ++
builtin/difftool.c | 31 +++
builtin/fast-export.c |
This hashmap_entry_init function is intended to take a
hashmap_entry struct pointer, not a hashmap struct pointer.
This was not noticed because hashmap_entry_init takes a "void *"
arg instead of "struct hashmap_entry *", and the hashmap struct
is larger and can be cast into a hashmap_entry struct
Using `container_of' can be verbose and choosing names for
intermediate "struct hashmap_entry" pointers is a hard problem.
So introduce "*_entry" APIs inspired by similar linked-list
APIs in the Linux kernel.
Unfortunately, `__typeof__' is not portable C, so we need an
extra parameter to specify t
Otherwise, the hashmap_entry.next field appears to remain
uninitialized, which can lead to problems when
add_lines_to_move_detection calls hashmap_add.
I found this through manual inspection when converting
hashmap_add callers to take "struct hashmap_entry *".
Signed-off-by: Eric Wong
---
diff.
Assigning hashmap_entry.hash manually leaves hashmap_entry.next
uninitialized, which can be dangerous once the hashmap_entry is
inserted into a hashmap. Detect those assignments and use
hashmap_entry_init, instead.
Signed-off-by: Eric Wong
---
contrib/coccinelle/hashmap.cocci | 16
Patches 1-11 are largely unchanged from the original series with the
exception of 2, which is new and posted at:
https://public-inbox.org/git/20190908074953.kux7zz4y7iolqko4@whir/
12-17 take further steps to get us away from hashmap_entry being
the first element, but they're also a bit ug
Johannes Schindelin wrote:
> On Mon, 16 Sep 2019, Emily Shaffer wrote:
> > - try and make progress towards running many tests from a single test
> >file in parallel - maybe this is too big, I'm not sure if we know how
> >many of our tests are order-dependent within a file for now...
>
>
On Fri, Sep 20, 2019 at 11:36:09AM +0200, SZEDER Gábor wrote:
> Ignoring everything but sources has the drawback that building an
> older version of Git (e.g. during bisecting) creates all those
> executables, and after going back to e.g. current 'master' the usual
> cleanup commands like 'make cl
On 23/09/2019 20:40, Jeff King wrote:
On Fri, Sep 20, 2019 at 06:47:01PM -0700, Emily Shaffer wrote:
"""
"Did You Mean..?"
There are some situations where it's fairly clear what a user meant to
do, even though they did not do that thing correctly. For example, if a
user runs `git commit` with
On Thu, Sep 19, 2019 at 10:48:30PM +0200, René Scharfe wrote:
> Use the macro COPY_ARRAY to copy array elements and MOVE_ARRAY to do the
> same for moving them backwards in an array with potential overlap. The
> result is shorter and safer, as it infers the element type automatically
> and does a
On Mon, Sep 23, 2019 at 01:19:18PM +0200, Christian Schoenebeck wrote:
> > if (cmit_fmt_is_mail(pp->fmt)) {
> > - if (pp->from_ident && ident_cmp(pp->from_ident, &ident)) {
> > + if (pp->always_use_in_body_from ||
> > + (pp->from_ident && ident_cmp(pp->from_id
On 9/21/19 5:11 AM, SZEDER Gábor wrote:
>>
>> +#define MIDX_PROGRESS (1 << 0)
>
> Please consider using an enum.
>
> A preprocessor constant is just that: a number. It is shown as a
> number while debugging, and there is no clear indication what related
> values belong in the same group (a
Hi Stolee,
On Thu, 19 Sep 2019, Derrick Stolee wrote:
> During the Virtual Git Contributors' Summit, Dscho brought up the topic of
> "Inclusion & Diversity". We discussed ideas for how to make the community
> more welcoming to new contributors of all kinds. Let's discuss some of
> the ideas we ta
Hi Mike,
On Fri, 20 Sep 2019, Mike Hommey wrote:
> On Thu, Sep 19, 2019 at 12:30:13PM -0400, Derrick Stolee wrote:
> > During the Virtual Git Contributors' Summit, Dscho brought up the topic of
> > "Inclusion & Diversity". We discussed ideas for how to make the community
> > more welcoming to ne
On Mon, Sep 23, 2019 at 01:38:54PM -0700, Jonathan Tan wrote:
> I didn't have any concrete ideas so I didn't include those, but some
> unrefined ideas:
One risk to a mentoring project like this is that the intern does a good
job of steps 1-5, and then in step 6 we realize that the whole thing is
On 9/20/19 1:10 PM, Junio C Hamano wrote:
>> diff --git a/midx.c b/midx.c
>> index b2673f52e8..54e4e93b2b 100644
>> --- a/midx.c
>> +++ b/midx.c
>> @@ -449,6 +449,8 @@ struct pack_list {
>> uint32_t nr;
>> uint32_t alloc;
>> struct multi_pack_index *m;
>> +struct progress *progre
> I approved this. I did leave some comments elsewhere in the thread, but
> I think we can continue to iterate on the idea.
Thanks.
> > There was a "How can applicants make a contribution to your project?"
> > question and a few questions about communication channels. I answered
> > them as best
On Mon, Sep 23, 2019 at 09:55:11PM +0200, René Scharfe wrote:
> -- >8 --
> Subject: [PATCH] name-rev: use FLEX_ARRAY for tip_name in struct rev_name
>
> Give each rev_name its very own tip_name string. This simplifies memory
> ownership, as callers of name_rev() only have to make sure the tip_nam
> I think this is an OK level of detail. I'm not sure quite sure about the
> goal of the project, though. In particular:
>
> - I'm not clear what we'd hope to gain. I.e., what richer information
> would we want to pass back and forth between index-pack and the
> other processes? It might
Am 23.09.19 um 20:59 schrieb SZEDER Gábor:
> On Mon, Sep 23, 2019 at 08:43:11PM +0200, René Scharfe wrote:
>>> It's overall memory usage, the avarage of five runs of:
>>>
>>> /usr/bin/time --format='%M' ~/src/git/git name-rev --all
>>>
And how much is that in absolute terms?
>>>
>>> git:
On Fri, Sep 20, 2019 at 06:47:01PM -0700, Emily Shaffer wrote:
> """
> "Did You Mean..?"
>
> There are some situations where it's fairly clear what a user meant to
> do, even though they did not do that thing correctly. For example, if a
> user runs `git commit` with tracked, modified, unstaged f
Hi,
On Wed, 18 Sep 2019, Junio C Hamano wrote:
> We have a new maintainer for git-gui now. Thanks Pratyush for
> volunteering.
Excellent!
I opened PRs at https://github.com/prati0100/git-gui/pulls. Pratyush, do
you accept contributions in this form, or should I do anything
differently?
Ciao,
On Tue, Sep 17, 2019 at 05:10:43PM +0200, Christian Couder wrote:
> > Nice projects, all. There are a couple more ideas on
> > https://github.com/gitgitgadget/git/issues, they could probably use some
> > tagging.
>
> Thanks! Maybe we should have a page with Outreachy microprojects on
> https://gi
On Mon, Sep 23, 2019 at 10:58:05AM -0700, Jonathan Tan wrote:
> > I think this is really great, both the idea and the description! No
> > need for more details.
>
> Thanks! I've just submitted the project proposal - hopefully it will be
> approved soon. In any case, it seems that project informat
Am 23.09.19 um 10:37 schrieb SZEDER Gábor:
> On Sun, Sep 22, 2019 at 11:01:26PM +0200, Johannes Sixt wrote:
>> Huh? For signed cutoff and positive CUTOFF_DATE_SLOP,
>> cutoff - CUTOFF_DATE_SLOP < cutoff is ALWAYS true. Signed interger
>> underflow is undefined behavior and signed integer arithmetic
On Fri, Sep 20, 2019 at 10:04:48AM -0700, Jonathan Tan wrote:
> > I'm happy to discuss possible projects if anybody has an idea but isn't
> > sure how to develop it into a proposal.
>
> I'm new to Outreachy and programs like this, so does anyone have an
> opinion on my draft proposal below? It do
On Mon, Sep 23, 2019 at 08:43:11PM +0200, René Scharfe wrote:
> > It's overall memory usage, the avarage of five runs of:
> >
> > /usr/bin/time --format='%M' ~/src/git/git name-rev --all
> >
> >> And how much is that in absolute terms?
> >
> > git: 29801 -> 28514
> > linux: 317018 -> 332218
Am 22.09.19 um 21:05 schrieb SZEDER Gábor:
> On Sat, Sep 21, 2019 at 02:37:18PM +0200, René Scharfe wrote:
>> Am 21.09.19 um 11:57 schrieb SZEDER Gábor:
>>> On Fri, Sep 20, 2019 at 08:14:07PM +0200, SZEDER Gábor wrote:
On Fri, Sep 20, 2019 at 08:13:02PM +0200, SZEDER Gábor wrote:
>> If the
On Mon, Sep 23, 2019 at 01:18:39PM -0400, Jeffrey Walton wrote:
> (A) core.sshCommand:
>
> sshcommand = "C:\\Users\\Jeffrey Walton\\Desktop\\test_tunnel.exe"
>
> Result:
>
> $ GIT_TRACE=1 git clone ssh://jeffrey.wal...@example.com:22480/main
> ...
> Cloning into 'main'...
> 11:44:32.192382 r
When running `make hdr-check`, we got the following error messages:
apply.h:146:22: error: use of undeclared identifier 'GIT_MAX_HEXSZ'
char old_oid_prefix[GIT_MAX_HEXSZ + 1];
^
apply.h:147:22: error: use of undeclared identifier
On platforms that can run `make hdr-check` but require custom flags,
this target was failing because none of them were being passed to the
compiler. For example, on MacOS, the NO_OPENSSL flag was being set but
it was not being passed into compiler so the check was failing.
Pass $(ALL_CFLAGS) into
This patchset relates to `make hdr-check`. The first patch addresses
getting it to run on platforms which require custom CFLAGS.
The other two patches address errors/warnings caught by actually running
`make hdr-check`.
Denton Liu (3):
Makefile: use $(ALL_CFLAGS) in $(HCO) target
apply.h: in
When we ran `make hdr-check`, we got the following warning message:
promisor-remote.h:21:46: warning: declaration of 'struct repository'
will not be visible outside of this function [-Wvisibility]
extern int promisor_remote_get_direct(struct repository *repo,
On Mon, Sep 23, 2019 at 02:47:23PM +0200, Johannes Schindelin wrote:
> The evaluation of the lazy prereq is indeed not different between Bash
> or dash. It is nevertheless quite disruptive in the trace of a test
> script, especially when it is evaluated for a test case that is skipped
> explicitly
On Tue, Sep 17, 2019 at 01:23:18PM +0200, Johannes Schindelin wrote:
> The only slightly challenging aspect might be that `merge-one-file` is
> actually not a merge strategy, but it is used as helper to be passed to
> `git merge-index` via the `-o ` option, which makes it slightly
> awkward to be
On Wed, Sep 04, 2019 at 03:41:15PM -0400, Jeff King wrote:
> The project page has a section to point people in the right direction
> for first-time contributions. I've left it blank for now, but I think it
> makes sense to point one (or both) of:
>
> - https://git-scm.com/docs/MyFirstContributio
> No need for user-facing benefits. Refactoring or improving the code in
> other useful ways are very good subjects (as I already said in my
> reply to Emily and Dscho).
Thanks!
> I think this is really great, both the idea and the description! No
> need for more details.
Thanks! I've just submi
On Mon, Sep 23, 2019 at 5:24 AM SZEDER Gábor wrote:
>
> On Sun, Sep 22, 2019 at 11:17:59PM -0400, Jeffrey Walton wrote:
> > I need to spy the command line arguments being passed around, but I
> > have not been able to do so. 'git clone -verbose' is ineffective, and
> > -vvv is rejected as an unkno
On Mon, Sep 23, 2019 at 02:47:23PM +0200, Johannes Schindelin wrote:
> Hi,
>
> On Tue, 17 Sep 2019, SZEDER Gábor wrote:
>
> > On Tue, Sep 17, 2019 at 01:23:18PM +0200, Johannes Schindelin wrote:
> > > Also, things like the code tracing via `-x` (which relies on Bash
> > > functionality in order t
On Fri, Sep 20, 2019 at 3:07 PM CB Bailey wrote:
>
> From: CB Bailey
>
> Signed-off-by: CB Bailey
> ---
> t/t4038-diff-combined.sh | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/t/t4038-diff-combined.sh b/t/t4038-diff-combined.sh
> index d4afe12554..b9d876efa2 100755
>
Hi everyone!
A draft of a new Git Rev News edition is available here:
https://github.com/git/git.github.io/blob/master/rev_news/drafts/edition-55.md
Everyone is welcome to contribute in any section either by editing the
above page on GitHub and sending a pull request, or by commenting on
this
On Mon, Sep 23, 2019 at 3:35 PM Emily Shaffer wrote:
>
> On Fri, Sep 20, 2019 at 10:04:48AM -0700, Jonathan Tan wrote:
>
> > I'm new to Outreachy and programs like this, so does anyone have an
> > opinion on my draft proposal below? It does not have any immediate
> > user-facing benefit, but it do
On 9/19/2019 10:23 AM, Derrick Stolee wrote:
> Here is today's test coverage report.
And I took a close look at the report, looking for interesting cases
that are not covered. Most of the uncovered lines were due to simple
refactors or error conditions. I point out a few below that took a
bit of d
Hi,
On Tue, 17 Sep 2019, Christian Couder wrote:
> On Tue, Sep 17, 2019 at 1:28 PM Johannes Schindelin
> wrote:
> > On Mon, 16 Sep 2019, Emily Shaffer wrote:
> >
> > > - reduce/eliminate use of fetch_if_missing global
>
> I like this one!
It looks as if a (non-Outreachy) contributor also does
Hi,
On Tue, 17 Sep 2019, SZEDER Gábor wrote:
> On Tue, Sep 17, 2019 at 01:23:18PM +0200, Johannes Schindelin wrote:
> > Also, things like the code tracing via `-x` (which relies on Bash
> > functionality in order to work properly,
>
> Not really.
To work properly. What I meant was the trick we n
On 9/19/2019 12:30 PM, Derrick Stolee wrote:
> During the Virtual Git Contributors' Summit, Dscho brought up the topic of
> "Inclusion & Diversity". We discussed ideas for how to make the community
> more welcoming to new contributors of all kinds. Let's discuss some of
> the ideas we talked about,
On Mon, Sep 23, 2019 at 10:53 AM Jonathan Tan wrote:
>
> > Prospective mentors need to sign up on that site, and should propose a
> > project they'd be willing to mentor.
Yeah, you are very welcome to sign up soon if you haven't already done
so as I think the deadline is really soon.
> > I'm hap
On Sat, Sep 21, 2019 at 11:11:28PM -0400, Taylor Blau wrote:
> Hi ZJ,
>
> On Tue, Sep 17, 2019 at 03:31:34PM +0200, Zeger-Jan van de Weg wrote:
> > When adding or updating configuration values using git-config, the
> > values could all be observed by different processes as these are passed
> > as
On Montag, 9. September 2019 16:25:12 CEST Jeff King wrote:
> On Mon, Sep 09, 2019 at 09:05:45AM -0500, Eric Blake wrote:
> > > But as you can already read from the manual, the overall behaviour of
> > > git
> > > regarding a separate "From:" line in the email body was intended solely
> > > for
> >
Hello,
I am trying to add a file to an arbitrary branch without touching the current
worktree with as little overhead as possible.
For this, the sparse-checkout feature in conjuntion with the "shared
repository" feature seems to be perfect.
The basic idea goes like this:
TMP=`mktemp -d /var
Commit 1/2: t0028: fix test for UTF-16-LE-BOM Commit 2/2: t0028: add more
tests Please refer to individual commit messages for more information.
Alexandr Miloslavskiy (2):
t0028: fix test for UTF-16-LE-BOM
t0028: add more tests
t/t0028-working-tree-encoding.sh | 41 ++
From: Alexandr Miloslavskiy
After I discovered that UTF-16-LE-BOM test was bugged and still
succeeded, I decided that better tests are required. Possibly the best
option here is to compare git results against hardcoded ground truth.
The new tests also cover more interesting chars where (ANSI !=
From: Alexandr Miloslavskiy
According to its name, the test is designed for UTF-16-LE-BOM.
However, possibly due to copy&paste oversight, it was using UTF-32 file.
While the test succeeds (probably interprets extra \x00\x00 as embedded
zero), I myself had an unrelated problem which caused the te
--
Hello dear
how are you?
my name is Edith Brown
i am a U.S military woman
is my pleasure meeting you here
best regards
In some cases, the svn author names might contain leading or trailing
whitespaces, leading to messages such as:
Author: user1
not defined in authors.txt
(the trailing newline leads to the line break). The user "user1" is
defined in authors.txt though, e.g.
user1 = User
Fix this by trimm
Hi Taylor and ZJ
On 22/09/2019 04:11, Taylor Blau wrote:
Hi ZJ,
On Tue, Sep 17, 2019 at 03:31:34PM +0200, Zeger-Jan van de Weg wrote:
When adding or updating configuration values using git-config, the
values could all be observed by different processes as these are passed
as arguments. In some
Hi
On 09/09/2019 15:13, Johannes Schindelin wrote:
Hi,
On Mon, 9 Sep 2019, Phillip Wood wrote:
On 08/09/2019 00:44, Warren He wrote:
Everyone in this thread, thanks for your support and encouragement.
[...]
It should not really imply `--interactive`, but `--rebase-merges`.
`imply_interact
On 23/09/2019 09:37, SZEDER Gábor wrote:
On Sun, Sep 22, 2019 at 11:01:26PM +0200, Johannes Sixt wrote:
Am 22.09.19 um 21:53 schrieb SZEDER Gábor:
On Sun, Sep 22, 2019 at 07:57:36PM +0100, Phillip Wood wrote:
On 22/09/2019 19:01, SZEDER Gábor wrote:
+/*
+ * One day. See the 'name a rev close
On Sun, Sep 22, 2019 at 11:17:59PM -0400, Jeffrey Walton wrote:
> I need to spy the command line arguments being passed around, but I
> have not been able to do so. 'git clone -verbose' is ineffective, and
> -vvv is rejected as an unknown option.
>
> How do I see command line arguments passed to t
On Mon, Sep 23, 2019 at 01:42:30AM +, brian m. carlson wrote:
> On 2019-09-22 at 18:01:43, SZEDER Gábor wrote:
> > diff --git a/builtin/name-rev.c b/builtin/name-rev.c
> > index c785fe16ba..a4d8d312ab 100644
> > --- a/builtin/name-rev.c
> > +++ b/builtin/name-rev.c
> > @@ -9,7 +9,11 @@
> > #in
On Sun, Sep 22, 2019 at 11:01:26PM +0200, Johannes Sixt wrote:
> Am 22.09.19 um 21:53 schrieb SZEDER Gábor:
> > On Sun, Sep 22, 2019 at 07:57:36PM +0100, Phillip Wood wrote:
> >> On 22/09/2019 19:01, SZEDER Gábor wrote:
> >>> +/*
> >>> + * One day. See the 'name a rev close to epoch' test in t6120
Commit 1/2: t0028: fix test for UTF-16-LE-BOM Commit 2/2: t0028: add more
tests Please refer to individual commit messages for more information.
Alexandr Miloslavskiy (2):
t0028: fix test for UTF-16-LE-BOM
t0028: add more tests
t/t0028-working-tree-encoding.sh | 41 ++
From: Alexandr Miloslavskiy
According to its name, the test its designed for UTF-16-LE-BOM.
However, possibly due to copy&paste oversight, it was using UTF-32 file.
While the test succeeds (probably interprets extra \x00\x00 as embedded
zero), I myself had an unrelated problem which caused the t
From: Alexandr Miloslavskiy
After I discovered that UTF-16-LE-BOM test was bugged and still
succeeded, I decided that better tests are required. Possibly the best
option here is to compare git results against hardcoded ground truth.
The new tests also cover more interesting chars where (ANSI !=
From: Alexandr Miloslavskiy
Even though Debug configuration builds, the resulting build is incorrect
in a subtle way: it mixes up Debug and Release binaries, which in turn
causes hard-to-predict bugs.
In my case, when git calls iconv library, iconv sets 'errno' and git
then tests it, but in Debu
Even though Debug configuration builds, the resulting build is incorrect in
a subtle way: it mixes up Debug and Release binaries, which in turn causes
hard-to-predict bugs.
In my case, when git calls iconv library, iconv sets 'errno' and git then
tests it, but in Debug and Release CRT those 'errno
Hi git contributors!
I'm Kunal Tyagi. While I was choosing the relevant patches for a commit
using the git add -p command, I found that there was no feedback regarding
how many hunks from the current file had been processed and how many were
left. So I decided to add a small change to the prompt w
From: Kunal Tyagi
Signed-off-by: Kunal Tyagi
---
git-add--interactive.perl | 2 +-
t/t3701-add-interactive.sh | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index c20ae9e210..3951c25a28 100755
--- a/git-add--interact
88 matches
Mail list logo
