It is not unusual for multiple distinct versions of Git to act on a
single repository. For example, some IDEs bundle a particular version
of Git, which can be a different version from the system copy of Git,
or on a Mac, /usr/bin/git quickly goes out of sync with the Homebrew
git in
If a user explicitly sets
[index]
threads = true
to read the index using multiple threads, ensure that index writes
include the offset table by default to make that possible. This
ensures that the user's intent of turning on threading is respected.
In other words,
"Derrick Stolee via GitGitGadget" writes:
> @@ -3143,6 +3144,9 @@ int prepare_revision_walk(struct rev_info *revs)
> commit_list_sort_by_date(>commits);
> if (revs->no_walk)
> return 0;
> + if (revs->limited &&
> + git_env_bool(GIT_TEST_COMMIT_GRAPH,
Documentation/technical/index-format explains:
4-byte extension signature. If the first byte is 'A'..'Z' the
extension is optional and can be ignored.
This allows gracefully introducing a new index extension without
having to rely on all readers having support for it. Mandatory
As with EOIE, popular versions of Git do not support the new IEOT
extension yet. When accessing a Git repository written by a more
modern version of Git, they correctly ignore the unrecognized section,
but in the process they loudly warn
ignoring IEOT extension
resulting in confusion
Since 3b1d9e04 (eoie: add End of Index Entry (EOIE) extension,
2018-10-10) Git defaults to writing the new EOIE section when writing
out an index file. Usually that is a good thing because it improves
threaded performance, but when a Git repository is shared with older
versions of Git, it
Junio C Hamano wrote:
> Ben Peart writes:
>> Why introduce a new setting to disable writing the IEOT extension
>> instead of just using the existing index.threads setting?
>
> But index.threads is about what the reader does, not about the
> writer who does not even know who will be reading the
Anders Waldenborg writes:
> + followed by a colon and zero or more comma-separated options:
> + ** 'only': omit non-trailer lines from the trailer block.
> + ** 'unfold': make it behave as if interpret-trailer's `--unfold`
> + option was given.
> + ** 'key=': only show trailers with
Anders Waldenborg writes:
> + followed by a colon and zero or more comma-separated options:
> + ** 'only': omit non-trailer lines from the trailer block.
> + ** 'unfold': make it behave as if interpret-trailer's `--unfold`
> + option was given.
> + ** 'key=': only show trailers with
On Sun, Nov 11, 2018 at 03:17:50PM +0200, Orgad Shaneh wrote:
> Hi,
>
> I found 2 bugs in grep, using Git for Windows 2.19.1 (but noticed
> these several versions ago):
>
> 1. git grep --recursive on a worktree (without rev) always matches
> against the submodule's HEAD, not its worktree, as it
On Tue, Nov 20, 2018 at 06:04:54AM +0100, tbo...@web.de wrote:
> From: Torsten Bögershausen
>
> Currently the length of data which is stored in memory is stored
> in "unsigned long" at many places in the code base.
> This is OK when both "unsigned long" and size_t are 32 bits,
> (and is OK when
From: Torsten Bögershausen
Currently the length of data which is stored in memory is stored
in "unsigned long" at many places in the code base.
This is OK when both "unsigned long" and size_t are 32 bits,
(and is OK when both are 64 bits).
On a 64 bit Windows system am "unsigned long" is 32 bit,
From: Torsten Bögershausen
Currently the length of data which is stored in memory is stored
in "unsigned long" at many places in the code base.
This is OK when both "unsigned long" and size_t are 32 bits,
(and is OK when both are 64 bits).
On a 64 bit Windows system am "unsigned long" is 32 bit,
Ævar Arnfjörð Bjarmason writes:
> I don't have time to poke at this now, but wonder if:
>
> 1) The correction facility shouldn't at least have a list of "this does
> stuff over the wire" commands and would then use a more conservative
> estimate.
Not limited to 'over the wire' but 'can
Duy Nguyen writes:
>> > I see this at the same level as "Switched to branch 'foo'" which is
>> > also protected by opts->quiet. If we start hiding messages based on
>> > tty it should be done for other messages in update_refs_for_switch()
>> > too, I guess?
>
> No let's drop this for now. I
Hi,
Git v2.20.0-rc0 has been released, and it's time to start new round of git l10n.
This time there are 254 updated messages need to be translated since last
update:
l10n: git.pot: v2.20.0 round 1 (254 new, 27 removed)
Generate po/git.pot from v2.20.0-rc0-23-gbb75be6cb9 for git v2.20.0
Duy Nguyen writes:
>
> - for (i = 0; i < state->istate->cache_nr; i++) {
> + for (i = 0; i < trust_ino && state->istate->cache_nr; i++) {
There is some typo here, but modulo that this looks like the right
thing to do.
> @@ -419,10 +419,24 @@ static void mark_colliding_entries(const
Sven Strickroth writes:
> This also removes an implicit conversion from size_t (unsigned) to int
> (signed).
>
> _stricmp as well as _strnicmp are both available since VS2012.
>
> Signed-off-by: Sven Strickroth
> ---
> compat/msvc.h | 8 +---
> 1 file changed, 1 insertion(+), 7
Torsten Bögershausen writes:
> The only problematic system is Win64, where "unsigned long" is 32 bit,
> and therefore we must use size_t to address data in memory.
> This is not to be confused with off_t, which is used for "data on disk"
> (and nothing else) or timestamp_t which is used for
Ævar Arnfjörð Bjarmason wrote:
> On Thu, Nov 15 2018, sxe...@google.com wrote:
>> +Parent-type
>> +---
>> +The “parent-type” field in the commit header identifies a commit as a
>> +meta-commit and indicates the meaning for each of its parents. It is never
>> +present for normal commits.
Hi,
Stefan Xenos wrote:
> But since several comments have focused on the commands, let's brainstorm!
>
> Here's some options that occur to me:
>
> 1. Three commands: evolve + change + obslog as top-level commands (the
> current proposal). Change gets a bunch of subcommands for manipulating
> the
ok 99 - colliding file detection
as well in macOS with APFS
Carlo
Stefan Xenos writes:
>> But it is not immediately obvious to me how it would help to have
>> "Z was cherry-picked from W" in "evolve".
>
> The evolve command would use it for handling the
> obsolescence-over-cherry-pick (OOCP) feature. If someone cherry-picks
> a commit and then amends the
On Sun, Nov 18, 2018 at 11:21 PM Torsten Bögershausen wrote:
> If nothing works,
> it may help to add some fprintf(stderr,...) in the functions used
> by 05b458c104708141d2f:
>
> strip_last_component(),
> get_next_component()
> real_path_internal()
I didnt see any "real_path_internal" in the
On 19/11/2018 23:29, Ramsay Jones wrote:
>
>
> On 19/11/2018 21:03, Duy Nguyen wrote:
>> First of all, Ramsay, it would be great if you could test the below
>> patch and see if it works on Cygwin. I assume since Cygwin shares the
>> underlying filesystem, it will share the same "no trusting
On Mon, Nov 19, 2018 at 02:44:32PM -0500, Jeff King wrote:
> On Mon, Nov 19, 2018 at 02:13:26PM +0100, SZEDER Gábor wrote:
>
> > Send these "bug in the test script" error messages directly to the
> > test scripts standard error and thus to the terminal, so those bugs
> > will be much harder to
On 19/11/2018 21:03, Duy Nguyen wrote:
> First of all, Ramsay, it would be great if you could test the below
> patch and see if it works on Cygwin. I assume since Cygwin shares the
> underlying filesystem, it will share the same "no trusting inode"
> issue with native builds (or it calculates
On Mon, Nov 19, 2018 at 08:23:00PM +, Ævar Arnfjörð Bjarmason wrote:
> Amend the progress output added in 7b0f229222 ("commit-graph write:
> add progress output", 2018-09-17) so that the total numbers it reports
> aren't higher than the total number of commits anymore. See [1] for a
> bug
On Mon, Nov 19, 2018 at 11:26:03PM +0200, Max Kirillov wrote:
> On Mon, Nov 19, 2018 at 11:36:08AM -0800, Carlo Arenas wrote:
> > NO_CURL reflects the build setting (for http support); CURL checks for
> > the curl binary, but as Ævar points out the requirements must be from
> > somewhere else
On Mon, Nov 19 2018, Derrick Stolee wrote:
> On 11/19/2018 1:33 PM, Ævar Arnfjörð Bjarmason wrote:
>> On Mon, Nov 19 2018, Derrick Stolee wrote:
>>
>>> [...]
>>> builtin/rebase.c
>>> 62c23938fa 55) return env;
>>> [...]
>>> Ævar Arnfjörð Bjarmason 62c23938f: tests: add a special setup
>>> where
On Mon, Nov 19, 2018 at 11:36:08AM -0800, Carlo Arenas wrote:
> NO_CURL reflects the build setting (for http support); CURL checks for
> the curl binary, but as Ævar points out the requirements must be from
> somewhere else since a NO_CURL=1 build (tested in macOS) still passes
> the test, but not
> Subcommand names and --long-options are just as descriptive.
Yeah, I'm convinced about the descriptiveness. If you check the latest
version of the patch, I've already updated the "change" command to use
subcommands rather than lettered arguments.
> If a user wants to deal with reflogs, then
On 11/19/2018 1:33 PM, Ævar Arnfjörð Bjarmason wrote:
On Mon, Nov 19 2018, Derrick Stolee wrote:
[...]
builtin/rebase.c
62c23938fa 55) return env;
[...]
Ævar Arnfjörð Bjarmason 62c23938f: tests: add a special setup
where rebase.useBuiltin is off
This one would be covered with
On Mon, Nov 19, 2018 at 10:03 PM Duy Nguyen wrote:
> Thanks Carlo for the file and "stat" output. The problem is APFS has
> 64-bit inode (according to the Internet) while we store inodes as
> 32-bit, so it's truncated.
> ...
> We will have to deal with the same
> truncated inode elsewhere to make
On 11/19/2018 2:00 PM, Ben Peart wrote:
On 11/19/2018 10:40 AM, Derrick Stolee wrote:
There are a lot of lines introduced by the IEOT extension in these
commits:
> Ben Peart 3255089ad: ieot: add Index Entry Offset Table
(IEOT) extension
> Ben Peart 3b1d9e045: eoie: add End of
... and I "dear Ramsay" without CCing him.. sigh.. sorry for the noise.
On Mon, Nov 19, 2018 at 10:03 PM Duy Nguyen wrote:
>
> First of all, Ramsay, it would be great if you could test the below
> patch and see if it works on Cygwin. I assume since Cygwin shares the
> underlying filesystem, it
First of all, Ramsay, it would be great if you could test the below
patch and see if it works on Cygwin. I assume since Cygwin shares the
underlying filesystem, it will share the same "no trusting inode"
issue with native builds (or it calculates inodes anyway using some
other source?).
Back to
On Mon, Nov 19 2018, Jonathan Nieder wrote:
> Ævar Arnfjörð Bjarmason wrote:
>> On Mon, Nov 19 2018, Derrick Stolee wrote:
>
>>> [...]
>>> builtin/rebase.c
>>> 62c23938fa 55) return env;
>>> [...]
>>> Ævar Arnfjörð Bjarmason 62c23938f: tests: add a special setup
>>> where rebase.useBuiltin is
On 11/19/2018 3:23 PM, Ævar Arnfjörð Bjarmason wrote:
+ if (report_progress)
+ progress = start_delayed_progress(
+ _("Expanding reachable commits in commit graph"), j =
0);
This should be the only one that shows up in all but the very largest of
Replying to this blast from the past:
https://public-inbox.org/git/1290787239-4508-1-git-send-email-kusmab...@gmail.com/
I apparently like to live dangerously and have help.autoCorrect
enabled. I just had:
git puss
Auto-corrected to:
git push
When I meant:
git pull
(For those
Hi,
Xenos wrote:
> Lets explore the "when" question. I think there's a compelling reason
> to add them as soon as possible - namely, gerrit. If and when we come
> to some sort of agreement on this proposal, gerrit could start adding
> tooling to understand change graphs as an alternative to
Amend the progress output added in 7b0f229222 ("commit-graph write:
add progress output", 2018-09-17) so that the total numbers it reports
aren't higher than the total number of commits anymore. See [1] for a
bug report pointing that out.
When I added this I wasn't intending to provide an
> But it is not immediately obvious to me how it would help to have "Z was
> cherry-picked from W" in "evolve".
The evolve command would use it for handling the
obsolescence-over-cherry-pick (OOCP) feature. If someone cherry-picks
a commit and then amends the original, the evolve command would
On Mon, Nov 19, 2018 at 02:28:18PM +0100, SZEDER Gábor wrote:
> The 'test_cmp_rev' helper is merely a wrapper around 'test_cmp'
> checking the output of two 'git rev-parse' commands, which means that
> its output on failure is not particularly informative, as it's
> basically two OIDs with a bit
On 11/19/2018 2:39 PM, Ævar Arnfjörð Bjarmason wrote:
On Mon, Nov 19 2018, Derrick Stolee wrote:
The coverage report has been using the following:
export GIT_TEST_MULTI_PACK_INDEX=1
export GIT_TEST_COMMIT_GRAPH=1
export GIT_TEST_INDEX_VERION=4
export GIT_TEST_SPLIT_INDEX=yes
export
On Mon, Nov 19, 2018 at 02:13:26PM +0100, SZEDER Gábor wrote:
> Send these "bug in the test script" error messages directly to the
> test scripts standard error and thus to the terminal, so those bugs
> will be much harder to overlook. Instead of updating all ~20 such
> 'error' calls with a
On Mon, Nov 19, 2018 at 9:23 AM Ramsay Jones
wrote:
> ok 99 # skip colliding file detection (missing !CYGWIN of
> !MINGW,!CYGWIN,CASE_INSENSITIVE_FS)
you need to enable this specific test first (removing !CYGWIN) so it
doesn't get skipped
Carlo
On Mon, Nov 19 2018, Derrick Stolee wrote:
> On 11/19/2018 1:33 PM, Ævar Arnfjörð Bjarmason wrote:
>> On Mon, Nov 19 2018, Derrick Stolee wrote:
>>
>>> Here is a test coverage report for the uncovered lines introduced in
>>> v2.20.0-rc0 compared to v2.19.1.
>> Thanks a lot for this.
>>
>>>
On Mon, Nov 19, 2018 at 10:40 AM Max Kirillov wrote:
>
> On Mon, Nov 19, 2018 at 02:15:35AM -0800, Carlo Marcelo Arenas Belón wrote:
> > 6c213e863a ("http-backend: respect CONTENT_LENGTH for receive-pack",
> > 2018-07-27)
> > introduced all tests but without a check for CURL support from git.
>
On 11/19/2018 1:33 PM, Ævar Arnfjörð Bjarmason wrote:
On Mon, Nov 19 2018, Derrick Stolee wrote:
Here is a test coverage report for the uncovered lines introduced in
v2.20.0-rc0 compared to v2.19.1.
Thanks a lot for this.
[...]
builtin/rebase.c
62c23938fa 55) return env;
[...]
Ævar Arnfjörð
From: Derrick Stolee
The revision-walk machinery is being rewritten to use generation
numbers in the commit-graph when availble. Due to some problematic
commit histories, the new logic can be slower than the previous
method due to how commit dates and generation numbers interact.
Thus, the new
The recent Git test report for v2.20.0-rc0 shows that the logic around
UNINTERESTING commits is not covered by the test suite. This is because the
code is currently unreachable! See the commit message for details.
An alternate approach would be to delete the code around UNINTERESTING
commits, but
On 11/19/2018 10:40 AM, Derrick Stolee wrote:
The test coverage reports started mid-way through this release cycle, so
I thought it would be good to do a full review of the new uncovered code
since the last release.
I eliminated most of the uncovered code due to the following cases:
1.
Ævar Arnfjörð Bjarmason wrote:
> On Mon, Nov 19 2018, Derrick Stolee wrote:
>> [...]
>> builtin/rebase.c
>> 62c23938fa 55) return env;
>> [...]
>> Ævar Arnfjörð Bjarmason 62c23938f: tests: add a special setup
>> where rebase.useBuiltin is off
>
> This one would be covered with
>
On Mon, Nov 19, 2018 at 02:15:35AM -0800, Carlo Marcelo Arenas Belón wrote:
> 6c213e863a ("http-backend: respect CONTENT_LENGTH for receive-pack",
> 2018-07-27)
> introduced all tests but without a check for CURL support from git.
The tests should not be using curl, they just pipe data to
On Mon, Nov 19, 2018 at 11:21:38AM -0500, Jeff King wrote:
> > + if (use_delta_islands) {
> > + const char *p;
> > + unsigned depth = 0;
> > + struct object_entry *ent;
> > +
> > + for (p = strchr(name, '/'); p; p = strchr(p + 1, '/'))
On Mon, Nov 19 2018, Derrick Stolee wrote:
> Here is a test coverage report for the uncovered lines introduced in
> v2.20.0-rc0 compared to v2.19.1.
Thanks a lot for this.
> [...]
> builtin/rebase.c
> 62c23938fa 55) return env;
> [...]
> Ævar Arnfjörð Bjarmason 62c23938f: tests: add a special
On Mon, Nov 19, 2018 at 6:14 PM Carlo Arenas wrote:
>
> On Mon, Nov 19, 2018 at 4:28 AM Torsten Bögershausen wrote:
> >
> > Did you test it on Mac ?
>
> macOS 10.14.1 but only using APFS, did you test my patch with HFS+?
>
> > So what exactly are you trying to fix ?
>
> I get
>
> not ok 99 -
Am 19.11.2018 um 06:33 schrieb Torsten Bögershausen:
> The archive-tar.c is actually a good example, why a step-by-step update
> is not ideal (the code would not work any more on Win64).
>
> If we look here:
>
> static int stream_blocked(const struct object_id *oid)
> {
> struct
On Sun, Nov 18, 2018 at 03:18:52PM -0500, Derrick Stolee wrote:
> On 11/17/2018 10:11 AM, tbo...@web.de wrote:
> >From: Torsten Bögershausen
> >
> >Currently Git users can not commit files >4Gib under 64 bit Windows,
> >where "long" is 32 bit but size_t is 64 bit.
> >Improve the code base in
On 19/11/2018 12:28, Torsten Bögershausen wrote:
> On 2018-11-19 09:20, Carlo Marcelo Arenas Belón wrote:
>> While I don't have an HFS+ volume to test, I suspect this patch should be
>> needed for both, even if I have to say thay even the broken output was
>> better than the current state.
>>
On Mon, Nov 19, 2018 at 4:28 AM Torsten Bögershausen wrote:
>
> Did you test it on Mac ?
macOS 10.14.1 but only using APFS, did you test my patch with HFS+?
> So what exactly are you trying to fix ?
I get
not ok 99 - colliding file detection
#
# grep X icasefs/warning &&
# grep x
On Mon, Nov 19, 2018 at 10:40:53AM -0500, Derrick Stolee wrote:
> > 2fa233a554 builtin/pack-objects.c 1512) hashcpy(base_oid.hash,
> > base_sha1);
> > 2fa233a554 builtin/pack-objects.c 1513) if
> > (!in_same_island(>idx.oid, _oid))
> > 2fa233a554 builtin/pack-objects.c 1514) return 0;
>
> These
Ping?
We are at -rc0, this progress output is a new feature since v2.19.0,
and the numbers shown are still way off.
On Mon, Oct 15, 2018 at 06:54:47PM +0200, SZEDER Gábor wrote:
> On Mon, Sep 17, 2018 at 03:33:35PM +, Ævar Arnfjörð Bjarmason wrote:
>
> > @@ -560,6 +563,9 @@ static int
On Sat, Nov 17, 2018 at 12:30:58PM -0800, Stefan Xenos wrote:
> > Further, I see that this document tries to suggest a proliferation of new
> > commands
>
> It does. Let me explain a bit about the reasoning behind this
> breakdown of commands. My main priority was to keep the commands as
>
The test coverage reports started mid-way through this release cycle, so
I thought it would be good to do a full review of the new uncovered code
since the last release.
I eliminated most of the uncovered code due to the following cases:
1. Code was only moved or refactored.
2. Code was
On Sun, Nov 18, 2018 at 8:58 PM Ævar Arnfjörð Bjarmason
wrote:
>
>
> On Sun, Nov 18 2018, Nguyễn Thái Ngọc Duy wrote:
>
> As noted in
> https://public-inbox.org/git/87d0r217vr@evledraar.gmail.com/ I'm
> happy to see this implemented. I have not read this patch in much
> detail...
>
> > [...]
On Mon, Nov 19, 2018 at 12:42 PM Ævar Arnfjörð Bjarmason
wrote:
>
>
> On Sun, Nov 18 2018, Nguyễn Thái Ngọc Duy wrote:
>
> > When :(attr) was added, it supported one of the two main pathspec
> > matching functions, the one that works on a list of paths. The other
> > one works on a tree,
On Mon, Nov 19, 2018 at 12:16 PM Ævar Arnfjörð Bjarmason
wrote:
> As an aside, how do you do the inverse of matching for an attribute by
> value? I.e.:
>
> $ git ls-files | wc -l; git ls-files ':(attr:diff=perl)' | wc -l
> 3522
> 65
>
> I'd like something gives me all files that don't
On Mon, Nov 19, 2018 at 2:08 PM Ævar Arnfjörð Bjarmason
wrote:
>
>
> On Mon, Nov 12 2018, Duy Nguyen wrote:
>
> > On Mon, Nov 12, 2018 at 7:21 AM Junio C Hamano wrote:
> >>
> >> Nguyễn Thái Ngọc Duy writes:
> >>
> >> > Since the purpose of printing this is to help disambiguate. Only do it
> >>
This also removes an implicit conversion from size_t (unsigned) to int (signed).
_stricmp as well as _strnicmp are both available since VS2012.
Signed-off-by: Sven Strickroth
---
compat/msvc.h | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/compat/msvc.h
Hi all!
We're observing a strange behavior of git describe. We have a local fork of an
open-source github.com/openbmc/openbmc repository. The local fork has some
extra commits and we merge from upstream on a regular basis. Until today it all
worked fine, the last merge was from upstream commit
On Mon, Nov 19, 2018 at 02:28:18PM +0100, SZEDER Gábor wrote:
> diff --git a/t/test-lib-functions.sh b/t/test-lib-functions.sh
> index d158c8d0bf..fc84db67a1 100644
> --- a/t/test-lib-functions.sh
> +++ b/t/test-lib-functions.sh
> @@ -854,9 +854,23 @@ test_must_be_empty () {
>
> # Tests that
The 'test_cmp_rev' helper is merely a wrapper around 'test_cmp'
checking the output of two 'git rev-parse' commands, which means that
its output on failure is not particularly informative, as it's
basically two OIDs with a bit of extra clutter of the diff header, but
without any indication of
Some of the functions in our test library check that they were invoked
properly with conditions like this:
test "$#" = 2 ||
error "bug in the test script: not 2 parameters to test-expect-success"
If this particular condition is triggered, then 'error' will abort the
whole test script with a
On Mon, Nov 12 2018, Duy Nguyen wrote:
> On Mon, Nov 12, 2018 at 7:21 AM Junio C Hamano wrote:
>>
>> Nguyễn Thái Ngọc Duy writes:
>>
>> > Since the purpose of printing this is to help disambiguate. Only do it
>> > when "--" is missing (the actual reason though is many tests check
>> > empty
On Wed, Nov 14 2018, Johannes Schindelin via GitGitGadget wrote:
> From: Johannes Schindelin
>
> It is a good idea to error out early upon seeing, say, `-Cbad`, rather
> than starting the rebase only to have the `--am` backend complain later.
>
> Let's do this.
>
> The only options accepting
On 2018-11-19 09:20, Carlo Marcelo Arenas Belón wrote:
> While I don't have an HFS+ volume to test, I suspect this patch should be
> needed for both, even if I have to say thay even the broken output was
> better than the current state.
>
> Travis seems to be using a case sensitive filesystem so
On Sun, Nov 18, 2018 at 08:51:52PM +0100, Ævar Arnfjörð Bjarmason wrote:
> > But this also reveals an interesting thing: even though we walk on a
> > tree, we check attributes from _worktree_ (and optionally fall back to
> > the index). This is how attributes are implemented since forever. I
> >
On Mon, Nov 19 2018, Mgr Georg Black wrote:
> Hello everyone,
> We have source codes in many files of 20 years development. It's approx
> 800mb. There are many programs. Every has about 100-200 modules.
> Company has 40 developers. They all works via terminal on aix.
> At this time we have
On Sun, Nov 18 2018, Nguyễn Thái Ngọc Duy wrote:
> When :(attr) was added, it supported one of the two main pathspec
> matching functions, the one that works on a list of paths. The other
> one works on a tree, tree_entry_interesting(), which gets :(attr)
> support in this series.
>
> With
Hello everyone,
We have source codes in many files of 20 years development. It's approx 800mb.
There are many programs. Every has about 100-200 modules.
Company has 40 developers. They all works via terminal on aix.
At this time we have three folders for three versions. Everybody send changes
to
On Sun, Nov 18 2018, Ævar Arnfjörð Bjarmason wrote:
> On Sun, Nov 18 2018, Nguyễn Thái Ngọc Duy wrote:
>
>> When :(attr) was added, it supported one of the two main pathspec
>> matching functions, the one that works on a list of paths. The other
>> one works on a tree, tree_entry_interesting(),
On Mon, Nov 19 2018, Carlo Marcelo Arenas Belón wrote:
> 6c213e863a ("http-backend: respect CONTENT_LENGTH for receive-pack",
> 2018-07-27)
> introduced all tests but without a check for CURL support from git.
>
> Signed-off-by: Carlo Marcelo Arenas Belón
> ---
>
On Tue, Nov 13, 2018 at 06:04:15PM -0500, _g e r r y _ _l o w r y _ wrote:
> Examples:
>
> {me, extreme often, Windows} very granular, with a brief yet appropriate
> comment [like narrating a story] per commit-i change a few
> lines of code,
> Alt+Tab to Git Bash, Git Add/Commit,
> Alt+Tab
6c213e863a ("http-backend: respect CONTENT_LENGTH for receive-pack", 2018-07-27)
introduced all tests but without a check for CURL support from git.
Signed-off-by: Carlo Marcelo Arenas Belón
---
t/t5562-http-backend-content-length.sh | 6 ++
1 file changed, 6 insertions(+)
diff --git
Hi,
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-45.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 GitHub
While I don't have an HFS+ volume to test, I suspect this patch should be
needed for both, even if I have to say thay even the broken output was
better than the current state.
Travis seems to be using a case sensitive filesystem so wouldn't catch this.
Was windows/cygwin tested?
Carlo
-- >8 --
88 matches
Mail list logo
