Running CI on Mac OS X in Azure Pipelines is currently broken due to a moved
homebrew package.
Change since v2:
* The commit message was improved (thanks Gábor).
Change since v1: -The step is now more robust (by pulling homebrew-cask and
trying again if the pull failed).
Thanks, -Stolee
Johan
From: Derrick Stolee
The sparse-checkout builtin used 'git read-tree -mu HEAD' to update the
skip-worktree bits in the index and to update the working directory.
This extra process is overly complex, and prone to failure. It also
requires that we write our changes to the sparse-che
On 10/18/2019 4:40 PM, SZEDER Gábor wrote:
> On Fri, Oct 18, 2019 at 10:24:21PM +0200, SZEDER Gábor wrote:
>> On Tue, Oct 15, 2019 at 01:56:02PM +, Derrick Stolee via GitGitGadget
>> wrote:
>>> From: Derrick Stolee
>>>
>>> The sparse-checkout built
On Fri, Oct 18, 2019 at 10:24:21PM +0200, SZEDER Gábor wrote:
> On Tue, Oct 15, 2019 at 01:56:02PM +, Derrick Stolee via GitGitGadget
> wrote:
> > From: Derrick Stolee
> >
> > The sparse-checkout builtin used 'git read-tree -mu HEAD' to update the
> >
On Tue, Oct 15, 2019 at 01:56:02PM +, Derrick Stolee via GitGitGadget wrote:
> From: Derrick Stolee
>
> The sparse-checkout builtin used 'git read-tree -mu HEAD' to update the
> skip-worktree bits in the index and to update the working directory.
> This extra proce
Perforce's release schedule. But once it is updated, we can now simply
+re-run the failed jobs and they will pick up that update.
+
+As for updating `homebrew-cask`: the beginnings of automating this in
+
https://dev.azure.com/gitgitgadget/git/_build?definitionId=11&_a
Hi Stolee,
On Tue, 15 Oct 2019, Derrick Stolee via GitGitGadget wrote:
> Running CI on Mac OS X in Azure Pipelines is currently broken due to a moved
> homebrew package.
It seems that the exact problem we tried to avoid by staying on caskroom
rears its ugly head: all of the macOS jobs are failin
Running CI on Mac OS X in Azure Pipelines is currently broken due to a moved
homebrew package.
Thanks, -Stolee
Johannes Schindelin (1):
ci(osx): use new location of the `perforce` cask
ci/install-dependencies.sh | 1 +
1 file changed, 1 insertion(+)
base-commit: 108b97dc372828f0e72e56bbb40c
From: Derrick Stolee
The sparse-checkout builtin used 'git read-tree -mu HEAD' to update the
skip-worktree bits in the index and to update the working directory.
This extra process is overly complex, and prone to failure. It also
requires that we write our changes to the sparse-che
On 10/12/2019 6:57 PM, Elijah Newren wrote:
> On Mon, Oct 7, 2019 at 1:08 PM Derrick Stolee via GitGitGadget
> wrote:
>>
>> From: Derrick Stolee
>>
>> The sparse-checkout builtin used 'git read-tree -mu HEAD' to update the
>> skip-worktree bits in
On Mon, Oct 7, 2019 at 1:08 PM Derrick Stolee via GitGitGadget
wrote:
>
> From: Derrick Stolee
>
> The sparse-checkout builtin used 'git read-tree -mu HEAD' to update the
> skip-worktree bits in the index and to update the working directory.
> This extra process is
From: Derrick Stolee
The sparse-checkout builtin used 'git read-tree -mu HEAD' to update the
skip-worktree bits in the index and to update the working directory.
This extra process is overly complex, and prone to failure. It also
requires that we write our changes to the sparse-che
In a todo list, `done_nr' is the amount of commands that were executed
or skipped, but skip_unnecessary_picks() did not update it.
This variable is mostly used by command prompts (ie. git-prompt.sh and
the like). As in the previous commit, this inconsistent behaviour is
not a problem yet, b
`total_nr' is the total number of items, counting both done and todo,
that are in a todo list. But unlike `nr', it was not updated when an
item was appended to the list.
This variable is mostly used by command prompts (ie. git-prompt.sh and
the like). By forgetting to update it, th
This test produces pseudo-collisions and tests git diff's behavior with
them, and is therefore sensitive to the hash in use. Update the test to
compute the collisions for both SHA-1 and SHA-256 using appropriate
constants. Move the heredocs inside the setup block so that all of the
setup cod
Signed-off-by: Pratyush Yadav
---
Changes in v2:
- Only link the repo, instead of having instructions to "clone" and
"browse online".
Do note that I am using single quotes around git gui instead of
backticks like you suggested because the rest of the man page does the
same.
Interdiff against
Pratyush Yadav writes:
> Signed-off-by: Pratyush Yadav
> ---
> Documentation/git-gui.txt | 8 ++--
> 1 file changed, 2 insertions(+), 6 deletions(-)
>
> diff --git a/Documentation/git-gui.txt b/Documentation/git-gui.txt
> index 5f93f8003d..98337b69f1 100644
> --- a/Documentation/git-gui.txt
Signed-off-by: Pratyush Yadav
---
Documentation/git-gui.txt | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/Documentation/git-gui.txt b/Documentation/git-gui.txt
index 5f93f8003d..98337b69f1 100644
--- a/Documentation/git-gui.txt
+++ b/Documentation/git-gui.txt
@@ -114
Hi Junio and Johannes,
Le 02/10/2019 à 10:59, Junio C Hamano a écrit :
> Johannes Schindelin writes:
>
>> Hi Junio,
>>
>> On Wed, 2 Oct 2019, Junio C Hamano wrote:
>>
>>> Alban Gruin writes:
>>>
`total_nr' is the total amount of items, done and toto, that are in a
todo list. But unli
Hi Junio,
On Wed, 2 Oct 2019, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > On Wed, 2 Oct 2019, Junio C Hamano wrote:
> >
> >> 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
Johannes Schindelin writes:
> Hi Junio,
>
> On Wed, 2 Oct 2019, Junio C Hamano wrote:
>
>> 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/am
Hi Junio,
On Wed, 2 Oct 2019, Junio C Hamano wrote:
> 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
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
On 01/10/19 09:46AM, Denton Liu wrote:
> Hi Pratyush,
>
> On Tue, Oct 01, 2019 at 07:44:35PM +0530, Pratyush Yadav wrote:
> > Since I have taken over maintainership of git-gui, it is a good idea to
> > point new contributors to my fork of the project, so they can see the
> > latest version of the
Hi Pratyush,
On Tue, Oct 01, 2019 at 07:44:35PM +0530, Pratyush Yadav wrote:
> Since I have taken over maintainership of git-gui, it is a good idea to
> point new contributors to my fork of the project, so they can see the
> latest version of the project.
>
> Signed-off-by: Pratyush Yadav
Junio
Since I have taken over maintainership of git-gui, it is a good idea to
point new contributors to my fork of the project, so they can see the
latest version of the project.
Signed-off-by: Pratyush Yadav
---
Documentation/SubmittingPatches | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
@@ -1874,7 +1874,7 @@ static int update_clone(int argc, const char **argv,
const char *prefix)
};
const char *const git_submodule_helper_usage[] = {
- N_("git submodule--helper update_clone [--prefix=]
[...]"),
+ N_("git submodule--help
ix test for UTF-16-LE-BOM
> t0028: add more tests
>
Thanks for the update -
Reviewed-by: Torsten Bögershausen
From: Johannes Schindelin
While `git update-index` mostly ignores paths referring to index entries
whose skip-worktree bit is set, in b4d1690df11 (Teach Git to respect
skip-worktree bit (reading part), 2009-08-20), for reasons that are not
entirely obvious, the `--remove` option was made special
`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.
This variable is mostly used by command prompts (ie. git-prompt.sh and
the like).
Signed-off-by: Alban Gruin
---
sequencer.c | 1 +
1 file
In a todo list, `done_nr' is the amount of commands that were executed
or skipped, but skip_unnecessary_picks() did not update it.
This variable is mostly used by command prompts (ie. git-prompt.sh and
the like).
Signed-off-by: Alban Gruin
---
sequencer.c | 1 +
1 file changed, 1 inse
Commit 1/2: t0028: fix test for UTF-16-LE-BOM Commit 2/2: t0028: add more
tests Please refer to individual commit messages for more information.
Alexandr Miloslavskiy (2):
t0028: fix test for UTF-16-LE-BOM
t0028: add more tests
t/t0028-working-tree-encoding.sh | 41 ++
Commit 1/2: t0028: fix test for UTF-16-LE-BOM Commit 2/2: t0028: add more
tests Please refer to individual commit messages for more information.
Alexandr Miloslavskiy (2):
t0028: fix test for UTF-16-LE-BOM
t0028: add more tests
t/t0028-working-tree-encoding.sh | 41 ++
cally, it does not elicit any "bug" reports, but this can easily be
linearized to
- A' - B' - E' - C' - F' -
In my mind, it makes no sense to update any local branches that pointed
to C and F to point to C' and F', respectively.
I agree
[...
Junio,
27.08.2019, 00:25, "Andrey Mazo" :
> From: Andrey Mazo
>
> I don't have access to my old work email since 20 Apr 2019.
> Replace with my personal email address.
>
> Signed-off-by: Andrey Mazo
> ---
> .mailmap | 1 +
> 1 file changed, 1 insertion(+)
>
Do I need any acks on this patch?
>
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, when we need more parameters
Steps 4 & 5 look OK.
"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
From: William Baker
Signed-off-by: William Baker
---
midx.c | 20
1 file changed, 12 insertions(+), 8 deletions(-)
diff --git a/midx.c b/midx.c
index 3a0e161aea..dc7c5f43f8 100644
--- a/midx.c
+++ b/midx.c
@@ -1098,15 +1098,16 @@ int verify_midx_file(struct repository *r,
From: William Baker
Signed-off-by: William Baker
---
midx.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/midx.c b/midx.c
index dc7c5f43f8..106ccc4ab2 100644
--- a/midx.c
+++ b/midx.c
@@ -1374,6 +1374,12 @@ int midx_repack(struct repository *r, const char
*object_dir, size_t batch_
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, 15 insertions(+), 13 deletions(-)
diff --git a/builtin/multi
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.
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.
Gabriele Mazzotta (1):
gitk: Do not mistake unchanged lines fo
ly. I am far from a Perl
expert, so take this with a train of salt: the patch now looks good to
me!
Ciao,
Johannes
> ---
> contrib/hooks/update-paranoid | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/contrib/hooks/update-paranoid b/contrib/hooks/up
see https://metacpan.org/pod/release/RJBS/perl-5.22.0/pod/perldelta.pod)
Signed-off-by: Dominic Winkler d.wink...@flexarts.at [d.wink...@flexarts.at]
Dominic Winkler (1):
contrib/hooks: escape left brace in regex in the paranoid update hook
contrib/hooks/update-paranoid | 4 ++--
1 file
cause a syntax error.
(see https://metacpan.org/pod/release/RJBS/perl-5.22.0/pod/perldelta.pod)
Signed-off-by: Dominic Winkler
---
contrib/hooks/update-paranoid | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/contrib/hooks/update-paranoid b/contrib/hooks/update-paranoid
Hi Dominic,
all looks good, with one exception: the Subject should start with
`:`, i.e. in this instance something like this would be better:
contrib/hooks: escape left brace in regex in the paranoid update hook
Ciao,
Johannes
On Mon, 9 Sep 2019, Dominic Winkler via GitGitGadget wrote:
> F
see https://metacpan.org/pod/release/RJBS/perl-5.22.0/pod/perldelta.pod)
Signed-off-by: Dominic Winkler d.wink...@flexarts.at [d.wink...@flexarts.at]
Dominic Winkler (1):
Fix perl error "unescaped left brace in regex" for paranoid update
hook
contrib/hooks/update-paranoid | 4 ++
cause a syntax error.
(see https://metacpan.org/pod/release/RJBS/perl-5.22.0/pod/perldelta.pod)
Signed-off-by: Dominic Winkler
---
contrib/hooks/update-paranoid | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/contrib/hooks/update-paranoid b/contrib/hooks/update-paranoid
Johannes Schindelin writes:
> In contrast, I would think that
>
> label --update-branch my-side-track
>
> would make for a nicer read than
>
> label my-side-track
> branch my-side-track
Because labelling while recreating a mergey history is conceptually
be all jumbled up. Imagine this history:
- A - B - C - D -
\ /
E - F
Typically, it does not elicit any "bug" reports, but this can easily be
linearized to
- A' - B' - E' - C' - F' -
In my mind, it makes no sense to
st_add_branch_updates` to run before
`todo_list_rearrange_squash`. The rearranging pulls fixups out, causing the
branch update to "fall" onto the items before, and reinserts them between a
commit and its branch update, casing them to be included in the updated branch.
which is my opinion of
On 2019-09-07 at 23:41:46, Warren He wrote:
> Brian, thanks for looking. The only thing I can come up with to say about
> having
> lots of refs is that at least that part of this isn't brand new code. The part
> that collects ref info uses the same routines as `git log --decorate`. Do you
> recall
Rebasing normally updates the current branch to the rewritten version.
If any other branches point to commits rewritten along the way, those
remain untouched. This commit adds an `--update-branches` option, which
instructs the command to update any such branches that it encounters to
point to the
_script_with_merges`.
> This loads also tags, correct? I am fairly certain that we don't want to
> update tags here, but maybe the check for `DECORATION_REF_LOCAL` later
> on already ensures that?
Right on both points. This isn't as efficient as possible, since we're w
Phillip, thanks for the comments. Indeed other branches that are not in the todo
list are still not updated.
I'm collecting the arguments about deferring the branch updates and issue with
worktrees for discussion along with Johannes's review.
Brian, thanks for looking. The only thing I can come up with to say about having
lots of refs is that at least that part of this isn't brand new code. The part
that collects ref info uses the same routines as `git log --decorate`. Do you
recall how long that took in the repository with 80,000 refs?
Hi Warren,
On Mon, 2 Sep 2019, Warren He wrote:
> Rebasing normally updates the current branch to the rewritten version.
> If any other branches point to commits rewritten along the way, those
> remain untouched. This commit adds an `--update-branches` option, which
> instructs th
small, logically separate changes), is to rebase that later branch and
then reset ancestor branches to the rewritten commits. You just have to work
out which branches correspond to which of the new commits.
Here's an automated way to update those ancestor branches.
I think this would be r
an's comment above, but I happened
to think of one while reading this thread that seemed worth pointing
out.
Perhaps we could avoid inserting the 'exec git branch -f' step in the
todo list for branches that have a configuration section forbidding them
from being updated?
For
"brian m. carlson" writes:
> I like the idea of using existing tooling for this and not needing an
> additional verb.
>
> My gut tells me folks may want a bit more control over *which* branches
> are rebased, but I don't have a personal need for that, so I'm not going
> to request it or propose a
> try
> to make small, logically separate changes), is to rebase that later branch and
> then reset ancestor branches to the rewritten commits. You just have to work
> out which branches correspond to which of the new commits.
>
> Here's an automated way to update
Rebasing normally updates the current branch to the rewritten version.
If any other branches point to commits rewritten along the way, those
remain untouched. This commit adds an `--update-branches` option, which
instructs the command to update any such branches that it encounters to
point to the
that later branch and
then reset ancestor branches to the rewritten commits. You just have to work
out which branches correspond to which of the new commits.
Here's an automated way to update those ancestor branches.
It's implemented as a function that processes a todo list, mod
From: Andrey Mazo
I don't have access to my old work email since 20 Apr 2019.
Replace with my personal email address.
Signed-off-by: Andrey Mazo
---
.mailmap | 1 +
1 file changed, 1 insertion(+)
diff --git a/.mailmap b/.mailmap
index 9a5ff04753..14fa041043 100644
--- a/.mailmap
+++ b/.mailma
On 26/08/19 07:22AM, Junio C Hamano wrote:
> Pratyush Yadav writes:
>
>
> > Subject: Re: [PATCH] git-gui: Update in-memory config when changing config
> > options
>
> s/git-gui: Update/git-gui: update/
I fixed this in my tree, just didn't send a re-roll w
Pratyush Yadav writes:
> Subject: Re: [PATCH] git-gui: Update in-memory config when changing config
> options
s/git-gui: Update/git-gui: update/
> lib/option.tcl | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/lib/option.tcl b/lib/option.tcl
> index e43971b..1
Junio,
This patch hasn't got any comments, but it looks correct to me, and fit
for merging IMO.
I updated the commit subject from 'git-gui: Update...' to 'git-gui:
update...' to match with the style of other commit messages, as you
suggested in the other series.
When the user updates any config variable from the options menu, the new
config gets saved, but the in-memory state of the config variables is
not updated. This results in the old settings being used until the user
either opens the options menu again (which triggers a call to
load_config), or re-st
This series contains a couple of patches to make the C version of rebase
--interactive behave more like the scripted version. The third patch is not
strictly related to the first two but is included here to avoid merge
conflicts.
Phillip Wood (3):
rebase -i: always update HEAD before rewording
From: Phillip Wood
If the user runs git log while rewording a commit it is confusing if
sometimes we're amending the commit that's being reworded and at other
times we're creating a new commit depending on whether we could
fast-forward or not[1]. Fix this inconsistency by always committing the
pi
My IEE 'home for life' email service is being withdrawn on 30 Sept 2019.
Replace with my new email domain.
I also have a secondary (backup) 'home for life' through
.
Signed-off-by: Philip Oakley
Signed-off-by: Philip Oakley
---
.mailmap | 1 +
1 file changed, 1 insertion(+)
diff --git a/.mail
On 7/9/2019 6:05 PM, Junio C Hamano wrote:
> Derrick Stolee writes:
>
>> From this list, do you think any of these settings are likely to
>> become defaults? It seems that protocol.version = 2 may be a default
>> now that _most_ services have an implementation, and it always falls
>> back to prot
Hi,
Le 18/07/2019 à 21:55, Junio C Hamano a écrit :
> Alban Gruin writes:
> > In a todo list, `done_nr' is the amount of commands that were executed
> > or skipped, but skip_unnecessary_picks() did not update it.
>
> OK. Together with 3/9 and this one, any increment
Hi,
Le 18/07/2019 à 21:52, Junio C Hamano a écrit :
> Alban Gruin writes:
> > `total_nr' is the total amount of items, done and toto, that are in a
>
> "amount" -> "number" perhaps. Also s/toto/todo/ perhaps but I am
> not sure what you wanted to say here, so...
>
`total_nr' is the number of
Alban Gruin writes:
> In a todo list, `done_nr' is the amount of commands that were executed
> or skipped, but skip_unnecessary_picks() did not update it.
OK. Together with 3/9 and this one, any increment of total_nr and
done_nr in the existing code is not removed; does it mean
Alban Gruin writes:
> `total_nr' is the total amount of items, done and toto, that are in a
"amount" -> "number" perhaps. Also s/toto/todo/ perhaps but I am
not sure what you wanted to say here, so...
> todo list. But unlike `nr', it was not updated when an item was
> appended to the list.
G
In a todo list, `done_nr' is the amount of commands that were executed
or skipped, but skip_unnecessary_picks() did not update it.
Signed-off-by: Alban Gruin
---
sequencer.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/sequencer.c b/sequencer.c
index e61ae75451..ec9c3d4dc5 100644
`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.
Signed-off-by: Alban Gruin
---
sequencer.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/sequencer.c b/sequencer.c
index cf262701e8..
The gpg --verify usage example within the 'gpg.program' variable reference
provides an incorrect example of the gpg --verify command arguments. The
command argument order, when providing both a detached signature and data,
should be signature first and data second:
https://gnupg.org/documentation/
Derrick Stolee writes:
> On 7/1/2019 10:29 AM, Derrick Stolee via GitGitGadget wrote:
>>
>> Here is a second run at this RFC, which aims to create a "meta" config
>> setting that automatically turns on other settings according to a user's
>> willingness to trade new Git behavior or new feature ris
Taylor Blau writes:
> Hi Gábor,
>
> On Wed, Jul 03, 2019 at 12:47:47PM +0200, SZEDER Gábor wrote:
>> Lately our GCC macOS build job on Travis CI has been erroring out
>> while installing dependencies with:
>>
>> +brew link gcc@8
>> Error: No such keg: /usr/local/Cellar/gcc@8
>> The command
Derrick Stolee writes:
> From this list, do you think any of these settings are likely to
> become defaults? It seems that protocol.version = 2 may be a default
> now that _most_ services have an implementation, and it always falls
> back to protocol v1 without extra cost.
>
> When pack.useSparse
On 7/9/2019 3:21 PM, Junio C Hamano wrote:
> Derrick Stolee writes:
>
>> The other category that has been discussed already is that of "experimental
>> features that we generally think are helpful but change behavior slightly in
>> some cases".
>>
>> feature.experimental:
>> pac
Derrick Stolee writes:
> The other category that has been discussed already is that of "experimental
> features that we generally think are helpful but change behavior slightly in
> some cases".
>
> feature.experimental:
> pack.useSparse = true
> status.aheadBehi
Hi Derrick,
I'm a little bit late to the part, but I think that this is a really
interesting feature with a lot of really interesting discussion so far.
I hope you don't mind me throwing in my $.02 as well :-).
On Mon, Jul 08, 2019 at 03:22:49PM -0400, Derrick Stolee wrote:
> On 7/1/2019 10:29 A
le in the Travis CI macOS image we use [1], it's at
> version 8.2. However, when installing dependencies we first
> explicitly run 'brew update', which spends over two minutes to update
> itself and information about the available packages, and it learns
> about GCC 8
On 7/1/2019 10:29 AM, Derrick Stolee via GitGitGadget wrote:
> Here is a second run at this RFC, which aims to create a "meta" config
> setting that automatically turns on other settings according to a user's
> willingness to trade new Git behavior or new feature risk for performance
> benefits. Th
Hi Gábor,
On Sat, 6 Jul 2019, SZEDER Gábor wrote:
> A comment in 'ci/lib.sh' claims that the "OS X build installs the
> latest available versions" of P4 and Git-LFS, but since 02373e56bd
> (ci: don't update Homebrew, 2019-07-03) that's no longer the case,
A comment in 'ci/lib.sh' claims that the "OS X build installs the
latest available versions" of P4 and Git-LFS, but since 02373e56bd
(ci: don't update Homebrew, 2019-07-03) that's no longer the case, as
it will install the versions which were recorded in the imag
A comment 'ci/lib.sh' claims that the "OS X build installs the latest
available versions" of P4 and Git-LFS, but since 02373e56bd (ci: don't
update Homebrew, 2019-07-03) that's no longer the case, as it will
install the versions which were recorded in the image'
d (but not linked) and would be
perfectly usable in the Travis CI macOS image we use [1], it's at
version 8.2. However, when installing dependencies we first
explicitly run 'brew update', which spends over two minutes to update
itself and information about the available packages, an
! 2: c562cf681f docs: update git-clone doc: refer to long
options
@@ -1,13 +1,10 @@
-Author: Quentin Nerden
+Author: Quentin Nerden
-docs: update git-clone doc: refer to long options
+docs: git-clone: list short form of options first
-To m
Here is a second run at this RFC, which aims to create a "meta" config
setting that automatically turns on other settings according to a user's
willingness to trade new Git behavior or new feature risk for performance
benefits. The new name for the setting is "core.featureAdoptionRate" and is
an in
Hi,
On Thu, 27 Jun 2019, Junio C Hamano wrote:
> "Quentin Nerden via GitGitGadget" writes:
>
> > From: Quentin Nerden
> >
> > To make the doc of git-clone easier to read,
> > refer to the long version of the options
> > (it is easier to guess what --verbose is doing than -v).
> >
> > Also:
> >
`, make the ``
> - itself the `$GIT_DIR`. This obviously implies the `-n`
> + itself the `$GIT_DIR`. This obviously implies `--no-checkout`
> because there is nowhere to check out the working tree.
> Also the branch heads at the remote are copied directly
> to cor
ponding local branch heads, without mapping
@@ -164,13 +164,13 @@ objects from the source repository into a pack in the
cloned repository.
that all these refs are overwritten by a `git remote update` in the
target repository.
---origin ::
-o ::
+--origin ::
Instead of u
To make doc of git-clone easier to read, refer to the long version of the
options (it is easier to guess what --verbose is doing than -v).
Also: put the short options first, to match the doc of git-add, git-commit,
git-clean, git-branch...
Quentin Nerden (1):
docs: update git-clone doc: refer
From: Jeff Hostetler
It is quite common that MS Visual C++ is installed into a location whose
path contains spaces, therefore we need to quote it.
Signed-off-by: Jeff Hostetler
Signed-off-by: Johannes Schindelin
---
Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/
r wherever
you want).
Also, update the default locations of the system bash-completion,
including the default bash-completion location for user scripts, and the
recommended way to find the system location (with pkg-config)
Signed-off-by: Felipe Contreras
---
contrib/completion/git-completio
1 - 100 of 3805 matches
Mail list logo
