Daniels Umanovskis writes:
> +static void print_current_branch_name()
> +{
> + const char *refname = resolve_ref_unsafe("HEAD", 0, NULL, NULL);
> + const char *shortname;
> + if (refname == NULL || !strcmp(refname, "HEAD"))
> + return;
Is it a normal situation to have ref
Ævar Arnfjörð Bjarmason writes:
>> It also means that we no longer need the inet_pton() and inet_ntop()
>> emulation, which is nice.
>
> Earlier in this series you add a:
>
> #if defined(_WIN32_WINNT) && _WIN32_WINNT >= 0x600
> ...
> #endif
>
> Shouldn't that now be something like:
>
> #if define
Rasmus Villemoes writes:
> @@ -1681,7 +1681,7 @@ sub process_file {
> # Now parse the message body
> while(<$fh>) {
> $message .= $_;
> - if (/^(Signed-off-by|Cc): (.*)/i) {
> + if (/^([a-z-]*-by|Cc): (.*)/i) {
So this picks up anything-by not j
Rasmus Villemoes writes:
> I considered that (and also had a version where I simply insisted on a @
> being present), but that means the user no longer would get prompted
> about the cases where the address was just slightly obfuscated, e.g. the
>
> Cc: John Doe
>
> cases, which would be a regre
On Wed, Oct 10, 2018 at 09:58:51AM +0900, Junio C Hamano wrote:
> > +static void bitmap_to_rle(struct strbuf *out, struct bitmap *bitmap)
> > +{
> > + int curval = 0; /* count zeroes, then ones, then zeroes, etc */
> > + size_t run = 0;
> > + size_t word;
> > + size_t orig_len = out->len;
`git ls-files` takes zero or more s, but the manpage (and the `-h`
output) lists it as taking zero or more s instead. This is confusing as
is documented in `man git` as a filename, without any magic. But a
pathspec has a lot of special handling. The gitglossary entry for pathspec does
say that
On Wed, Oct 10, 2018 at 09:48:53AM +0900, Junio C Hamano wrote:
> Jeff King writes:
>
> > The one difference is the sort order: git's diff output is
> > in tree-sort order, so a subtree "foo" sorts like "foo/",
> > which is after "foo.bar". Whereas the bitmap path list has a
> > true byte sort,
On Thu, 11 Oct 2018 08:01:40 +0900, Junio wrote:
> Michael Witten writes:
>
>> On Wed, 10 Oct 2018 14:43:46 +0900, Junio wrote:
>>
>>> We haven't seen much complaints and breakages reported against the
>>> two big "rewrite in C" topics around "rebase"; perhaps it is a good
>>> time to merge t
Johannes Schindelin writes:
> https://github.com/git-for-windows/git/commit/6bc7024aecdb1aeb2760c519f7b26e6e5ef21051
> fixup! builtin rebase: support `-C` and `--whitespace=`
For c7ee2134d4 (rebase-in-c-4-opts); a single liner that is
obviously correct.
> https://github.com/git-for-windows/
Junio C Hamano writes:
> From: Johannes Schindelin
> Date: Thu, 27 Sep 2018 14:48:17 +0200
>
> The `--gpg-sign` option takes an *optional* argument, not a mandatory
> one.
>
> This was discovered as part of the investigation of
> https://github.com/git-for-windows/git/issues/1836.
>
> Signed-off
From: Johannes Schindelin
Date: Thu, 27 Sep 2018 14:48:17 +0200
The `--gpg-sign` option takes an *optional* argument, not a mandatory
one.
This was discovered as part of the investigation of
https://github.com/git-for-windows/git/issues/1836.
Signed-off-by: Johannes Schindelin
---
* I am sen
Stefan Beller writes:
>> * pw/diff-color-moved-ws-fix (2018-10-04) 5 commits
> I would suggest merging to 'next'.
OK.
>> * sb/strbuf-h-update (2018-09-29) 1 commit
> The patch as-is just adds names everywhere.
> I'd be happy to resend with either
> (a) not enforcing names everywhere, but only a
Phillip Wood writes:
> On 10/10/2018 06:43, Junio C Hamano wrote:
>> Here are the topics that have been cooking. Commits prefixed with
>> '-' are only in 'pu' (proposed updates) while commits prefixed with
>> '+' are in 'next'. The ones marked with '.' do not appear in any of
>> the integration
Johannes Sixt writes:
> Am 10.10.18 um 07:43 schrieb Junio C Hamano:
>> We haven't seen much complaints and breakages reported against the
>> two big "rewrite in C" topics around "rebase"; perhaps it is a good
>> time to merge them to 'next' soonish to cook them for a few weeks
>> before moving t
Hi,
Derrick Stolee wrote:
> commit-reach.c| 4 +++-
> t/t6600-test-reach.sh | 2 +-
> 2 files changed, 4 insertions(+), 2 deletions(-)
I like this testing technique, and the test passes for me.
Except: if I put
CC = cc -m32
NO_OPENSSL = YesPlease
NO_CURL = YesP
Thomas Gummerer writes:
> There was a v9 of this series [*1*], which hasn't been picked up yet.
> Was that intentional, or an oversight?
;-) Yes, I often miss patches that are buried in other discussions,
but this time, it was quite deliberate. I saw comments that pointed
out at least one thing
Signed-off-by: Jonathan Tan
---
commit-graph.c | 4 ++--
revision.c | 20
2 files changed, 14 insertions(+), 10 deletions(-)
diff --git a/commit-graph.c b/commit-graph.c
index 90b0b3df90..d21d555611 100644
--- a/commit-graph.c
+++ b/commit-graph.c
@@ -782,9 +782,9 @@ st
Signed-off-by: Jonathan Tan
---
bloom-filter.c | 31 ++-
bloom-filter.h | 12
commit-graph.c | 26 --
revision.c | 9 +++--
4 files changed, 37 insertions(+), 41 deletions(-)
diff --git a/bloom-filter.c b/bloom-filter.c
in
I did my own experiments on top of what Szeder provided - the first
patch is to have one fixed-size bloom filter per commit, and the second
patch makes that bloom filter apply to only the first parent of each
commit. The results are:
Original (szeder's)
$ GIT_USE_POC_BLOOM_FILTER=$((8*1024*102
Olga Telezhnaya writes:
> Use ref_array_clear() to release memory instead of UNLEAK macros.
>
> Signed-off-by: Olga Telezhnaia
> ---
> builtin/ls-remote.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
OK, this is immediately before the command exits, and we have a way
to clear and re
Olga Telezhnaya writes:
> Release item->value.
> Initialize item->value->s dynamically and then release its resources.
> Release some local variables.
Again, "why" is lacking.
> @@ -1373,36 +1379,31 @@ static void fill_remote_ref_details(struct used_atom
> *atom, const char *refname,
>
Olga Telezhnaya writes:
> Release memory from used_atom variable.
That much readers would know from a quick look of the patch text.
Without knowing what you are aiming at, it is impossible to judge if
the patch is a good change.
Seeing FREE_AND_NULL(array->items) in the same function makes me
On Wed, Oct 10, 2018 at 10:59:45PM +0200, Ævar Arnfjörð Bjarmason wrote:
> > Callers who _are_ prepared to act on the exit code probably ought to
> > just use --auto-exit-code in their invocation.
> >
> > That said, I'm not entirely opposed to the matching config. There's
> > enough history here t
On Wed, Oct 10, 2018 at 10:54:32PM +0200, Daniels Umanovskis wrote:
> When called with --show-current, git branch will print the current
> branch name and terminate. Only the actual name gets printed,
> without refs/heads. In detached HEAD state, nothing is output.
I also wondered what happens in
On Thu, Oct 11, 2018 at 06:54:15AM +0900, Junio C Hamano wrote:
> > I'm not sure about saying "branch or tag" in the first bullet. It's
> > friendlier to most users, but less technically correct (if you said
> > "notes/foo", I believe we'd match an existing "refs/notes/foo", because
> > it's reall
On Wed, Oct 10, 2018 at 11:23:25PM +0200, Ævar Arnfjörð Bjarmason wrote:
> > I wonder if we could reword the first paragraph to be a little less
> > confusing, and spell out what we tried already. E.g., something like:
> >
> > The destination you provided is not a full refname (i.e., starting
>
On Thu, Oct 11, 2018 at 07:14:31AM +0900, Junio C Hamano wrote:
> Jeff King writes:
>
> > I get why you're doing it: your topic here only cares about removing
> > index dependencies, so you did the minimal thing to move that forward.
> >
> > But if you think about what this function is doing, it
On Wed, Oct 10, 2018 at 08:09:16AM -0700, Lucas De Marchi wrote:
> Do like it's done in grep so mode doesn't end up as
> 016, which means range-diff doesn't work if one has
> "submodule.diff = log" in the configuration. Without this
> while using range-diff I only get a
>
> Submodule a 000
On Wed, Oct 10, 2018 at 4:38 PM Junio C Hamano wrote:
>
> Brandon Casey writes:
>
> > ... Again, I don't feel strongly about it, but I'm not
> > sure this change actually improves the code.
>
> Yeah, in the context of the current caller, this is a safe change
> that does not break anybody and re
On 2018.10.05 12:25, Stefan Beller wrote:
> > > > I suppose if we are strict about serving from a single endpoint, the
> > > > version registry makes more sense, and individual operations can declare
> > > > acceptable version numbers before calling any network code?
> > >
> > > Ah yeah, that makes
On Wed, Oct 10, 2018 at 05:59:05AM +0900, Junio C Hamano wrote:
> I do not offhand know if we want "show the current one only" option
> that is "command mode" sitting next to "list", "delete", "rename"
> etc., or "limit the operation to the one that is currently cheked
> out". If we want the forme
Daniels Umanovskis writes:
> On 10/11/18 12:26 AM, Junio C Hamano wrote:
>> Among the remaining ones in the list, cherry and get-tar-commit-id
>> are probably better classified as plumbing. I do not know why
>> cherry is marked for completion; perhaps some crazy people use that
>> on the command
Brandon Casey writes:
> ... Again, I don't feel strongly about it, but I'm not
> sure this change actually improves the code.
Yeah, in the context of the current caller, this is a safe change
that does not break anybody and reduces the number of instructions
executed in this codepath. A mistak
Mihir Mehta writes:
> -Just in case if you are doing something exotic, it should be
> +Just in case you are doing something exotic, it should be
Thanks. Somehow I didn't notice this change earlier, but it looks
good, too.
Will queue.
Instead of passing the sign directly to emit_line_ws_markup, pass only the
index to lookup the sign in diff_options->output_indicators.
Signed-off-by: Stefan Beller
---
I still have this patch laying around, it simplifies the diff code
a tiny bit.
Stefan
diff.c | 12 +---
1 file chang
On Wed, Oct 10 2018, SZEDER Gábor wrote:
> On Thu, Oct 04, 2018 at 11:09:58PM -0700, Junio C Hamano wrote:
>> SZEDER Gábor writes:
>>
>> >> git-gc - Cleanup unnecessary files and optimize the local repository
>> >>
>> >> Creating these indexes like the commit-graph falls under "optimize the
Michael Witten writes:
> On Wed, 10 Oct 2018 14:43:46 +0900, Junio wrote:
>
>> We haven't seen much complaints and breakages reported against the
>> two big "rewrite in C" topics around "rebase"; perhaps it is a good
>> time to merge them to 'next' soonish to cook them for a few weeks
>> be
On 10/11/18 12:26 AM, Junio C Hamano wrote:
> Among the remaining ones in the list, cherry and get-tar-commit-id
> are probably better classified as plumbing. I do not know why
> cherry is marked for completion; perhaps some crazy people use that
> on the command line?
I think cherry could go eit
On Wed, Oct 10, 2018 at 11:56 AM Antonio Ospite wrote:
>
> On Mon, 8 Oct 2018 15:19:00 -0700
> Stefan Beller wrote:
>
> > > +test_expect_success 'not writing gitmodules config file when it is not
> > > checked out' '
> > > +test_must_fail git -C super submodule--helper config
> > > subm
On Tue, Oct 9, 2018 at 5:10 PM Jonathan Tan wrote:
>
> > It claimed that grep would still need some explicit handling, but that is
> > not the call to repo_read_gitmodules (applying this patch on top of
> > ff6f1f564c4 still keep the test suite happy, specifically
> > t7814-grep-recurse-submodules
On Wed, Oct 10 2018, SZEDER Gábor wrote:
> On Wed, Oct 10, 2018 at 11:56:45PM +0200, Ævar Arnfjörð Bjarmason wrote:
>> On Wed, Oct 10 2018, SZEDER Gábor wrote:
>
>> >> for (i = 0; i < oids->nr; i++) {
>> >> + display_progress(progress, ++j);
>>
>> [...]
>>
>> > This display_progress()
On Wed, Oct 10, 2018 at 12:32 PM Ævar Arnfjörð Bjarmason
wrote:
>
> Checking gc_auto_threshold in too_many_loose_objects() was added in
> 17815501a8 ("git-gc --auto: run "repack -A -d -l" as necessary.",
> 2007-09-17) when need_to_gc() itself was also reliant on
> gc_auto_pack_limit before its ear
I noticed that git-merge-base was unlikely to actually be a git command,
and tried it in my shell. Seeing that it doesn't work, I cleaned up two
places in the docs where it appears.
Signed-off-by: Mihir Mehta
---
Documentation/git-diff.txt | 4 ++--
Documentation/howto/update-ho
Daniels Umanovskis writes:
> git-rev-parse mostly seems like plumbing, and is more usd in
> scripts than in regular use. Online it's often mentioned as
> a plumbing command. Nonetheless it's listed under porcelain
> interrogators in `man git`. It seems appropriate to formally
> move git-rev-parse
Ævar Arnfjörð Bjarmason wrote:
> Which is what I'm doing by running "gc --auto" across a set of servers
> and looking at the exit code. If it's been failing I get an error, if
> there's no need to gc nothing happens, and if it hasn't been failing and
> it just so happens that it's time to GC then
On Wed, Oct 10, 2018 at 11:56:45PM +0200, Ævar Arnfjörð Bjarmason wrote:
> On Wed, Oct 10 2018, SZEDER Gábor wrote:
> >>for (i = 0; i < oids->nr; i++) {
> >> + display_progress(progress, ++j);
>
> [...]
>
> > This display_progress() call, however, doesn't seem to be necessary.
> > F
Mihir Mehta writes:
> Thanks, Junio. Instead of removing that part of the patch, I opted to
> expand it to make it a little clearer (in my opinion) than it was
> before. Let me know if this works.
I am mildly negative on that change. "Omitting both would give an
empty diff" would be understanda
On Wed, Oct 10 2018, Jonathan Nieder wrote:
> Junio C Hamano wrote:
>> Jonathan Nieder writes:
>
>>> Perhaps this reporting could also print the message from a previous
>>> run, so you could write:
>>>
>>> git gc --detached-status || exit
>>> git gc --auto; # perhaps also passing --deta
Jeff King writes:
> I get why you're doing it: your topic here only cares about removing
> index dependencies, so you did the minimal thing to move that forward.
>
> But if you think about what this function is doing, it is quite clearly
> dependent on the whole repository, since the userdiff con
On Thu, Oct 04, 2018 at 11:09:58PM -0700, Junio C Hamano wrote:
> SZEDER Gábor writes:
>
> >> git-gc - Cleanup unnecessary files and optimize the local repository
> >>
> >> Creating these indexes like the commit-graph falls under "optimize the
> >> local repository",
> >
> > But it doesn't f
On Wed, Oct 10 2018, SZEDER Gábor wrote:
> On Mon, Sep 17, 2018 at 03:33:35PM +, Ævar Arnfjörð Bjarmason wrote:
>> $ git -c gc.writeCommitGraph=true gc
>> [...]
>> Annotating commits in commit graph: 1565573, done.
>> Computing commit graph generation numbers: 100% (782484/78
Jeff King writes:
>> Fix both of those, now the message will look like this instead:
>>
>> $ ./git-push avar v2.19.0^{commit}:newbranch -n
>> error: unable to push to unqualified destination: newbranch
>> hint: The destination refspec neither matches an existing
>> hint: ref on t
Junio C Hamano wrote:
> Jonathan Nieder writes:
>> Perhaps this reporting could also print the message from a previous
>> run, so you could write:
>>
>> git gc --detached-status || exit
>> git gc --auto; # perhaps also passing --detach
>>
>> (Names still open for bikeshedding.)
>
> When
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 case,
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.
As we do not rely on the sortedness while building the
list, we pick the "append and sort at the end" as it
has better wo
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 b53cb6e9c4..0de9e2800a 100644
--- a/submodule
Helped-by: Junio C Hamano
Signed-off-by: Stefan Beller
---
Documentation/technical/api-oid-array.txt | 5 +
sha1-array.c | 17 +
sha1-array.h | 3 +++
3 files changed, 25 insertions(+)
diff --git a/Documentation/tec
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 --git
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 t
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 workflow
When constructing a struct repository for a submodule for some revision
of the superproject where the submodule is not contained in the index,
it may not be present in the working tree currently either. In that
siutation giving a 'path' argument is not useful. Upgrade the
repo_submodule_init functi
'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 acc
This is nearly the same as sent in [1], with one commit message fixed.
[1] https://public-inbox.org/git/20180925194755.105578-1-sbel...@google.com/
and replaces sb/submodule-recursive-fetch-gets-the-tip.
Thanks,
Stefan
Stefan Beller (9):
sha1-array: provide oid_array_filter
submodule.c: fix i
git-rev-parse mostly seems like plumbing, and is more usd in
scripts than in regular use. Online it's often mentioned as
a plumbing command. Nonetheless it's listed under porcelain
interrogators in `man git`. It seems appropriate to formally
move git-rev-parse to plumbing interrogators.
Signed-off
Jonathan Nieder writes:
> Perhaps this reporting could also print the message from a previous
> run, so you could write:
>
> git gc --detached-status || exit
> git gc --auto; # perhaps also passing --detach
>
> (Names still open for bikeshedding.)
When the command is given --detached
Am 10.10.18 um 07:43 schrieb Junio C Hamano:
We haven't seen much complaints and breakages reported against the
two big "rewrite in C" topics around "rebase"; perhaps it is a good
time to merge them to 'next' soonish to cook them for a few weeks
before moving them to 'master'?
Please let me exp
On Wed, Oct 10 2018, Jeff King wrote:
> On Wed, Oct 10, 2018 at 10:41:45AM +, Ævar Arnfjörð Bjarmason wrote:
>
>> Improve the error message added in f8aae12034 ("push: allow
>> unqualified dest refspecs to DWIM", 2008-04-23), which before this
>> change looks like this:
>>
>> $ git push
Ævar Arnfjörð Bjarmason wrote:
> Right. I know. What I mean is now I can (and do) use it to run 'git gc
> --auto' across our server fleet and see whether I have any of #3, or
> whether it's all #1 or #2. If there's nothing to do in #1 that's fine,
> and it just so happens that I'll
On Wed, Oct 10 2018, Jonathan Nieder wrote:
> Hi,
>
> Ævar Arnfjörð Bjarmason wrote:
>
>> Add an --auto-exit-code variable and a corresponding 'gc.autoExitCode'
>> configuration option to optionally bring back the 'git gc --auto' exit
>> code behavior as it existed between 2.6.3..2.19.0 (inclusi
On Wed, Oct 10 2018, Jeff King wrote:
> On Wed, Oct 10, 2018 at 07:27:32PM +, Ævar Arnfjörð Bjarmason wrote:
>
>> Add an --auto-exit-code variable and a corresponding 'gc.autoExitCode'
>> configuration option to optionally bring back the 'git gc --auto' exit
>> code behavior as it existed be
When called with --show-current, git branch will print the current
branch name and terminate. Only the actual name gets printed,
without refs/heads. In detached HEAD state, nothing is output.
Intended both for scripting and interactive/informative use.
Unlike git branch --list, no filtering is nee
Hi,
Ævar Arnfjörð Bjarmason wrote:
> Add an --auto-exit-code variable and a corresponding 'gc.autoExitCode'
> configuration option to optionally bring back the 'git gc --auto' exit
> code behavior as it existed between 2.6.3..2.19.0 (inclusive).
Hm. Can you tell me more about the use case where
On Wed, Oct 10, 2018 at 10:41:45AM +, Ævar Arnfjörð Bjarmason wrote:
> Improve the error message added in f8aae12034 ("push: allow
> unqualified dest refspecs to DWIM", 2008-04-23), which before this
> change looks like this:
>
> $ git push avar v2.19.0^{commit}:newbranch -n
> error:
On Wed, Oct 10, 2018 at 10:41:44AM +, Ævar Arnfjörð Bjarmason wrote:
> Mark up the error(...) messages in remote.c for translation. The likes
> of "unable to push to unqualified destination" are relatively big
> parts of the UI, i.e. error messages shown when "git push" fails.
>
> I don't thi
v2 reroll of a previously-discussed patch. Thanks to everyone for their
comments. Based on feedback:
1. Command is now a verb: git branch --show-current.
2. Changed to gitster's suggested implementation: nothing is printed
if HEAD does not point to a symbolic ref. A fatal
error if HEAD is a sym
On Mon, Sep 17, 2018 at 03:33:35PM +, Ævar Arnfjörð Bjarmason wrote:
> $ git -c gc.writeCommitGraph=true gc
> [...]
> Annotating commits in commit graph: 1565573, done.
> Computing commit graph generation numbers: 100% (782484/782484), done.
While poking around 'commit-graph.c'
On 10.10.18 07:43, Junio C Hamano wrote:
* ts/alias-of-alias (2018-09-17) 3 commits
(merged to 'next' on 2018-10-09 at ac19b4730b)
+ t0014: introduce an alias testing suite
+ alias: show the call history when an alias is looping
+ alias: add support for aliases of an alias
An alias th
On Wed, Oct 10, 2018 at 07:27:32PM +, Ævar Arnfjörð Bjarmason wrote:
> Add an --auto-exit-code variable and a corresponding 'gc.autoExitCode'
> configuration option to optionally bring back the 'git gc --auto' exit
> code behavior as it existed between 2.6.3..2.19.0 (inclusive).
>
> This was
Explicitly mention in the intro that we may be writing supplemental
data structures such as the commit-graph during "gc", i.e. to call out
the "optimize" part of what this command does, it doesn't just
"collect garbage" as the "gc" name might imply.
Past changes have updated the intro to reflect n
Expand on the work started in 095c741edd ("commit: run git gc --auto
just before the post-commit hook", 2018-02-28) to run "gc --auto" in
more commands where new objects can be created.
The notably missing commands are now "rebase" and "stash". Both are
being rewritten in C, so any use of "gc --au
Checking gc_auto_threshold in too_many_loose_objects() was added in
17815501a8 ("git-gc --auto: run "repack -A -d -l" as necessary.",
2007-09-17) when need_to_gc() itself was also reliant on
gc_auto_pack_limit before its early return:
gc_auto_threshold <= 0 && gc_auto_pack_limit <= 0
When tha
Add an --auto-exit-code variable and a corresponding 'gc.autoExitCode'
configuration option to optionally bring back the 'git gc --auto' exit
code behavior as it existed between 2.6.3..2.19.0 (inclusive).
This was changed in 3029970275 ("gc: do not return error for prior
errors in daemonized mode"
Need for update subscribing to mailing list from @git
Thanks
Sent from my Evertek
On Tue, Oct 9, 2018 at 6:10 PM Junio C Hamano wrote:
>
> Stefan Beller writes:
> >> Oh, I think I misled you by saying "more important".
> >> ...
> > I do challenge the decision to take a hardcoded value, though, ...
>
> I do not find any reason why you need to say "though" here.
I caught myself
On Wed, 10 Oct 2018 18:51:17 -, Michael Witten wrote:
> merge -# Same as merge -C abcde r1
That should be:
merge -# Same as `merge r1'
On Mon, 8 Oct 2018 15:19:00 -0700
Stefan Beller wrote:
> > +test_expect_success 'not writing gitmodules config file when it is not
> > checked out' '
> > +test_must_fail git -C super submodule--helper config
> > submodule.submodule.url newurl
>
> This only checks the exit code, do we a
> * pw/diff-color-moved-ws-fix (2018-10-04) 5 commits
> - diff --color-moved: fix a memory leak
> - diff --color-moved-ws: fix another memory leak
> - diff --color-moved-ws: fix a memory leak
> - diff --color-moved-ws: fix out of bounds string access
> - diff --color-moved-ws: fix double free
On Wed, 10 Oct 2018 14:43:46 +0900, Junio wrote:
> We haven't seen much complaints and breakages reported against the
> two big "rewrite in C" topics around "rebase"; perhaps it is a good
> time to merge them to 'next' soonish to cook them for a few weeks
> before moving them to 'master'?
I
On Wed, Oct 10 2018, Jonathan Nieder wrote:
> Hi,
>
> Ævar Arnfjörð Bjarmason wrote:
>
>> I'm just saying it's hard in this case to remove one piece without the
>> whole Jenga tower collapsing, and it's probably a good idea in some of
>> these cases to pester the user about what he wants, but pr
Hello,
Am 10.10.2018 um 01:38 schrieb Артем Семенов:
> Hello.
>
> Git svn bug on merging svn branches:
>
> Svn repository (branches tag trunk).
>
> 1. Add a some file by svn tools.
> 2. Create a new branch by svn tools (e.g. br1) .
> 3. Create a new branch by svn tools on branch br1 (e.g. br2).
> I'd be happy to submit a documentation patch for discussion that
> formally moves rev-parse to plumbing.
I'd be happy to see such a patch.
On Wed, Oct 10, 2018 at 8:26 AM Phillip Wood wrote:
>
> On 09/10/2018 22:10, Stefan Beller wrote:
> >> As I said above I've more or less come to the view that the correctness
> >> of pythonic indentation is orthogonal to move detection as it affects
> >> all additions, not just those that correspo
On Wed, Oct 10, 2018 at 09:51:52AM -0700, Jonathan Nieder wrote:
> Ævar Arnfjörð Bjarmason wrote:
>
> > I'm just saying it's hard in this case to remove one piece without the
> > whole Jenga tower collapsing, and it's probably a good idea in some of
> > these cases to pester the user about what h
Hi,
Ævar Arnfjörð Bjarmason wrote:
> I'm just saying it's hard in this case to remove one piece without the
> whole Jenga tower collapsing, and it's probably a good idea in some of
> these cases to pester the user about what he wants, but probably not via
> gc --auto emitting the same warning eve
On Wed, Oct 10, 2018 at 8:21 AM Junio C Hamano wrote:
> We probably can keep the "let's not run for a day" safety while
> pretending that "git gc -auto" succeeded for callers like "git svn"
> so that these callers do not hae to do "eval { ... }" to hide our
> exit code, no?
>
> I think that is wha
On 10/10/18 5:03 PM, Ævar Arnfjörð Bjarmason wrote:
>
> I'm mildly negative on this because git-rev-parse is plumbing, but
> git-branch is porcelain [..]
>
> We also list git-rev-parse as porcelain, just under "Porcelain / Ancillary
> Commands / Interrogators".
>
> Should we just move it to plum
From: Ben Peart
This patch enables addressing the CPU cost of loading the index by adding
additional data to the index that will allow us to efficiently multi-
thread the loading and conversion of cache entries.
It accomplishes this by adding an (optional) index extension that is a
table of offs
From: Ben Peart
This patch helps address the CPU cost of loading the index by loading
the cache extensions on a worker thread in parallel with loading the cache
entries.
In some cases, loading the extensions takes longer than loading the
cache entries so this patch utilizes the new EOIE to start
From: Ben Peart
This patch helps address the CPU cost of loading the index by utilizing
the Index Entry Offset Table (IEOT) to divide loading and conversion of
the cache entries across multiple threads in parallel.
I used p0002-read-cache.sh to generate some performance data:
Test w/100,000 fil
From: Ben Peart
Add support for a new index.threads config setting which will be used to
control the threading code in do_read_index(). A value of 0 will tell the
index code to automatically determine the correct number of threads to use.
A value of 1 will make the code single threaded. A value
1 - 100 of 166 matches
Mail list logo
