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 '.'
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 c
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
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
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
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
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
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.
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
>>
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
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
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
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
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
is likely that I'd parrot these fixup commits or
result of "commit --amend" to the list if we take that route.
Johannes Schindelin writes:
> Hi Junio,
>
> On Wed, 10 Oct 2018, Junio C Hamano wrote:
>
>> We haven't seen much complaints and breakages reported against the
&g
Johannes Schindelin writes:
> Hi Junio,
>
> On Wed, 10 Oct 2018, Junio C Hamano wrote:
>
>> * js/mingw-wants-vista-or-above (2018-10-04) 3 commits
>> - mingw: bump the minimum Windows version to Vista
>> - mingw: set _WIN32_WINNT explicitly for Git for Wind
Christian Couder writes:
> So I think one solution to this problem is already proposed on our web site.
OK, that's a good start. The next step is to make those who are
involved in these education programs to be more aware of it ;-)
Ævar Arnfjörð Bjarmason writes:
> - We use this warning as a proxy for "let's not run for a day",
>otherwise we'll just grind on gc --auto trying to consolidate
>possibly many hundreds of K of loose objects only to find none of
>them can be pruned because the run into the expiry
Johannes Schindelin writes:
> Personally, I find the "whoever is picking it up should do the thinking"
> much too harsh for a first-time contributor who specifically came through
> the Outreachy program, i.e. expected to have a gentle introduction into
> the project, and into the ways we work.
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 haven't seen much complaints
Forwarding to Jonathan, as I think this is an interesting supporting
vote for the topic that we were stuck on.
Eric Wong writes:
> Martin Langhoff wrote:
>> Hi folks,
>>
>> Long time no see! Importing a 3GB (~25K revs, tons of files) SVN repo
>> I hit the gc error:
>>
>> warning: There are
Daniels Umanovskis writes:
> +--current::
> + Print the name of the current branch. In detached HEAD state,
> + or if otherwise impossible to resolve the branch name, print
> + "HEAD".
Where does "if otherwise impossible to resolve" come from? In the
code in [PATCH 1/2], we see
Christian Hesse writes:
> From: Christian Hesse
>
> We have targets 'install-man' and 'install-html', let's add build
> targets as well.
> ...
> +man: $(GIT_SUBTREE_DOC)
> +
> +html: $(GIT_SUBTREE_HTML)
> +
As 'contrib' material without real maintenance, I do not care too
deeply, but
Josh Steadmon writes:
> ### Fuzz testing
> #
> -.PHONY: fuzz-clean fuzz-objs fuzz-compile
> +.PHONY: fuzz-clean fuzz-objs fuzz-compile fuzz-all
> ...
> FUZZ_CFLAGS = $(CFLAGS) -fsanitize-coverage=trace-pc-guard -fsanitize=address
> ...
> +
> +fuzz-all: $(FUZZ_PROGRAMS)
I guess I read your
Josh Steadmon writes:
> +FUZZ_OBJS += fuzz-pack-headers.o
> +
> +FUZZ_PROGRAMS += $(patsubst %.o,%,$(FUZZ_OBJS))
> +
> ...
> +### Fuzz testing
> +#
> +.PHONY: fuzz-clean fuzz-objs fuzz-compile
I take it that you anticipate the fuzz programs in the future all
be named fuzz-$(blah), whose source
Noam Postavsky writes:
> For octopus merges where the first parent edge immediately merges into
> the next column to the left:
>
> | *-.
> | |\ \
> |/ / /
>
> then the number of columns should be one less than the usual case:
>
> | *-.
> | |\ \
> | | | *
I had a bit hard time parsing the above,
Jonathan Tan writes:
> After feedback, I restricted this to partial clone. Once restricted, I
> agree with Ben that this can be done for all users of
> cache_tree_update(), not just unpack-trees, so I have removed the
> ability to control the behavior using a flag.
Makes sense. Great.
> I
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. If you
understood the message you are responding to that use of hardcoded
value
Jeff King writes:
> +static void strbuf_add_varint(struct strbuf *out, uintmax_t val)
> +{
> + size_t len;
> + strbuf_grow(out, 16); /* enough for any varint */
> + len = encode_varint(val, (unsigned char *)out->buf + out->len);
> + strbuf_setlen(out, out->len + len);
> +}
> +
>
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, which puts "foo.bar" after "foo".
If we truly cared, it is easy enough to
Daniels Umanovskis writes:
> I often find myself needing the current branch name, for which
> currently there's git rev-parse --abrev-ref HEAD. I would expect
> `git branch` to have an option to output the branch name instead.
[jc: wrapped an overlong line]
If "git branch" had many operations
Derrick Stolee writes:
> On 10/8/2018 1:05 PM, Ananya Krishna Maram wrote:
>> Hi All,
> Hello, Ananya! Welcome.
>
>> I was searching through #leftovers and found this.
>> https://public-inbox.org/git/cabpp-bgvvxcbzx44er6to-pusfen_6gnyj1u5cuon9deaa4...@mail.gmail.com/
>>
>> This patch address the
Jonathan Tan writes:
> @@ -1635,6 +1635,7 @@ int unpack_trees(unsigned len, struct tree_desc *t,
> struct unpack_trees_options
> o->result.cache_tree = cache_tree();
> if (!cache_tree_fully_valid(o->result.cache_tree))
>
Jonathan Tan writes:
> Because cache_tree_update() is used from multiple places, this new
> behavior is guarded by a new flag WRITE_TREE_SKIP_WORKTREE_MISSING_OK.
The name of the new flag is mouthful, but we know we do not need to
materialize these blobs (exactly because the skip-worktree bit
"Derrick Stolee via GitGitGadget" writes:
> diff --git a/builtin/repack.c b/builtin/repack.c
> index c6a7943d5c..7925bb976e 100644
> --- a/builtin/repack.c
> +++ b/builtin/repack.c
> @@ -432,6 +432,10 @@ int cmd_repack(int argc, const char **argv, const char
> *prefix)
>
>
"Derrick Stolee via GitGitGadget" writes:
> From: Derrick Stolee
>
> When closing a multi-pack-index, we intend to close each pack-file
> and free the struct packed_git that represents it. However, this
> line was previously freeing the array of pointers, not the
> pointer itself. This leads to
Derrick Stolee writes:
> I see these failures, too, but I believe they are due to
> ds/commit-graph-with-grafts not being merged to 'next' yet. The
> purpose of that branch is to fix these test breaks. The environment
> variable got merged a lot faster.
A separate "ping" would have helped me.
Stephen & Linda Smith writes:
> Junio - I've been working this but would like your opinion on 7500, 7501 and
> now 7510.
>
> I note that the the commit tests have intermixed functionality. An example
> is
> signoff tests that are in the three tests I mentioned.
>
> I've been tempted
Junio C Hamano writes:
>> There is one crucial difference: the exit code.
>
> OK, and it was good that you explicitly said "with exit code 0" in
> the log message. Together with the idea to update the doc I floated
> earlier, this probably is worth documenting, too
Jeff King writes:
> I think that is the best we could do for "-S", though, which is
> inherently about counting hits.
>
> For "-G", we are literally grepping the diff. It does not seem
> unreasonable to add the ability to grep only "-" or "+" lines, and the
> interface for that should be pretty
Johannes Schindelin writes:
> Hi Junio,
>
> On Fri, 5 Oct 2018, Junio C Hamano wrote:
>
>> "Johannes Schindelin via GitGitGadget"
>> writes:
>>
>> > From: Johannes Schindelin
>> >
>> > The 'edit' command can be used to cherry-
Junio C Hamano writes:
> Antonio Ospite writes:
>
>> Finally, add t7416-submodule-sparse-gitmodules.sh to verify that reading
>> from .gitmodules succeeds and that writing to it fails when the file is
>> not checked out.
>> ...
>> t/t7416
Antonio Ospite writes:
> Finally, add t7416-submodule-sparse-gitmodules.sh to verify that reading
> from .gitmodules succeeds and that writing to it fails when the file is
> not checked out.
> ...
> t/t7416-submodule-sparse-gitmodules.sh | 78 ++
This now triggers
Ævar Arnfjörð Bjarmason writes:
> Depending on how we're counting there's at least two.
I thought you were asking "why the special sentinel is not 0{40}?"
You counted the number of reasons why 0{40} is used to stand in for
a real value, but that was the number I didn't find interesting in
the
Stefan Beller writes:
> On Sun, Oct 7, 2018 at 1:07 PM Junio C Hamano wrote:
>>
>> Junio C Hamano writes:
>
>> > ...
>> > by general public and I do not have to explain the choice to the
>> > general public ;-)
>>
>> One thing t
Julia Lawall writes:
>> Doing the same for -S is much harder at the machinery level, as it
>> performs its thing without internally running "diff" twice, but just
>> counts the number of occurrences of 'foo'---that is sufficient for
>> its intended use, and more efficient.
>
> There is still the
SZEDER Gábor writes:
> There is certainly potential there. With a (very) rough PoC
> experiment, a 8MB bloom filter, and a carefully choosen path I can
> achieve a nice, almost 25x speedup:
>
> $ time git rev-list --count HEAD -- t/valgrind/valgrind.sh
> 6
>
> real0m1.563s
> user
Johannes Sixt writes:
> Am 07.10.18 um 21:06 schrieb Ævar Arnfjörð Bjarmason:
>> Picking any one number is explained in the comment. I'm asking why 17 in
>> particular not for correctness reasons but as a bit of historical lore,
>> and because my ulterior is to improve the GC docs.
>>
>> The
Junio C Hamano writes:
> Ævar Arnfjörð Bjarmason writes:
>
>> 1. We still have this check of objects/17/ in builtin/gc.c today. Why
>>objects/17/ and not e.g. objects/00/ to go with other 000* magic such
>>as the 000
Ævar Arnfjörð Bjarmason writes:
> 1. We still have this check of objects/17/ in builtin/gc.c today. Why
>objects/17/ and not e.g. objects/00/ to go with other 000* magic such
>as the SHA-1?d Statistically
>it doesn't matter, but 17 seems like
Nguyễn Thái Ngọc Duy writes:
> diff --git a/refs/files-backend.c b/refs/files-backend.c
> index 2dd77f9485..9ca2a3706c 100644
> --- a/refs/files-backend.c
> +++ b/refs/files-backend.c
> ...
> case REF_TYPE_PSEUDOREF:
> strbuf_addf(sb, "%s/logs/%s", refs->gitdir, refname);
>
Steve writes:
> Since stash list accepts git-log options, add the following useful
> options that make sense in the context of the `git stash list` command:
>
> --name-status --oneline --patch-with-stat
>
> Signed-off-by: Steven Fernandez
> ---
>
> This is my first patch to the project so
Stefan Beller writes:
> On Thu, Sep 27, 2018 at 12:24 PM Jonathan Tan
> wrote:
>
>>
>> +test_expect_success 'when dynamically fetching missing object, do not list
>> refs' '
>> + cat trace &&
>
> leftover debug cat?
It does look that way.
Ævar Arnfjörð Bjarmason writes:
> On Sat, Oct 6, 2018 at 5:16 PM Julia Lawall wrote:
>> Git log -S or -G make it possible to find commits that have particular
>> words in the changed lines. Sometimes it would be helpful to search for
>> words in the removed lines or in the added lines
Stefan Beller writes:
> After ff6f1f564c4 (submodule-config: lazy-load a repository's .gitmodules
> file, 2017-08-03) this is no longer necessary, but that commit did not
> cleanup the whole tree, but just show cased the new way how to deal with
> submodules in ls-files.
The log message of the
Stefan Beller writes:
> In f9ee2fcdfa (grep: recurse in-process using 'struct repository',
> 2017-08-02), we introduced a call to repo_read_gitmodules in builtin/grep
> to simplify the submodule handling.
>
> After ff6f1f564c4 (submodule-config: lazy-load a repository's .gitmodules
> file,
Matthew DeVore writes:
> The name "tree:0" allows later filtering based on depth, i.e. "tree:1"
> would filter out all but the root tree and blobs. In order to avoid
> confusion between 0 and capital O, the documentation was worded in a
> somewhat round-about way that also hints at this future
Matthew DeVore writes:
> This version of the patchset fixes some wording and formatting issues
> pointed out by Junio. The commit message in the first patch has also
> been reworded.
Thanks.
If no further major issues are raised, let's merge it to 'next'.
"Johannes Schindelin via GitGitGadget"
writes:
> Note: while this patch targets pk/rebase-in-c-6-final, it will not work
> correctly without ag/rebase-i-in-c. So my suggestion is to rewrite the
> pk/rebas-in-c-6-final branch by first merging ag/rebase-i-in-c, then
> applying this here patch,
Stefan Beller writes:
>> static int module_config(int argc, const char **argv, const char *prefix)
>> {
>> + enum {
>> + CHECK_WRITEABLE = 1
>> + } command = 0;
>
> Can we have the default named? Then we would only use states
> from within the enum?
Why? Do we use a
Ananya Krishna Maram writes:
>> But it does not need to be escaped, when you specify the regular
>> expression the way we do. And the way we specified it is really the
>> standard when specifying regular expressions in C code, i.e. *without* the
>> suggested backslash.
>
> Aha!. this makes total
Duy Nguyen writes:
>> > The main worktree has to be treated specially because well.. it's
>> > special from the beginning. So HEAD from the main worktree is
>> > acccessible via the name "main/HEAD" (we can't use
>> > "worktrees/main/HEAD" because "main" under "worktrees" is not
>> > reserved).
These releases fix a security flaw (CVE-2018-17456), which allowed an
attacker to execute arbitrary code by crafting a malicious .gitmodules
file in a project cloned with --recurse-submodules.
When running "git clone --recurse-submodules", Git parses the supplied
.gitmodules file for a URL field
Matthew DeVore writes:
> Add the following guideline to Documentation/CodingGuidelines:
>
> &&, ||, and | should appear at the end of lines, not the
> beginning, and the \ line continuation character should be
> omitted
"should be omitted" sounds as if it is the norm to have
Matthew DeVore writes:
> Some pipes in tests lose the exit code of git processes, which can mask
> unexpected behavior like crashes. Split these pipes up so that git
> commands are only at the end of pipes rather than the beginning or
> middle.
>
> The violations fixed in this patch were found
Jeff King writes:
> On Fri, Oct 05, 2018 at 04:20:27PM +0200, Ævar Arnfjörð Bjarmason wrote:
>
>> I.e. something to generate the .gitattributes file using this format:
>>
>> https://git-scm.com/docs/gitattributes#_packing_objects
>>
>> Some stuff is obvious, like "*.gpg binary -delta", but I'm
Rasmus Villemoes writes:
>> It also is strange to count from (0); if the patchset is rerolled
>> again, I'd prefer to see these start counting from (1), in which
>> case this item will become (3).
>
> If you prefer, I can send a v4.
Sure, if you prefer, you can send a v4 for me to look at and
Tao Qingyun writes:
> ---
> builtin/branch.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/builtin/branch.c b/builtin/branch.c
> index c396c41533..52aad0f602 100644
> --- a/builtin/branch.c
> +++ b/builtin/branch.c
> @@ -222,10 +222,11 @@ static int
Rasmus Villemoes writes:
> As discussed in the thread for v1 of this patch [1] [2], this changes the
> rules for "git foo --help" when foo is an alias.
>
> (0) When invoked as "git help foo", we continue to print the "foo is
> aliased to bar" message and nothing else.
>
> (1) If foo is an alias
Stefan Beller writes:
> git-grep is always file/tree recursive, but there is --recurse-submodules
> which is off by default. Instead of providing a short alias to a noop,
> we could use -r for submodules. (And if you happen to have no
> submodules, this is a noop for you)
I am not sure if it is
René Scharfe writes:
>
> Recognize -r and --recursive as synonyms for --max-depth=-1 for
> compatibility with GNU grep; it's still the default for git grep.
>
> This also adds --no-recursive as synonym for --max-depth=0 for free,
> which is welcome for completeness and consistency.
>
> Fix the
Matthew DeVore writes:
> I screwed up by putting the positional argument *after* the
> redirection. Sorry for the mix-up. This is interestingly syntactically
> valid, though bad stylistically. Here is an inter-diff:
Thanks for being careful. Except for a rather idiomatic
echo >&2
"Johannes Schindelin via GitGitGadget"
writes:
> From: Johannes Schindelin
>
> The 'edit' command can be used to cherry-pick a commit and then
> immediately drop out of the interactive rebase, with exit code 0, to let
> the user amend the commit, or test it, or look around.
>
> Sometimes this
Mihir Mehta writes:
> diff --git a/Documentation/git-diff.txt b/Documentation/git-diff.txt
> index b180f1fa5..6173f569e 100644
> --- a/Documentation/git-diff.txt
> +++ b/Documentation/git-diff.txt
> @@ -72,8 +72,9 @@ two blob objects, or changes between two files on disk.
> This form is to
SZEDER Gábor writes:
> On Fri, Sep 28, 2018 at 06:24:53PM +0200, SZEDER Gábor wrote:
>> Interdiff:
>> diff --git a/t/t1700-split-index.sh b/t/t1700-split-index.sh
>> index c8acbc50d0..f053bf83eb 100755
>> --- a/t/t1700-split-index.sh
>> +++ b/t/t1700-split-index.sh
>> @@ -6,6 +6,9 @@
Matthew DeVore writes:
> diff --git a/t/README b/t/README
> index 9028b47d9..85024aba6 100644
> --- a/t/README
> +++ b/t/README
> @@ -393,13 +393,13 @@ This test harness library does the following things:
> consistently when command line arguments --verbose (or -v),
> --debug (or -d),
Michał Górny writes:
> On Fri, 2018-08-17 at 09:34 +0200, Michał Górny wrote:
>> GnuPG supports creating signatures consisting of multiple signature
>> packets. If such a signature is verified, it outputs all the status
>> messages for each signature separately. However, git currently does not
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 fall under "cleanup unnecessary files", which the
> commit-graph file is, since,
Jeff King writes:
> And I think this has to be stderr. We're polluting the output of the
> aliased command with our extra message, so we have two choices:
>
> 1. Pollute stderr, and risk copious stdout (or a pager) scrolling it
> off the screen.
>
> 2. Pollute stdout, at which point our
ups on string-list).
Signed-off-by: Junio C Hamano
---
builtin/fetch.c | 121 +---
1 file changed, 94 insertions(+), 27 deletions(-)
diff --git a/builtin/fetch.c b/builtin/fetch.c
index 0696abfc2a..489531ec93 100644
--- a/builtin/fetch.c
+++ b/builtin/fetc
Stefan Xenos writes:
> What is the evolve command?
> ...
> - Systems like gerrit would no longer need to rely on "change-id" tags
> in commit comments to associate commits with the change that they
> edit, since git itself would have that information.
> ...
> Is anyone else interested in this?
Jonathan Tan writes:
> This was prompted by a user at $DAY_JOB who had a partial clone
> excluding trees, and had a workflow that only required tree objects (and
> not blobs).
>
> This will hopefully make partial clones excluding trees (with the
> "tree:0" filter) a bit better, in that if an
Jeff King writes:
> Wow, what's old is new again. Here's more or less the same patch from
> 2012:
>
> https://public-inbox.org/git/20120407033417.ga13...@sigill.intra.peff.net/
>
> Unfortunately, some people seem to rely on this multi-helper behavior. I
> recommend reading the whole thread, as
Ramsay Jones writes:
> You probably already know, but I had to add this on top of the 'pu'
> branch to get a clean compile tonight (your 'jc/war-on-string-list'
> branch).
It was not just about squelching a warning but simply broken code
that deserved to be warned/errored. I think what we have
Jeff King writes:
> On Wed, Sep 26, 2018 at 03:59:08PM -0700, Stefan Beller wrote:
>
>> > +struct refname_hash_entry {
>> > + struct hashmap_entry ent; /* must be the first member */
>>
>> $ git grep "struct hashmap_entry" reveals that we have another
>> convention that we follow but not
Duy Nguyen writes:
> On Wed, Sep 26, 2018 at 03:54:38PM -0400, Ben Peart wrote:
>> +
>> +#define EOIE_SIZE (4 + GIT_SHA1_RAWSZ) /* <4-byte offset> + <20-byte hash>
>> */
>> +#define EOIE_SIZE_WITH_HEADER (4 + 4 + EOIE_SIZE) /* <4-byte signature> +
>> <4-byte length> + EOIE_SIZE */
>
> If you
Jeff King writes:
> Right, I'm proposing only to add the extra message and then continue as
> usual.
>
> It is a little funny, I guess, if you have a script which doesn't
> respond to "-h", because you'd get our "foo is aliased to git-bar"
> message to stderr, followed by who-knows-what. But as
Ævar Arnfjörð Bjarmason writes:
> This --recursive (-r) option does nothing, and is purely here to
> appease people who have "grep -r ..." burned into their muscle memory.
>
> Requested-by: Christoph Berg
> Signed-off-by: Ævar Arnfjörð Bjarmason
> ---
I personally am not all that sympathetic
Jonathan Nieder writes:
> My experience is that bug reporters are very sensitive to hints the
> project gives about what kind of bugs they want to receive. I'd
> rather make use of that lesson now instead of waiting to relearn it in
> the wild. Here goes.
OK. This unfortunately came a bit
Sam McKelvie writes:
>> Or perhaps
>>
>> rev-parse: --show-superproject-working-tree should work during a merge
>>
>> may be more to the point. It does not hint the root cause of the
>> bug like the other one, but is more direct how the breakage would
>> have been observed by the end users.
Ramsay Jones writes:
>> if (!nr) {
>> ieot_blocks = istate->cache_nr / THREAD_COST;
>> - if (ieot_blocks < 1)
>> - ieot_blocks = 1;
>> cpus = online_cpus();
>>
Junio C Hamano writes:
> ... However, because the same mistakes are inherited to
> builtin/rebase.c by these topics, we'd need a matching fix to
> correct 07664161 ("builtin rebase: error out on incompatible
> option/mode combinations", 2018-08-08) and either squash the
Ralf Thielow writes:
> Signed-off-by: Ralf Thielow
> ---
> git-rebase.sh | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
This patch itself will soon stop mattering once the group of
rebase-in-c topics graduate, which hopefully will happen during this
cycle. However, because the
Stefan Beller writes:
> The previous patch suggested the strbuf header to be the leading example
> of how we would want our APIs to be documented. This may lead to some
> scrutiny of that code and the coding style (which is different from the
> API documentation style) and hence might be taken
Junio C Hamano writes:
> I actually do not mind the rule to be more like
>
> * Use the same parameter names used in the function declaration when
>the description in the API documentation refers the parameter.
Assuming that we adopt the above guideline, let's extending it to
Junio C Hamano writes:
> Stefan Beller writes:
>
>> So let's format strbuf.h in a way that we'd like to see:
>> * omit the extern keyword from function declarations
>
> OK
>
>> * name all parameters (usually the parameters are obvious from its type,
>>
Stefan Beller writes:
> So let's format strbuf.h in a way that we'd like to see:
> * omit the extern keyword from function declarations
OK
> * name all parameters (usually the parameters are obvious from its type,
> but consider exceptions like
> `int strbuf_getwholeline_fd(struct strbuf
Kyle Hubert writes:
> Subject: Re: [PATCH] Improvement to only call Git Credential Helper once
Nobody will send in a patch to worsen things, so phrases like
"Improvement to" that convey no useful information has no place on
the title.
There probably are multiple ways that credential helpers
Ben Peart writes:
> Junio, can you squash in the following patch or would you prefer I
> reroll the entire series?
Squash it to f8cd77d5 ("fsmonitor: update GIT_TEST_FSMONITOR
support", 2018-09-18) and use the two new lines in the log message?
I can do that.
Thanks.
701 - 800 of 27729 matches
Mail list logo
