Taylor Blau writes:
> On Thu, Sep 27, 2018 at 09:49:36PM -0700, Stephen P. Smith wrote:
>> When updating the collect and print functions, it was found that
>> status variables were initialized in the collect phase and some
>> variables were later freed in the print functions.
>
> Nit: I think
Jonathan Nieder writes:
> (dropping cc-s to my internal address that I don't use on this list
> and to git-c...@google.com which bounces)
> Hi,
>
> Stefan Beller wrote:
>
>> Internally we have rolled out this as an experiment for
>> "submodules replacing the repo tool[1]". The repo tool is
Sam McKelvie writes:
>> Ah, that, too. I meant to correct triple ell, though ;-)
>> ...
>
> I wholeheartedly approve of that plan and your tweaking commit below. Thank
> you, Junio.
Thanks for a fix. But now I re-read the title and think about it,
this is mistitled. The word 'stage' in
SZEDER Gábor writes:
> Junio,
>
> On Thu, Sep 27, 2018 at 02:44:30PM +0200, SZEDER Gábor wrote:
>> diff --git a/t/t1701-racy-split-index.sh b/t/t1701-racy-split-index.sh
>> new file mode 100755
>> index 00..ebde418d7e
>> --- /dev/null
>> +++ b/t/t1701-racy-split-index.sh
>> @@ -0,0
Ben Peart writes:
>> Why does multithreading have to be disabled in this test?
>
> If multi-threading is enabled, it will write out the IEOT extension
> which changes the SHA and causes the test to fail.
I think it is a design mistake to let the writing processes's
capability decide what is
Rasmus Villemoes writes:
>>> + if (follow_alias > 0) {
>>> + fprintf_ln(stderr,
>>> + _("Continuing to help for %s in %0.1f
>>> seconds."),
>>> + alias, follow_alias/10.0);
>>> +
Martin Ågren writes:
>> Hm. I think this encourages a behavior that I want to discourage:
>> assuming that if a bug has already been reported then there's nothing
>> more for the new user to add.
>
> It was my hope that all of these could be inferred from the above text:
>
> "I'll just drop a
.h files, and the development
community generally considers that how inline docs in strbuf.h is
done the best current practice.
We recommend documenting in the header over documenting near the
implementation to encourage people to write the docs that are
readable without peeking at the implementio
Taylor Blau writes:
> On Wed, Sep 26, 2018 at 10:28:31AM -0700, Junio C Hamano wrote:
>> Duy Nguyen writes:
>>
>> > Here's the patch that adds that external commands and aliases
>> > sections. I feel that external commands section is definitely good to
>>
Sam McKelvie writes:
>>> Subject: Re: [PATCH] submodule: Alllow staged changes for
>>> get_superproject_working_tree
>>
>> s/Alllow/allow/;
>>
>
> Ok, no caps on first letter of subject.
Ah, that, too. I meant to correct triple ell, though ;-)
When one reviewer says Reviewed-by: but you
Jeff King writes:
> Alternatively, %(HEAD) could return "*" or "+" depending on whether it's
> the current worktree head. That would mildly break an existing format
> like:
>
> %(if)%(HEAD)%(then) *%(color:green)%(end)%(refname)
>
> since it would start coloring worktree HEADs the same way. It
Josh Steadmon writes:
> Yes, the version on my desktop sends version=2 when archiving:
>
> ∫ which git
> /usr/bin/git
> ∫ git --version
> git version 2.19.0.605.g01d371f741-goog
> ∫ GIT_TRACE_PACKET=${HOME}/server_trace git daemon \
> --enable=upload-archive \
>
Jonathan Nieder writes:
> 1. Clients sending version=2 when they do not, in fact, speak protocol
> v2 for a service is a (serious) bug. (Separately from this
> series) we should fix it.
>
> 2. That bug is already in the wild, alas. Fortunately the semantics of
> GIT_PROTOCOL as a
Sam McKelvie writes:
> Subject: Re: [PATCH] submodule: Alllow staged changes for
> get_superproject_working_tree
s/Alllow/allow/;
> Invoking 'git rev-parse --show-superproject-working-tree' exits with
>
> "fatal: BUG: returned path string doesn't match cwd?"
>
> when the superproject has
Stefan Beller writes:
> There are different opinions on how to document an API properly.
> Discussion turns out nobody disagrees with documenting new APIs on the
> function level in the header file and high level concepts in
Looks conditionally good ;-) Thanks for keeping the ball rolling.
I
Jeff King writes:
> On Thu, Sep 27, 2018 at 03:35:59PM -0400, Jeff King wrote:
>
>> now, we could do:
>>
>> %(if)%(HEAD)%(then)* %(color:bold green)
>> %(else)%(if)%(worktree)%(then)+ %(color:green)
>> %(else) %(end)%(end)
>>
>> (respecting the user's color config, of course, rather
Jonathan Tan writes:
> To answer Junio's questions in [1], I think it's best to include the
> full patch set that I'm developing, so here it is. The original patch is
> now patch 3 of this set.
Yeah, taking it out of context did make its purpose fuzzy. Without
the other patches in the series
Jeff King writes:
> If you're interested in pulling documentation out of the header files
> and generating asciidoc from it, I'm happy to at least try keeping it up
> to date. When we started putting this information into header files, we
> used "/**" to start the comment, as a special marker to
Stefan Beller writes:
> 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
Stefan Beller writes:
> The submodule subsystem is really bad at staying within 80 characters.
> Fix it while we are here.
>
> Signed-off-by: Stefan Beller
> ---
Makes sense.
> submodule.c | 9 ++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/submodule.c
Stefan Beller writes:
> 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 +++
>
Stefan Beller writes:
> 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
Ben Peart writes:
> Base Ref: master
> Web-Diff: https://github.com/benpeart/git/commit/a0300882d4
> Checkout: git fetch https://github.com/benpeart/git read-index-multithread-v6
> && git checkout a0300882d4
>
>
> This iteration brings back the Index Entry Offset Table (IEOT) extension
> which
Tacitus Aedifex writes:
> It may be a little more complicated than this because looking at the
> tests it seems like they set up their own dummy user with dummy keys
> and use gpg directly.
Yes, that is """the test framework (t/test-lib.sh, t/lib-gpg.sh,
etc.) tries to run our tests in a
Ævar Arnfjörð Bjarmason writes:
> So in terms of implementation I'm a big fan of the perl.git approach of
> having these docs as comments before the function implementation in the
> *.c file.
>
> It means you can't avoid seeing it or updating it when source
> spelunking, and it leaves header
o hashmaps and one string list---the hashmaps
are used for look-ups and the string list is to keep the order of
items in the returned result stable (which is the only single thing
hashmap does worse than lookups on string-list).
Signed-off-by: Junio C Hamano
---
* Just to remind ourselves that we ta
Stefan Beller writes:
>> I agree on both counts. I just like to read these in plain text
>> while I am coding for Git (or reviewing patches coded for Git).
>>
>> The reason why I have mild preference to D/technical/ over in-header
>> doc is only because I find even these asterisks at the
Jeff King writes:
> Now I'll admit it seems like make-work to me because I would not plan to
> ever look at the formatted output myself. But I guess I don't understand
> the audience for this formatted output. These are APIs internal to Git
> itself. We would not generally want to install
Jeff King writes:
>> When you have "[alias] cp = cherry-pick -n", "git cp --help" should
>> not do "git help cherry-pick". Only a single word that exactly
>> matches a git command should get this treatment.
>
> I'm not sure I agree. A plausible scenario (under the rules I gave
> above) is:
>
>
Junio C Hamano writes:
> SZEDER Gábor writes:
>
>> Having said all that, I didn't omit the quotes in 4362da078e with the
>> above in mind; in fact I tend to use quotes even when they are
>> unnecessary (e.g. in variable assignments: var="$1"), because
Paul-Sebastian Ungureanu writes:
> Hello,
>
> This is a new iteration of `git stash`, based on the last review I got.
> This new iteration brings mostly code styling fix issues in order to make
> the code more readable. There is also a new patch "strbuf.c: add
> `strbuf_join_argv()`". By making
Ævar Arnfjörð Bjarmason writes:
> On Wed, Sep 26 2018, Junio C Hamano wrote:
>
>> Jeff King writes:
>>>
>>> Yes, please. I think it prevents exactly this sort of confusion. :)
>>
>> CodingGuidelines or SubmittingPatches update, perhaps?
>>
>
Taylor Blau writes:
> This pause (though I'm a little surprised by it when reviewing the
> code), I think strikes a good balance between the two, i.e., that you
> can get help for whatever it is aliased to, and see what that alias is.
And I need to react to it within subsecond with ^C when I
SZEDER Gábor writes:
> Having said all that, I didn't omit the quotes in 4362da078e with the
> above in mind; in fact I tend to use quotes even when they are
> unnecessary (e.g. in variable assignments: var="$1"), because unquoted
> variables and command substitutions freak me out before I can
Jeff King writes:
>> I do not think "sources that are not git repositories" is all that
>> interesting, unless they can also serve as the source for ext::
>> remote helper. And if they can serve "git fetch ext::...", I think
>> they can be treated just like a normal Git repository by the
>>
Derrick Stolee writes:
> In an effort to ensure new code is reasonably covered by the test
> suite, we now have contrib/coverage-diff.sh to combine the gcov output
> from 'make coverage-test ; make coverage-report' with the output from
> 'git diff A B' to discover _new_ lines of code that are
Duy Nguyen writes:
> I believe the main selling point of multiple worktrees is sharing
> refs. You could easily avoid expensive clones with --local, but
> synchronizing between different clones is not very convenient. Other
> than that, different worktrees tend to behave like separate clones.
Duy Nguyen writes:
> Here's the patch that adds that external commands and aliases
> sections. I feel that external commands section is definitely good to
> have even if we don't replace "help -a". Aliases are more
> subjective...
I didn't apply this (so I didn't try running it), but a quick
Duy Nguyen writes:
> -v was recently added just for the new "help -a" in May 2018. I think
> it's ok to get rid of it. Memory muscles probably take a couple more
> months to kick in.
If it is not hurting, keeping it lets people say "--no-verbose" to
get a less verbose output to help those who
Jeff King writes:
> On Tue, Sep 25, 2018 at 12:26:44PM -0700, Stefan Beller wrote:
>
>> On Sat, Sep 22, 2018 at 5:58 AM Ævar Arnfjörð Bjarmason
>> wrote:
>> >
>> >
>> > On Fri, Sep 21 2018, Stefan Beller wrote:
>> >
>> > > +/*
>> > > + * Apply want to each entry in array, retaining only the
Tacitus Aedifex writes:
> I keep getting prompted for my algorithm preferences while running all
> of the git test suite:
>
> Set preference list to:
> Cipher: AES256, AES192, AES, 3DES
> Digest: SHA512, SHA384, SHA256, SHA224, SHA1
> Compression: Uncompressed
> Features: MDC,
Duy Nguyen writes:
> On Wed, Sep 26, 2018 at 05:24:14PM +0200, Duy Nguyen wrote:
>> On Wed, Sep 26, 2018 at 6:46 AM Kaartic Sivaraam
>> wrote:
>> > This is the most interesting part of the issue. I **did not** run
>> >'git fetch ...' in between those cat commands. I was surprised by
>> >how the
Taylor Blau writes:
>> +help.followAlias::
>> +When requesting help for an alias, git prints a line of the
>> +form "'' is aliased to ''". If this option is
>> +set to a positive integer, git proceeds to show the help for
>
> With regard to "set to a positive integer", I'm not sure
Rasmus Villemoes writes:
> I often use 'git --help' as a quick way to get the documentation
> for a command. However, I've also trained my muscle memory to use my
> aliases (cp=cherry-pick, co=checkout etc.), which means that I often end
> up doing
>
> git cp --help
>
> to which git correctly
Taylor Blau writes:
> My reading of this is threefold:
>
> 1. There are some cosmetic changes that need to occur in t5410 and
> documentation, which are mentioned above. Those seem self
> explanatory, and I've applied the necessary bits already on my
> local version of this
Jonathan Tan writes:
> diff --git a/transport-helper.c b/transport-helper.c
> index 143ca008c8..7213fa0d32 100644
> --- a/transport-helper.c
> +++ b/transport-helper.c
> @@ -1105,6 +1105,7 @@ static struct ref *get_refs_list(struct transport
> *transport, int for_push,
> }
>
> static struct
Christian Couder writes:
> The main issue that this patch series tries to solve is that
> extensions.partialclone config option limits the partial clone and
> promisor features to only one remote. One related issue is that it
> also prevents to have other kind of promisor/partial clone/odb
>
Jonathan Tan writes:
> Whenever a lazy fetch is performed for a tree object, any trees and
> blobs it directly or indirectly references will be fetched as well.
> There is a "no_dependents" argument in struct fetch_pack_args that
> indicates that objects that the wanted object references need
Philip Oakley writes:
> +Variable name/value syntax
> +^^
> +
> All the other lines (and the remainder of the line after the section
> header) are recognized as setting variables, in the form
> 'name = value' (or just 'name', which is a short-hand to say that
> @@
Kaartic Sivaraam writes:
>> Also please try
>> "git fetch" again with GIT_TRACE=1 and GIT_TRACE_SETUP=1. Hopefully we
>> could catch something with that.
>
> $ GIT_TRACE_SETUP=1 GIT_TRACE=1 git fetch origin next
> 23:10:26.049785 trace.c:377 setup: git_dir:
>
Nguyễn Thái Ngọc Duy writes:
> This extension is most useful in multiple worktree setup because you
> now have an option to store per-worktree config (which is either
> .git/config.worktree for main worktree, or
> .git/worktrees/xx/config.worktree for linked ones).
Heh. "This is useful if you
Nguyễn Thái Ngọc Duy 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).
I
SZEDER Gábor writes:
> However, if we go for a more informative error message, then wouldn't
> it be better to add this condition in populate_value() before it even
> calls get_object()? Then we could also add the problematic format
> specifier to the error message (I think, but didn't actually
Stefan Beller writes:
> Heh, thanks for calling that out. So we're looking at a full formatter
> instead of a partial formatter that helps moving in the right direction now.
> :-/
The parts left out of these patches (e.g. use subshell when working
in a subdirectory) need human decision and a
Derrick Stolee writes:
> Another commit walk that could be improved by generation numbers? It's
> like my bat-signal!
Ah, nevermind. The "traversal" done by these helper functions is
the most stupid kind (not the algorthim, but the need). It's not
like there is an opportunity to optimize by
"Derrick Stolee via GitGitGadget" writes:
> +files=$(git diff --name-only $V1 $V2 -- *.c)
You'd want to quote that *.c from the shell, i.e. either one of
these
files=$(git diff --name-only $V1 $V2 -- \*.c)
files=$(git diff --name-only $V1 $V2 -- '*.c')
otherwise you'd lose
Derrick Stolee writes:
> @@ -622,10 +623,7 @@ int can_all_from_reach_with_flag(struct object_array
> *from,
> }
>
> cleanup:
> - for (i = 0; i < nr_commits; i++) {
> - clear_commit_marks(list[i], RESULT);
> - clear_commit_marks(list[i], assign_flag);
> -
Jeff King writes:
> Right, I think that is totally fine for the current uses. I guess my
> question was: do you envision cutting the interface down to only the
> oids to bite us in the future?
>
> I was on the fence during past discussions, but I think I've come over
> to the idea that the
SZEDER Gábor writes:
> On Mon, Sep 24, 2018 at 02:15:30PM -0700, Derrick Stolee via GitGitGadget
> wrote:
>> From: Derrick Stolee
>>
>> The index v4 format has been available since 2012 with 9d22778
>> "reach-cache.c: write prefix-compressed names in the index". Since
>> the format has been
Sebastian Kuzminsky writes:
> I've got two tiny git repos whose commit graphs are identical, but
> where 'git describe' gives different results.
> ...
> The histories differ only in the timestamps of the commits...
describe does take the commit timestamps into account, so it is
expected you
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.
The tip of 'master' has been
Jeff King writes:
> Do you have an opinion on whether for_each_alternate_refs() interface
> should stop passing back refnames? By the "they may not even exist"
> rationale in this sub-thread, I think it's probably foolish for any
> caller to actually depend on the names being meaningful.
I
Stephen Smith writes:
> I can see three solutions and could support any of the three:
> 1) Move the free calls to run_status() and cmd_status().
> 2) Move the calls calls to wt_status_print since that is the last function
> from wt_status.c that is called befor the structure goes out of scope
Jeff King writes:
> I agree that "help -av" is likely to be more friendly. I kind of wonder
> if it should just be the default for "-a". Do we have any obligation not
> to change the format of that output?
I know that at least older versions of git-completion.bash (I think
it was up to 2.17.x
Jeff King writes:
> So I think it's conceptually consistent to always show a subset.
OK. Then I agree with you that it is a good approach to first adopt
core.* knobs that universally apply, and add specialized ones as
they are needed later.
Thanks.
"brian m. carlson" writes:
>> But that is a response in a dream-world. If there is no such tool,
>> I am perfectly OK if the plan is to manually keep them (loosely) in
>> sync. I do not think it is good use of our time to try to come up
>> with such a tool (unless somebody is really interested
SZEDER Gábor writes:
> The command 'git ls-remote --sort=authordate ' segfaults when
> run outside of a repository, ever since the introduction of its
> '--sort' option in 1fb20dfd8e (ls-remote: create '--sort' option,
> 2018-04-09).
>
> While in general the 'git ls-remote' command can be run
Derrick Stolee writes:
>> +test_expect_success 'moving the file back into subdirectory' '
>> +cd path0 && git mv ../path1/COPYING COPYING
>> +'
>
> Split at &&, use subshell?
Yes, I was almost going to point out the same, saying "'reformat to
newer style' is much larger than only changing
Jeff King writes:
> That function is now called "check_connected()", but we forgot to update
> this comment in 7043c7071c (check_everything_connected: use a struct
> with named options, 2016-07-15).
>
> Signed-off-by: Jeff King
> ---
> Just a minor annoyance I happened to notice while
Jeff King writes:
> I was suggesting that check_everything_connected() is not strictly
> transport-related, so would be inappropriate for transport.*, and we'd
> need a more generic name. And my "either way" was that I could see
> an argument that it _is_ transport related, since we only call it
Jeff King writes:
> On Fri, Sep 21, 2018 at 02:09:08PM -0700, Junio C Hamano wrote:
>
>> > +test_expect_success 'setup' '
>> > + test_commit one &&
>> > + git update-ref refs/heads/a HEAD &&
>> > + test_commit two &&
>
Jeff King writes:
> There's no extension necessary; these should already affect upload-pack
> as well. I agree transport.* would cover both upload-pack and
> receive-pack. If we extend it to check_everything_connected(), would it
> make sense as part of transport.*, too?
>
> I dunno. I guess I
Junio C Hamano writes:
>> The above prototype change seems to have created a semantic conflict
>> with ds/commit-graph-tests (859fdc "commit-graph: define
>> GIT_TEST_COMMIT_GRAPH") because when GIT_TEST_COMMIT_GRAPH is set, we
>> call write_commit_graph_r
Derrick Stolee writes:
> On 9/7/2018 2:29 PM, Ævar Arnfjörð Bjarmason wrote:
>> -void write_commit_graph_reachable(const char *obj_dir, int append);
>> +void write_commit_graph_reachable(const char *obj_dir, int append,
>> + int report_progress);
>> void
"Derrick Stolee via GitGitGadget" writes:
> Changes in V3: I added a new patch that updates the tab-alignment for flags
> in revision.h before adding new ones (Thanks, Ævar!).
This is most unwelcome while other topics are in flight that caused
unnecessary conflict. It would have been very
Taylor Blau writes:
> +core.alternateRefsPrefixes::
> + When listing references from an alternate, list only references that
> begin
> + with the given prefix. Prefixes match as if they were given as
> arguments to
> + linkgit:git-for-each-ref[1]. To list multiple prefixes,
Taylor Blau writes:
> +core.alternateRefsCommand::
> + When listing references from an alternate (e.g., in the case of
> ".have"), use
It is not clear how (e.g.,...) connects to what is said in the
sentence. "When advertising tips of available history from an
alternate, use ..." without
Jonathan Tan writes:
> In acb0c57260 ("fetch: support filters", 2017-12-08), check_connected()
> was extended to allow objects to either be promised to be available (if
> the repository is a partial clone) or to be present; previously, this
> function required the latter. However, this change
Taylor Blau writes:
> In fact, I think that we can go even further: since we don't need to
> catch the beginning '^.*' (without -o), we can instead:
>
> extract_haves () {
> depacketize - | grep '\.have' | sed -e 's/\\0.*$//g'
> }
Do not pipe grep into sed, unless you have an overly
Johannes Sixt writes:
> Am 21.09.18 um 07:22 schrieb Junio C Hamano:
>> The tip of 'next' hasn't been rewound yet. The three GSoC "rewrite
>> in C" topics are still unclassified in this "What's cooking" report,
>> but I am hoping that we can have them
Ramsay Jones writes:
> BTW, I notice that patch #9 (commit-reach.h: add missing declarations
> (hdr-check)) didn't make it onto 'pu' - was there something else I
> needed to do? (I am still in two minds about sending an RFC patch
> on-top of patch #9).
I refrained from queuing it as I did not
Nguyễn Thái Ngọc Duy writes:
> diff --git a/userdiff.h b/userdiff.h
> index 2ef0ce5452..dad3fc03c1 100644
> --- a/userdiff.h
> +++ b/userdiff.h
> @@ -21,7 +21,8 @@ struct userdiff_driver {
>
> int userdiff_config(const char *k, const char *v);
> struct userdiff_driver
Taylor Blau writes:
> ...' block with your suggestion above. It's tempting to introduce it as:
>
> expect_haves() {
> printf "%s .have\n" $(git rev-parse -- $@)
> }
>
> And call it as:
>
> expect_haves one three two >expect
>
> But I'm not sure whether I think that this is better or
Eric Sunshine writes:
> On Thu, Sep 20, 2018 at 2:04 PM Taylor Blau wrote:
>> The recently-introduced "core.alternateRefsCommand" allows callers to
>> specify with high flexibility the tips that they wish to advertise from
>> alternates. This flexibility comes at the cost of some inconvenience
Taylor Blau writes:
> +extract_haves () {
> + depacketize - | grep -o '^.* \.have'
Not portable, isn't it?
cf. http://pubs.opengroup.org/onlinepubs/9699919799/utilities/grep.html
frede...@ofb.net writes:
> On Thu, Sep 20, 2018 at 06:23:03PM +0200, Duy Nguyen wrote:
>> On Wed, Sep 19, 2018 at 03:59:58PM -0700, Junio C Hamano wrote:
>> > > @@ -23,7 +26,7 @@ OPTIONS
>> > >
>> > > --mode=::
>> > >
Ramsay Jones writes:
> Signed-off-by: Ramsay Jones
> ---
>
> Hi Junio,
>
> ... and this is the patch I needed for the current 'pu' branch.
Which in turn means that this is to fix 5b338d60 ("userdiff.c:
remove implicit dependency on the_index", 2018-09-15) and should be
rolled into nd/the_index
Ramsay Jones writes:
> Signed-off-by: Ramsay Jones
> ---
>
> Hi Junio,
>
> This is the patch I needed for the current 'next' branch to get
> a clean 'hdr-check'
Which means that this is a fix on top of jt/lazy-object-fetch-fix
topic, I think.
Will apply there.
Thanks.
Antonio Ospite writes:
> Protecting the problematic submodules function could work for now, but
> I'd like to have more comments, my proposal is:
>
> diff --git a/builtin/grep.c b/builtin/grep.c
> index 601f801158..52b45de749 100644
> --- a/builtin/grep.c
> +++ b/builtin/grep.c
> @@ -427,6
Tim Schumacher writes:
> it is located at the top of the while() loop. Giving an example is nice, but
> wouldn't
> it be better to say something like the following?
>
> /*
>* Check if av[0] is a command before seeing if it is an
>* alias to avoid taking over existing
Derrick Stolee writes:
> On 9/21/2018 10:40 AM, Ævar Arnfjörð Bjarmason wrote:
>> On Fri, Sep 21 2018, Derrick Stolee wrote:
>>
>>>
>>> This error was reported by Peff [1] and fixed in [2], but as stated
>>> [3] I was waiting for more review before sending a v3. I'll send that
>>> v3 shortly,
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.
The tip of 'next' hasn't been
Junio C Hamano writes:
> Well, reading builtin/merge-base.c::handle_fork_point(), I think the
> intended behaviour is:
>
> - die() when input is not well formed (e.g. bad commit object,
>ambigous ref name, etc.); there is an error worth reporting in
>this case.
>
&g
Eric Sunshine writes:
> On Wed, Sep 19, 2018 at 6:25 PM Alexander Mills
> wrote:
>> The following command sequence exits with 1, and no stderr
>>
>> base='remotes/origin/dev';
>> fork_point="$(git merge-base --fork-point "$base")";
>>
>> I cannot figure out why it's exiting with 1, but there is
Jonathan Tan writes:
> The hard part for me lies in how to communicate to future readers of the
> code that they cannot remove this section to simplify the code. We would
> need a more complicated comment, something like this:
That suggests two things.
- Perhaps quickfetch() is misnamed. It
Junio C Hamano writes:
> Nguyễn Thái Ngọc Duy writes:
>
>> Commit b0db704652 (pathspec: allow querying for attributes -
>> 2017-03-13) adds new pathspec magic 'attr' but only with
>> match_pathspec(). "git add" has some pathspec related code that
Junio C Hamano writes:
> I also noticed that 2/6 made "commti_contains --tag" enclosed in dq
> pair for one test, but the next test after it has the identical one.
>
> Here is what I queued in the meantime.
> ...
And of course, I find out that 3/6 needs a matching
Jonathan Tan writes:
> diff --git a/builtin/fetch.c b/builtin/fetch.c
> index 61bec5d21..e9640fe5a 100644
> --- a/builtin/fetch.c
> +++ b/builtin/fetch.c
> @@ -938,6 +938,25 @@ static int quickfetch(struct ref *ref_map)
>*/
> if (deepen)
> return -1;
> +
> + if
Martin Ågren writes:
> In the "Reporting Bugs" section of git(1), we refer to the mailing list,
> but we do not give any hint about where the archives might be found.
And why is it a good idea to give that information in Reporting Bugs
section? Are we asking the bug reporters to look for
Ramsay Jones writes:
> Yes, this was one of my first concerns (I even asked Elijah what
> compiler options he used), but I was getting useful results without
> passing CFLAGS, so I just ignored that issue ... :-D
> ...
> Indeed. This bothered me as well. The 'compat' directory does not
> follow
801 - 900 of 27729 matches
Mail list logo
