On Sat, Jun 03, 2017 at 12:40:34PM +0200, René Scharfe wrote:
> There is no portable way to pass timezone information to strftime. Add
> parameters for timezone offset and name to strbuf_addftime and let it
> handle the timezone-related format specifiers %z and %Z internally.
> Callers can opt ou
On Wed, Jun 07, 2017 at 04:17:29AM -0400, Jeff King wrote:
> > Duplicates strbuf_expand to a certain extent, but not too badly, I
> > think. Leaves the door open for letting strftime handle the local
> > case.
>
> I guess you'd plan to do that like this in the caller:
>
> if (date->local)
>
On Mon, Jun 05, 2017 at 10:35:23AM -0700, Jonathan Tan wrote:
> > The rest of the pack code uses a varint encoding which is generally
> > much smaller than a uint64 for most files, but can handle arbitrary
> > sizes.
> >
> > The one thing it loses is that you wouldn't have a fixed-size record, so
Recently I've updated a bunch of stuff, including git and gpg. I'm using
- mac OS 10.10.5
- git 2.13.1
- gpg (GnuPG) 2.1.21 / libgcrypt 1.7.7
When I do
$ git commit --allow-empty -v -m "lol"
error: gpg failed to sign the data
fatal: failed to write commit object
I tried the verbose flag hoping
On Fri, Jun 02, 2017 at 04:25:08PM -0700, Jonathan Nieder wrote:
> > We have a name-hash cache extension in the bitmap file, but it doesn't
> > carry enough information to deduce the .git-ness of a file. I don't
> > think it would be too hard to add a "flags" extension, and give a single
> > bit t
On Mon, Jun 05, 2017 at 10:55:42AM +0900, Junio C Hamano wrote:
> I do not expect any single person to tackle the splitting. I just
> wished that a patch inspired by this patch (or better yet, a new
> version of this patch) made the tail end of "make test" output to
> read like this:
>
>...
On Wed, Jun 07, 2017 at 10:46:08AM +0100, pedro rijo wrote:
> Recently I've updated a bunch of stuff, including git and gpg. I'm using
>
> - mac OS 10.10.5
> - git 2.13.1
> - gpg (GnuPG) 2.1.21 / libgcrypt 1.7.7
>
> When I do
>
> $ git commit --allow-empty -v -m "lol"
> error: gpg failed to sign
From: Junio C Hamano
Signed-off-by: Junio C Hamano
Signed-off-by: Kevin Daudt
---
Documentation/RelNotes/2.14.0.txt | 55 +++
1 file changed, 55 insertions(+)
diff --git a/Documentation/RelNotes/2.14.0.txt
b/Documentation/RelNotes/2.14.0.txt
index ee6c6075
On Wed, Jun 07, 2017 at 12:33:41PM +0200, Kevin Daudt wrote:
> From: Junio C Hamano
>
sorry for the noise, please ignore this.
Thanks for the hint!
$ GIT_TRACE=1 git commit --allow-empty -v -m "lol"
11:37:24.594795 git.c:369 trace: built-in: git 'commit'
'--allow-empty' '-v' '-m' 'lol'
11:37:24.605842 run-command.c:369 trace: run_command: 'gpg'
'--status-fd=2' '-bsau' '8AEC0DB537A9FC7E'
error: gpg fail
Hi Johannes
Thanks for your feedback
On 01/06/17 13:56, Johannes Schindelin wrote:
> Hi Phillip,
>
> On Wed, 31 May 2017, Phillip Wood wrote:
>
>> From: Phillip Wood
>>
>> Check the console output when using --autostash and the stash applies
>> cleanly is what we expect. To avoid this test depe
£1.5 Million Has Been Granted To You As A Donation Visit
www.bbc.co.uk/news/uk-england-19254228 Sendname Address Phone for more info
Where this email is unrelated to the business of University of the Arts London
the opinions expressed in it are the opinions of the sender and do not
necessarily c
On Tue, Jun 6, 2017 at 8:37 PM, Jeff King wrote:
>> To put your worries to rest we should eliminate remote->fetch_refspec
>> altogether and parse refspecs into remote->fetch right away, I'd
>> think. After all, that's what's used in most places anyway, and it
>> can be easily turned back to a si
On Wednesday 07 June 2017 03:35 AM, Philip Oakley wrote:
Maybe have a try at a patch to update the text? See the
git/Documentation/SubmittingPatches for guidance.
I guess this should be trivial (correct me if I'm wrong). I'll try when
I find time. In case I make the change which of the following
Hi,
On Tue, 6 Jun 2017, Konstantin Podsvirov wrote:
> 06.06.2017, 21:25, "Stefan Beller" :
> > On Tue, Jun 6, 2017 at 10:34 AM, Konstantin Podsvirov
> > wrote:
> >> Reproduction:
> >> - Start git gui
> >> - Go to menu panel: Help > About Git Gui
> >>
> >> Output:
> >> error: git-gui died of
Hi Stefan,
On Tue, 6 Jun 2017, Stefan Beller wrote:
> On Tue, Jun 6, 2017 at 3:22 PM, Johannes Schindelin
> wrote:
>
> > 3) the only person who could make that call is Junio
>
> Occasionally I think the same, but in fact it is not true.
Again my poor English skillz make sure I get misunderstoo
Hi,
On Mon, 5 Jun 2017, Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason writes:
>
> > On Fri, Jun 2, 2017 at 6:10 PM, Johannes Schindelin
> >>
> >> Will continue with testing Git for Windows using PCRE2 next week and keep
> >> you posted,
> >
> > Thanks a lot for testing it. Great to hear that
Git has this feature where suggests similar commands (including aliases)
in case that the user specified an unknown command.
This feature currently relies on a side effect of the way we expand
aliases right now: when a command is not a builtin, we use the regular
config machinery (meaning: discove
When expanding an alias in a subdirectory, we setup the git_dir
(gently), read the config, and then restore the "env" (e.g. the current
working directory) so that the command specified by the alias can run
correctly.
What we failed to reset was the git_dir, meaning that in the most common
case, it
When discovering a .git/ directory, we take pains to ensure that its
repository format version matches Git's expectations, and we return NULL
otherwise.
However, we still appended the invalid path to the strbuf passed as
argument.
Let's just reset the strbuf to the state before we appended the .g
When an alias expands to a shell command, and when we are inside a
regular worktree's subdirectory (i.e. not inside the .git/ directory nor
in a worktree initialized via `git worktree add`), and only then, the
current working directory is switched to the top-level directory of the
worktree before r
So far, when we invoked the early config code path, we implicitly
determined the top-level directory of the worktree while discovering the
.git/ directory.
And then we simply forgot that information.
However, when we expand aliases, we very much need that information, as
aliases expanding to shel
When expanding aliases, the git_dir is set during the alias expansion
(by virtue of running setup_git_directory_gently()).
This git_dir may be relative to the current working directory, and
indeed often is simply ".git/".
When the alias expands to a shell command, we restore the original
working
When get_value() parses a key/value pair, it is possible that the line
number is decreased (because the \n has been consumed already) before the
key/value pair is passed to the callback function, to allow for the
correct line to be attributed in case of an error.
However, when git_parse_source() a
We already taught alias_lookup() to use the early config if the .git/
directory was not yet discovered, of course, however, since we called
setup_git_directory_gently() before expanding the alias (if any), we
only used the early config code path only if outside of any Git-managed
directory.
With t
We are about to change the way aliases are expanded, to use the early
config machinery.
This machinery reports errors in a slightly different manner than the
cached config machinery.
Let's not get hung up by the precise wording of the message mentioning
the lin number. It is really sufficient to
Hi,
On Wed, 7 Jun 2017, Johannes Schindelin wrote:
> Johannes Schindelin (9):
> discover_git_directory(): avoid setting invalid git_dir
> config: report correct line number upon error
> help: use early config when autocorrecting aliases
> read_early_config(): optionally return the worktre
On Wed, Jun 7, 2017 at 5:50 PM, Johannes Schindelin
wrote:
> Hi,
>
> On Mon, 5 Jun 2017, Junio C Hamano wrote:
>
>> Ævar Arnfjörð Bjarmason writes:
>>
>> > On Fri, Jun 2, 2017 at 6:10 PM, Johannes Schindelin
>> >>
>> >> Will continue with testing Git for Windows using PCRE2 next week and keep
>>
On Wed, Jun 7, 2017 at 7:47 AM, Johannes Schindelin
wrote:
> Hi Stefan,
>
> On Tue, 6 Jun 2017, Stefan Beller wrote:
>
>> On Tue, Jun 6, 2017 at 3:22 PM, Johannes Schindelin
>> wrote:
>>
>> > 3) the only person who could make that call is Junio
>>
>> Occasionally I think the same, but in fact it
--
Good Day,
My wife and I have awarded you with a donation of $ 1,000,000.00 Dollars from
part of our Jackpot Lottery of 50 Million Dollars, respond with your details
for claims.
We await your earliest response and God Bless you.
Friedrich And Annand Mayrhofer.
On Tue, Jun 6, 2017 at 10:47 PM, Liam Breck wrote:
>
> This is configured to send via a gmail account
> git send-email --to-cover --cc-cover
>
> I See
> Attempt to reload IO/Socket/SSL.pm aborted.
> Compilation failed in require at
> /usr/share/perl5/vendor_perl/Net/SMTP/SSL.pm line 6.
> BEGIN fa
On Wed, Jun 7, 2017 at 7:00 PM, Liam Breck wrote:
> On Tue, Jun 6, 2017 at 10:47 PM, Liam Breck wrote:
>>
>> This is configured to send via a gmail account
>> git send-email --to-cover --cc-cover
>>
>> I See
>> Attempt to reload IO/Socket/SSL.pm aborted.
>> Compilation failed in require at
>> /u
On 06/06, Stefan Beller wrote:
> Use modern style in the test t4005. Remove hard coded sha1 values.
> Combine test prep work and the actual test. Rename the first
> test to contain the word "setup".
>
> Signed-off-by: Stefan Beller
> ---
>
> Junio wrote:
> > If it helps, I _can_ make any set of
On 06/07, Johannes Schindelin wrote:
> When discovering a .git/ directory, we take pains to ensure that its
> repository format version matches Git's expectations, and we return NULL
> otherwise.
>
> However, we still appended the invalid path to the strbuf passed as
> argument.
>
> Let's just re
On 06/07, Johannes Schindelin wrote:
> Git has this feature where suggests similar commands (including aliases)
nit: s/where/which/
> in case that the user specified an unknown command.
s/that//
>
> This feature currently relies on a side effect of the way we expand
> aliases right now: when a
Thanks for your help!
On Wed, Jun 7, 2017 at 10:16 AM, Ævar Arnfjörð Bjarmason
wrote:
> On Wed, Jun 7, 2017 at 7:00 PM, Liam Breck wrote:
>> On Tue, Jun 6, 2017 at 10:47 PM, Liam Breck wrote:
>>>
>>> This is configured to send via a gmail account
>>> git send-email --to-cover --cc-cover
>>>
>>
On 06/07, Johannes Schindelin wrote:
> So far, when we invoked the early config code path, we implicitly
> determined the top-level directory of the worktree while discovering the
> .git/ directory.
>
> And then we simply forgot that information.
>
> However, when we expand aliases, we very much
On 06/07, Johannes Schindelin wrote:
> We are about to change the way aliases are expanded, to use the early
> config machinery.
>
> This machinery reports errors in a slightly different manner than the
> cached config machinery.
Not a comment on the patch but just a genuine question: Is there an
On 06/07, Johannes Schindelin wrote:
> We already taught alias_lookup() to use the early config if the .git/
> directory was not yet discovered, of course, however, since we called
> setup_git_directory_gently() before expanding the alias (if any), we
> only used the early config code path only if
On Tue, Jun 6, 2017 at 3:05 PM, Jacob Keller wrote:
> On Tue, Jun 6, 2017 at 2:50 AM, Michael Haggerty wrote:
>> On Mon, Jun 5, 2017 at 8:23 PM, Stefan Beller wrote:
>>>
>>> > [...]
>>> > "git diff" has been taught to optionally paint new lines that are
>>> > the same as deleted lines elsewher
On 06/07, Johannes Schindelin wrote:
> When expanding an alias in a subdirectory, we setup the git_dir
> (gently), read the config, and then restore the "env" (e.g. the current
> working directory) so that the command specified by the alias can run
> correctly.
>
> What we failed to reset was the
Add the missing documentation for `git svn init --ignore-refs`.
Signed-off-by: Andreas Heiduk
---
Documentation/git-svn.txt | 16
1 file changed, 16 insertions(+)
diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
index 9bee9b0c4..fba0b4eec 100644
--- a/Document
This patch aims to detangle (a) the usage of `git-submodule`
from (b) the concept of submodules and (c) how the actual
implementation looks like, such as where they are configured
and (d) what the best practices are.
To do so, move the conceptual parts of the 'git-submodule'
man page to a new man
On Wed, Jun 7, 2017 at 8:04 PM, Liam Breck wrote:
> Thanks for your help!
>
> On Wed, Jun 7, 2017 at 10:16 AM, Ævar Arnfjörð Bjarmason
> wrote:
>> On Wed, Jun 7, 2017 at 7:00 PM, Liam Breck wrote:
>>> On Tue, Jun 6, 2017 at 10:47 PM, Liam Breck wrote:
This is configured to send via a
On Wed, Jun 7, 2017 at 12:30 PM, Ævar Arnfjörð Bjarmason
wrote:
> On Wed, Jun 7, 2017 at 8:04 PM, Liam Breck wrote:
>> Thanks for your help!
>>
>> On Wed, Jun 7, 2017 at 10:16 AM, Ævar Arnfjörð Bjarmason
>> wrote:
>>> On Wed, Jun 7, 2017 at 7:00 PM, Liam Breck wrote:
On Tue, Jun 6, 2017 at
On 6/2/2017 7:06 PM, Ævar Arnfjörð Bjarmason wrote:
I don't have time to update the perf test now or dig into it, but most
of what you're describing in this mail doesn't at all match with the
ad-hoc tests I ran in
https://public-inbox.org/git/CACBZZX5e58bWuf3NdDYTxu2KyZj29hHONzN=rp-7vxd8nur...
> $ GIT_TRACE=1 git commit --allow-empty -v -m "lol"
> 11:37:24.594795 git.c:369 trace: built-in: git 'commit'
> '--allow-empty' '-v' '-m' 'lol'
> 11:37:24.605842 run-command.c:369 trace: run_command: 'gpg'
> '--status-fd=2' '-bsau' '8AEC0DB537A9FC7E'
> error: gpg failed to sign
On Wed, Jun 7, 2017 at 9:39 PM, Liam Breck wrote:
> On Wed, Jun 7, 2017 at 12:30 PM, Ævar Arnfjörð Bjarmason
> wrote:
>> On Wed, Jun 7, 2017 at 8:04 PM, Liam Breck wrote:
>>> Thanks for your help!
>>>
>>> On Wed, Jun 7, 2017 at 10:16 AM, Ævar Arnfjörð Bjarmason
>>> wrote:
On Wed, Jun 7, 20
Dear all.
The git-2.13.1.* files are missing in
https://www.kernel.org/pub/software/scm/git/sha256sums.asc
All the best,
--
Andrés
La información contenida en este correo electrónico está dirigida únicamente a
su destinatario y puede contener información confidencial, material
privilegiado
On Wed, Jun 7, 2017 at 1:43 PM, Ævar Arnfjörð Bjarmason
wrote:
> On Wed, Jun 7, 2017 at 9:39 PM, Liam Breck wrote:
>> On Wed, Jun 7, 2017 at 12:30 PM, Ævar Arnfjörð Bjarmason
>> wrote:
>>> On Wed, Jun 7, 2017 at 8:04 PM, Liam Breck wrote:
Thanks for your help!
On Wed, Jun 7, 2017
On Thu, Jun 1, 2017 at 5:51 PM, Ben Peart wrote:
> +if [ $1 -eq 1 ]
Tiny nit: Needs quoting:
$ .git/hooks/query-fsmonitor
.git/hooks/query-fsmonitor: 15: [: -eq: unexpected operator
On Wed, Jun 7, 2017 at 9:51 PM, Ben Peart wrote:
>
>
> On 6/2/2017 7:06 PM, Ævar Arnfjörð Bjarmason wrote:
>>
>>
>> I don't have time to update the perf test now or dig into it, but most
>> of what you're describing in this mail doesn't at all match with the
>> ad-hoc tests I ran in
>>
>> https://
On Wed, Jun 7, 2017 at 8:28 PM, Stefan Beller wrote:
> On Tue, Jun 6, 2017 at 3:05 PM, Jacob Keller wrote:
>> On Tue, Jun 6, 2017 at 2:50 AM, Michael Haggerty
>> wrote:
>>> On Mon, Jun 5, 2017 at 8:23 PM, Stefan Beller wrote:
> [...]
> "git diff" has been taught to optionally p
On Wed, Jun 7, 2017 at 2:58 PM, Ævar Arnfjörð Bjarmason
wrote:
> On Wed, Jun 7, 2017 at 8:28 PM, Stefan Beller wrote:
>> On Tue, Jun 6, 2017 at 3:05 PM, Jacob Keller wrote:
>>> On Tue, Jun 6, 2017 at 2:50 AM, Michael Haggerty
>>> wrote:
On Mon, Jun 5, 2017 at 8:23 PM, Stefan Beller wrote
From: "Kaartic Sivaraam"
On Wednesday 07 June 2017 03:35 AM, Philip Oakley wrote:
Maybe have a try at a patch to update the text? See the
git/Documentation/SubmittingPatches for guidance.
I guess this should be trivial (correct me if I'm wrong). I'll try when I
find time. In case I make the ch
I sometimes forget about something that I stashed. It would be nice if
the git status command would just say "There are x entries in the
stash." It can say nothing if there is nothing stashed so it is
usually not adding clutter.
Andreas Heiduk wrote:
> Add the missing documentation for `git svn init --ignore-refs`.
>
> Signed-off-by: Andreas Heiduk
Thanks, signed-off and pushed for Junio:
The following changes since commit 8d1b10321b20bd2a73a5b561cfc3cf2e8051b70b:
Sync with maint (2017-06-07 09:32:04 +0900)
On Wed, Jun 7, 2017 at 4:43 PM, Ævar Arnfjörð Bjarmason
wrote:
> Ah, so you installed Net::SSLeay via CPAN, and then upgraded your Arch
> openssl, breaking the CPAN-built *.so object?
>
>> Agreed that send-email should be report errors properly. It's a rather
>> essential tool.
>
> Indeed, do you
On Wed, Jun 7, 2017 at 5:06 PM, Samuel Lijin wrote:
> On Wed, Jun 7, 2017 at 4:43 PM, Ævar Arnfjörð Bjarmason
> wrote:
>> Ah, so you installed Net::SSLeay via CPAN, and then upgraded your Arch
>> openssl, breaking the CPAN-built *.so object?
>>
>>> Agreed that send-email should be report errors p
I've rewritten git stash as a builtin c command. All tests pass,
and I've added two new tests. Test coverage is around 95% with the
only things missing coverage being error handlers.
Changes since v3:
* Fixed formatting issues
* Fixed a bug with stash branch and added a new test for it
* Fixed
Implement all git stash functionality as a builtin command
Signed-off-by: Joel Teichroeb
---
Makefile |2 +-
builtin.h |1 +
builtin/stash.c | 1224 +
git-stash.
Ensure the command gives the correct return code
Signed-off-by: Joel Teichroeb
---
t/t3903-stash.sh | 8
1 file changed, 8 insertions(+)
diff --git a/t/t3903-stash.sh b/t/t3903-stash.sh
index 3b4bed5c9a..cc923e6335 100755
--- a/t/t3903-stash.sh
+++ b/t/t3903-stash.sh
@@ -444,6 +444,14
If the merge does not have anything to do, it does not unlock the index,
causing any further index operations to fail. Thus, always unlock the index
regardless of outcome.
Signed-off-by: Joel Teichroeb
---
merge-recursive.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --g
If the return value of merge recurisve is not checked, the stash could end
up being dropped even though it was not applied properly
Signed-off-by: Joel Teichroeb
---
t/t3903-stash.sh | 14 ++
1 file changed, 14 insertions(+)
diff --git a/t/t3903-stash.sh b/t/t3903-stash.sh
index cc9
Signed-off-by: Joel Teichroeb
---
t/t3903-stash.sh | 12
1 file changed, 12 insertions(+)
diff --git a/t/t3903-stash.sh b/t/t3903-stash.sh
index 5399fb05ca..ce4c8fe3d6 100755
--- a/t/t3903-stash.sh
+++ b/t/t3903-stash.sh
@@ -822,6 +822,18 @@ test_expect_success 'create with multiple
On 07/06/17 11:24, Jeff King wrote:
> On Mon, Jun 05, 2017 at 10:55:42AM +0900, Junio C Hamano wrote:
>
> If you use "prove", it already records this information, and it can
> print it with "--timer".
Yes I have
DEFAULT_TEST_TARGET=prove
GIT_PROVE_OPTS='--timer'
in my config.mak and r
On Wed, Jun 7, 2017 at 8:26 PM, Liam Breck wrote:
> On Wed, Jun 7, 2017 at 5:06 PM, Samuel Lijin wrote:
>> On Wed, Jun 7, 2017 at 4:43 PM, Ævar Arnfjörð Bjarmason
>> wrote:
>>> Ah, so you installed Net::SSLeay via CPAN, and then upgraded your Arch
>>> openssl, breaking the CPAN-built *.so object
On 6/7/2017 5:46 PM, Ævar Arnfjörð Bjarmason wrote:
On Wed, Jun 7, 2017 at 9:51 PM, Ben Peart wrote:
On 6/2/2017 7:06 PM, Ævar Arnfjörð Bjarmason wrote:
I don't have time to update the perf test now or dig into it, but most
of what you're describing in this mail doesn't at all match with
On Mon, Jun 5, 2017 at 11:52 PM, Jacob Keller wrote:
>
> I will try to find some time tomorrow to go over it in detail.
>
> Thanks,
> Jake
For the record, I got pulled into a project at work, so I won't have
spare time to look into this for the near future. :( Probably not
until next week.
Thank
In 618e613a70, 10 years ago, the default for pack depth used for
git-pack-objects and git-repack was changed from 10 to 50, while
leaving fast-import's default to 10.
There doesn't seem to be a reason besides oversight for the change not
having happened in fast-import as well.
Interestingly, fast
On Thu, Jun 8, 2017 at 3:32 AM, Samuel Lijin wrote:
> On Wed, Jun 7, 2017 at 8:26 PM, Liam Breck wrote:
>> On Wed, Jun 7, 2017 at 5:06 PM, Samuel Lijin wrote:
>>> On Wed, Jun 7, 2017 at 4:43 PM, Ævar Arnfjörð Bjarmason
>>> wrote:
Ah, so you installed Net::SSLeay via CPAN, and then upgraded
On Thu, Jun 8, 2017 at 2:06 AM, Samuel Lijin wrote:
> On Wed, Jun 7, 2017 at 4:43 PM, Ævar Arnfjörð Bjarmason
> wrote:
>> Ah, so you installed Net::SSLeay via CPAN, and then upgraded your Arch
>> openssl, breaking the CPAN-built *.so object?
>>
>>> Agreed that send-email should be report errors p
73 matches
Mail list logo
