On Wed, Jul 3, 2019 at 11:49 AM Junio C Hamano wrote:
>
> Carlo, no need to rush, but has this happened already? I do not
> recall seeing an update, and I am wondering if I missed one.
Junio; had yet to send the update, so nothing was missed
Carlo
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 third batch of topics post 2.2
On Wed, Jul 03, 2019 at 11:37:52AM -0700, Junio C Hamano wrote:
> In the meantime, this is about patch 2/1; the underlying "when .keep
> is there, disable bitmaps" is probably good to go, still.
>
> -- >8 --
> From: Eric Wong
> Date: Sat, 29 Jun 2019 19:13:59 +
> Subject: [PATCH] repack: dis
On Wed, Jul 03, 2019 at 11:10:22AM -0700, Junio C Hamano wrote:
> > Or perhaps we could differentiate our temporary locks from "real" .keep
> > files by looking at the content; I think our locks always say something
> > like "(receive|receive)-pack \d+ on .*", and it wouldn't be too onerous
> > to
On Wed, Jul 03, 2019 at 09:41:46PM +0200, Johannes Schindelin wrote:
> Hi Emily,
>
> On Wed, 3 Jul 2019, Emily Shaffer wrote:
>
> > > > + up="$HTTPD_URL"/smart/atomic-branches.git &&
> > > > + test_commit atomic1 &&
> > > > + test_commit atomic2 &&
> > > > + git push "$up"
The main issue we work around here is that Windows does not have a UTF-8
"code page".
Side note: there is actually a code page for UTF-8: 65001 (see
https://docs.microsoft.com/en-us/windows/desktop/Intl/code-page-identifiers
). However, when experimenting with it, we ran into a multitude of issue
From: Karsten Blees
On native Windows, Git exclusively uses UTF-8 for console output (both
with MinTTY and native Win32 Console). Gettext uses `setlocale()` to
determine the output encoding for translated text, however, MSVCRT's
`setlocale()` does not support UTF-8. As a result, translated text i
Dear Git gurus,
A quick question on either such difference in behavior is intended or
ideally should be "fixed" by making it more consistent.
# prep demo usecase with a submodule sub/ containing a file 123
$> mkdir /tmp/testrepo; cd /tmp/testrepo; git init; touch 123; git add
12
Hi Emily,
On Wed, 3 Jul 2019, Emily Shaffer wrote:
> > > + up="$HTTPD_URL"/smart/atomic-branches.git &&
> > > + test_commit atomic1 &&
> > > + test_commit atomic2 &&
> > > + git push "$up" master &&
> >
> > It would be more succinct to do a `git clone --bare . "$d"` here, instead
> > of a `git in
On Wed, Jul 03, 2019 at 10:50:26AM -0700, Junio C Hamano wrote:
> Felipe Contreras writes:
>
> > Here's another try at completion fixes, cleanups, and more tests. Some
> > of these have already been sent.
> >
> > Felipe Contreras (14):
> > completion: zsh: fix __gitcomp_direct()
> > completio
Thanks for the explanation. So then to find out the current commit of
the submodule, I should cd into the submodule directory and say "git
rev-parse HEAD" or "git log -n1", etc.
Suggestion: for a moved HEAD, it would be nice to show "(detached from
now at )".
Thanks for considering, and thanks
> > > > +'
> > > +
> > > +test_expect_success 'push --atomic shows all failed refs' '
> > > + # Make up/master, up/allrefs
> > > + d=$HTTPD_DOCUMENT_ROOT_PATH/atomic-failed-refs.git &&
> > > + git init --bare "$d" &&
> > > + git --git-dir="$d" config http.receivepack true &&
> > > + up="$HTTPD_URL"
On Wed, Jul 03, 2019 at 11:13:45AM -0700, Junio C Hamano wrote:
> SZEDER Gábor writes:
>
> > On Tue, Jul 02, 2019 at 02:37:42PM -0700, Junio C Hamano wrote:
> >> > +test_expect_success 'push --atomic shows all failed refs' '
> >> > +# Make up/master, up/allrefs
> >> > +d=$HTTPD_DO
> > +test_expect_success 'push --atomic also prevents branch creation' '
> > + # Make up/master
> > + d=$HTTPD_DOCUMENT_ROOT_PATH/atomic-branches.git &&
> > + git init --bare "$d" &&
> > + git --git-dir="$d" config http.receivepack true &&
>
> Why not `-C "$d"`?
The example I had found bel
Jeff King writes:
> On Wed, Jun 19, 2019 at 02:12:30AM -0700, Carlo Arenas wrote:
>
>> > I did a quick grep for similar cases, and didn't find any that I think
>> > would be problematic. There were a few cleanups, below.
>>
>> would you mind if I add your 2 patches to a series and include that
>
Junio C Hamano writes:
> Jeff King writes:
>
>>
>> A much more robust solution would be to stop conflating user-provided
>> permanent .keep files with temporary locks. I think that was a mistaken
>> design added many years ago. We probably could introduce a different
>> filename for the temporar
Johannes Schindelin writes:
> Junio, please hold off from advancing `kb/windows-force-utf8` until this
> is resolved.
OK, will do.
Julius Smith writes:
> "git branch" in the the submodule directory says "(detached from
> )" but this seems to be wrong. I did "git diff
> " in the submodule directory to show that it was the C-commit
> and not the D-commit as it appeared. Could "git branch" in the
> submodule directory be refe
SZEDER Gábor writes:
> On Tue, Jul 02, 2019 at 02:37:42PM -0700, Junio C Hamano wrote:
>> > +test_expect_success 'push --atomic shows all failed refs' '
>> > + # Make up/master, up/allrefs
>> > + d=$HTTPD_DOCUMENT_ROOT_PATH/atomic-failed-refs.git &&
>> > + git init --bare "$d" &&
>> > + git -
Jeff King writes:
>
> A much more robust solution would be to stop conflating user-provided
> permanent .keep files with temporary locks. I think that was a mistaken
> design added many years ago. We probably could introduce a different
> filename for the temporary locks (though I am not entirely
Felipe Contreras writes:
> Here's another try at completion fixes, cleanups, and more tests. Some
> of these have already been sent.
>
> Felipe Contreras (14):
> completion: zsh: fix __gitcomp_direct()
> completion: zsh: fix for directories with spaces
> completion: remove zsh hack
> comp
On Fri, Jun 21, 2019 at 05:31:04PM -0500, Felipe Contreras wrote:
> There's a regression in the completion since the introduction of
> __gitcomp.
>
> Go to any directory that doesn't contain a git repository, like /tmp.
> Then type the following:
>
> git checkout --
>
> You will see nothing. T
On Mon, Jun 24, 2019 at 11:30:59AM +0200, Ævar Arnfjörð Bjarmason wrote:
> I can't think of some great solution for this case, some thoughts:
>
> a. Perhaps we should split the *.keep flag into two things or
> more.
>
> We're using it for all of "I want this *.pack forever"
> (e.g.
Felipe Contreras writes:
> +offgit ()
> +{
Style: opening brace comes on the same line, like
offgit () {
> + GIT_CEILING_DIRECTORIES="$ROOT" &&
> + export GIT_CEILING_DIRECTORIES &&
> + test_when_finished "ROOT='$ROOT'; cd '$TRASH_DIRECTORY'; unset
> GIT_CEILING_DIRECTORI
On Mon, Jul 01, 2019 at 11:15:38AM -0700, Junio C Hamano wrote:
> >> Maybe that's tricky with the gc.log functionality, but I think we should
> >> at least document this before the next guy shows up with "sometimes my
> >> .bitmap files aren't generated...".
> >
> > I'm not sure if the warning sho
Felipe Contreras writes:
> When appropriate.
It is unclear what makes these (but not other use of test_config)
appropriate.
>
> Signed-off-by: Felipe Contreras
> ---
> t/t9902-completion.sh | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/t/t9902-completion.
On Mon, Jun 24, 2019 at 08:11:40PM -0500, Felipe Contreras wrote:
> On Mon, Jun 24, 2019 at 12:24 PM Junio C Hamano wrote:
> >
> > Felipe Contreras writes:
> >
> > > In case the command fails.
> >
> > It is unclear what you wanted to say with this. What command?
> > After "git merge" fails?
>
>
SZEDER Gábor writes:
> On Wed, Jul 03, 2019 at 12:41:16PM -0400, Jeff King wrote:
>> On Wed, Jul 03, 2019 at 11:12:25AM +0200, SZEDER Gábor wrote:
>>
>> > On Mon, Jul 01, 2019 at 09:18:15AM -0400, Jeff King wrote:
>> > > diff --git a/t/t5618-alternate-refs.sh b/t/t5618-alternate-refs.sh
>> > > n
SZEDER Gábor writes:
> On Wed, Jul 03, 2019 at 02:26:21PM +0200, Thomas Braun wrote:
>> Am 03.07.2019 um 12:47 schrieb SZEDER Gábor:
>> > Lately Homebrew learned to automagically clean up information about
>> > outdated packages during other 'brew' commands, which might be useful
>> > for the ava
On Wed, Jul 03, 2019 at 12:41:16PM -0400, Jeff King wrote:
> On Wed, Jul 03, 2019 at 11:12:25AM +0200, SZEDER Gábor wrote:
>
> > On Mon, Jul 01, 2019 at 09:18:15AM -0400, Jeff King wrote:
> > > diff --git a/t/t5618-alternate-refs.sh b/t/t5618-alternate-refs.sh
> > > new file mode 100755
> > > inde
Jeff King writes:
> On Wed, Jul 03, 2019 at 11:12:25AM +0200, SZEDER Gábor wrote:
>
>> On Mon, Jul 01, 2019 at 09:18:15AM -0400, Jeff King wrote:
>> > diff --git a/t/t5618-alternate-refs.sh b/t/t5618-alternate-refs.sh
>> > new file mode 100755
>> > index 00..3353216f09
>> > --- /dev/null
On Wed, Jul 03, 2019 at 11:12:25AM +0200, SZEDER Gábor wrote:
> On Mon, Jul 01, 2019 at 09:18:15AM -0400, Jeff King wrote:
> > diff --git a/t/t5618-alternate-refs.sh b/t/t5618-alternate-refs.sh
> > new file mode 100755
> > index 00..3353216f09
> > --- /dev/null
> > +++ b/t/t5618-alternate-
On 02/07/2019 20:24, Theodore Ts'o wrote:
I think the real problem with all of this feature request is that it's
all presuming a particular workflow, and git is currently*not*
strongly opinionated about the workflow.
I'd suggest that git does have a clear preference for a workflow that is
based
On 7/3/2019 9:01 AM, Johannes Schindelin wrote:
> Team,
>
> I kept talking about this idea of a purely online Git Contributor Summit,
> and it is finally time for action.
Thanks for organizing this!
> To alleviate both of those points, we might want to consider spreading it
> out over a couple o
On Wed, Jul 03, 2019 at 02:26:21PM +0200, Thomas Braun wrote:
> Am 03.07.2019 um 12:47 schrieb SZEDER Gábor:
> > Lately Homebrew learned to automagically clean up information about
> > outdated packages during other 'brew' commands, which might be useful
> > for the avarage user, but is a waste of
Team,
I kept talking about this idea of a purely online Git Contributor Summit,
and it is finally time for action.
The idea: just like the Git Contributor Summits we have on the day before
GitMerge, but instead of traveling to the same place, we'll use an online
conferencing system.
>From my poi
Am 03.07.2019 um 12:47 schrieb SZEDER Gábor:
> Lately Homebrew learned to automagically clean up information about
> outdated packages during other 'brew' commands, which might be useful
> for the avarage user, but is a waste of time in CI build jobs, because
> the next build jobs will start from t
Hi,
On Wed, 3 Jul 2019, SZEDER Gábor wrote:
> Lately Homebrew learned to automagically clean up information about
> outdated packages during other 'brew' commands, which might be useful
> for the avarage user, but is a waste of time in CI build jobs, because
> the next build jobs will start from
Hi,
On Wed, 3 Jul 2019, Johannes Schindelin wrote:
> Hi,
>
> On Tue, 2 Jul 2019, Johannes Schindelin wrote:
>
> > [...] I probably failed to mention another breakage, though...:
> >
> > not ok 54 - LC_ALL='C' git grep -P -f f -i 'Æ[Ð]' a
> >
> > expecting success:
> > >stderr
Hi,
On Thu, 27 Jun 2019, Karsten Blees via GitGitGadget wrote:
> diff --git a/gettext.c b/gettext.c
> index d4021d690c..d8423e5c41 100644
> --- a/gettext.c
> +++ b/gettext.c
> @@ -12,7 +12,9 @@
> #ifndef NO_GETTEXT
> #include
> #include
> -#ifdef HAVE_LIBCHARSET_H
> +#ifdef G
Hi,
On Tue, 2 Jul 2019, Junio C Hamano wrote:
> Junio C Hamano writes:
>
> > * nd/index-dump-in-json (2019-06-26) 11 commits
> > - SQUASH???
> > - t3008: use the new SINGLE_CPU prereq
> > - read-cache.c: dump "IEOT" extension as json
> > - read-cache.c: dump "EOIE" extension as json
> > - r
Lately Homebrew learned to automagically clean up information about
outdated packages during other 'brew' commands, which might be useful
for the avarage user, but is a waste of time in CI build jobs, because
the next build jobs will start from the exact same image containing
the same outdated pack
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 "ci/install-dependencies.sh" failed and exited with 1 during .
Now, while gcc@8 is still pre-installed (but not link
Hi,
On Tue, 2 Jul 2019, Johannes Schindelin wrote:
> [...] I probably failed to mention another breakage, though...:
>
> not ok 54 - LC_ALL='C' git grep -P -f f -i 'Æ[Ð]' a
>
> expecting success:
> >stderr &&
> printf 'ÆQ[Ð]' | q_to_nul >f &&
>
Hi Junio,
On Tue, 2 Jul 2019, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > Please note that the problem is _not_ MinGW! The problem is that the
> > non-JIT'ted code path is a lot more stringent than the JIT'ted one. So
> > what you'd need is a prerequisite that tests whether the PCR
On Mon, Jul 01, 2019 at 09:18:15AM -0400, Jeff King wrote:
> diff --git a/t/t5618-alternate-refs.sh b/t/t5618-alternate-refs.sh
> new file mode 100755
> index 00..3353216f09
> --- /dev/null
> +++ b/t/t5618-alternate-refs.sh
> @@ -0,0 +1,60 @@
> +test_expect_success 'log --source shows .alt
On Tue, Jul 02, 2019 at 02:37:42PM -0700, Junio C Hamano wrote:
> > +test_expect_success 'push --atomic shows all failed refs' '
> > + # Make up/master, up/allrefs
> > + d=$HTTPD_DOCUMENT_ROOT_PATH/atomic-failed-refs.git &&
> > + git init --bare "$d" &&
> > + git --git-dir="$d" config http.
On Mon, Jun 24, 2019 at 08:02:21PM +0700, Nguyễn Thái Ngọc Duy wrote:
> diff --git a/t/t3011-ls-files-json.sh b/t/t3011-ls-files-json.sh
> index 082fe8e966..dbb572ce9d 100755
> --- a/t/t3011-ls-files-json.sh
> +++ b/t/t3011-ls-files-json.sh
> @@ -44,4 +44,18 @@ test_expect_success 'ls-files --json,
> diff --git a/t/t0066-dir-iterator.sh b/t/t0066-dir-iterator.sh
> index c739ed7911..8f996a31fa 100755
> --- a/t/t0066-dir-iterator.sh
> +++ b/t/t0066-dir-iterator.sh
> @@ -65,4 +65,99 @@ test_expect_success 'begin should fail upon non directory
> paths' '
> test_cmp expected-non-dir-output
I should add:
> git --version
git version 2.20.1 (Apple Git-117)
On Wed, Jul 3, 2019 at 1:28 AM Julius Smith wrote:
>
> Greetings,
>
> I have a repo with two branches A and B, say, and a submodule pointing
> to a repo also with two branches, say C and D. Branch A of the parent
> uses branch C of
Greetings,
I have a repo with two branches A and B, say, and a submodule pointing
to a repo also with two branches, say C and D. Branch A of the parent
uses branch C of the submodule, while B uses D. My clone is in a
state (that I've seen often) where branch A's submodule directory
_appears_ to
51 matches
Mail list logo
