Alban Gruin writes:
> `total_nr' is the total amount of items, done and toto, that are in a
> todo list. But unlike `nr', it was not updated when an item was
> appended to the list.
s/amount/number/, as amount is specifically for something
that cannot be counted.
Perhaps a stupid language ques
Eric Wong writes:
> 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.
> +/*
> + * like offsetof(), but takes a pointer to type instead of
Alex Henrie writes:
> Well, I admit that code clarity is somewhat subjective. To me it's not
> obvious that "if (q->nr <= j)" means "if the loop exited normally",
I actually do not have too much problem with this side of the
equation. I however do see problem with squashing the two diff_q
calls
Alex Henrie writes:
> The condition "if (q->nr <= j)" checks whether the loop exited normally
> or via a break statement. This check can be avoided by replacing the
> jump out of the inner loop with a jump to the end of the outer loop.
>
> With the break replaced by a goto, the two diff_q calls t
"Kunal Tyagi via GitGitGadget" writes:
> From: Kunal Tyagi
> Subject: Re: [PATCH v2 1/1] git-add--interactive.perl: Add progress counter
> in the prompt
Either of these two, perhaps (I'd use the former if I were writing
this patch):
add -i: show progress counter in the prompt
Alex Henrie writes:
> The variable g was being set to the same value both at the beginning of
> the function and before the loop. The assignment before the loop was
> kept because it helps clarify what the loop does, and the redundant
> assignment at the beginning of the function was removed.
Wr
CB Bailey writes:
> For easier discussion, I've snipped the original patch and replaced with
> one with enough context to show the entire function.
>
> I was reviewing this patch and it appeared to introduce a change in
> behaviour.
>
>> diff --git a/diffcore-break.c b/diffcore-break.c
>> index 8
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 branches, but I am still holding onto them.
I've been offline for a week or so
Eric Wong writes:
> 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 elem
"brian m. carlson" writes:
> On 2019-09-07 at 17:26:53, Junio C Hamano wrote:
>> * bc/object-id-part17 (2019-08-19) 26 commits
>> ...
>> - builtin/replace: make hash size independent
>>
>> Preparation for SHA-256 upgrade continues.
>>
>
"Johannes Schindelin via GitGitGadget"
writes:
> diff --git a/t/test-lib.sh b/t/test-lib.sh
> index d1ba33745a..f21c781e68 100644
> --- a/t/test-lib.sh
> +++ b/t/test-lib.sh
> @@ -695,7 +695,7 @@ test_failure_ () {
> say_color error "not ok $test_count - $1"
> shift
> printf '%s
"Johannes Schindelin via GitGitGadget"
writes:
> ---
> Makefile | 2 +-
> compat/mingw.c| 5 -
> git-compat-util.h | 4 +++-
> compat/qsort.c => qsort.c | 2 +-
> 4 files changed, 5 insertions(+), 8 deletions(-)
> rename compat/qsort.c => qsort.c (97%)
Thomas Gummerer writes:
>> I thought it was to be 1700 UTC, which currently is 1800 BST her in UK, and
>> 1900 CST in Europe.
>
> That's my recollection as well, and what the calendar should say.
> Thanks for flagging this!
>
> I don't know. I'd be happy to keep it at 17:00 UTC, but that might b
Johannes Schindelin writes:
> The only problem is that my patch made it into `next` already, according
> to https://github.com/gitgitgadget/git/pull/129 (look for the labels on
> the right side, or for the comments on the bottom), and
> https://github.com/gitster/git/commit/a3f332f4fb10 agrees (l
"Alexandr Miloslavskiy via GitGitGadget"
writes:
> From: Alexandr Miloslavskiy
>
> After I discovered that UTF-16-LE-BOM test was bugged, I decided that
s/bugged/buggy/ perhaps? Usually people do not place hidden
listening devices in tests ;-)
> better tests are required. Possibly the best op
SZEDER Gábor writes:
>> Hmm...
>>
>> > +# ,---ooo-.
>> > +# / D,R e \
>> > +# o--o-o-o---ox
>> > +# \B/
>> > +# `---ooo-'
>> > +#Ac
>>
>> What's the first parent of the merge between
Eric Wong writes:
> C is fine for unit tests, and maybe we can use more unit tests
> and less integration tests.
Nicely put. I often find it somewhat disturbing that what some of
the t/helper/ tests are trying to exercise is at too low a level
that the distance from the real-world observable ef
Jeff King writes:
> On Tue, Sep 24, 2019 at 04:25:45PM +0200, Johannes Schindelin wrote:
>
>> > I think it could make sense for merge-index to be able to directly run
>> > the merge-one-file code[1]. But I think we'd want to keep its ability to
>> > run an arbitrary script, and for people to call
William Baker writes:
> 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;
&
SZEDER Gábor writes:
> On Fri, Sep 20, 2019 at 09:53:48AM -0700, William Baker via GitGitGadget
> wrote:
>> diff --git a/midx.h b/midx.h
>> index f0ae656b5d..e6fa356b5c 100644
>> --- a/midx.h
>> +++ b/midx.h
>> @@ -37,6 +37,8 @@ struct multi_pack_index {
>> char object_dir[FLEX_ARRAY];
>>
Matheus Tavares Bernardino writes:
> Right, this would be the best way of doing it. However, I think this
> is not how it's currently implemented. I if correctly understood the
> code in this call chain:
>
> grep_source_load_driver() > userdiff_find_by_path() >
> git_check_attr() > collect_some_
SZEDER Gábor writes:
> The 'check_describe' helper function runs 'git describe' outside of
> 'test_expect_success' blocks, with extra hand-rolled code to record
> and examine its exit code.
>
> Update this helper and move the 'git decribe' invocation inside the
> 'test_expect_success' block.
Tha
SZEDER Gábor writes:
> At the top of 't6120-describe.sh' an ASCII graph illustrates the
> repository's history used in this test script. This graph is a bit
> misleading, because it swapped the second merge commit's first and
> second parents.
Hmm...
> +# ,---ooo-.
> +#
Jonathan Tan writes:
>> OK. We notice that we need to newly create foo/bar but we
>> incorrectly find that there is "foo/bar" already because of the
>> careless use of bare lstat(2) makes "bar" visible as if it were also
>> "foo/bar". I wonder if the current code would be confused the same
>> w
Junio C Hamano writes:
> This step is meant to be just preparing by extending the interface
> and passing the new argument throughout the callchain, I believe,
> and it looks correctly done, assuming that we are OK to take this
> "add a separate 'progress' parameter, w
Steps 4 & 5 look OK.
"William Baker via GitGitGadget" writes:
> 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 *progress;
"William Baker via GitGitGadget" writes:
> From: William Baker
>
> Signed-off-by: William Baker
> ---
> builtin/multi-pack-index.c | 8
> builtin/repack.c | 2 +-
> midx.c | 8
> midx.h | 10 ++
> 4 files changed, 1
"William Baker via GitGitGadget" writes:
> William Baker (6):
> midx: add MIDX_PROGRESS flag Add the MIDX_PROGRESS flag and update the
> write|verify|expire|repack functions in midx.h to accept a flags
> parameter. The MIDX_PROGRESS flag indicates whether the caller of
> the functi
Taylor Blau writes:
> commit-graph files on all repositories hosted on GitHub, and some
> corrupt repositories triggered the behavior.
> ...
> We've been running this patch since a few days before I submitted it to
> ...
> This one has a similar origin story, and has also been running at GitHub
>
Junio C Hamano writes:
> Growth and the world domination may come as a consequence, and I
> would not reject it when it happens, but we should not be actively
> seeking it.
I realize that it was my mistake that I did not explicitly say this,
but I do appreciate many of the things the
SZEDER Gábor writes:
>> But in the larger picture, I would expect that readers would more
>> immediately grasp what it is about if it were titled "do not skip
>> versions that have already tested good in debug mode"
>
> Will try to come up with a better subject line, but I don't have any
> usable
SZEDER Gábor writes:
> skip_good_tree () {
> + if test "$TRAVIS_DEBUG_MODE" = true
> + then
> + return
> + fi
I think you convinced readers why it is a good idea to avoid
skipping an already tested tree, and technically the title of this
commit is not incorrect per-se.
Garima Singh writes:
>> could get people to tag with [FIRST PATCH] or something when sending in
>> their first patch.
I personally think that the [FIRST PATCH] thing will add distraction
without helping much, so I am mildly negative on that idea.
>> If the patch is not desired, then we should e
Jeff King writes:
> I've had similar thoughts over the years, but eventually switched my way
> of thinking. I think part of that switch was coming to the conclusion
> that most of the value of a Code of Conduct isn't about having a system
> of enforcement against bad actors (in fact, I think that
Derrick Stolee writes:
> I. Goals and Perceived Problems
>
> As a community, our number one goal is for Git to continue to be the best
> distributed version control system. At minimum, it should continue to be
> the most widely-used DVCS. Towards that goal, we need to make sure Git is
> the best
Jonathan Tan writes:
> When the working tree has:
> - bar (directory)
> - bar/file (file)
> - foo (symlink to .)
>
> (note that lstat() for "foo/bar" would tell us that it is a directory)
>
> and the user merges a commit that deletes the foo symlink and instead
> contains:
> - bar (directory,
Thomas Gummerer writes:
> I have sent an updated version of this, that integrates the changes
> the js/builtin-add-i topic needs in [*1*]. I think it would be ok to
> pick up that version and keep js/builtin-add-i out of pu until it's
> rebased on top of that.
Thanks, will replace after looking
Martin Ågren writes:
> Hi Junio,
>
> On Thu, 19 Sep 2019 at 01:44, Junio C Hamano wrote:
>
>> * ma/asciidoctor-refmiscinfo (2019-09-16) 3 commits
>> - doc-diff: replace --cut-header-footer with --cut-footer
>> - asciidoctor-extensions: provide ``
>> - D
Jonathan Tan writes:
>> * jt/cache-tree-avoid-lazy-fetch-during-merge (2019-09-09) 1 commit
>> - cache-tree: do not lazy-fetch tentative tree
>>
>> The cache-tree code has been taught to be less aggressive in
>> attempting to see if a tree object it computed already exists in
>> the reposito
Matheus Tavares Bernardino writes:
> Hmm, I may have gotten a little confused here. Are you talking
> about the attributes stack (which contains .gitattributes and
> info/attributes)? If so, isn't this stack already rebuild for
> every path? I mean, by the previous call chain it seems to me that
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 branches, but I am still holding onto them.
We have a new maintainer for git-g
Matheus Tavares writes:
> Make git-grep --recurse-submodules stop adding subrepos to the in-memory
> alternates list and, instead, pass a reference to the subrepo struct
> down to the threads.
Nice. This is done by updating all the codepaths used by grep to
use the lower-level helper functions
Denton Liu writes:
> Hi Pratyush,
>
> Since you're the maintainer now, you should submit a patch to
> Documentation/SubmittingPatches to change
>
> - `git-gui/` comes from git-gui project, maintained by Pat Thoyts:
>
> git://repo.or.cz/git-gui.git
>
> to have your own informat
Pratyush Yadav writes:
> Assuming I have git.git cloned in ../git (relative to git-gui.git), I
> ran:
>
> git pull -Xsubtree=git-gui ../git $branches
>
> instead of:
>
> git merge $branches
>
> because git-gui's tree doesn't have those commits and branches yet, so
> we can't merge straight
Birger Skogeng Pedersen writes:
> For example, I created a patch back in March 2018[3]. Junio pulled it
> so the changes are really there in git/git-gui/git-gui.sh (see this[4]
> line). This was while there was no git-gui maintainer. I guess the
> change never got merged to git-gui, but directly
Thanks.
Johannes Sixt writes:
> Am 18.09.19 um 02:11 schrieb Kamil Domański:
>> Create a '--count' option for ls-remote, based on the one from
>> for-each-ref. This allows e.g. to return only the first result
>> from a sorted list of refs.
>>
>> Signed-off-by: Kamil Domański
>> ---
>> Documentation/gi
Hervé Beraud writes:
> Python 2 is EOL at the end of 2019, many distros
> and systems now come with python 3 is the default version.
Grammo. s/is the/as their/ or something like that to fix.
> These changes introduce a syntaxe compatible with the both versions of
> python and so with the nearl
Junio C Hamano writes:
One more thing.
> Subject: Re: [PATCH] Rewrite feature to render hg-to-git compatible with
> python2.x and 3.x
Our commit titles typically begin with : prefix, e.g.
Subject: hg-to-git: make it compatibile with both Python 3 and Python 2
or something like that.
Jonathan Tan writes:
>> In any case, if the working tree has 'foo' as a symlink, Git should
>> not look at or get affected by what 'foo' points at.
>
> Git should not, but it does - there is a call in process_entry() that calls
> lstat() on "foo/bar", which indeed reports that "foo/bar" is a dire
Hervé Beraud writes:
> Rewrite features that are no longer supported (or recommended)
> in Python 3 in the script so that it can be used with both
> Python 2 and 3, namely:
>
> - print is not a statement; use print() function instead.
> - dict.has_key(key) is no more; use "key in dict" instead.
>
Jonathan Tan writes:
> When the working tree has:
> - foo (symlink)
> - foo/bar (directory)
Whoa, wait. I assume, since this is about merge, the assumption is
that the working tree is clean with respect to the index, so 'foo'
is a symbolic link that is in the index. Now, if foo is a symlink,
Junio C Hamano writes:
> This would make this in line with pt_{pt,br}.po, existing locales
> with country code in them.
>
> Reviewed-by: Junio C Hamano
Paul, I've applied this to a clone of gitk locally and merged it
(resutling in 2a4ac71ffb that should be reachable from &#x
Jeff King writes:
> It's a good idea to parse as much as we can in step 1, in order to catch
> problems early (e.g., a blob size limit that isn't a number). But one
> thing we _shouldn't_ do is resolve any oids at that step (e.g., for
> sparse-file contents specified by oid). In the case of a fet
Zeger-Jan van de Weg writes:
> Subject: Re: [PATCH 1/1] Git config allows value setting from stdin
Probably something like this, with the ":" prefix.
config: learn the --stdin option to take args from the standard input
> When setting values in the git config, the value is part of the
gt; rename po/{zh_CN.po => zh_cn.po} (100%)
>
> diff --git a/po/zh_CN.po b/po/zh_cn.po
> similarity index 100%
> rename from po/zh_CN.po
> rename to po/zh_cn.po
This would make this in line with pt_{pt,br}.po, existing locales
with country code in them.
Reviewed-by: Junio C Hamano
SZEDER Gábor writes:
> On Mon, Sep 16, 2019 at 01:57:14PM -0700, Junio C Hamano wrote:
>> Queued; thanks.
>
> Nit: it would be nicer to queue this series on top of
> 'dl/compat-cleanup', because 'make coccicheck' errors out suggesting
> transformation
Queued; thanks.
Denton Liu writes:
> +# THIRD_PARTY_SOURCES is a list of patterns compatible with
> +# the $(filter) and $(filter-out) family of functions
That defines the format, but does it convey what they want to
achieve to the readers? "... to catch the list of source files
we borrowed from elsewhere" or
Masaya Suzuki writes:
> Debugging this, it seems most of the time is spent on iterating the want refs
> to
> see OIDs are included there. This patch speeds up this process by using
> oid_set.
> Now the client can send a fetch request almost immediately.
Wonderful. Thanks.
Martin Ågren writes:
> On Sun, 15 Sep 2019 at 21:26, Johannes Sixt wrote:
>> I do not have the toolchain to check that a correct result is produced.
>
> But I do. I've tested this patch and 2/2 with AsciiDoc 8.6.10 and
> Asciidoctor 1.5.5, as well as with Asciidoctor 2.0.10 (on top of brian's
>
Denton Liu writes:
> Break `--default` and `--branch` into their own separate invocations to
> make it obvious that these options are mutually exclusive.
That sounds even clearer than what the original wanted to do. Very
good idea.
> diff --git a/Documentation/git-submodule.txt b/Documentation
Robert Schmidt-Cisternas writes:
> However, when cloning a repo with submodules, the variable is cleared
GIT_OBJECT_DIRECTORY applies to the source object store, not the
target object store---clearing is very much intentional, I think.
An operation like clone, fetch and push can involve two obj
Martin Ågren writes:
>> -Git omitted 01/01/1970
>> GIT-ADD(1)
>> + omitted 1970-01-01
>> GIT-ADD(1)
>
> Yeah, I should be able to post v3 of my refmiscinfo-series this evening,
> which should fix th
Palmer Dabbelt writes:
> ... It looks
> like there are some test failures when I rebase to the latest master,
> which I'm happy to fix. Just let me know if I should:
> * Send just the first 4 patches, holding onto the last one for later.
> ...
> * Send just a single patch, which wouldn't add t
Jeff King writes:
> - a way to independently specify the source pathspec and the
> output-limiting pathspec. This is a cheaper version of the one
> above, where you could look at a subset of the tree a sources, but
> limit the set of shown paths even further. It's not conceptually
>
Paul Mackerras writes:
> Hi Junio,
>
> Whenever it's convenient, please do a pull from my gitk repository at
> git://ozlabs.org/~paulus/gitk.git to get four commits updating gitk.
>
> Thanks,
> Paul.
Will do. Thanks.
"brian m. carlson" writes:
> Users may or may not read the documentation, but at least we've done our
> best at providing them helpful information should they choose to do so.
Good.
> Documentation/git-commit-tree.txt | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/Documentation
Jeff King writes:
> On Fri, Sep 13, 2019 at 03:29:00PM -0700, Junio C Hamano wrote:
>
>> This comment has nothing to do with the change, but the way the
>> patch is presented is quite hard to follow, in that the preimage or
>> the common context lines do not help underst
Denton Liu writes:
>> > -set-branch ((-d|--default)|(-b|--branch )) [--] ::
>>
>> I say "almost", as it gives a wrong impression that you can give
>> "-b" without "" X-<.
>>
>> Now what does the updated text say to us?
>>
>> > +set-branch (-d|--default)|(-b|--branch ) [--] ::
>>
>> I think th
Christian Couder writes:
> +/*
> + * Record the offsets needed in our reused packfile chunks due to
> + * "gaps" where we omitted some objects.
> + */
The meaning of 'start' and 'offset' is unclear from the first
reading. Is it "starting offset" and "for how many bytes the region
lasts"? If so
Christian Couder writes:
> From: Jeff King
>
> Let's make it possible to configure if we want pack reuse or not.
>
> Signed-off-by: Jeff King
> Signed-off-by: Christian Couder
> ---
> builtin/pack-objects.c | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/builti
Elijah Newren writes:
>> Also, you talked about tracked paths in the proposed log message; do
>> they not participate in reproducing the issue(s)?
>
> If there is only one directory which has no tracked files, then the
> user can clean up the files -- but confusingly, they have to issue the
> sam
William Baker writes:
>> I also see in the code that
>> handles opts.batch_size that there is a workaround for this inverted
>> code structure to make sure subcommands other than repack does not
>> allow --batch-size option specified.
>
>> we probably would want to correct the use
>> of parse_opt
Elijah Newren writes:
> The way match_pathspec_item() handles names and pathspecs with trailing
> slash characters, in conjunction with special options like
> DO_MATCH_DIRECTORY and DO_MATCH_LEADING_PATHSPEC were non-obvious, and
> broken until this patch series. Add a table in a comment explain
Elijah Newren writes:
> For git clean, if a directory is entirely untracked and the user did not
> specify -d (corresponding to DIR_SHOW_IGNORED_TOO), then we usually do
> not want to remove that directory and thus do not recurse into it.
Makes sense. To clean named paths in such a directory, w
Elijah Newren writes:
> For a pathspec like 'foo/bar' comparing against a path named "foo/",
> namelen will be 4, and match[namelen] will be 'b'. The correct location
> of the directory separator is namelen-1.
And the reason why name[namelen-1] may not be slash, in which case
your new code make
Elijah Newren writes:
> +test_expect_failure 'git clean handles being told what to clean' '
> + mkdir -p d1 d2 &&
> + touch d1/ut d2/ut &&
> + git clean -f */ut &&
> + test_path_is_missing d1/ut &&
> + test_path_is_missing d2/ut
> +'
Looks like d1 and d2 are new directories a
Jeff King writes:
>> Thanks for spotting it. I wonder if it was broken like this forever
>> since the beginning X-<.
>
> Not quite since the beginning; it comes from 8d2dfc49b1
> (process_{tree,blob}: show objects without buffering, 2009-04-10). I
> suspect nobody noticed because the cost for th
Denton Liu writes:
> Remove surrounding parentheses so that the "index term" syntax is not
> triggered (and because it looks nicer without them anyway ;) ).
"Correct" always trumps "nicer", though ;-)
The $USAGE string in the script describes the available options to
this subcommand like so:
SZEDER Gábor writes:
>> Using a procedure whose output is fed to xargs has an advantage that
>> a platform with very short command line limit can still work with
>> many source files, but the way you create and use COCCI_SOURCES in
>> this patch would defeat that advantage anyway,
>
> COCCI_SOURC
Jeff King writes:
> On Wed, Sep 11, 2019 at 09:11:00PM -0700, Stephen P. Smith wrote:
>
>> Range Diff:
>> 1: f4170ad553 ! 1: e2b8322d58 Quit passing 'now' to date code
>> [...]
>
> Thanks, this version addresses all of my concerns from v1 (and overall
> looks good).
Yup, the result of applying
Jeff King writes:
> On Fri, Sep 13, 2019 at 01:52:40AM +, brian m. carlson wrote:
>
>> We also need to teach xmlto how to use the namespaced DocBook XSLT
>> stylesheets instead of the non-namespaced ones it usually uses.
>> Normally these stylesheets are interchangeable, but the non-namespace
Denton Liu writes:
> After looking through the source files in compat/ and investigating the
> files' content and/or its Git history, I've determined the list of files
> that were copied from a third-party source. Place the names of these
> files into the THIRD_PARTY_SOURCES variable in the Makef
Denton Liu writes:
> Currently, the completion function for rebase and archive don't take
> advantage of __gitcomp_builtin(). Teach them to use it so that future
> changes to options will automatically be included by the completion
> script with no extra work.
Nice ;-)
"Garima Singh via GitGitGadget" writes:
> diff --git a/Documentation/git-commit-graph.txt
> b/Documentation/git-commit-graph.txt
> index eb5e7865f0..ca0b1a683f 100644
> --- a/Documentation/git-commit-graph.txt
> +++ b/Documentation/git-commit-graph.txt
> @@ -10,8 +10,8 @@ SYNOPSIS
>
>
"William Baker via GitGitGadget" writes:
> [verse]
> -'git multi-pack-index' [--object-dir=]
> +'git multi-pack-index' [--object-dir=] [--[no-]progress]
I am wondering what the reasoning behind having this new one *after*
the subcommand while the existing one *before* is. Isn't the
--[no-]pr
Johannes Schindelin writes:
> Hi Max,
>
> The patch looks good to me!
Thanks, both. Will queue.
Denton Liu writes:
> +FIND_C_SOURCES = $(filter %.c,$(shell $(FIND_SOURCE_FILES)))
> +COCCI_SOURCES = $(filter-out $(THIRD_PARTY_SOURCES),$(FIND_C_SOURCES))
The former is somewhat misnamed. FIND_SOURCE_FILES is *not* a list
of source files---it is a procedure to list source files to its
standar
Denton Liu writes:
> Unify the two possible invocations in $(FIND_SOURCE_FILES) by using sed
> to remove the `./` prefix in the $(FIND) case.
> diff --git a/Makefile b/Makefile
> index b88b42d7ed..e2c693440b 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -2610,6 +2610,7 @@ FIND_SOURCE_FILES = ( \
"Cameron Steffen via GitGitGadget" writes:
> From: Cameron Steffen
>
> Move a closing backtick that was placed one character too soon.
>
> Signed-off-by: Cameron Steffen
> ---
> Documentation/pretty-formats.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Thanks for spotting and fi
Johannes Schindelin writes:
>> * pd/fetch-jobs (2019-08-13) 5 commits
>> . fetch: make --jobs control submodules and remotes
>> . fetch: add the --submodule-fetch-jobs option
>> . fetch: add the fetch.jobs config key
>> . fetch: add the "--fetch-jobs" option
>> . fetch: rename max_children t
Jeff King writes:
>> I was surprised we ever called repo_get_commit_tree() at all, since
>> we're literally just traversing commits here. It looks like
>> list-objects.c is very happy to queue pending trees for each commit,
>> even if we're just going to throw them away when we get to
>> process_
Thomas Gummerer writes:
> On 09/11, Johannes Schindelin wrote:
>> Hi Thomas,
>>
>> On Fri, 6 Sep 2019, Thomas Gummerer wrote:
>> > Oops, I didn't realize there was another series in flight that also
>> > introduces 'repo_refresh_and_write_index'. Probably should have done
>> > a test merge of t
Junio C Hamano writes:
>> fwrite(final_buf.buf, 1, final_buf.len, stdout);
>> +if (final_buf.len)
>> +putchar('\n');
>
> While we are introducing a conditional, let's drop the useless
> fwrite of 0-byte while we are at
Eric Freese writes:
> If the format string expands to an empty string for a given ref, do not
> print the empty line.
>
> This is helpful when wanting to print only certain kinds of refs that
> you can't already filter for.
We tend to prefer stating the reason why we want to do so first and
then
Jeff King writes:
> I wondered also if this means we should be using OBJECT_INFO_QUICK.
> I.e., do we expect to see a "miss" here often, forcing us to re-scan the
> packed directory?
As a performance optimization hack, it is OK if we did not notice
that the tree object, which corresponds to what
"brian m. carlson" writes:
> On 2019-09-07 at 17:26:53, Junio C Hamano wrote:
>> * bc/object-id-part17 (2019-08-19) 26 commits
>> - midx: switch to using the_hash_algo
>> ...
>> - builtin/replace: make hash size independent
>>
>> Preparat
Sebastian Gniazdowski writes:
> Hello,
> if the password contains a hash, then it's impossible to clone a
> repository, either with https or ssh protocols. I've had to use a
> `gitg' GUI to clone such a repo.
Hmph, do you mean that
git clone https://user:passw...@hosting.site/repository
201 - 300 of 31372 matches
Mail list logo
