On Mon, Sep 17, 2018 at 4:43 PM Eric Sunshine wrote:
> I did consider this case and felt that it would be reasonable for it
> to error out and ignore the error if git was missing or if the
> directory was not a repository. And, I _thought_ I had prefixed the
> line with "-" to handle just such a
On 09/17, Junio C Hamano wrote:
> Thomas Gummerer writes:
>
> > In t5551 we check that we save cookies correctly to a file when
> > http.cookiefile and http.savecookies are set. To do so we create an
> > expect file that expects the cookies in a certain order.
> >
> > However after e2ef8d6fa
Thomas Gummerer wrote:
> On 09/17, Junio C Hamano wrote:
>> The other
>> effort implicitly depends on the expected output is kept sorted, but
>> this one is more explicit---I tend to prefer this approach as tools
>> and automation is easier
Duy Nguyen writes:
>> diff --git a/read-cache.c b/read-cache.c
>> index 858935f123..b203eebb44 100644
>> --- a/read-cache.c
>> +++ b/read-cache.c
>> @@ -23,6 +23,10 @@
>> #include "split-index.h"
>> #include "utf8.h"
>> #include "fsmonitor.h"
>> +#ifndef NO_PTHREADS
>> +#include
>> +#include
On Mon, Sep 17, 2018 at 3:36 PM Junio C Hamano wrote:
> Jonathan Nieder writes:
> >> +'$(SHELL_PATH_SQ)' ./doc-diff --clean
> >
> > This means I need a copy of git in order to run "make clean". That
> > was never required before. It makes bootstrapping difficult --- do we
> > really need
Helped-by: Junio C Hamano
Signed-off-by: Stefan Beller
---
sha1-array.c | 17 +
sha1-array.h | 9 +
2 files changed, 26 insertions(+)
diff --git a/sha1-array.c b/sha1-array.c
index 265941fbf40..67db5eeec9a 100644
--- a/sha1-array.c
+++ b/sha1-array.c
@@ -77,3 +77,20 @@
v2:
* extended commit messages,
* plugged a memory leak
* rewrote the patch "sha1-array: provide oid_array_filter" to be much more like
object_array_fiter
* fixed a typo pointed out by Ramsay.
The range diff is below.
Thanks,
Stefan
v1:
Currently when git-fetch is asked to recurse into
The submodule subsystem is really bad at staying within 80 characters.
Fix it while we are here.
Signed-off-by: Stefan Beller
---
submodule.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/submodule.c b/submodule.c
index a2b266fbfae..d29dfa3d1f5 100644
---
We can string_list_insert() to maintain sorted-ness of the
list as we find new items, or we can string_list_append() to
build an unsorted list and sort it at the end just once.
To pick which one is more appropriate, we notice the fact
that we discover new items more or less in the already
sorted
Add a few functions to allow a string-list to be used as a stack:
- string_list_last() lets a caller peek the string_list_item at the
end of the string list. The caller needs to be aware that it is
borrowing a pointer, which can become invalid if/when the
string_list is resized.
-
This patch started as a refactoring to make 'get_next_submodule' more
readable, but upon doing so, I realized that "git fetch" of the submodule
actually doesn't need to be run in the submodules worktree. So let's run
it in its git dir instead.
That should pave the way towards fetching submodules
'calculate_changed_submodule_paths' uses a local list to compute the
changed submodules, and then produces the result by copying appropriate
items into the result list.
Instead use the result list directly and prune items afterwards
using string_list_remove_empty_items.
By doing so we'll have
Currently when git-fetch is asked to recurse into submodules, it dispatches
a plain "git-fetch -C " (with some submodule related options
such as prefix and recusing strategy, but) without any information of the
remote or the tip that should be fetched.
This works surprisingly well in some
The `changed_submodule_names` are only used for fetching, so let's make it
part of the struct that is passed around for fetching submodules.
Signed-off-by: Stefan Beller
---
submodule.c | 42 +++---
1 file changed, 23 insertions(+), 19 deletions(-)
diff
Gerrit, the code review tool, has a different workflow than our mailing
list based approach. Usually users upload changes to a Gerrit server and
continuous integration and testing happens by bots. Sometimes however a
user wants to checkout a change locally and look at it locally. For this
use
In t5551 we check that we save cookies correctly to a file when
http.cookiefile and http.savecookies are set. To do so we create an
expect file that expects the cookies in a certain order.
However after e2ef8d6fa ("cookies: support creation-time attribute for
cookies", 2018-08-28) in curl.git
Hi All,
Does anyone know whether it is practical to rework git-lfs under a language
other than "go"? GCC is not even close to being possible to port to my
NonStop platform (may have tried, some have died - joke - trying). I would
like to convert this directly to C or something more widely
Hi,
Randall S. Becker wrote:
> Does anyone know whether it is practical to rework git-lfs under a language
> other than "go"? GCC is not even close to being possible to port to my
> NonStop platform (may have tried, some have died - joke - trying). I would
> like to convert this directly to C
Junio C Hamano wrote:
> Jonathan Nieder writes:
>> Eric Sunshine wrote:
>>> + '$(SHELL_PATH_SQ)' ./doc-diff --clean
>>
>> This means I need a copy of git in order to run "make clean". That
>> was never required before. It makes bootstrapping difficult --- do we
>> really need it?
>
> Gahh,
Jonathan Nieder writes:
> I'd rather that we revert this change altogether. I have nothing
> against a convenient command to do this kind of non build related
> cleanup, but it shouldn't be spelled as "make clean".
OK, let's do this for now as I wanted to merge the remainder to
'master' today.
On 9/14/2018 7:26 PM, Ramsay Jones wrote:
Signed-off-by: Ramsay Jones
---
Hi Derrick,
If you need to re-roll your 'ds/multi-pack-verify' branch, could you
please squash this into the relevant patch (commit 64cbf3df21,
"multi-pack-index: add 'verify' verb", 2018-09-13).
[noticed by sparse].
Please try the following:
mmatrosov@Mikhail-PC:~/test$ git init --bare server
Initialized empty Git repository in /home/mmatrosov/test/server/
mmatrosov@Mikhail-PC:~/test$ git clone server local
Cloning into 'local'...
warning: You appear to have cloned an empty repository.
done.
Derrick Stolee writes:
>> Replaced with a newer version.
>
> I think this has been the same note for a few weeks now. What does it
> mean? Did I send a new version out that you haven't picked up?
It just means that I didn't bother to look at the current status
message for the topic that had
Duy Nguyen writes:
> I get annoyed by the "ignoring unknown extension xxx" messages while
> testing though (not just this extension) and I think it will be the
> same for other git implementations. But perhaps other implementations
> just silently drop the extension. Most of the extensions we
Duy Nguyen writes:
> On Mon, Sep 17, 2018 at 6:25 PM Junio C Hamano wrote:
>>
>> Nguyễn Thái Ngọc Duy writes:
>>
>> > This function calls do_diff_cache() which eventually needs to set this
>> > "istate" to unpack_options->src_index (*). This is an unfortunate fact
>> > that unpack_trees()
Duy Nguyen writes:
> On Mon, Sep 17, 2018 at 7:09 PM Junio C Hamano wrote:
>> ...
>> On the other hand, if I am keeping some change that should never be
>> in a commit in the working tree file, and building the contents in
>> the index using "add -p" to incrementally, it would be the same
>>
Jonathan Nieder writes:
>> +'$(SHELL_PATH_SQ)' ./doc-diff --clean
>
> This means I need a copy of git in order to run "make clean". That
> was never required before. It makes bootstrapping difficult --- do we
> really need it?
Gahh, you are absolutely right. Also "doc-diff --clean", if I
Thomas Gummerer writes:
> In t5551 we check that we save cookies correctly to a file when
> http.cookiefile and http.savecookies are set. To do so we create an
> expect file that expects the cookies in a certain order.
>
> However after e2ef8d6fa ("cookies: support creation-time attribute for
>
Junio C Hamano wrote:
> Jonathan Nieder writes:
>> I'd rather that we revert this change altogether. I have nothing
>> against a convenient command to do this kind of non build related
>> cleanup, but it shouldn't be spelled as "make clean".
>
> OK, let's do this for now as I wanted to merge
Derrick Stolee writes:
> ds/multi-pack-verify is currently queued for 'next', so I wasn't
> planning on sending another version.
>
> Junio, could you add this commit to the tip, or squash it into
> 64cbf3df2 "multi-pack-index: add 'verify' verb"?
I think it makes sense to queue this on top.
Derrick Stolee writes:
> Thanks for catching this, Ramsay. Sorry for the mistake.
>
> ds/multi-pack-verify is currently queued for 'next', so I wasn't
> planning on sending another version.
Marked for 'next' does not mean we cannot touch it. It merely means
"so far no issue that requires a
On Mon, Sep 17, 2018 at 2:36 PM Stefan Beller wrote:
>
> Helped-by: Junio C Hamano
> Signed-off-by: Stefan Beller
> ---
> sha1-array.c | 17 +
> sha1-array.h | 9 +
> 2 files changed, 26 insertions(+)
>
> diff --git a/sha1-array.c b/sha1-array.c
> index
Jeff King writes:
> Yes, I think sorting the expect file would work fine. I'm OK with that,
> or just leaving a comment. The comment has the bonus that it does not
> cost an extra process at runtime. I'd probably use a sort if we expected
> the list to be long and complicated, since it makes
In t5551 we check that we save cookies correctly to a file when
http.cookiefile and http.savecookies are set. To do so we create an
expect file that expects the cookies in a certain order.
However after e2ef8d6fa ("cookies: support creation-time attribute for
cookies", 2018-08-28) in curl.git
Thanks Jonathan and Junio for the comments on the first round.
Changes since the first round:
- add a preparatory patch to modernize the test script
- add Reported-by to credit Todd
- just use 'sort' instead of 'cat | sort'
Thomas Gummerer (2):
t5551: move setup code inside test_expect blocks
Move setup code inside test_expect blocks, to catch unexpected
failures in the setup steps, and bring the test scripts in line with
our modern test style.
Suggested-by: Jonathan Nieder
Signed-off-by: Thomas Gummerer
---
t/t5551-http-fetch-smart.sh | 66 ++---
1
On Mon, Sep 17, 2018 at 9:31 AM Jonathan Nieder wrote:
>
> Matthew DeVore wrote:
>
> > Subject: t/*: fix pipe placement and remove \'s
> >
> > Where ever there was code in the tests like this:
> >
> > foo \
> > | bar
>
> Language nits:
> - s/Where ever/Wherever/
> - Git's
On September 17, 2018 3:28 PM, Jonathan Nieder wrote:
> Randall S. Becker wrote:
>
> > Does anyone know whether it is practical to rework git-lfs under a
> > language other than "go"? GCC is not even close to being possible to
> > port to my NonStop platform (may have tried, some have died - joke
Hi Randall,
On Mon, Sep 17, 2018 at 05:55:55PM -0400, Randall S. Becker wrote:
> On September 17, 2018 3:28 PM, Jonathan Nieder wrote:
> > Randall S. Becker wrote:
> >
> > > Does anyone know whether it is practical to rework git-lfs under a
> > > language other than "go"? GCC is not even close to
(+cc: Taylor Blau, git-lfs expert)
Randall S. Becker wrote:
> On September 17, 2018 3:28 PM, Jonathan Nieder wrote:
>> Randall S. Becker wrote:
>>> Does anyone know whether it is practical to rework git-lfs under a
>>> language other than "go"? GCC is not even close to being possible to
>>> port
On Mon, Sep 17, 2018 at 11:18:00AM -0700, Jonathan Nieder wrote:
> v2.18.0-rc0~70^2 (mailmap: update brian m. carlson's email address,
> 2018-05-08) changed the mailmap to map
>
> sand...@crustytoothpaste.ath.cx
>-> brian m. carlson
>
> instead of
>
> sand...@crustytoothpaste.net
>
On September 17, 2018 6:01 PM, Taylor Blau wrote:
> On Mon, Sep 17, 2018 at 05:55:55PM -0400, Randall S. Becker wrote:
> > On September 17, 2018 3:28 PM, Jonathan Nieder wrote:
> > > Randall S. Becker wrote:
> > >
> > > > Does anyone know whether it is practical to rework git-lfs under a
> > > >
This applies the suggestions from jrn@'s response to v1 here:
https://public-inbox.org/git/20180917163137.gb89...@aiede.svl.corp.google.com/
The major changes are:
- Added two bullet points to Documentation/CodingGuidelines about 1) how to
format pipe sequences and 2) using temporary files
---
t/Makefile | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/t/Makefile b/t/Makefile
index c83fd1886..4eceabbd5 100644
--- a/t/Makefile
+++ b/t/Makefile
@@ -78,7 +78,7 @@ check-chainlint:
done && exit $$err
test-lint: test-lint-duplicates
---
t/Makefile | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/t/Makefile b/t/Makefile
index c83fd1886..4eceabbd5 100644
--- a/t/Makefile
+++ b/t/Makefile
@@ -78,7 +78,7 @@ check-chainlint:
done && exit $$err
test-lint: test-lint-duplicates
Fix various places where the ordering was obviously wrong, meaning it
was easy to find with grep.
Signed-off-by: Matthew DeVore
---
t/t-basic.sh | 2 +-
t/t0021-conversion.sh | 4 +--
t/t1300-config.sh | 4 +--
Instead of using a line-continuation and pipe on the second line, take
advantage of the shell's implicit line continuation after a pipe
character. So for example, instead of
some long line \
| next line
use
some long line |
next line
And add a blank
Some pipes in tests lose the exit code of git processes, which can mask
unexpected behavior. Split these pipes up so that git commands are at
the end of pipes rather than the beginning or middle.
---
t/t5317-pack-objects-filter-objects.sh | 156 +
t/t5500-fetch-pack.sh
Add two guidelines:
- pipe characters should appear at the end of lines, and not cause
indentation
- pipes should be avoided when they swallow exit codes that can
potentially fail
---
Documentation/CodingGuidelines | 29 +
1 file changed, 29 insertions(+)
A test uses several separate pipe sequences in a row which are awkward
to split up. Wrap the split-up pipe in a function so the awkwardness is
not repeated.
Signed-off-by: Matthew DeVore
---
t/t9101-git-svn-props.sh | 21 +
1 file changed, 13 insertions(+), 8 deletions(-)
On Mon, Sep 17, 2018 at 02:45:55PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > Yes, I think sorting the expect file would work fine. I'm OK with that,
> > or just leaving a comment. The comment has the bonus that it does not
> > cost an extra process at runtime. I'd probably use a
Taylor Blau wrote:
> On Sun, Sep 16, 2018 at 03:05:48PM -0700, Jonathan Nieder wrote:
> > On Sun, Sep 16, 2018 at 11:17:27AM -0700, John Austin wrote:
> > > Taylor Blau wrote:
Right, though this still subjects the remote copy to all of the
difficulty of packing large objects (though
On 9/15/2018 6:22 AM, Duy Nguyen wrote:
+index.threads::
+ Specifies the number of threads to spawn when loading the index.
+ This is meant to reduce index load time on multiprocessor machines.
+ Specifying 0 or 'true' will cause Git to auto-detect the number of
+
On 17/09/18 15:15, Ben Peart wrote:
>
>
> On 9/16/2018 3:17 AM, Eric Sunshine wrote:
>> On Fri, Sep 14, 2018 at 7:29 PM Ramsay Jones
>> wrote:
>>> At one time, the POSIX standard required the type used to represent
>>> a thread handle (pthread_t) be an arithmetic type. This is no longer
>>>
Ævar Arnfjörð Bjarmason wrote:
> There's surely other aspects of that square peg of large file tracking
> not fitting the round hole of file locking, the point of my write-up was
> not that *that* solution is perfect, but there's prior art here that's
> very easily adopted to distributed locking
Antonio Ospite writes:
> I did send a v4 addressing this:
> https://public-inbox.org/git/20180824132951.8000-1-...@ao2.it/
>
> In case you missed it I might as well send a v5 with some minor
> cosmetic touches suggested by Ævar:
> https://public-inbox.org/git/87wosfesxl@evledraar.gmail.com/
"brian m. carlson" writes:
> On Fri, Sep 14, 2018 at 02:56:36PM -0700, Junio C Hamano wrote:
>> * bc/hash-independent-tests (2018-09-13) 12 commits
>> - t5318: use test_oid for HASH_LEN
>> - t1407: make hash size independent
>> - t1406: make hash-size independent
>> - t1405: make hash size
On Mon, Sep 17, 2018 at 05:00:10PM +0200, Ævar Arnfjörð Bjarmason wrote:
> > 2. Multi-file locks, e.g., "I need to lock file(s) X, Y, and Z
> > together." This isn't possible in Git LFS today with the existing "git
> > lfs lock" command (I had to check, but it takes only _one_ filename
On Mon, Sep 17, 2018 at 4:55 PM Ben Peart wrote:
> On 9/15/2018 6:02 AM, Duy Nguyen wrote:
>
> >> default:
> >> if (*ext < 'A' || 'Z' < *ext)
> >> return error("index uses %.4s extension, which we
> >> do not understand",
> >> @@ -1889,6
On 9/15/2018 6:24 AM, Duy Nguyen wrote:
On Sat, Sep 15, 2018 at 12:22 PM Duy Nguyen wrote:
@@ -1944,6 +1993,26 @@ int do_read_index(struct index_state *istate, const char
*path, int must_exist)
istate->cache = xcalloc(istate->cache_alloc, sizeof(*istate->cache));
David Aguilar writes:
> While I do see the utility, it would be just as easy to configure a 2nd
> and 3rd variant of the same difftool and use those as needed instead.
>
> "git difftool -t ccdiff2" or "-t ccdiff3" is the simplest, and there's
> nothing stopping the user from creating aliases to
On 17/09/18 17:27, Ramsay Jones wrote:
>
>
> On 17/09/18 15:15, Ben Peart wrote:
>>
>>
>> On 9/16/2018 3:17 AM, Eric Sunshine wrote:
>>> On Fri, Sep 14, 2018 at 7:29 PM Ramsay Jones
>>> wrote:
At one time, the POSIX standard required the type used to represent
a thread handle
On Mon, Sep 17 2018, Taylor Blau wrote:
> On Sun, Sep 16, 2018 at 04:55:13PM +0200, Ævar Arnfjörð Bjarmason wrote:
>> In the hypothetical git-annex-like case (simplifying a bit for the
>> purposes this explanation), for every FILE in your tree you have a
>> corresponding FILE.lock file, but
Before this change the "commit-graph write" command didn't report any
progress. On my machine this command takes more than 10 seconds to
write the graph for linux.git, and around 1m30s on the
2015-04-03-1M-git.git[1] test repository (a test case for a large
monorepository).
Furthermore, since the
Micro change since v2: Missing _() in 2/2 pointed out by Duy.
Ævar Arnfjörð Bjarmason (2):
commit-graph write: add progress output
commit-graph verify: add progress output
builtin/commit-graph.c | 5 ++--
builtin/gc.c | 3 +-
commit-graph.c | 65
For the reasons explained in the "commit-graph write: add progress
output" commit leading up to this one, emit progress on "commit-graph
verify". Since e0fd51e1d7 ("fsck: verify commit-graph", 2018-06-27)
"git fsck" has called this command if core.commitGraph=true, but
there's been no progress
Tim Schumacher writes:
> On 08.09.18 15:28, Duy Nguyen wrote:
>> On Sat, Sep 8, 2018 at 12:44 AM Tim Schumacher wrote:
>>> + /*
>>> +* It could be an alias -- this works around the insanity
>>> * of overriding "git log" with "git show" by having
On Mon, Sep 17, 2018 at 3:55 AM wrote:
>
> The following:
>
> git add -u :\(glob,attr:-someAttr\):src/**
>
> Produces an error that, according to the source code, should never be visible
> to the user. This attribute/pathspec *should* be supported according to the
> documentation provided by
Nguyễn Thái Ngọc Duy writes:
> The current naming convention for 'struct repository *' is 'r' for
> temporary variables or arguments. I did not notice this. Since we're
> updating blame.c again in the next patch, let's fix this.
It is likely that we end up having to refer to an in-core
Nguyễn Thái Ngọc Duy writes:
> This function calls do_diff_cache() which eventually needs to set this
> "istate" to unpack_options->src_index (*). This is an unfortunate fact
> that unpack_trees() _will_ destroy src_index so we can't really pass a
Wasn't the whole point of introducing
Matthew DeVore wrote:
> Subject: t/*: fix pipe placement and remove \'s
>
> Where ever there was code in the tests like this:
>
> foo \
> | bar
Language nits:
- s/Where ever/Wherever/
- Git's commit messages use the present tense to describe the existing
previous state of
On Mon, Sep 17, 2018 at 6:26 PM Ben Peart wrote:
>
>
>
> On 9/15/2018 6:22 AM, Duy Nguyen wrote:
> >> +index.threads::
> >> + Specifies the number of threads to spawn when loading the index.
> >> + This is meant to reduce index load time on multiprocessor machines.
> >> +
On September 17, 2018 11:58 AM, Taylor Blau wrote:
> On Mon, Sep 17, 2018 at 05:00:10PM +0200, Ævar Arnfjörð Bjarmason
> wrote:
> > > 2. Multi-file locks, e.g., "I need to lock file(s) X, Y, and Z
> > > together." This isn't possible in Git LFS today with the existing
"git
> > > lfs
On Mon, Sep 17, 2018 at 6:25 PM Junio C Hamano wrote:
>
> Nguyễn Thái Ngọc Duy writes:
>
> > This function calls do_diff_cache() which eventually needs to set this
> > "istate" to unpack_options->src_index (*). This is an unfortunate fact
> > that unpack_trees() _will_ destroy src_index so we
On September 17, 2018 6:02 PM, Jonathan Nieder wrote:
> Randall S. Becker wrote:
> > On September 17, 2018 3:28 PM, Jonathan Nieder wrote:
> >> Randall S. Becker wrote:
>
> >>> Does anyone know whether it is practical to rework git-lfs under a
> >>> language other than "go"? GCC is not even close
Bonjour
Vous aviez besoin de prêts d'argent entre particuliers pour faire face
aux difficultés financières pour enfin sortir de l'impasse que
provoquent les banques, par le rejet de vos dossiers de demande de
crédits ?
Je suis un citoyen français à la retraite en mesure de vous faire
un prêt de
Junio C Hamano writes:
> The tip of 'next' hasn't been rewound yet, but the states of many
> topics that were marked to "Cook in 'next'" read "Will merge to
> 'master'" now. I'll probably start merging a handful of topics that
> have been in 'next' down to 'master' tonight (they appear at the
>
Contributors to Git use a variety of editors, each with their own
configuration files. Because C lacks the defined norms on how to indent
and style code that other languages, such as Ruby and Rust, have, it's
possible for various contributors, especially new ones, to have
configured their editor
Hi brian,
Thanks for CC-ing me on this.
I use editorconfig every day via the configuration in my home directory
[1], and the Vim plugin editorconfig-vim [2]. It's a great piece of
software, and I've been using it without any issue since around the
beginning of 2015.
On Mon, Sep 17, 2018 at
On Mon, Sep 17, 2018 at 6:24 PM Matthew DeVore wrote:
> diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines
> @@ -163,6 +163,35 @@ For shell scripts specifically (not exhaustive):
> + - In a piped sequence which spans multiple lines, put each statement
> + on a separate
On Mon, Sep 17, 2018 at 6:25 PM Matthew DeVore wrote:
> tests: Add linter check for pipe placement style
Until now, the various "lint" checks have been for genuine portability
problems (except perhaps 'test-lint-duplicates'). This new lint check
makes style violations worthy of failing "make
On Mon, Sep 17, 2018 at 6:25 PM Matthew DeVore wrote:
> tests: split up pipes
This title explains the mechanical changes the patch is making but not
the intent. Perhaps reword it to say something like:
tests: avoid swallowing Git exit code upstream of a pipe
> Some pipes in tests lose the
On 9/15/2018 6:31 AM, Duy Nguyen wrote:
On Wed, Sep 12, 2018 at 6:18 PM Ben Peart wrote:
This patch helps address the CPU cost of loading the index by creating
multiple threads to divide the work of loading and converting the cache
entries across all available CPU cores.
It accomplishes
On Mon, Sep 17, 2018 at 7:09 PM Junio C Hamano wrote:
>
> Nguyễn Thái Ngọc Duy writes:
>
> > This is about mixing "git add -p" and "git commit -a" (or "git commit
> > ") where you may accidentally lose staged changes. After the
> > discussion with Jonathan, I'm going with a bit different
[Sorry about the double send in private, forgot to CC the list]
On Mon, Sep 17 2018, Duy Nguyen wrote:
> Brandon, b0db704652[...]
I noticed a few days ago that CC's to bmw...@google.com bounce. Has he
left Google, and if so is he still interested in being CC'd on Git stuff
(maybe he'll chime
Jeff King writes:
>> > What's the donness of this one?
>> > cf. <20180717201348.gd26...@sigill.intra.peff.net>
>>
>> This topic has stayed in 'pu' for a long time. I thought it was
>> concluded that this was a good change? Jeff, Jonathan?
>
> I read over the thread again. I don't think I
On Tue, Jul 17, 2018 at 03:59:47PM -0400, Jeff King wrote:
> On Mon, Jul 16, 2018 at 11:54:16PM -0700, Jonathan Nieder wrote:
>
> > A value of -1 returned from cmd_gc gets propagated to exit(),
> > resulting in an exit status of 255. Use die instead for a clearer
> > error message and a
On Mon, Sep 17, 2018 at 8:15 PM Jeff King wrote:
> On Mon, Sep 17, 2018 at 07:29:26PM +0200, Duy Nguyen wrote:
> > I don't see a good way to get to recover this situation. I could go
> > back to the "index log" idea, where we keep a log of index changes (or
> > just "interesting" changes). That
Thomas Gummerer wrote:
> Currently the 'compute_assignment()' function may read memory out
> of bounds, even if used correctly. Namely this happens when we only
> have one column.
[...]
> Reported-by: ryenus
> Helped-by: Derrick Stolee
> Signed-off-by: Thomas Gummerer
> ---
>
On 9/15/2018 7:09 AM, Duy Nguyen wrote:
On Sat, Sep 15, 2018 at 01:07:46PM +0200, Duy Nguyen wrote:
12:50:00.084237 read-cache.c:1721 start loading index
12:50:00.119941 read-cache.c:1943 performance: 0.034778758 s: loaded all
extensions (1667075 bytes)
12:50:00.185352
Nguyễn Thái Ngọc Duy writes:
> This is about mixing "git add -p" and "git commit -a" (or "git commit
> ") where you may accidentally lose staged changes. After the
> discussion with Jonathan, I'm going with a bit different approach than
> v1, this behavior now becomes default, and if the user
On Mon, Sep 17 2018, Joey Hess wrote:
> Ævar Arnfjörð Bjarmason wrote:
>> There's surely other aspects of that square peg of large file tracking
>> not fitting the round hole of file locking, the point of my write-up was
>> not that *that* solution is perfect, but there's prior art here that's
Duy Nguyen writes:
> But it _is_ available now. If you need it, you write the extension
> out.
Are you arguing for making it omitted when it is not needed (e.g.
small enough index file)? IOW, did you mean "If you do not need it,
you do not write it out" by the above?
I do not think overhead
On Mon, Sep 17, 2018 at 7:31 PM Junio C Hamano wrote:
>
> Duy Nguyen writes:
>
> > But it _is_ available now. If you need it, you write the extension
> > out.
>
> Are you arguing for making it omitted when it is not needed (e.g.
> small enough index file)? IOW, did you mean "If you do not need
On Mon, Sep 17, 2018 at 10:51 AM Ævar Arnfjörð Bjarmason
wrote:
>
> Aside from that particular address bouncing [...] it would be nice if git
> {format-patch,send-email,check-contacts} & the .mailmap format would
> support and understand some way to map addresses to
> e.g. nore...@example.com,
On Mon, Sep 17, 2018 at 07:29:26PM +0200, Duy Nguyen wrote:
> > On the other hand, if I am keeping some change that should never be
> > in a commit in the working tree file, and building the contents in
> > the index using "add -p" to incrementally, it would be the same
> > disaster as you are
Jeff King wrote:
> Let me inject some more uncertainty, then. ;)
>
> If we are not going to do 3/3, then should 2/3 simply avoid passing "-1"
> back via return from main? I guess I don't have a strong opinion, but
> one of the things I noted was that we converted those die() calls
> introduced in
Duy Nguyen writes:
> On Sat, Sep 15, 2018 at 12:22 PM Duy Nguyen wrote:
>> Wait there's no way to disable this parallel reading? Does not sound
>> right. And if ordinary numbers mean the number of threads then 0
>> should mean no threading. Auto detection could have a new keyword,
>> like
v2.18.0-rc0~70^2 (mailmap: update brian m. carlson's email address,
2018-05-08) changed the mailmap to map
sand...@crustytoothpaste.ath.cx
-> brian m. carlson
instead of
sand...@crustytoothpaste.net
-> brian m. carlson
That means the mapping
Brian M. Carlson
-> brian m.
Hi,
Eric Sunshine wrote:
> doc-diff creates a temporary working tree (git-worktree) and generates a
> bunch of temporary files which it does not remove since they act as a
> cache to speed up subsequent runs. Although doc-diff's working tree and
> generated files are not strictly build products
1 - 100 of 147 matches
Mail list logo
