Stefan Beller writes:
> This re-introduces 984cd77ddb (submodule deinit: unset core.worktree,
> 2018-06-18), which was reverted as part of f178c13fda (Revert "Merge
> branch 'sb/submodule-core-worktree'", 2018-09-07)
>
> The whole series was reverted as the offending commit e98317508c
>
Stefan Beller writes:
> Shortly after f178c13fda (Revert "Merge branch
> 'sb/submodule-core-worktree'", 2018-09-07), we had another series
> that implemented partially the same, ensuring that core.worktree was
> set in a checked out submodule, namely 74d4731da1 (submodule--helper:
> replace
Stefan Beller writes:
> This reintroduces 4fa4f90ccd (submodule: unset core.worktree if no working
> tree is present, 2018-06-12), which was reverted as part of f178c13fda
> (Revert "Merge branch 'sb/submodule-core-worktree'", 2018-09-07).
>
> 4fa4f90ccd was reverted as its followup commit was
Matthew DeVore writes:
> $ git -C pc1 fetch-pack --stdin "file://$(pwd)/srv.bare"
> Where observed.oids contains all the blobs that were missing. It tells
> the remote that it already has the "refs/heads/master" commit, which
> means it is excluded. Before, this worked fine, since it didn't
Stefan Beller writes:
> On Fri, Dec 7, 2018 at 1:40 PM Jonathan Nieder wrote:
>>
>> Brandon Williams wrote:
>>
>> > Signed-off-by: Brandon Williams
>> > ---
>> > .mailmap | 1 +
>> > 1 file changed, 1 insertion(+)
>>
>> I can confirm that this is indeed the same person.
>
> What would be more
Jonathan Nieder writes:
>> So it seems most sensible to me if this is going to be supported that we
>> go a bit beyond the call of duty and fake up the start of it, namely:
>>
>> --- a/arch/x86/kernel/process.c
>> +++ b/arch/x86/kernel/process.c
>>
>> To be:
>>
>> diff --git
Stefan Beller writes:
> A couple days before the 2.19 release we had a bug report about
> broken submodules[1] and reverted[2] the commits leading up to them.
>
> The behavior of said bug fixed itself by taking a different approach[3],
> specifically by a weaker enforcement of having
Jonathan Tan writes:
> When a user runs "git commit" without specifying a message, an editor
> appears with advice:
>
> Please enter the commit message for your changes. Lines starting
> with '#' will be ignored, and an empty message aborts the commit.
>
> However, if the user supplies
Jonathan Tan writes:
>> Jonathan Tan writes:
>>
>> > @@ -126,6 +129,12 @@ static int read_pack_objects_stdout(int outfd, struct
>> > output_state *os)
>> >}
>> >os->used += readsz;
>> >
>> > + if (!os->packfile_started) {
>> > + os->packfile_started = 1;
>> > + if
Konstantin Khomoutov writes:
>> I do not see why the "name each rev relative to HEAD" formatting
>> option cannot produce HEAD^2~2 etc.
>> ...
> My reading was that the OP explicitly wanted to just glance at a single
> integer number and use it right away in a subsequent rebase command.
>
> I
Jeff King writes:
> Each "wait" will try to collect all processes, but may be interrupted by
> a signal. So the correct number is actually "1 plus the number of times
> the user hits ^C".
Yeah and that is not bounded. It is OK not to catch multiple ^C
that races with what we do, so having ane
Jonathan Tan writes:
> @@ -126,6 +129,12 @@ static int read_pack_objects_stdout(int outfd, struct
> output_state *os)
> }
> os->used += readsz;
>
> + if (!os->packfile_started) {
> + os->packfile_started = 1;
> + if (use_protocol_v2)
> +
Josh Steadmon writes:
> diff --git a/fuzz-commit-graph.c b/fuzz-commit-graph.c
> new file mode 100644
> index 00..420851d0d2
> --- /dev/null
> +++ b/fuzz-commit-graph.c
> @@ -0,0 +1,18 @@
> +#include "object-store.h"
> +#include "commit-graph.h"
> +
> +struct commit_graph
Junio C Hamano writes:
>> +if (graph_size < GRAPH_MIN_SIZE)
>> +return NULL;
>> +
>
> The load_commit_graph_one() grabbed graph_map out of xmmap() so it
> is guaranteed to be non-NULL, but we need to check graph_map != NULL
> when we're calling
Josh Steadmon writes:
> @@ -108,27 +106,61 @@ struct commit_graph *load_commit_graph_one(const char
> *graph_file)
> die(_("graph file %s is too small"), graph_file);
> }
> graph_map = xmmap(NULL, graph_size, PROT_READ, MAP_PRIVATE, fd, 0);
> + ret =
Matthew DeVore writes:
> When a command is invoked with both --exclude-promisor-objects,
> --objects-edge-aggressive, and a missing object on the command line,
> the rev_info.cmdline array could get a NULL pointer for the value of
> an 'item' field. Prevent dereferencing of a NULL pointer in
Jeff King writes:
> In my opinion this feature is so contrary to Git's general assumptions
> that it's likely to create a ton of information leaks of the supposedly
> protected data.
> ...
Yup, with s/implemented/designed/, I agree all you said here
(snipped).
> Sorry I don't have a more
Frank Schäfer writes:
> Just to be sure that I'm not missing anything here:
> What's your definition of "LF in repository, CRLF in working tree" in
> terms of config parameters ?
:::Documentation/config/core.txt:::
core.autocrlf::
Setting this variable to "true" is the same as setting
Ævar Arnfjörð Bjarmason writes:
>> Documentation says "If you are absolutely certain that you want your
>> script to load and execute a file from the current directory, then use
>> a ./ prefix". We can do that, like so:
>>
>> diff --git i/gitweb/Makefile w/gitweb/Makefile
>> index
Konstantin Khomoutov writes:
> On Wed, Dec 05, 2018 at 05:22:14PM +0300, Konstantin Kharlamov wrote:
>
>> It would be great if git-log has a formatting option to insert an
>> index of the current commit since HEAD.
>>
>> It would allow after quitting the git-log to immediately fire up "git
>>
Jeff King writes:
> But the ^C case is interesting. Try running your script under "sh -x"
> and hitting ^C. The signal interrupts the first wait. In my script (or
> yours modified to use a single wait), we then proceed immediately to the
> "exit", and get output from the subshells after we've
Jonathan Tan writes:
> Looking at the bigger picture, the speed of the connectivity check
> during a fetch might be further improved by passing only the negotiation
> tips (obtained through --negotiation-tip) instead of "--all". This patch
> just handles the low-hanging fruit first.
That sounds
Johannes Sixt writes:
> Am 05.12.18 um 16:37 schrieb Elijah Newren:
>> On Tue, Dec 4, 2018 at 11:40 PM Junio C Hamano wrote:
>>>
>>> Johannes Sixt writes:
>>>
>>>> Please let me deposit my objection. This paragraph is not the right
>
Johannes Sixt writes:
> Please let me deposit my objection. This paragraph is not the right
> place to explain what directory renme detection is and how it works
> under the hood. "works fine" in the original text is the right phrase
> here; if there is concern that this induces expectations
Elijah Newren writes:
> What depends on stage#2 coming from the commit that will become the
> first parent?
How about "git diff --cc" for a starter? What came from HEAD's
ancestry should appear first and then what came from the side branch
that is merged into.
Jonathan Tan writes:
> +struct output_state {
> + char buffer[8193];
> + int used;
> +};
> +
> +static int read_pack_objects_stdout(int outfd, struct output_state *os)
> +{
The naming feels quite odd. We are downstream of pack-objects and
reading its standard output stream, so "read
Junio C Hamano writes:
> So, this is OK, but
>
>> +Clients then should understand that the returned packfile could be
>> incomplete,
>> +and that it needs to download all the given URIs before the fetch or clone
>> is
>> +complete. Each URI should point to
Jonathan Tan writes:
> +This feature allows servers to serve part of their packfile response as URIs.
> +This allows server designs that improve scalability in bandwidth and CPU
> usage
> +(for example, by serving some data through a CDN), and (in the future)
> provides
> +some measure of
Jonathan Tan writes:
> The git command line expects Git servers to follow a specific order of
"Command line"? It sounds like you are talking about the order of
command line arguments and options, but apparently that is not what
you are doing. Is it "The git over-the-wire protocol"?
> +
Elijah Newren writes:
> Gah, when I was rebasing on your patch I adopted your sentence rewrite
> but forgot to remove the "sometimes". Thanks for catching; correction:
>
> -- 8< --
> Subject: [PATCH v2] git-rebase.txt: update note about directory rename
> detection and am
>
> In commit
Ævar Arnfjörð Bjarmason writes:
> Change the "error" message emitted by alt_odb_usable() to be a
> "warning" instead. As noted in commits leading up to this one this has
> never impacted the exit code ever since the check was initially added
> in 26125f6b9b ("detect broken alternates.",
Ævar Arnfjörð Bjarmason writes:
> Since 26125f6b9b ("detect broken alternates.", 2006-02-22) we've
> emitted an error if the alternates directory doesn't exist, but not
> for the common misstep of adding a path to another git repository as
> an alternate, as opposed to its "objects" directory.
_commits(), so we'll also run that code
in case the submodule recursion is set to "on".
+The submodule checks were done only when a ref in the superproject
+changed, these checks were extended to also be performed when fetching
+into FETCH_HEAD for co
Duy Nguyen writes:
> On Tue, Dec 4, 2018 at 6:43 PM Elijah Newren wrote:
>> > > > +--ours::
>> > > > +--theirs::
>> ...
>> go away. Maybe it can still be fixed (I haven't dug too deeply into
>> it), but if so, the only fix needed here would be to remove this long
>> explanation about why the
Duy Nguyen writes:
>> My single biggest worry about this whole series is that I'm worried
>> you're perpetuating and even further ingraining one of the biggest
>> usability problems with checkout: people suggest and use it for
>> reverting/restoring paths to a previous version, but it doesn't do
Elijah Newren writes:
>> +Updates files in the working tree to match the version in the index
>> +or the specified tree.
>> +
>> +'git restore-files' [--from=] ...::
>
> and ? I understand and ,
> or but have no clue why it'd be okay to specify
> and together. What does that even mean?
I
Jonathan Nieder writes:
> Stefan Beller wrote:
>> On Mon, Dec 3, 2018 at 3:23 PM Jonathan Nieder wrote:
>
>>> I was curious about what versions of Gerrit this is designed to
>>> support (or in other words whether it's a bug fix or a feature).
Well, bf1a11f0 ("sideband: highlight keywords in
Johannes Sixt writes:
> Am 03.12.18 um 21:42 schrieb Martin Ågren:
>> On Mon, 3 Dec 2018 at 18:35, Johannes Sixt wrote:
>>> I actually did not test the result, because I don't have the
>>> infrastructure.
>>
>> I've tested with asciidoc and Asciidoctor, html and man-page. Looks
>> good.
>
>
Junio C Hamano writes:
> If "git clean" takes a pathspec, perhaps you can give a negative
> pathspec to exclude whatever you do not want to get cleaned,
> something like
>
> git clean '*.o' ':!precious.o'
>
> to say "presious.o is ignored (hence norma
Martin Ågren writes:
> We have three double-quote characters, which is one too many or too few.
> Dropping the last one seems to match the original intention best.
Thanks for spotting. The actual original intention was that the
user says two things:
first saying "add only what does
Martin Ågren writes:
> I had to read this sentence a few times to understand it. Let's try to
> clarify it.
Great. Thanks.
>
> Signed-off-by: Martin Ågren
> ---
> Documentation/RelNotes/2.20.0.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git
Martin Ågren writes:
> Some items that should be in "Performance, Internal Implementation,
> Development Support etc." have ended up in "UI, Workflows & Features"
> and "Fixes since v2.19". Move them, and do s/uses/use/ while at it.
>
> Signed-off-by: Martin Ågren
> ---
I agree with the early
Jeff King writes:
> That said, our C99 designated initializer weather-balloons haven't
> gotten any complaints yet. So I think you could actually do:
>
> struct setup_revision_opt s_r_opt = {
> .allow_exclude_promisor_objects = 1,
> };
> ...
> setup_revisions(...);
>
> which is
Eric Sunshine writes:
> This is a re-roll of Martin's v2[1]. The only difference from v2 is that
> it retains coloring when emitting to the terminal (plus an in-code
> comment was simplified).
>
> The regression introduced by d8981c3f88, in which the range-diff only
> ever gets emitted to the
Carlo Marcelo Arenas Belón writes:
> ea2d20d4c2 ("t5004: avoid using tar for checking emptiness of archive",
> 2013-05-09), introduced a fake empty tar archive to allow for portable
> tests of emptiness without having to invoke tar
>
> 4318094047 ("archive: don't add empty directories to
Frank Schäfer writes:
> Hi Junio,
>
> Am 29.11.18 um 03:11 schrieb Junio C Hamano:
> [...]
>> This was misspoken a bit. Let's revise it to
>>
>> When producing a colored output (not limited to whitespace
>> error coloring of diff output) for content
"H.Merijn Brand" writes:
> When $PATH contains the current directory as .:PATH, PATH:., PATH:.:PATH,
> or (maybe worse) as :PATH, PATH:, or PATH::PATH - as an empty entry is
> identical to having dot in $PATH - this test used to fail
It is totally unclear what "this test" refers to. Let's
Jeff King writes:
> Since the test is ultimately checking "can we run should-not-run from
> the current directory", might it be simpler to actually try that as the
> precondition? I.e., something like:
> ...
A nice egg of columbus. It also would save us from mischievous
users who have
Thomas Gummerer writes:
> Agreed, I think --{no-,}overlay is a much better name for the option,
> I'll use that for my patch series (I hope to send that soon after 2.20
> is released).
OK.
> I must admit that I was not aware that the mode is called overlay
> mode, before you explained it to
Jiang Xin writes:
> Git v2.20.0-rc2 has been released, and there are 5 new messages need to
> be translated. So let's start new round of l10n for Git 2.20.0.
A huge thanks, as always, to the translation team. Jiang, sorry to
see that -rc2 slipped just after you sent out the round 2 message
and
"Randall S. Becker" writes:
> Would something like git clean --exclude=file-pattern work as a
> compromise notion? Files matching the pattern would not be cleaned
> regardless of .gitignore or their potential preciousness status
> long-term. Multiple repetitions of the --exclude option might be
Junio C Hamano writes:
> Cameron Boehmer writes:
>
>> 1) add a new flag
>> -l, --local
>> Do not consult git config --global core.excludesFile in
>> determining what files git ignores. This is useful in conjunction with
>> -x/-X to preserve user
Cameron Boehmer writes:
> 1) add a new flag
> -l, --local
> Do not consult git config --global core.excludesFile in
> determining what files git ignores. This is useful in conjunction with
> -x/-X to preserve user files while removing build artifacts.
This does not belong to the "clean"
single file to create another
file.
Signed-off-by: Carlo Marcelo Arenas Belón
Signed-off-by: Junio C Hamano
---
t/t6036-recursive-corner-cases.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/t/t6036-recursive-corner-cases.sh
b/t/t6036-recursive-corner-cases.sh
index
Johannes Schindelin writes:
> Hi Junio,
>
> On Fri, 30 Nov 2018, Junio C Hamano wrote:
>
>> * en/rebase-merge-on-sequencer (2018-11-08) 2 commits
>> - rebase: implement --merge via git-rebase--interactive
>> - git-rebase, sequencer: extend --quiet option
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 road to the upcoming 2.20
Junio C Hamano writes:
>> I had to delay -rc2 to see these last minute tweaks come to some
>> reasonable place to stop at, and I do not think we want to delay the
>> final any longer or destablizing it further by piling last minute
>> undercooked changes on top
Duy Nguyen writes:
> core.uiVersion is a big no no to me. I don't want to go to someone's
> terminal, type something and have a total surprise because they set
> different ui version. If you want a total UI redesign, go with a new
> prefix, like "ng" (for new git) or something instead of "git".
Duy Nguyen writes:
>>
>> OK. Is "auto-vivify the named branch based on a remote-tracking"
>> also rejected, as it is a confusing behaviour that is a too subtle
>> and implicit, just like the detaching head is, and require --guess
>> or sticking to 'git checkout'? I think it should.
>
> This
Junio C Hamano writes:
> In any case, I tend to agree with the conclusion in the downthread
> by Dscho that we should just clearly mark that invocations of the
> "format-patch --range-diff" command with additional diff options is
> an experimental feature that may no
Derrick Stolee writes:
> You're right that having this hidden as an opt-in config variable
> makes it hard to discover as a typical user.
>
> I would argue that we should actually make the config setting true by
> default, and recommend that servers opt-out. Here are my reasons:
>
> 1. The vast
Ævar Arnfjörð Bjarmason writes:
>> What prevents you from using `sq_dequote_to_argv()`?
>
> I mean not just nasty in terms of implementation, yeah we could do it,
> but also a nasty UX for things like --word-diff-regex. I.e. instead of:
>
> --range-diff-word-diff-regex='[0-9"]'
>
> You need:
Nguyễn Thái Ngọc Duy writes:
> 'git switch-branch'
>
> - implicit detaching is rejected. If you need to detach, you need to
> give --detach. Or stick to 'git checkout'.
OK. Is "auto-vivify the named branch based on a remote-tracking"
also rejected, as it is a confusing behaviour that is a
Duy Nguyen writes:
> On Wed, Nov 28, 2018 at 9:01 PM Duy Nguyen wrote:
>> should we do
>> something about detached HEAD in this switch-branch command (or
>> whatever its name will be)?
>>
>> This is usually a confusing concept to new users
>
> And it just occurred to me that perhaps we should
Johannes Schindelin writes:
> But I guess that I should not be so lazy and really use two different
> messages here:
>
> Changes from to
>
> and if there is no merge base,
>
> Changes in
Ah, that's excellent.
Thanks.
Masaya Suzuki writes:
> Yes, I did. And it also didn't end up in a build error. Do I have a
> different build option...?
Passig DEVELOPER=Yes to make turns a bit more warnings on (in this
case, I think it was "unused-variable") and also uses -Werror to
turn warnings into errors.
Masaya Suzuki writes:
> In the Git pack protocol definition, an error packet may appear only in
> a certain context. However, servers can face a runtime error (e.g. I/O
> error) at an arbitrary timing. This patch changes the protocol to allow
> an error packet to be sent instead of any packet.
>
Junio C Hamano writes:
>> diff --git a/connect.c b/connect.c
>> index 24281b608..458906e60 100644
>> --- a/connect.c
>> +++ b/connect.c
>> @@ -306,8 +306,6 @@ struct ref **get_remote_heads(struct packet_reader
>> *reader,
>> di
Junio C Hamano writes:
>> +test_expect_success 'log -G ignores binary files' '
>> +git checkout --orphan orphan1 &&
>> +printf "a\0a" >data.bin &&
>> +git add data.bin &&
>> +git commit -m "mess
Thomas Braun writes:
> Subject: Re: [PATCH v2] log -G: Ignore binary files
s/Ig/ig/; (will locally munge--this alone is no reason to reroll).
The code changes looked sensible.
> diff --git a/t/t4209-log-pickaxe.sh b/t/t4209-log-pickaxe.sh
> index 844df760f7..5c3e2a16b2 100755
> ---
Ævar Arnfjörð Bjarmason writes:
> -To skip tests, set the GIT_SKIP_TESTS variable. Individual tests can
> -be skipped:
> +To skip tests, set either the GIT_SKIP_TESTS or GIT_TODO_TESTS
> +variables. The difference is that with SKIP the tests won't be run at
> +all, whereas they will be run with
Nguyễn Thái Ngọc Duy writes:
> Signed-off-by: Nguyễn Thái Ngọc Duy
> ---
> My bad.
>
> transport-helper.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/transport-helper.c b/transport-helper.c
> index 7213fa0d32..bf225c698f 100644
> --- a/transport-helper.c
> +++
Nguyễn Thái Ngọc Duy writes:
> +static struct option *add_switch_branch_options(struct checkout_opts *opts,
> + struct option *prevopts)
> +{
> + struct option options[] = {
> OPT_STRING('b', NULL, >new_branch, N_("branch"),
>
Stefan Xenos writes:
> So - IMO - detaching should always be an explicit action. Some options
> that occur to me:
>
> git switch-branch --detach
That is the most obvious way to spell it, and it is why we have "git
checkout --detach". If we were to split one half of "checkout" into
Duy Nguyen writes:
> I see my deliberate attempt to provoke has failed :D Giving your view
> of the new commands as "training wheels", I take it we still should
> make them visible as much as possible, but we just not try to hide
> "git checkout" as much (e.g. we mention both new and old
Stefan Xenos writes:
> Although I have no problem with "switch-branch" as a command name,
> some alternative names we might consider for switch-branch might be:
>
> chbranch
> swbranch
Please never go in that direction. So far, we made a conscious
effort to keep the names of most frequently
Stefan Beller writes:
> I dislike the checkout-* names, as we already have checkout-index
> as plumbing, so it would be confusing as to which checkout-* command
> should be used when and why as it seems the co-index moves
> content *from index* to the working tree, but the co-files moves content
"Johannes Schindelin via GitGitGadget"
writes:
> The built-in version of the `git rebase` command blindly translated that
> shell script code, assuming that there is no need to test whether there
> *was* a merge base, and due to its better error checking, exited with a
> fatal error (because it
Eric Sunshine writes:
> Playing Devi's Advocate, what if Apple's clang "8" was, in reality,
> real-world clang 3? Then this condition would incorrectly enable the
> compiler option on Apple for a (real) clang version below 4. For this
> reason, it seems we shouldn't be trusting only the clang
Ævar Arnfjörð Bjarmason writes:
> I don't think something like the endgame you've described in
> https://public-inbox.org/git/xmqqzhtwuhpc@gitster-ct.c.googlers.com/
> is ever going to work. Novice git users (the vast majority) are not
> going to diligently update both .gitignore and some
Ævar Arnfjörð Bjarmason writes:
> Since I raised this 'should we hold off?' I thought I'd chime in and say
> that I'm fine with going along with what you suggest and having the
> builtin as the default in the final. IOW not merge
> jc/postpone-rebase-in-c down.
OK.
Ævar Arnfjörð Bjarmason writes:
> + [--range-diff]]
Let's make sure a random string thrown at this mechanism will
properly get noticed and diagnosed.
> @@ -257,6 +258,13 @@ feeding the result to `git send-email`.
> creation/deletion cost fudge factor. See
Johannes Sixt writes:
> Am 27.11.18 um 00:31 schrieb Junio C Hamano:
>> Johannes Sixt writes:
>>> Am 26.11.18 um 04:04 schrieb Junio C Hamano:
>>> ... this goes too far, IMO. It is the pager's task to decode control
>>> characters.
>>
>>
Johannes Schindelin writes:
> -test_expect_success 'run_command is restricted to PATH' '
> +test_lazy_prereq DOT_IN_PATH '
> + case ":$PATH:" in
> + *:.:*) true;;
> + *) false;;
> + esac
> +'
An empty element in the colon-separated list also serves as an
instruction to pick up
Bryan Turner writes:
> For us, the biggest issue was "git gc"'s insistence on trying to run
> "git reflog expire". That triggers locking behaviors that resulted in
> very frequent GC failures--and the only reflogs Bitbucket Server (by
> default) creates are all configured to never ex[ire or be
Ævar Arnfjörð Bjarmason writes:
> The advice to run 'git replace --convert-graft-file' added in
> f9f99b3f7d ("Deprecate support for .git/info/grafts", 2018-04-29)
> didn't add an exception for the 'git replace --convert-graft-file'
> codepath itself.
>
> As a result we'd suggest running
Will writes:
> I’m far from being a guru, but I consider myself a competent Git
> user. Yet, here’s my understanding of the output of one the most-used
> commands, `git push`:
>> Counting objects: 6, done.
> No idea what an “object” is. Apparently there’s 6 of them
> here. What does “counting”
Nguyễn Thái Ngọc Duy writes:
> The assumption made is here
>
> - "git checkout" is a horrible monster that should only be touched
> with a two-meter pole
>
> - there are other commands that can achieve the same thing
Thanks for clearly spelling out the assumptions. It is good that
this step
Nguyễn Thái Ngọc Duy writes:
> The good old "git checkout" command is still here and will be until
> all (or most of users) are sick of it.
Two comments on the goal (the implementation looked reasonable
assuming the reader agrees with the gaol).
At least to me, the verb "switch" needs two
Nguyễn Thái Ngọc Duy writes:
> There is currently no caller that calls this function with "a" being
> NULL. But it will be introduced shortly. It is used to construct the
> option array from scratch, e.g.
>
>struct parse_options opts = NULL;
Missing asterisk somewhere?
>opts =
Eric Sunshine writes:
> On Tue, Nov 27, 2018 at 11:43 AM Ævar Arnfjörð Bjarmason
> wrote:
>> Avoid a bug in dash that's been fixed ever since its
>> ec2c84d ("[PARSER] Fix clobbering of checkkwd", 2011-03-15)[1] first
>> released with dash v0.5.7 in July 2011.
>
> Perhaps enhance the commit
Johannes Schindelin writes:
> It takes a little folding and knotting of the brain to understand that
> this `!skip_dos_drive_prefix()` has *nothing* to do with the comment
> `unc paths` nor with the test whether the paths starts with two directory
> separators.
>
> As a consequence, I would
Johannes Schindelin writes:
>> Sorry, but I fail to see the point the last example wants to make.
>
> I agree. For me, the real test is this:
>
> me@work ~
> $ cd /cygdrive
>
> me@work /cygdrive
> $ ls
> c d
>
> So `/cygdrive` *is* a valid directory in Cygwin.
That supports the code that does
Johannes Schindelin writes:
> ...
> In short, even a thorough study of the code (keeping in mind the few
> tidbits of information provided by you) leaves me really wondering which
> code you run, because it sure does not look like current `master` to me.
>
> And if it is not `master`, then I
Ævar Arnfjörð Bjarmason writes:
> What do you think about some patch like that which retains the plumbing
> behavior for things like read-tree, doesn't introduce "precious" or
> "trashable", and just makes you specify "[checkout|merge|...] --force"
> in cases where we'd have clobbering?
Whether
Masaya Suzuki writes:
> In the Git pack protocol definition, an error packet may appear only in
> a certain context. However, servers can face a runtime error (e.g. I/O
> error) at an arbitrary timing. This patch changes the protocol to allow
> an error packet to be sent instead of any packet.
Steven Penny writes:
> If you strip the drive, you can still navigate within the same drive:
>
> $ cd 'C:\Users'
> $ pwd
> /cygdrive/c/Users
>
> $ cd '\Windows'
> $ pwd
> /cygdrive/c/Windows
>
> but you can no longer traverse drives:
>
> $ cd '\Testing'
> sh: cd:
tbo...@web.de writes:
> Reported-By: Steven Penny
> Signed-off-by: Torsten Bögershausen
> ---
>
> This is the first vesion of a patch.
> Is there a chance that you test it ?
>
> abspath.c | 2 +-
> compat/cygwin.c | 18 ++
> compat/cygwin.h | 32
Stefan Beller writes:
> On Wed, Nov 21, 2018 at 1:08 PM Thomas Braun
> wrote:
>>
>> The -G option of log looks for the differences whose patch text
>> contains added/removed lines that match regex.
>>
>> The concept of differences only makes sense for text files, therefore
>> we need to ignore
Stefan Beller writes:
>> > +static int record_ieot(void)
>> > +{
>> > + int val;
>> > +
>>
>> Initialize stack val to zero to ensure proper default.
>
> I don't think that is needed here, as we only use `val` when
> we first write to it via git_config_get_bool.
Yup.
1 - 100 of 27729 matches
Mail list logo
